# Cisco SD-WAN (Viptela) Fundamentals: — Why SD-WAN, the 4 Planes & the Overlay Source: https://ai.techclick.in/blog_cisco_sdwan_fundamentals Markdown: https://ai.techclick.in/blog_cisco_sdwan_fundamentals.md Publisher: Techclick Infosec Pvt Ltd Cisco SD-WAN (Viptela) fundamentals for L1/L2 engineers and ENSDWI 300-415: why SD-WAN beats traditional MPLS WAN, the 4 planes (Validator, Manager, Controller, WAN Edge), and overlay vs underlay. Cisco SD-WAN (Viptela) Fundamentals: — Why SD-WAN, the 4 Planes & the Overlay student learning map A visual study map for Cisco SD-WAN (Viptela) Fundamentals: — Why SD-WAN, the 4 Planes & the Overlay showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Cisco SD-WAN (Viptela) Fundamentals: — Why SD-WAN,... 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 ① Why SD-WAN exists — the pain of... 4. Practice ② The Viptela story & the 4 planes 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 first hear "SD-WAN" and think it's just "replace MPLS with cheap internet and add a fancy dashboard." So they picture one box, one link, one GUI. Wrong — and that picture will sink you in interviews and on the job. SD-WAN's actual move is separating four planes (a Validator that onboards, a Manager that configures, a Controller that decides routes via OMP , and WAN Edges that just forward) and building a transport-independent encrypted overlay on top of whatever links you have — MPLS, broadband and LTE all active at once. The dashboard is the easy part; the plane separation is the whole idea. ## ① Why SD-WAN exists — the pain of the traditional WAN Picture Rahul, an L1 engineer at Infosys , looking after 40 branch offices. Every branch hangs off a single MPLS circuit from a telco. When the Pune branch wants a second site added, the carrier quotes a 3-month lead time and a per-Mbps price that makes the finance team wince. Meanwhile the 4G backup link sits idle 99% of the time, paid for and doing nothing. That is the first pain: MPLS is costly and slow to provision, and your backup is dead weight. Pain two is backhaul . In the old design every branch's internet and SaaS traffic is dragged back to the HQ data centre, inspected, then sent out — and the reply hairpins all the way back. So a Zoom call from the Lucknow branch to a colleague in the same city can travel Lucknow → Mumbai DC → internet → back, adding lag for no reason. Users feel it; the helpdesk hears about it. Pain three is complexity . The old way to get site-to-site tunnels over the internet was DMVPN , later dressed up as iWAN . Both are configured router-by-router on the CLI, with crypto maps, routing protocols and path control glued together by hand. Make one typo across 40 routers and you are debugging at 2 a.m. There is no single place to push a change. Pain four is the quiet killer: no application awareness . Traditional routing forwards by destination prefix only. It has no idea that one flow is a voice call that hates packet loss and another is a backup that just needs throughput. So your voice call can ride a brown-out MPLS link while a healthy broadband link sits unused. 👉 So far: four pains — cost & lead time, backhaul, box-by-box complexity, and no app awareness. Next: what SD-WAN actually changes about all four. Here is the shift. SD-WAN builds a transport-independent encrypted overlay that rides on every link you have at once, and you manage the whole estate from one central screen. Cheap broadband and LTE become active paths, not cold spares. Branches break out to the internet locally ( DIA ) instead of backhauling. And the path is picked per application , so voice always gets the cleanest link. Figure 1 — Traditional WAN vs Cisco SD-WAN A two-column comparison. Left, traditional WAN: a branch has a single MPLS link, all internet traffic is backhauled to the HQ data centre and hairpins back, DMVPN or iWAN tunnels are configured box by box with no application awareness. Right, Cisco SD-WAN: the branch uses MPLS plus broadband plus LTE at once, an encrypted overlay rides on top of any transport, central policy is pushed from the Manager, and the path is chosen per application. Red marks the costly or blind old path; green marks the SD-WAN improvements. Traditional WAN vs Cisco SD-WAN — same branch, two worlds Traditional WAN (MPLS + backhaul) ✗ one MPLS circuit — months to provision ✗ ₹/Mbps high; second link idle (backup only) ✗ all internet hairpins via HQ data centre ✗ DMVPN / iWAN built box-by-box, by hand ✗ no app awareness — voice rides the lossy link branch HQ / DC hairpin - Zoom call → HQ → back out → laggy Cisco SD-WAN (transport-independent overlay) ✓ MPLS + broadband + LTE/5G all active ✓ broadband in days; cheap ₹/Mbps ✓ Direct Internet Access — local breakout ✓ central policy pushed from the Manager ✓ app-aware routing (AAR) picks best path branch SaaS / peer site Zoom breaks out locally → crisp; data overlay direct Same hardware budget, very different experience for the user on the floor Read both columns for the same branch. Left (red) = one slow MPLS link, hairpinned internet, hand-built tunnels, no app awareness. Right (green) = every transport active, local breakout, central policy, app-aware paths. ### The four pains, in one tap each Tap each card — these are the problems every SD-WAN sales deck and every interview question starts from. 💸 Cost & lead time tap to flip MPLS is dear and takes months to turn up; the backup link sits idle. So: you pay twice and use once. 🔁 Backhaul hairpin tap to flip Branch internet drags back to HQ and out again. So: extra latency on every SaaS and Zoom call for no reason. 🧶 Box-by-box config tap to flip DMVPN/iWAN tunnels built per router on the CLI. So: one typo across 40 sites and you're up at 2 a.m. 🙈 No app awareness tap to flip Routing only sees destination prefixes, not 'this is voice'. So: a call can ride a lossy link while a good one is idle. Daily-life analogy — the dabbawala vs the single courier Traditional MPLS is hiring one premium courier and forcing every tiffin through the head office first. SD-WAN is the Mumbai dabbawala network: many ordinary trains and bikes (MPLS, broadband, LTE) all in use at once, a colour-coded routing system on top, and a central plan that re-routes instantly if one train is late. Same lunch, delivered cheaper and faster — because the routing logic sits above the transport. Quick check · Q1 of 10 Sneha at TCS says: "We pay for an MPLS line AND a 4G backup, but the 4G is only used when MPLS dies." Which SD-WAN change directly fixes the wasted backup? a) An active/active transport-independent overlay so both links carry traffic at once b) Backhauling all traffic through HQ for inspection c) Replacing both links with a single bigger MPLS circuit d) Turning off the 4G link to save money Correct: a. SD-WAN's overlay is transport-independent and runs both links active/active, so the 4G stops being idle dead weight. Backhauling adds latency (the opposite of the goal); one bigger MPLS line is more cost, not less; turning the link off wastes the resilience you paid for. Pause & Predict Predict: if every branch breaks out to the internet locally (DIA) instead of backhauling to HQ, name ONE thing that gets better and ONE new thing you now have to worry about. Type your guess. Reveal answer Answer: Better: latency drops and the HQ internet pipe stops being a bottleneck — a Zoom call or SaaS app goes straight out the local link. New worry: security inspection now has to happen at the branch (or in the cloud), because traffic no longer passes the central firewall stack at HQ. That is exactly why SD-WAN and cloud security (SASE) grew up together. ## ② The Viptela story & the 4 planes A bit of history so the names make sense. Viptela was a startup Cisco bought in 2017 for about $610 million . Its software became Cisco SD-WAN , and from 2023 the whole thing was rebranded Cisco Catalyst SD-WAN . The components got new names too — but the field, the CLI and the exam still use the old ones every single day, so you learn both . The mapping you must know cold: vManage → Manager , vSmart → Controller , vBond → Validator , and the branch routers vEdge / cEdge → WAN Edge . The split inside the box names is worth noting: a vEdge runs the original Viptela OS, while a cEdge is a Cisco IOS-XE router (ISR/ASR/Catalyst 8000) running SD-WAN code — same fabric, two router families. 👉 So far: Viptela (2017) → Cisco SD-WAN → Catalyst SD-WAN, and the five names. Next: snap each name onto its plane. Now the heart of it — the four planes . Cisco split the WAN into four jobs that used to be jammed into every router, and gave each job its own device. This separation is what makes central management and app-aware routing possible at scale. Orchestration plane — the SD-WAN Validator (vBond). It is the bouncer at the door: it authenticates every device trying to join, checks the certificate and organisation name , and introduces the new edge to the Manager and Controllers. It also helps devices behind NAT find each other. Nothing joins the fabric without passing the Validator first. Management plane — the SD-WAN Manager (vManage). This is the single GUI where you configure, template and monitor the entire overlay. When you build a feature template or read a device's health, you are on the Manager. Control plane — the SD-WAN Controller (vSmart). This is the brain. It runs OMP to distribute routes, tunnel endpoints and policy to every edge — but it never carries user data. Data plane — the WAN Edge (vEdge/cEdge). These are the routers at each site that build the IPsec tunnels and actually forward packets. Figure 2 — The 4-plane fabric at a glance The Cisco Catalyst SD-WAN fabric drawn as four planes. The orchestration plane is the SD-WAN Validator (vBond) which authenticates and introduces devices. The management plane is the SD-WAN Manager (vManage) GUI for config and monitoring. The control plane is the SD-WAN Controller (vSmart) running OMP to distribute routes and policy over DTLS or TLS. The data plane is the WAN Edge routers (vEdge or cEdge) that build IPsec tunnels edge to edge over any transport. Dashed orange lines are DTLS control connections to the controllers; solid blue pipes are encrypted IPsec overlay tunnels between edges. The 4 planes — separated on purpose SD-WAN Validator vBond · orchestration authenticate + introduce SD-WAN Manager vManage · management config + monitor (GUI) SD-WAN Controller vSmart · control OMP routes + policy controllers on-prem or cloud — dashed = DTLS control connection (no user data) — WAN Edge — Mumbai cEdge (IOS-XE) · data plane MPLS Internet 2 transports = 2 TLOCs WAN Edge — Pune cEdge (IOS-XE) · data plane MPLS LTE/5G 2 transports = 2 TLOCs IPsec overlay tunnel (edge ↔ edge, no controller in the path) controllers decide; edges forward — separated underlay / untrusted overlay / trusted control / policy key insight allowed / SLA-met Look for the split: dashed orange lines are DTLS control connections from each edge up to the controllers; the solid blue pipe is the IPsec overlay tunnel directly between the two WAN Edges — the controllers are not in that data path. vManage → Monitor → Devices → (pick the device) → Real Time , command Control Connections . (Recreated for clarity — your console matches this.)"> 🖥️ This is where you confirm a controller is up — vManage → Monitor → Devices → (pick the device) → Real Time , command Control Connections . (Recreated for clarity — your console matches this.) vmanage.lab.local · Monitor → Devices → Real Time 1 Device BR-Mumbai-cEdge-01 (10.10.1.1) 2 Real Time command Control Connections 3 Peer Type vsmart / vbond / vmanage Protocol dtls Local Color mpls / biz-internet 4 State up Search cEdge CLI — confirm the edge reached all three controller types BR-Mumbai-cEdge-01# show sdwan control connections Expected output PEER PEER PEER SITE DOMAIN PEER PEER LOCAL STATE UPTIME TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT COLOR vbond dtls 10.0.0.3 0 0 203.0.113.3 12346 mpls up 0:01:22:14 vmanage dtls 10.0.0.1 1 0 10.0.0.1 12446 mpls up 0:01:21:58 vsmart dtls 10.0.0.2 1 1 10.0.0.2 12546 mpls up 0:01:21:55 Common mistake — "control connections down to vSmart, up to vBond" Symptom: show sdwan control connections shows the edge reached the Validator (vBond) but the line to the Controller (vSmart) is missing or flapping, often with code DCONFAIL . Cause is almost always a firewall dropping the DTLS port-hop range or ESP. Fix: allow UDP 12346 (it hops to 12366/12386/12406/12426) and ESP (IP protocol 50) outbound, or enable IPsec-over-UDP if the firewall eats ESP. A CTORGNMMIS code instead means the organisation name doesn't match across the fabric. Quick check · Q2 of 10 Aditya's brand-new cEdge at a Wipro branch can't join the fabric. Which device must it successfully reach FIRST, and what does that device do? a) vManage — it pushes the running config before anything else b) vSmart — it sends OMP routes so the edge can route c) vBond (Validator) — it authenticates the edge and points it to the Manager and Controllers d) Another WAN Edge — peers onboard each other directly Correct: c. The Validator (vBond) is the orchestration plane: it authenticates the device and introduces it to the Manager and Controllers. Config (vManage) and OMP routes (vSmart) only come after the Validator has let the edge in. WAN Edges never onboard each other — that would break the control/data separation. Pause & Predict Predict: the vSmart Controller distributes every route and policy in the fabric. So what happens to user data forwarding if all the vSmarts are briefly unreachable but the IPsec tunnels are already up? Type your guess. Reveal answer Answer: Existing data-plane tunnels keep forwarding. The Controller's job is to compute and distribute routes/policy (the control plane); it is not in the packet path. So already-established edge-to-edge IPsec tunnels keep carrying traffic. What you lose is the ability to learn NEW routes or push NEW policy until a Controller returns — which is exactly why you deploy controllers redundantly. ## ③ Overlay vs underlay — why the split is the whole trick Two words decide whether SD-WAN clicks for you: underlay and overlay . The underlay is whatever transport you happen to have — an MPLS circuit, a broadband line, an LTE/5G modem. The overlay is the set of encrypted IPsec tunnels SD-WAN builds on top of that. The overlay does not care what the underlay is — that is what "transport-independent" means, and it's the single most useful idea in the whole solution. How does an edge in Mumbai know how to reach a subnet behind an edge in Pune? Through a TLOC — a Transport Locator. A TLOC is just system-IP + colour + encapsulation (e.g. the Mumbai edge's mpls colour, or its biz-internet colour). The Controller advertises, over OMP, "prefix 192.168.20.0/24 is reachable via the Pune edge's TLOC." The underlay only ever sees the TLOC's outer IP; the real user prefixes live inside the encrypted overlay. One more piece of vocabulary that locks the underlay/overlay split into the config you'll actually see. Every WAN Edge ships with two reserved VPNs you cannot delete. VPN 0 is the transport VPN — it holds the underlay links and is where the DTLS/IPsec tunnels are built from, so the edge needs at least one interface in VPN 0 to reach the controllers at all. VPN 512 is the out-of-band management VPN — it's ignored by OMP and never rides the overlay. Everything in between — VPN 1, 10, 20… , the service VPNs — are your LAN-side segments whose user traffic actually crosses the overlay, kept isolated end-to-end by a VPN label. So: VPN 0 = underlay, service VPNs = what rides the overlay, VPN 512 = management. Now the split that makes it all work. The control plane (the vSmart Controller speaking OMP) lives on DTLS/TLS connections between each edge and the controllers. The data plane (user traffic) rides IPsec tunnels directly edge-to-edge and never touches the Controller. Separating "who decides the routes" from "who forwards the packets" is why one Controller can drive thousands of edges, and why losing a Controller doesn't drop live calls. Figure 3 — How a new branch joins and the overlay forms A five-step control-plane bring-up. Step 1 the WAN Edge boots and reaches the SD-WAN Validator (vBond) at its DNS name over UDP 12346. Step 2 the Validator checks the certificate and organisation name and hands back the addresses of the Manager and Controllers. Step 3 the edge forms DTLS control connections to Manager and Controller. Step 4 the Controller runs OMP and pushes routes, TLOCs and policy. Step 5 edges build IPsec data-plane tunnels to each other and BFD watches them. A break note shows what fails when the firewall blocks the DTLS port. Branch bring-up — Validator first, then OMP teaches the map WAN Edge new branch · Lucknow SD-WAN Validator vBond · the bouncer SD-WAN Manager vManage SD-WAN Controller vSmart · OMP 1· dial Validator (UDP 12346) 2· cert + org-name OK → here are the controllers 3· DTLS to Manager 3· DTLS to Controller 4· OMP pushes routes + TLOCs + policy down to the edge 5· IPsec data tunnels edge↔edge BFD watches each tunnel for loss/latency Key idea: controllers leave the path once tunnels are up, user data never touches vSmart underlay / untrusted overlay / trusted control / policy key insight allowed / SLA-met Follow the numbered arrows: dial the Validator (1–2), form DTLS to Manager & Controller (3), OMP pushes routes (4), then IPsec data tunnels come up edge-to-edge (5). Notice the Controller is gone from the final data path. ### ▶ Watch one packet ride the overlay A user at the Mumbai branch opens an app hosted behind the Pune branch. Follow the packet through the underlay and the overlay, step by step. Press Play for the healthy path, then Break it to see the failure. ① Underlay 10.10.20.5 → app 192.168.30.9 ; edge has only the underlay IP to the ISP ▼ ② OMP lookup edge checks OMP: 192.168.30.0/24 is via Pune's TLOC (system-IP + colour) ▼ ③ Encapsulate packet wrapped in IPsec , outer header = Mumbai TLOC → Pune TLOC over the chosen colour ▼ ④ Deliver Pune edge decrypts, forwards to 192.168.30.9 ; vSmart never saw the packet Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset cEdge CLI — see the overlay routes OMP installed (note the TLOC next-hops) BR-Mumbai-cEdge-01# show sdwan omp routes Expected output PATH TLOC IP COLOR ENCAP STATUS VPN PREFIX ID FROM PEER LABEL 1 192.168.30.0/24 1 10.0.0.2 1003 10.10.2.1 mpls ipsec C,I,R 1 192.168.30.0/24 2 10.0.0.2 1003 10.10.2.1 biz-internet ipsec C,I,R 1 192.168.40.0/24 3 10.0.0.2 1004 10.10.3.1 biz-internet ipsec C,I,R Prove the data plane is actually healthy, not just 'up' Control connections being up only proves the control plane. To prove user traffic can flow, check the data plane with show sdwan bfd sessions — every edge-to-edge tunnel runs BFD to measure loss/latency/jitter. If BFD is up on the colours you expect, the overlay can carry traffic; if BFD is down on a colour, that transport's tunnel is dead even when OMP looks fine. Priya at ICICI faces this Priya, an L1 analyst, gets a ticket: the new Lucknow branch cEdge shows control connections UP, but users there can't reach the app servers behind the Pune branch at all. Likely cause Control plane up ≠ data plane up. The edge authenticated and even learned OMP routes, but the IPsec data tunnels on the expected colour never came up — usually because the firewall in front of the branch blocks ESP (IP protocol 50) while still allowing the DTLS control port. Diagnosis She separates control from data: control connections are fine, so the problem is the overlay data path. She checks the per-tunnel BFD state to see which colour's tunnel is dead. vManage → Monitor → Devices → BR-Lucknow-cEdge → Real Time → BFD Sessions (or CLI: show sdwan bfd sessions) Fix Get the firewall team to permit ESP (IP protocol 50) and the UDP 12346 range outbound for the branch; if ESP can't be opened, enable IPsec-over-UDP on the tunnel so encryption rides UDP instead. Verify Re-run show sdwan bfd sessions → the biz-internet tunnel to Pune shows STATE up; users reach the Pune app servers, and the OMP route now resolves to a live TLOC. Quick check · Q3 of 10 Karthik at HCL asks: "What exactly does the underlay network see when my Mumbai edge sends encrypted traffic to my Pune edge?" a) The user's real source and destination IPs in clear text b) The OMP routing table being exchanged c) Only the outer TLOC IPs and the encrypted IPsec payload d) Nothing at all — the overlay is invisible to the transport Correct: c. The underlay routes the outer header — the TLOC IPs — and carries the encrypted IPsec payload it can't read. The real user IPs are inside the tunnel, not visible. OMP runs over the separate control connections, not the data tunnel. And the transport must see the outer TLOC IPs to forward at all, so it isn't 'invisible'. Pause & Predict Predict: why can a single vSmart Controller drive thousands of WAN Edges, when an old hub router in a DMVPN design would melt under that many tunnels? Type your guess. Reveal answer Answer: Because of the control/data split. The vSmart only handles the control plane — it computes and distributes routes, TLOCs and policy over lightweight OMP/DTLS sessions; it never forwards user packets. The actual data tunnels are built directly edge-to-edge, so the heavy lifting is spread across all the edges. A DMVPN hub, by contrast, sat in the data path and had to forward (and often decrypt/re-encrypt) every spoke's traffic — so it became the bottleneck. ## ④ Where you'll meet it — cloud vs on-prem, benefits, exam & career On a real job, the first thing you'll notice is where the controllers live . The Validator, Manager and Controller can be on-prem (VMs in the customer's own data centre) or cloud-hosted — Cisco-hosted or in a public cloud. Cloud-hosted is increasingly the default because nobody wants to babysit controller VMs and patch them for advisories. The WAN Edges, of course, are always physical (or virtual) routers at the branches and in the cloud. The benefits you now understand, stated the way a customer hears them: active/active links (every transport earning its keep, not idle backup), central policy (one change on the Manager, pushed everywhere, instead of 40 CLI logins), and app-aware routing (voice on the clean link, backups on the fat one — by application, in real time). Those three lines are why businesses migrate; everything later in this series is the how behind them. One sober note from the real world: because the Manager and Controllers are so central, they're a juicy target. In 2026 Cisco confirmed active exploitation of authentication-bypass flaws in Catalyst SD-WAN Controller/Manager — CVE-2026-20182 (CVSS 10.0, the peering-authentication bypass in the vdaemon service over DTLS/UDP 12346) and the earlier CVE-2026-20127 — attributed to the threat actor UAT-8616 , who used them to gain admin, add SSH keys and modify NETCONF config. The takeaway for you: keeping the controllers patched and access-controlled isn't optional housekeeping — a compromised Manager is the whole fabric. This is one reason many teams prefer Cisco-hosted controllers. 👉 So far: cloud vs on-prem controllers, the three headline benefits, and why controller security matters. Next: the exam + career, then a cheat-sheet of everything. For your certification path, this lesson maps straight onto the ENSDWI 300-415 blueprint — the CCNP Enterprise SD-WAN exam. Its very first domain, Architecture (20%) , is exactly the four planes and components you just learned; Router Deployment (20%) covers WAN Edge onboarding, OMP, TLOCs and underlay-overlay connectivity. Get these fundamentals solid and a fifth of the exam is already yours, plus the foundation for Controller Deployment, Policies and Security domains. Career-wise, SD-WAN sits right where enterprise networking is hiring in India — and it dovetails into SASE/SSE, the next thing every customer asks about. Figure 4 — Cisco SD-WAN fundamentals — the cheat-sheet A nine-tile cheat sheet. Tiles cover the working-name to new-name map, the four planes, the Validator, the Controller and OMP, the WAN Edge, the overlay versus underlay idea, the TLOC formula, the control versus data ports, and the first three show commands. Each tile has a one-line role. Cisco SD-WAN fundamentals — your one-glance card Old → new names vManage→Manager · vSmart→Controller vBond→Validator · vEdge/cEdge→WAN Edge field still says vManage/vSmart/vBond daily The 4 planes orchestration · management control · data decide vs forward, split apart Validator (vBond) authenticates + introduces devices always reached over DTLS/UDP the bouncer at the door Controller + OMP vSmart distributes routes + policy OMP ≈ BGP for the overlay never sees user data WAN Edge vEdge (Viptela OS) / cEdge (IOS-XE) builds IPsec tunnels, forwards traffic the worker on the floor Overlay vs underlay underlay = MPLS / broadband / LTE overlay = IPsec tunnels on top transport-independent TLOC = system-IP + colour + encap only thing the underlay sees tunnel endpoint + OMP next-hop Ports to open control: UDP 12346 (hops 12366…) data: ESP / IP-proto 50 block these → connections fail First show commands show sdwan control connections show sdwan omp routes show sdwan bfd sessions Your one-card map of this whole lesson — names, planes, overlay/underlay, TLOC, the ports to open, and the first show commands. Keep it open in your first week and revisit it before any SD-WAN interview. Daily-life analogy — Aadhaar OTP onboarding Joining the SD-WAN fabric is like an Aadhaar-OTP onboarding . The Validator (vBond) is the OTP gate — it verifies who you are before you're allowed in. The Manager (vManage) is the app that then fills in all your details (the config). The Controller (vSmart) is the directory that tells you how to reach everyone else (the routes). Only after all three are happy do you actually start transacting (data plane). No OTP, no entry — which is precisely why control connections to the Validator are step one in every troubleshoot. Next: vManage, vSmart & vBond in depth Prove you own the fundamentals Cold, in 30 seconds: name the four planes and their device for each ( orchestration=Validator, management=Manager, control=Controller, data=WAN Edge ); say what the underlay vs overlay is; and explain why losing all Controllers doesn't drop live calls (control/data split — tunnels are edge-to-edge). If you can do that without notes, you're ready for the next lesson and for the Architecture domain of 300-415. Quick check · Q4 of 10 An interviewer asks Meera: "Give me the single biggest architectural reason Cisco SD-WAN scales and survives a controller outage better than old DMVPN." Best answer? a) It uses cheaper internet links instead of MPLS b) It has a nicer GUI for configuration c) Controllers are cloud-hosted so they never go down d) It separates the control plane (routes/policy) from the data plane (edge-to-edge forwarding) Correct: d. The control/data plane separation is the core architectural win: controllers compute and distribute routes/policy but stay out of the forwarding path, so one Controller scales to thousands of edges and an outage doesn't drop already-up tunnels. Cheaper links and a nicer GUI are benefits, not the architectural reason; and controllers absolutely can go down — which is why the separation matters. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. vManage, vSmart, vBond — how do I never mix these up? What's the actual difference between vEdge and cEdge? Is the underlay vs overlay thing really that important, or is it jargon? Why do we even need a separate Controller? Why not let the edges talk directly? If a branch can't join the fabric, where do I start? How much of ENSDWI 300-415 does this one lesson actually cover? 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 In Cisco Catalyst SD-WAN, which component is the orchestration plane that authenticates a new device and introduces it to the rest of the fabric? a) SD-WAN Manager (vManage) b) WAN Edge (cEdge) c) SD-WAN Validator (vBond) d) SD-WAN Controller (vSmart) Correct: c. The SD-WAN Validator (vBond) is the orchestration plane — it authenticates devices and points them at the Manager and Controllers. The Manager is management (config/monitor), the Controller is control (OMP routes), and the WAN Edge is data (forwarding). Q6 · Apply A new Airtel branch has an MPLS link plus a broadband link. You want BOTH to actively carry production traffic at the same time. What does SD-WAN give you that traditional WAN didn't? a) A transport-independent overlay running both links active/active b) A single bigger MPLS circuit to replace both c) Backhauling all traffic to HQ for inspection first d) A faster routing protocol on the MPLS link only Correct: a. SD-WAN's transport-independent overlay rides every link at once, so MPLS and broadband are both active paths. A bigger MPLS line is more cost not more flexibility; backhauling adds latency; speeding up one link ignores the second entirely. Q7 · Apply You need to verify that a cEdge has actually reached all three controller types after onboarding. Which CLI command shows that, and what proves success? a) show ip route — a default route is present b) show sdwan control connections — vbond, vmanage and vsmart all show STATE up c) show sdwan bfd sessions — all colours are down d) show running-config — the org name is configured Correct: b. show sdwan control connections lists each peer type (vbond/vmanage/vsmart) with its state; all three up proves control-plane onboarding. show ip route doesn't show SD-WAN control state; BFD being down would mean the data plane is broken; the running-config shows intent, not live connection status. Q8 · Analyze A branch cEdge shows control connections UP to all controllers and OMP routes are present, but users can't reach servers behind a remote branch. Steering and certificates are fine. Most likely root cause? a) The vSmart Controller is overloaded and dropping OMP b) The org name is mismatched on the controllers c) The Manager hasn't pushed a device template yet d) The IPsec data tunnel is down (e.g. ESP/UDP 12346 blocked by a firewall) even though the control plane is up Correct: d. Control plane up plus OMP routes present means onboarding and routing are fine — the failure is the data plane: the edge-to-edge IPsec tunnel isn't forming, classically because ESP (IP protocol 50) or the UDP 12346 range is blocked. An org-name mismatch would stop control connections forming at all; an overloaded vSmart or missing template wouldn't leave OMP routes present with no data path. Q9 · Analyze All vSmart Controllers in a fabric briefly go offline, but existing branch-to-branch IPsec tunnels were already up. What happens to in-progress user traffic, and why? a) Traffic on existing tunnels keeps flowing, because the Controllers aren't in the data path — only the control plane is affected b) All traffic stops instantly, because every packet is forwarded through the vSmart c) Traffic fails over to MPLS only, dropping all internet links d) The WAN Edges reboot to re-onboard Correct: a. The control/data separation means the Controllers compute and distribute routes/policy but never forward user packets. Already-established edge-to-edge tunnels keep carrying traffic; what's lost is learning NEW routes or pushing NEW policy until a Controller returns. Packets don't route through vSmart, so option 2 is the classic misconception. Q10 · Evaluate Two ways to describe SD-WAN's core advantage to a hiring manager: (A) "it replaces expensive MPLS with cheap internet and gives a nice GUI"; (B) "it separates the four planes and builds a transport-independent overlay, so control and data split, links go active/active, and policy is central." Which is the stronger answer and why? a) A — it's simpler and what customers care about most b) B — it names the actual architecture (plane separation + overlay) that produces the benefits, instead of just listing surface perks c) A — GUI and cost are the only real differences d) Identical — both describe the same depth Correct: b. B explains the cause (plane separation and a transport-independent overlay) that produces active/active links, central policy and app-aware routing — that's the architecture the exam and the job test. A lists surface perks (cost, GUI) without the 'why', and SD-WAN doesn't even require dropping MPLS; you can keep it as one active transport. 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 doesn't a vSmart Controller outage drop calls that are already in progress between two branches? Then compare to the expert version. Compare with expert answer Expert version: Because the control plane and data plane are separated: the Controller only computes and distributes routes/policy, while user traffic rides IPsec tunnels built directly edge-to-edge — so already-established tunnels keep forwarding even with no Controller reachable. ### 🗣 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 Fundamentals at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary SD-WAN Software-Defined WAN — an encrypted overlay built on any transport, managed centrally from a controller stack. Viptela The SD-WAN startup Cisco bought in 2017; its software became Cisco SD-WAN, now Cisco Catalyst SD-WAN. SD-WAN Validator (vBond) Orchestration plane — authenticates devices, checks the org name, and introduces edges to the Manager and Controllers. SD-WAN Manager (vManage) Management plane — the single GUI to configure, template and monitor the whole overlay. SD-WAN Controller (vSmart) Control plane — runs OMP to distribute routes, TLOCs and policy to every edge; never carries user data. WAN Edge (vEdge / cEdge) Data plane router at each site. vEdge runs Viptela OS; cEdge runs Cisco IOS-XE SD-WAN. Builds IPsec tunnels and forwards. OMP Overlay Management Protocol — a TCP-based, BGP-like protocol the Controller uses to advertise overlay routes and policy. TLOC Transport Locator = system-IP + colour + encapsulation. The tunnel endpoint and OMP next-hop; the only SD-WAN identity the underlay sees. Underlay The physical transports beneath SD-WAN — MPLS, broadband, LTE/5G. Whatever links the carrier provides. Overlay The virtual network of encrypted IPsec tunnels SD-WAN builds on top of the underlay; transport-independent. DTLS / TLS The encrypted channels for SD-WAN control connections (DTLS over UDP, TLS over TCP) between edges and controllers. BFD Bidirectional Forwarding Detection — runs on every edge-to-edge tunnel to measure loss/latency/jitter and trigger reroute. VPN 0 / VPN 512 Two reserved VPNs on every WAN Edge: VPN 0 = transport (underlay links + control tunnels), VPN 512 = out-of-band management. Service VPNs (1, 10, 20…) carry user data across the overlay. #### 📚 Sources Cisco Catalyst SD-WAN Getting Started Guide — "The Cisco Catalyst SD-WAN Solution" (the four planes: orchestration/management/control/data; component-to-plane mapping; rebrand vManage→Manager, vSmart→Controller, vBond→Validator from Release 20.12). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-xe-gs-book/system-overview.html - Cisco Catalyst SD-WAN Getting Started Guide — "Overlay Network Bring-Up Process" (WAN Edge establishes DTLS control connections; base port UDP 12346 with port-hopping 12366/12386/12406/12426; OMP route distribution). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-xe-gs-book/cisco-sd-wan-overlay-network-bringup.html - Cisco Community — "SD-WAN Routers: Troubleshoot Control Connections" + Cisco doc 214509 (real error codes DCONFAIL/CTORGNMMIS/NOACTVBMS; firewall/NAT must allow the DTLS port range + ESP). community.cisco.com/t5/networking-knowledge-base/sd-wan-routers-troubleshoot-control-connections/ta-p/3813237 · cisco.com/c/en/us/support/docs/routers/sd-wan/214509-troubleshoot-control-connections.html - Cisco Newsroom — "Cisco Completes Acquisition of Viptela" (Aug 2017, ~$610M) and the rebrand to Cisco Catalyst SD-WAN (2023). newsroom.cisco.com/c/r/newsroom/en/us/a/y2017/m08/cisco-completes-acquisition-of-viptela.html - Cisco Talos — "Active exploitation of Cisco Catalyst SD-WAN by UAT-8616" (CVE-2026-20182, CVSS 10.0 peering-auth bypass in Controller/Manager via the vdaemon service over DTLS/UDP 12346; earlier CVE-2026-20127), plus Cisco PSIRT advisory cisco-sa-sdwan-rpa2. blog.talosintelligence.com/uat-8616-sd-wan/ · sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-rpa2-v69WY2SW - Cisco ENSDWI 300-415 v1.2 exam blueprint — Architecture (20%: orchestration/management/control/data planes), Router Deployment (20%: WAN Edge, OMP, TLOCs, underlay/overlay). learningcontent.cisco.com/documents/marketing/exam-topics/300-415-ENSDWI-v1.2.pdf · learningnetwork.cisco.com/s/ensdwi-exam-topics ### What's next? You can now name the four planes and the overlay. Next we crack open the controllers themselves — how vManage, vSmart and vBond are deployed, certified and made redundant, and exactly what each one does on the wire. Next · The Cisco SD-WAN Controllers: vManage, vSmart, vBond → 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