# Cisco SD-WAN Data Plane: — TLOCs, Colors, IPsec Tunnels & BFD Source: https://ai.techclick.in/blog_cisco_sdwan_data_plane_tlocs Markdown: https://ai.techclick.in/blog_cisco_sdwan_data_plane_tlocs.md Publisher: Techclick Infosec Pvt Ltd Cisco SD-WAN data plane explained: TLOC = system-IP + colour + encap, public vs private colours and the restrict keyword, IPsec tunnels without IKE (OMP-distributed keys), and BFD feeding App-Aware Routing. For ENSDWI 300-415. Cisco SD-WAN Data Plane: — TLOCs, Colors, IPsec Tunnels & BFD student learning map A visual study map for Cisco SD-WAN Data Plane: — TLOCs, Colors, IPsec Tunnels & BFD showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Cisco SD-WAN Data Plane: — TLOCs, Colors, IPsec... Cisco SD-WAN · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① TLOC anatomy — the address a... 4. Practice ② Colours — who is allowed to call... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most engineers think the SD-WAN data plane is "just IPsec tunnels, same as DMVPN — IKE negotiates keys, the routing table picks the path, done." Wrong on two counts. There is no IKE — each WAN Edge generates its own IPsec key and the controller distributes it over OMP, so a controller you trust replaces a peer negotiation you don't. And the path isn't picked by a static metric: BFD inside every tunnel measures loss, latency and jitter, and App-Aware Routing reroutes live traffic off a link that is technically "up" but quietly broken. Miss those two and you'll mis-diagnose every brownout. ## ① TLOC anatomy — the address a remote edge dials Every overlay tunnel in Cisco SD-WAN has to start somewhere, and that somewhere is a TLOC (Transport Locator). Think of it as the data-plane phone number of a transport on a WAN Edge router. A site with two transports — MPLS and Internet — has two TLOCs, one per transport, and a remote edge dials one of them to bring up a tunnel. A TLOC is a 3-tuple , and all three parts matter: the system-IP (which edge), the colour (which transport), and the encapsulation (ipsec or gre). Change any one and it's a different TLOC. The system-IP is just an identity, like a BGP router-ID — it does not have to be reachable or routable anywhere. 👉 So far: a TLOC = system-IP + colour + encap, one per transport. Next: how that TLOC gets advertised so a remote edge even knows it exists. TLOCs travel over OMP . Each edge advertises its TLOC up to the SD-WAN Controller (vSmart) over the encrypted control connection, and the controller reflects it to every other edge. The advertisement carries far more than an IP: the colour, the encapsulation, the private and public IP/port , and the IPsec keys . The TLOC is the OMP next-hop for an overlay route — the SD-WAN answer to BGP's NEXT_HOP attribute. Figure 1 — TLOC anatomy and OMP advertisement A WAN Edge router with two transports, MPLS and Internet, each forming a TLOC. Each TLOC is a triplet of system IP, colour, and encapsulation. The TLOCs are advertised to the SD-WAN Controller (vSmart) over an OMP control connection, and the controller redistributes them so a remote edge can build an IPsec tunnel directly to the TLOC. - TLOC = system-IP + colour + encap — the address a remote edge dials WAN Edge — Branch system-IP 10.0.0.11 mpls · ipsec biz-internet · ipsec two transports → two TLOCs SD-WAN Controller (vSmart) — OMP reflector TLOCs advertised over OMP/DTLS OMP carries, per TLOC: system-IP · colour · encap · private + public IP/port · IPsec keys (next-hop = TLOC) analogous to BGP next-hop — but it is colour + IP + encap, not just an IP WAN Edge — DC system-IP 10.0.0.99 learns the branch TLOCs, then dials a direct IPsec tunnel to each data-plane IPsec tunnel — built edge-to-edge, not via the controller underlay / untrusted overlay / trusted control / policy key idea SLA met / up Left: one WAN Edge, two transports, two TLOCs. Follow the amber dashed lines up to the controller (OMP advertises each TLOC) then the green curve — the actual data tunnel is built edge-to-edge, NOT through the controller. The dabbawala analogy from Mumbai fits perfectly. A dabbawala doesn't memorise every flat in the city; each tiffin carries a coded tag — area, building, floor. The system-IP is the building , the colour is which route the runner takes (local train vs cycle), and the encap is the box it's wrapped in . The central sorting desk (the controller) hands every runner the same tag-list, but the runner then walks the last leg himself — exactly how a WAN Edge learns TLOCs from the controller but builds the tunnel directly to the peer. cEdge CLI · show sdwan omp tlocs (see what's advertised) Branch-Mumbai# show sdwan omp tlocs | tab Expected output ADDRESS PUBLIC PRIVATE FAMILY TLOC IP COLOR ENCAP FROM PEER IP / PORT IP / PORT STATUS ----------------------------------------------------------------------------------------------- ipv4 10.0.0.11 mpls ipsec 10.0.0.99 192.168.10.2 192.168.10.2 C,I,R ipv4 10.0.0.11 biz-internet ipsec 10.0.0.99 203.0.113.11 172.16.10.2 C,I,R ipv4 10.0.0.99 biz-internet ipsec 10.0.0.99 203.0.113.99 172.16.99.2 C,I,R ### The four words you'll say every day Tap each card — these are the anchors for the whole lesson. 🆔 System-IP tap to flip The unique name of the WAN Edge across the fabric. Like a BGP router-ID — identity only, never needs to be routable. 🎨 Colour tap to flip An abstract transport label (mpls, biz-internet, lte). It also gates which TLOCs may build tunnels. Not cosmetic — it's policy. 📦 Encapsulation tap to flip How the tunnel is wrapped: ipsec (default) or gre. Both ends must agree, or no tunnel. 📞 TLOC = the phone number tap to flip system-IP + colour + encap together. OMP advertises it as the data-plane next-hop. So: a remote edge dials the TLOC, not just an IP. Quick check · Q1 of 10 Sneha at Infosys changes a branch transport's colour from 'mpls' to 'private1' but keeps the same interface and IP. Does the rest of the fabric see the same TLOC? a) Yes — same system-IP and IP, so it's the same TLOC b) No — colour is part of the TLOC triplet, so it's now a different TLOC c) Only if the encapsulation also changed d) Only the controller notices; edges don't Correct: b. A TLOC is uniquely the 3-tuple system-IP + colour + encapsulation. Change the colour and it is a brand-new TLOC, re-advertised over OMP — old tunnels tear down and new ones must form. Same IP doesn't matter; the colour is part of the identity. Pause & Predict Predict: a WAN Edge has THREE transports — MPLS, broadband, and LTE — all with encap ipsec. How many TLOCs does it advertise, and why does that number matter for the mesh? Type your guess. Reveal answer Answer: Three TLOCs — one per transport (system-IP is the same, but the colour differs each time, so each is a distinct TLOC). It matters because every remote edge can build a tunnel to each of the three, giving three independent overlay paths per remote site. More transports = more TLOCs = more redundant paths for App-Aware Routing to choose from. ## ② Colours — who is allowed to call whom Colour is the single most misunderstood word in SD-WAN. It looks like a label you can name anything, and you can — but the colour you pick decides whether a tunnel is even allowed to form , and which IP address the edge uses to reach the peer. There are two families: public colours and private colours . A public colour — biz-internet , public-internet , lte , default , the metallic set ( gold , silver , bronze ) and custom1-3 — uses the post-NAT public IP that STUN via the Validator (vBond) discovered, and it can build a tunnel to any colour. A private colour — mpls , metro-ethernet , private1 … private6 — uses the pre-NAT private IP and only builds a tunnel to the same private colour. The logic: public colours expect a NAT in the path; private colours assume a clean transport (an MPLS core) with no NAT between sites. Figure 2 — Public vs private colours — who may build a tunnel A comparison of public versus private TLOC colours. Public colours such as biz-internet and public-internet use the post-NAT public IP and can build tunnels to any other colour. Private colours such as mpls and metro-ethernet use the pre-NAT private IP and only build tunnels to the same colour, and break when a NAT sits in the path. A worked example shows a branch private mpls colour failing to reach a DC private mpls colour across a NAT. Which TLOCs are allowed to build a tunnel? PUBLIC colour (post-NAT IP) default · biz-internet · public-internet · lte · 3g blue · bronze · gold · silver · red · green · custom1-3 + talks to ANY colour + uses the public IP STUN learned + survives NAT (public ↔ anything) use these when an ISP/NAT is in the path PRIVATE colour (pre-NAT IP) mpls · metro-ethernet · private1 … private6 − only talks to the SAME private colour − uses the private (pre-NAT) IP − a NAT in the path breaks the tunnel made for a clean MPLS core with no NAT Classic "tunnels won't form" bug — colour mismatch Branch: colour mpls (private) pre-NAT 192.168.10.2 DC: colour biz-internet public 203.0.113.9 ✗ no tunnel: private mpls ≠ public biz-internet Fix: make both sides a public colour (biz-internet ↔ biz-internet), or mark mpls as a matching private colour with NAT-free path underlay / untrusted overlay / trusted control / policy key idea SLA met / up Left card = public colours (post-NAT IP, talk to anyone). Right card = private colours (pre-NAT IP, same colour only). Bottom = the classic mismatch: a private mpls TLOC will never tunnel to a public biz-internet TLOC. There's a second lever beyond the colour family: the restrict keyword and the carrier attribute. Add restrict to a tunnel and that TLOC will only form tunnels to remote TLOCs with the same colour — even a normally-promiscuous public colour gets locked down. Engineers use restrict on biz-internet to stop the broadband transport from wastefully meshing with an MPLS-coloured TLOC, keeping like-with-like. vManage → Configuration → Templates → Feature → Cisco VPN Interface Ethernet → Tunnel . Real field labels. (Recreated for clarity — your console matches this.)"> 🖥️ This is the screen where colour, restrict and carrier live — vManage → Configuration → Templates → Feature → Cisco VPN Interface Ethernet → Tunnel . Real field labels. (Recreated for clarity — your console matches this.) vmanage.lab.local · Configuration · Templates · Feature · VPN Interface · Tunnel 1 Tunnel Interface On 2 Color biz-internet 3 Restrict On (same-colour only) Carrier carrier1 Max Control Connections 2 4 Allow Service — BFD On Update → Configure Device Rahul at TCS faces this Rahul brings up a new branch. Control connections to the controllers are green, OMP routes are present, but the branch can't reach any other site — every data-plane tunnel to peers is missing. The interface and routing look healthy. Likely cause Colour mismatch across a NAT. The branch's broadband interface was left on the private colour 'mpls', but it sits behind an ISP NAT and the DC side is the public colour 'biz-internet'. A private colour uses the pre-NAT IP and only meets the same private colour — so no tunnel can form to a public-coloured peer behind NAT. Diagnosis He checks the data plane, not the control plane: BFD sessions are the tell. The TLOC table shows the local colour, and BFD shows zero sessions to the peer despite a healthy control plane. vManage → Monitor → Devices → (branch) → Real Time → BFD Sessions, and CLI: show sdwan bfd sessions Fix Re-colour the broadband transport to a public colour (biz-internet) on both ends so it uses the STUN-learned public IP and can mesh across the NAT. Reserve 'mpls'/private colours for the genuine NAT-free MPLS core. Verify show sdwan bfd sessions now lists 'up' sessions on biz-internet to each peer; a ping across the overlay from VPN 10 succeeds, and vManage → Monitor shows the tunnels green. cEdge CLI · prove the colour and tunnel state Branch-Pune# show sdwan control local-properties | i color|tloc Branch-Pune# show sdwan bfd sessions | tab Expected output tloc-color biz-internet ... SOURCE DST PUBLIC SYSTEM IP SITE STATE COLOR COLOR IP ENCAP UPTIME 10.0.0.99 100 up biz-internet biz-internet 203.0.113.99 ipsec 0:02:14:51 10.0.0.50 200 up biz-internet biz-internet 203.0.113.50 ipsec 0:02:14:48 Quick check · Q2 of 10 Priya at ICICI has a DC TLOC on colour 'public-internet' and a branch TLOC on colour 'lte', both public, both behind their own NAT. Will the data tunnel form? a) No — the colours are different b) Only if she adds the restrict keyword c) Only if one side uses a private colour d) Yes — both are public colours, and a public colour builds to ANY colour using the post-NAT IP Correct: d. Public colours use the public (post-NAT) IP and can build tunnels to any colour — including a different public colour. Different colours are only fatal when a private colour is involved (private talks only to the same private colour). 'restrict' would actually PREVENT this cross-colour tunnel, not enable it. Pause & Predict Predict: a branch behind a symmetric NAT on a private 'mpls' colour can't tunnel to the DC. You'd love to keep calling it 'mpls'. Name two clean fixes. Type your guess. Reveal answer Answer: One: change the colour to a public colour (biz-internet) on both ends so it uses the STUN-learned public IP and tolerates the NAT — private colours simply don't survive a NAT. Two: if it truly is a private MPLS core, fix the path so there is NO NAT between the sites (private colours need the pre-NAT IP to be the reachable IP). A symmetric NAT is the worst case — at minimum the DC/hub side should hold a public IP or a full-cone (1-to-1) NAT so one side can always initiate inbound. ## ③ IPsec without IKE — OMP hands out the keys Here's the part that surprises everyone coming from DMVPN or classic site-to-site VPN: SD-WAN builds IPsec with no IKE . There is no phase-1, no phase-2, no DH negotiation between the two routers. Instead each WAN Edge generates its own inbound IPsec key , advertises it to the controller over the trusted OMP/DTLS control connection, and the controller re-advertises that key to every other edge. The peers never negotiate directly — a controller you already trust replaces a handshake you'd otherwise have to secure. By default the overlay forms a full mesh — every TLOC builds an IPsec (or GRE) tunnel to every compatible remote TLOC — though a control policy or a hub-and-spoke topology can prune that. Keys aren't forever: they rekey on a timer , default 86400 seconds (24 hours) , configurable from 10 seconds up to 1209600 seconds (14 days). One subtle rule the exam loves: the IPsec rekey timer must be at least 2× the OMP graceful-restart timer , because the controller distributes the keys — if a controller blip happens to land inside a rekey, traffic drops. Figure 3 — IPsec without IKE — key distribution over OMP Each WAN Edge generates its own outbound IPsec key, advertises it to the SD-WAN Controller over the encrypted OMP control connection, and the controller reflects the keys to every other edge. Data-plane IPsec tunnels then form in a full mesh with no IKE negotiation. Keys are rekeyed on a timer, default 86400 seconds. No IKE: OMP distributes the keys, tunnels form in a full mesh Edge A generates its own inbound IPsec key no IKE phase 1/2 Edge B generates its own inbound IPsec key no IKE phase 1/2 SD-WAN Controller reflects keys via OMP A's key (OMP/DTLS) B's key (OMP/DTLS) controller re-advertises each key to the other edge data-plane IPsec tunnel — encrypted with the OMP-shared keys Rekey on a timer (default 86400 s / 24 h, range 10 s – 14 days) IPsec rekey must be ≥ 2× the OMP graceful-restart timer, or a controller blip drops traffic underlay / untrusted overlay / trusted control / policy key idea SLA met / up Each edge makes its own key (amber lines up to the controller), the controller reflects it to the far edge (blue/green dashed), then the green tunnel forms. No IKE between the two edges — the trusted control plane carries the keys. Aadhaar OTP onboarding is the everyday analogy. You don't swap a secret face-to-face with the bank clerk; a trusted central authority (UIDAI) issues a one-time code over a channel you both already trust, and you present it. SD-WAN does the same — the trusted controller distributes the per-edge keys over the already-encrypted OMP path, so two edges that have never spoken can bring up an encrypted tunnel instantly. The key even expires and is reissued, exactly like an OTP rotating. ### ▶ Watch a tunnel come up with zero IKE Step through how two edges that never negotiate still get an encrypted IPsec tunnel. Press Play for the healthy path, then Break it to see the failure. ① Generate Edge-A creates its own inbound IPsec key locally — no IKE peer negotiation ▼ ② Advertise Edge-A sends the key to the Controller over the trusted OMP / DTLS control connection ▼ ③ Reflect Controller re-advertises Edge-A's key to Edge-B (and B's key back to A) ▼ ④ Tunnel up Edge-A ⇄ Edge-B IPsec tunnel forms; rekeys every 86400 s Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset When two routers sit at the same site and only one of them owns a given transport, TLOC-extension lets the second router borrow the first's transport over a dedicated link — so both get a TLOC on that colour for redundancy. A related knob, the tunnel group , overrides colour entirely: give two TLOCs the same group-ID and they'll tunnel to each other regardless of colour. These are the transport-sharing tools the 300-415 blueprint expects you to recognise. Common mistake — GRE encap and NAT don't mix Symptom: you switch a tunnel to encap gre to save overhead, and tunnels behind NAT silently stop forming. Cause: GRE encapsulation only supports public IP addressing or one-to-one (full-cone) NAT — it has no UDP wrapper to ride a port-translating NAT the way IPsec/UDP does. Fix: keep encap ipsec on any transport that traverses a NAT; reserve gre for clean public or 1-to-1 paths. Quick check · Q3 of 10 Aditya at Flipkart reads that SD-WAN uses IPsec but sees no crypto ikev2 proposal anywhere in the config. Why are the tunnels still encrypting? a) The tunnels are actually unencrypted b) IKE config is hidden in vManage and applied silently c) SD-WAN skips IKE — each edge generates its key and OMP distributes it over the control plane d) GRE is doing the encryption Correct: c. SD-WAN deliberately removes IKE. Each WAN Edge generates its own IPsec key and advertises it to the controller over OMP/DTLS; the controller reflects keys to peers. So tunnels are genuinely encrypted with no IKE proposal in sight. GRE provides no encryption, and nothing is hidden — the trust model simply moved to the control plane. Pause & Predict Predict: an engineer sets the IPsec rekey timer to 30 seconds 'for extra security'. Beyond CPU churn, what real risk did they just create? Type your guess. Reveal answer Answer: They likely dropped below 2× the OMP graceful-restart timer. Because the controller distributes the keys, a controller reconnection or graceful-restart window that overlaps a 30-second rekey means the new key can't be handed out in time — and that tunnel loses traffic during the gap. The rule of thumb: IPsec rekey ≥ 2× OMP graceful-restart. Aggressive rekey buys little and risks black-holing traffic on every control-plane hiccup. ## ④ BFD — the sensor inside every tunnel Once a tunnel is up, BFD runs inside it automatically — you don't enable it per neighbour the way you would for OSPF/BGP. BFD has two jobs. First, liveness : it sends a hello every 1000 ms by default, and if 7 in a row go missing (the default multiplier) it declares the tunnel down — roughly a 7-second blackout detection. Second, and this is the one people forget, it measures the path quality : loss, latency and jitter on every probe. That measurement is what feeds App-Aware Routing (AAR) . The edge accumulates BFD's loss/latency/jitter over a poll-interval (default 10 minutes), and AAR reviews 6 of those windows (the default multiplier) — a 1-hour rolling SLA view — to decide whether a tunnel still meets the policy for voice, video or business apps. This is why BFD is a data-plane topic that quietly drives routing decisions. cEdge CLI · the command you'll run on the SOC floor DC-Edge# show sdwan bfd sessions Expected output SOURCE REMOTE DST PUBLIC DETECT TX SYSTEM IP SITE STATE COLOR COLOR SOURCE IP IP MULT INT UPTIME 10.0.0.11 100 up mpls mpls 192.168.10.2 192.168.99.2 7 1000 0:11:03:18 10.0.0.11 100 up biz-internet biz-internet 172.16.10.2 203.0.113.11 7 1000 0:11:03:13 10.0.0.50 200 up biz-internet biz-internet 172.16.50.2 203.0.113.50 7 1000 0:09:41:02 vManage → Monitor → Devices → (DC-Edge) → Real Time , then set the device-options search to BFD Sessions . This is the per-tunnel health table you'll stare at on the NOC floor. (Recreated for clarity — your console matches this.)"> 🖥️ Same data, GUI side — vManage → Monitor → Devices → (DC-Edge) → Real Time , then set the device-options search to BFD Sessions . This is the per-tunnel health table you'll stare at on the NOC floor. (Recreated for clarity — your console matches this.) vmanage.lab.local · Monitor · Devices · DC-Edge · Real Time 1 Device Options (search) BFD Sessions 2 System IP / Site ID 10.0.0.11 / 100 3 State up 4 Local · Remote Color mpls · mpls 5 Detect Multiplier · Tx Interval 7 · 1000 ms Encap · Uptime ipsec · 0:11:03:18 Refresh Now the scenario the whole lesson builds to — the brownout . A link doesn't always fail cleanly. An MPLS circuit can stay line-protocol UP while quietly dropping 4% of packets — a ping looks fine, the interface counter barely moves, but a voice call turns robotic. The interface can't see it; BFD can , because it's measuring loss and jitter on the live path. When BFD's numbers breach the voice SLA, AAR hops the call onto the healthy Internet tunnel and the user never notices — then returns it automatically when MPLS recovers. ### ▶ A brownout the interface never sees Follow a voice call as the MPLS link degrades but stays 'up'. Press Play for the healthy path, then Break it to see the failure. ① Healthy voice rides mpls tunnel ; BFD: loss 0.1% lat 22ms jit 5ms — SLA met ▼ ② Degrade MPLS circuit browns out: loss 4%, jitter 38ms — but interface still UP ▼ ③ Detect BFD inside the tunnel measures the breach; AAR sees loss/jitter over the poll window ▼ ④ Reroute AAR moves voice to biz-internet tunnel (SLA met); auto-returns when MPLS heals Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Figure 4 — Brownout before/after + BFD cheat-sheet A before-and-after of a brownout. The MPLS interface line protocol stays up, but BFD running inside the tunnel measures loss, latency and jitter and sees the SLA breach. App-Aware Routing then moves the voice call off the lossy MPLS tunnel onto the healthy Internet tunnel. A cheat-sheet card lists the key show command, default BFD hello 1000ms, multiplier 7, poll-interval 10 minutes, and app-route multiplier 6. Brownout: link says "up", BFD says "lossy" — AAR moves the call BEFORE — voice rides lossy MPLS interface Tunnel-mpls: line protocol UP but BFD inside it: loss 4% · jitter 38ms SLA voice (loss≤1%, lat≤150, jit≤30) BREACHED a ping/interface check would call this link "fine" → choppy, robotic call for the user AFTER — AAR reroutes to Internet BFD on biz-internet tunnel: loss 0.1% · jit 8ms SLA met → app-aware policy hops voice here show sdwan app-route stats — verifies move MPLS tunnel stays UP, just unused for voice traffic auto-returns when MPLS recovers BFD = the early-warning sensor App-Aware Routing listens to BFD & App-Route cheat-sheet show sdwan bfd sessions per-tunnel STATE · COLOR · DETECT MULT · TX INT BFD hello = 1000 ms (default) multiplier = 7 → dead after ~7 s of silence app-route poll-interval = 10 min multiplier = 6 → 1-hour rolling SLA window show sdwan app-route stats live loss / latency / jitter feeding AAR underlay / untrusted overlay / trusted control / policy key idea SLA met / up Your one-card map: the brownout (interface lies, BFD tells the truth, AAR reroutes) on top, and the show commands + default timers (hello 1000ms, mult 7, poll 10min, app-route mult 6) on the bottom. Keep it open before any SD-WAN interview. Common mistake — control up, BFD empty Symptom: control connections to the controllers are green and OMP routes are present, but show sdwan bfd sessions is EMPTY and no site can reach another. Cause: it's a data-plane problem, not control — usually a colour/NAT mismatch (section ②) or a firewall blocking the BFD/IPsec data port (UDP, the 124xx range) between edges while leaving the control port open. Fix: confirm matching colours, allow the data-plane UDP ports edge-to-edge, and re-check show sdwan bfd sessions. Pro tip — the two-question mental model For any SD-WAN data-plane task ask: (1) are the right TLOCs even allowed to tunnel? — check colour family (public vs private), NAT, and restrict. (2) is the path actually healthy? — read BFD state (show sdwan bfd sessions) for up/down, and app-route stats for loss/latency/jitter. Almost every 'site can't reach site' or 'app is choppy' ticket lands on one of those two. Prove you've got the data-plane model Take a real ask — 'voice from the Bengaluru branch to the Mumbai DC keeps going robotic, but the MPLS link shows up' — and answer cold: the TLOC triplet that built the tunnel, why the interface lies (line-protocol UP), what actually sees it (BFD loss/jitter), what reroutes it (AAR off the SLA), and the two commands you'd run (show sdwan bfd sessions, show sdwan app-route stats). If you can do that, you're ready for ENSDWI 300-415 and the NOC floor. Back: OMP — how TLOCs get advertised Next: Segmentation & VPNs Quick check · Q4 of 10 Meera at Airtel insists 'the MPLS link is fine — line protocol is up and ping works,' yet voice keeps degrading. Which command settles it? a) show sdwan bfd sessions / show sdwan app-route stats — read the per-tunnel loss/latency/jitter b) show ip interface brief c) show running-config | i ip route d) show sdwan control connections Correct: a. Line-protocol-up and ping can't see a brownout; BFD inside the tunnel measures loss/latency/jitter, and show sdwan app-route stats exposes exactly what AAR is acting on. The interface brief and route table show reachability, not quality, and control connections are about the control plane, not the degraded data tunnel. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Why isn't a TLOC just an IP address? What actually decides if two TLOCs can build a tunnel? Why do my tunnels fail across a NAT even though colours look right? How can it be IPsec with no IKE? What does the rekey-timer ≥ 2× rule protect against? Why does BFD matter for routing, not just up/down? Pre-curated from Cisco SD-WAN docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember A TLOC in Cisco SD-WAN is uniquely identified by which three values? a) Hostname, site-ID, region-ID b) MAC address, VLAN, encapsulation c) System-IP, colour, encapsulation d) Public IP, private IP, port Correct: c. A TLOC is the 3-tuple system-IP + colour + encapsulation, advertised by OMP as the data-plane next-hop. Hostname/site/region are organisational, not the TLOC identity; MAC/VLAN are L2; and the public/private IPs are attributes carried with the TLOC, not its identity. Q6 · Apply A branch broadband transport sits behind an ISP NAT and must mesh with a DC also on the public Internet. Which colour do you assign so the tunnel forms across the NAT? a) A public colour like biz-internet (uses the STUN-learned post-NAT IP) b) The private colour mpls (uses the pre-NAT IP) c) private1, to keep it isolated d) metro-ethernet, because it's Ethernet Correct: a. Public colours use the post-NAT public IP that STUN/Validator discovered, so they tolerate a NAT and build to any colour. Private colours (mpls, private1, metro-ethernet) use the pre-NAT IP and only meet the same private colour — they break across a NAT, which is exactly what you must avoid here. Q7 · Apply You want a branch's biz-internet TLOC to build tunnels ONLY to other biz-internet TLOCs, never to an MPLS-coloured peer. Which knob do you set? a) Change encap to gre b) Lower the BFD multiplier c) Set the rekey timer to 30 seconds d) Add the restrict keyword on the tunnel interface Correct: d. restrict forces a TLOC to tunnel only to remote TLOCs of the same colour, even for an otherwise-promiscuous public colour. Encap, BFD multiplier and rekey timer don't gate which colours may peer — restrict is the precise tool for same-colour-only meshing. Q8 · Analyze Control connections to the controllers are up, OMP routes are present, but 'show sdwan bfd sessions' is empty and no site can reach another. Most likely root cause? a) The OMP graceful-restart timer expired b) A data-plane problem — colour/NAT mismatch or a firewall blocking the BFD/IPsec data port between edges c) The system-IP isn't routable d) The vManage certificate expired Correct: b. Healthy control plane + empty BFD = a data-plane issue: most often a colour/NAT mismatch (private colour across a NAT, or incompatible colours) or a firewall passing the control port but blocking the data-plane UDP (124xx) ports edge-to-edge. OMP/cert/graceful-restart issues would also break the control plane, which here is fine; the system-IP never needs to be routable. Q9 · Analyze A voice call from a branch keeps turning robotic, yet the MPLS interface shows line-protocol UP and ping succeeds. What is happening and what reacts to it? a) A brownout — BFD measures the loss/jitter inside the tunnel and App-Aware Routing reroutes the call to a healthy tunnel b) Routing loop; OSPF reconverges c) The IPsec key expired; IKE renegotiates d) The system-IP changed; OMP rewithdraws Correct: a. Line-protocol-up and ping can't detect a brownout (loss/jitter on a still-up link). BFD running inside the tunnel measures loss/latency/jitter, and AAR reroutes traffic off the SLA-breaching tunnel. There's no IKE in SD-WAN, no routing loop is implied, and the system-IP is unchanged. Q10 · Evaluate Two ways to secure the overlay: (A) configure IKEv2 with pre-shared keys between every edge pair; (B) the native SD-WAN model — each edge generates its key, OMP distributes it, timer rekeys. For a 400-site full mesh, which is sounder and why? a) A — IKE is the industry standard and easier to audit b) A — pre-shared keys are simpler at scale c) Identical — pick by licence cost d) B — no per-pair negotiation to scale or maintain; the trusted control plane distributes keys and a timer rekeys, so 400 sites mesh without N² IKE handshakes Correct: d. The native model removes IKE entirely: each edge owns its key, the controller reflects keys to all peers, and a timer rekeys — so a 400-site mesh needs no N-squared per-pair IKE negotiation or PSK sprawl to maintain. Option A's per-pair IKEv2/PSK approach is exactly the scaling and operational burden SD-WAN was built to eliminate. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: In one line, why can an MPLS link be 'up' yet still ruin a voice call — and what catches it? Then compare to the expert version. Compare with expert answer Expert version: Because line-protocol-up only means the circuit is alive, not that it's clean — a brownout can drop 4% of packets while staying up; BFD inside the tunnel measures the loss/latency/jitter, and App-Aware Routing reroutes the call off the SLA-breaching tunnel. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on TLOCs & Tunnels at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary TLOC (Transport Locator) The data-plane endpoint of a transport on a WAN Edge — the triplet system-IP + colour + encapsulation that a remote edge dials. System-IP Unique identity of a WAN Edge across the fabric, like a BGP router-ID; does not need to be routable. Colour Abstract transport label (mpls, biz-internet, lte) that also gates which TLOCs may build tunnels to which. Public colour default, biz-internet, public-internet, lte, 3g, blue, bronze, gold, silver, red, green, custom1-3 — uses the post-NAT public IP, builds tunnels to any colour. Private colour mpls, metro-ethernet, private1-private6 — uses the pre-NAT private IP, builds tunnels only to the same private colour; breaks across a NAT. restrict / carrier restrict forces a TLOC to tunnel only to the same colour (even public); carrier adds a service-provider label to pin same-carrier paths. OMP Overlay Management Protocol — BGP-like control protocol that advertises TLOCs (and routes) between WAN Edges and the controller. Encapsulation How the tunnel is wrapped: ipsec (default) or gre; GRE supports only public IP or 1-to-1 NAT, no port-translating NAT. IPsec without IKE Each edge generates its own key; the controller distributes keys over OMP. Rekey default 86400 s, range 10 s – 14 days; rekey must be ≥ 2× OMP graceful-restart. BFD Bidirectional Forwarding Detection — runs in every data-plane tunnel; default hello 1000 ms, multiplier 7; measures loss/latency/jitter, not just liveness. App-Aware Routing (AAR) Uses BFD's loss/latency/jitter over the poll-interval (default 10 min) × multiplier (default 6) to reroute traffic off any tunnel that breaches the SLA. Brownout A link that stays 'up' (line-protocol UP) while silently dropping packets — invisible to interface counters, caught by BFD. #### 📚 Sources Cisco Catalyst SD-WAN Systems and Interfaces Configuration Guide, IOS XE 17.x — "TLOC" (3-tuple system-IP + colour + encap; public vs private colours; restrict; carrier). cisco.com/c/en/us/td/docs/routers/sdwan/17-x/systems-interfaces/systems-interfaces-guide-17-x/tloc.html - Cisco Catalyst SD-WAN Security Configuration Guide, IOS XE 17.x — "Configure Security Parameters" (IPsec without IKE; key generated by edge, distributed via OMP; rekey default 86400 s, range 10 s–1209600 s; rekey ≥ 2× OMP graceful-restart). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/security/ios-xe-17/security-book-xe/configure-security-param.html - Cisco support doc — "Understand BFD Protocol Relationship with App-Aware Routing" (BFD in every tunnel; hello 1000 ms, multiplier 7; loss/latency/jitter feed AAR; poll-interval 10 min, app-route multiplier 6; black-out vs brown-out). cisco.com/c/en/us/support/docs/routers/sd-wan/221604-understand-bfd-protocol-relationship-wit.html - Cisco Community — "Cisco SD-WAN: Control Connections (DTLS) are up, but BFDs are down" (real colour-mismatch / data-plane-port troubleshooting thread). community.cisco.com/t5/sd-wan-and-cloud-networking/cisco-sd-wan-control-connections-dtls-are-up-but-bfds-are-down/td-p/4980024 - Network Journey — "Ticket#16 SD-WAN VPN 0 Down: Color Mismatch Between Transport Interfaces (CCNP Enterprise)" — practitioner walkthrough of the classic 'tunnels won't form' colour bug. networkjourney.com/ticket16-sd-wan-vpn-0-down-color-mismatch-between-transport-interfaces-ccnp-enterprise/ - Cisco Live BRKTRS-3241 (2025) — "7 ways to fail with Cisco Catalyst SD-WAN" — recent field gotchas incl. colour/NAT and rekey pitfalls. ciscolive.com/c/dam/r/ciscolive/emea/docs/2025/pdf/BRKTRS-3241.pdf - Cisco ENSDWI 300-415 exam blueprint — Section 2.0 Controller and Edge Deployment / data-plane: TLOCs, colours, BFD, App-Aware Routing. learningnetwork.cisco.com (300-415 ENSDWI exam topics) ### What's next? You can read the data plane now — TLOCs, colours, tunnels and BFD. Next we slice that single fabric into many: how VPNs/VRFs keep guest, corp and PCI traffic apart end-to-end without separate hardware. Next · Segmentation & VPNs in Cisco SD-WAN → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt