# Cisco SD-WAN Controllers Deep-Dive: — vManage, vSmart, vBond & vAnalytics Source: https://ai.techclick.in/blog_cisco_sdwan_controllers Markdown: https://ai.techclick.in/blog_cisco_sdwan_controllers.md Publisher: Techclick Infosec Pvt Ltd Cisco SD-WAN controllers explained: vBond Validator (NAT discovery, public IP), vManage Manager (GUI + REST API), vSmart Controller (OMP, TLOC, policy), vAnalytics, DTLS ports, HA cluster and certificate trust — for jobs and ENSDWI 300-415. Cisco SD-WAN Controllers Deep-Dive: — vManage, vSmart, vBond & vAnalytics student learning map A visual study map for Cisco SD-WAN Controllers Deep-Dive: — vManage, vSmart, vBond & vAnalytics showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Cisco SD-WAN Controllers Deep-Dive: — vManage,... 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 ① vBond (Validator) — the bouncer... 4. Practice ② vManage (SD-WAN Manager) — the... 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 "vManage is the brain — it pushes the routes, so if vManage is down, my whole SD-WAN dies." So they panic the moment the GUI is unreachable. Wrong — and the difference is exam gold and 2 a.m. peace of mind. vManage is the management plane, not the control plane. The brain that distributes routes and policy is vSmart over OMP. If vManage goes down you lose the GUI, templates and monitoring, but the fabric keeps forwarding because the edges already hold their OMP routes from vSmart. And not one controller — vBond, vManage or vSmart — ever sits in the user data path. They build the map; the WAN Edge drives the car. ## ① vBond (Validator) — the bouncer at the gate Before any branch router can join the fabric, it has to be let in — and vBond (now branded the Validator ) is the bouncer. It is the orchestration plane : the very first controller every device contacts. The job is small but non-negotiable — authenticate the device by certificate, work out whether it is behind a NAT, and then hand it the addresses of vManage and vSmart so it can build the connections that actually matter. The Aadhaar-OTP analogy is the one students remember. When you walk into a bank to open an account, the guard at the door doesn't manage your money or decide your interest rate — he just verifies who you are and points you to the right counter. vBond is that guard. It checks your certificate, notes whether you came in through the back lane (a NAT), and says "go to counter 5 (vManage) and counter 7 (vSmart)". Then it steps aside — it never touches your transactions. 👉 So far: vBond = the bouncer that authenticates and redirects. Next: the one thing that makes vBond special among all four controllers — its address. Here is the fact the exam loves and the field forgets: vBond is the only component that MUST have a public, NATable IP address. Why? Because a branch edge sitting behind a corporate firewall and NAT has no idea what its own public address is. vBond, by default, runs as a STUN server (RFC 5389). The edge tells vBond its private source IP inside the packet; vBond reads the public IP the packet actually arrived from. If they differ, the edge is behind a NAT, and vBond records the public-to-private mapping so the rest of the fabric can find it. No public IP on vBond = no NAT discovery = edges behind NAT can't be reached. Figure 1 — One fabric, four planes — vBond orchestrates, vManage manages, vSmart controls, the WAN Edge forwards Cisco SD-WAN four-plane architecture. vBond Validator is the orchestration plane in public address space. vManage is the management plane single pane of glass. vSmart is the control plane brain running OMP. WAN Edge routers are the data plane carrying user traffic over MPLS and Internet. Dashed amber lines are DTLS control connections from each edge up to the three controllers; the solid blue pipe between edges is the IPsec data tunnel that no controller ever touches. One fabric, four planes — three controllers up top, the edges down below vBond / Validator orchestration · PUBLIC IP vManage / Manager management · GUI + REST API vSmart / Controller control · OMP brain — — dashed = DTLS / TLS control connections (no user data) — — WAN Edge · Mumbai 10.10.10.1 · Site 100 Internet MPLS WAN Edge · Pune 10.20.20.1 · Site 200 Internet MPLS - IPsec data tunnel — user traffic only, NO controller in the path Controllers ride the control plane (amber); user packets ride the overlay data plane (blue). They never mix. underlay / untrusted overlay / trusted control / policy key idea allowed / up Read it top-to-bottom: three controllers up top, two edges below. The dashed amber lines are DTLS control connections (no user data). The thick blue pipe between the edges is the IPsec data tunnel — notice no controller touches it. Walk the diagram once and the whole lesson clicks. Each WAN Edge runs a fistful of dashed DTLS lines up to vBond, vManage and vSmart — that is the control plane. The single blue pipe between the two edges is the overlay data tunnel. The controllers built the map that made that tunnel possible, but the user packets ride the blue pipe alone. Keep that picture in your head and you will never confuse "the GUI is down" with "the network is down". ### Four things to lock about vBond Tap each card — these are the vBond facts that show up in interviews and the 300-415. 🛂 First contact tap to flip Every device talks to vBond before anything else. It authenticates by certificate, then redirects. So: vBond down at boot = new sites can't onboard. 🌐 Public IP only tap to flip vBond is the ONE controller that must own a public, NATable IP — it is the STUN server that detects NAT. vManage and vSmart can hide behind NAT. 🔁 Transient, not permanent tap to flip The edge's DTLS session to vBond is temporary. Once vBond returns the controller list, that session tears down. vBond is the intro, not the relationship. 🗺️ The signpost tap to flip vBond never carries routes, policy or user data. It just tells edges WHERE vManage and vSmart live — and tells those controllers to expect the edge. Quick check · Q1 of 10 Rahul at TCS is racking controllers in a new data centre. He puts vManage, vSmart and vBond all behind the same firewall with private IPs and a single NAT. Edges onboard fine over MPLS but every Internet-side branch fails. What did he miss? a) vBond must have a public, NATable IP so NAT discovery works for Internet-side edges b) vSmart needs the public IP, not vBond c) vManage must be in the cloud d) He should disable certificates Correct: a. vBond is the STUN server and the only controller that must be reachable on a public IP — Internet-side edges behind NAT can only be discovered if vBond sees their real public address. vSmart and vManage can sit behind NAT (their source IP just has to be NATed to a public IP with the port preserved). The cert and cloud points are unrelated to this symptom. Pause & Predict Predict: if the edge's DTLS connection to vBond is only TRANSIENT (it tears down after onboarding), why does losing vBond later NOT drop your running data tunnels? Type your guess. Reveal answer Answer: Because vBond's only job is the introduction. Once an edge has the vManage and vSmart addresses and has built its permanent control connections to them, it no longer needs vBond — the OMP routes and TLOCs come from vSmart, not vBond. So an established fabric keeps forwarding even if vBond is briefly down; you only feel it when a NEW site tries to onboard or an edge needs to re-discover the controllers. ## ② vManage (SD-WAN Manager) — the control room vManage (now Catalyst SD-WAN Manager ) is the management plane — the single screen where you run the entire fabric. It is the GUI you log into, the REST API automation drives, the place you build feature and device templates, push software upgrades, install certificates, and watch every device's health. If a job touches configuration or monitoring, it happens here. But — and this is the line that separates a junior from a job-ready engineer — vManage never sits in the data path, and it is not the control plane either. It is the control room , not the traffic controller. Think of an airport control tower: it schedules, monitors and gives clearance, but the planes (your packets) and the routing brain (vSmart) operate even if the tower's screens flicker. You push config from vManage; the edges then run that config independently. 👉 So far: vManage = the control room you configure and monitor from, never in the data path. Next: what you actually click on that screen. vManage → Configuration → Certificates → Controllers . Where you check that each controller's cert is installed and its control connections are up. (Recreated for clarity — your console matches this.)"> 🖥️ This is the screen you'll live in — vManage → Configuration → Certificates → Controllers . Where you check that each controller's cert is installed and its control connections are up. (Recreated for clarity — your console matches this.) vmanage.lab.local · Configuration · Certificates · Controllers 1 Controller vBond (Validator) — Site 1 2 Certificate Installed · Cisco signed 3 Organization Name Techclick-Infosec-Overlay Control Connections Up · vManage + vSmart 4 vBond IP / Public 203.0.113.10 (public) Action Send to Controllers Send to Controllers Certificate management lives right here. vManage is where you generate the CSR for each controller, install the signed certificate, and push the result with Send to Controllers . It is also where the Organization Name is set and verified — remember that name, because in section 4 a single mismatch in it will take the whole control plane down. vManage CLI (verify cluster + device list) vmanage# show control connections vmanage# request nms all status Expected output PEER PEER SITE DOMAIN PEER PEER TYPE PROTOCOL ID ID PRIV IP STATE ---------------------------------------------------------- vbond dtls 0 0 203.0.113.10 up vsmart dtls 1 1 10.0.0.5 up NMS application server : running NMS messaging server : running vManage rarely runs alone in production. For scale and resilience you deploy it as a cluster — three nodes minimum (which tolerates one node failing) or six nodes for very large fabrics. A single vManage can handle roughly 1,000–1,500 devices; a six-node cluster pushes past 10,000. We'll come back to this in the HA section. Quick check · Q2 of 10 Priya at Wipro gets paged: "vManage GUI is unreachable!" Branch users report no application problems at all. What is the correct first statement to her manager? a) vManage is the management plane; the data plane and OMP routing keep running, so users are unaffected while we restore the GUI b) All traffic has stopped — declare a Sev-1 outage c) vSmart must also be down d) We must rebuild the certificates immediately Correct: a. vManage is management, not data or control plane. Losing it costs you the GUI, templates, REST API and monitoring — not forwarding. The edges keep their OMP routes from vSmart and keep forwarding over existing tunnels. vSmart being down is a separate, unrelated condition, and certs aren't implicated by a GUI outage. Pause & Predict Predict: you automate config changes by hitting vManage's REST API instead of clicking the GUI. Does that change WHERE the config ends up running — on vManage, or on the edges? Type your guess. Reveal answer Answer: It changes nothing about where it runs. The REST API and the GUI are two front doors to the same vManage management plane. Either way, vManage compiles your intent into device config and pushes it to the WAN Edge routers, which then run it independently. vManage stores and orchestrates the config; the edges execute it. The API just lets a script do the clicking. ## ③ vSmart (Controller) — the route-and-policy brain If vBond is the bouncer and vManage is the control room, vSmart (now just the Controller ) is the brain. It is the control plane . It holds a permanent DTLS/TLS session with every WAN Edge and runs OMP (the Overlay Management Protocol) over it. Through OMP, vSmart learns every site's reachability, then redistributes it so every edge knows how to reach every other edge — without the edges ever peering directly with each other for routing. The cleanest mental model — and an exam favourite — is the BGP route reflector . In a route-reflected BGP design, clients don't full-mesh; they peer with the reflector, which redistributes routes for them. vSmart does exactly this for the overlay: edges peer with vSmart, not with each other, and vSmart reflects the TLOC and OMP routes around. Add a second vSmart and you have redundancy, just like a second route reflector. 👉 So far: vSmart runs OMP like a route reflector, distributing routes and TLOCs. Next: the second half of its job — policy — and the one thing it never does. vSmart is also where every centralized policy lives and is enforced. You build the policy in vManage, but it is activated on vSmart , which applies it to the OMP updates it sends and receives — control policy (steer which routes an edge sees, hub-and-spoke vs full mesh), and the control half of data policy and app-aware routing. The edges enforce localized policy; the overlay-wide steering is vSmart's. The hard rule: vSmart NEVER forwards a user packet. It shapes the map that the edges use; the cars drive themselves. Figure 2 — Pick the controller by the job — orchestrate, manage, control, or just see; only the edge ever forwards a user packet A four-column comparison of vBond, vManage, vSmart and vAnalytics. Each column lists its plane, its one job, whether it sits in the data path (none do), and its key fact. vBond orchestration needs a public IP. vManage management is the GUI and REST API. vSmart control runs OMP and policy. vAnalytics is cloud-only telemetry and forecasting. Four roles, one rule: not one of them forwards user traffic vBond · Validator plane: orchestration job: first contact, auth + NAT discovery MUST have a public IP (STUN server) data path? NO tells edges where vManage + vSmart live vManage · Manager plane: management job: GUI + REST API, templates, upgrades single pane of glass + certificates data path? NO cluster of 3 or 6 for scale + HA vSmart · Controller plane: control job: OMP routes, TLOCs + all policy route reflector for the overlay data path? NO run 2+ for redundancy; edge keeps 2 sessions vAnalytics plane: visibility job: app + path insight, forecasting cloud-hosted SaaS only — telemetry data path? NO bandwidth forecast + predictive path rec. Memory hook: Validator = bouncer · Manager = control room · Controller = traffic-route brain · Analytics = the dashboard Four columns, one punchline in every 'data path?' row: NO. vBond needs a public IP; vManage is the GUI/API; vSmart is OMP + policy; vAnalytics is cloud-only telemetry. ### ▶ Follow one route advertisement through OMP Watch the Pune branch's subnet travel from its edge, up to vSmart, and back down to the Mumbai edge — without vSmart ever forwarding a packet. Press Play for the healthy path, then Break it to see the failure. ① Originate Pune edge 10.20.20.1 learns local subnet 192.168.20.0/24, builds an OMP route + its TLOC ▼ ② Advertise edge sends the OMP route + TLOC up the DTLS session to vSmart ▼ ③ Reflect vSmart applies centralized policy, then reflects the route down to Mumbai edge 10.10.10.1 ▼ ④ Install Mumbai edge installs the route, builds an IPsec tunnel direct to Pune — vSmart is not in that tunnel Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Aditya at HCL faces this Aditya, an L1 engineer, sees a brand-new Chennai branch that onboarded fine (control connections all UP) but no other site can reach its 192.168.30.0/24 subnet. Data tunnels to it won't form. Likely cause The Chennai edge has its control connection to vBond and vManage up, but its OMP session to vSmart is not advertising/receiving routes — often a centralized control policy on vSmart filtering the new site, or the edge in a VPN/segment the policy doesn't permit. Diagnosis He confirms the OMP routes and TLOCs are actually present on vSmart and on the peer edges, then checks the centralized control policy that's active on vSmart. vManage → Monitor → Devices → (Chennai edge) → Real Time → OMP Routes Received / Advertised; then Configuration → Policies → (active centralized policy) Fix Adjust the centralized control policy on vSmart so the new site/VPN is permitted (or its TLOCs/routes aren't filtered), then re-activate the policy from vManage. Verify On a peer edge, 'show sdwan omp routes' now lists the 192.168.30.0/24 prefix with a valid TLOC, and a 'show sdwan bfd sessions' shows the tunnel to Chennai coming up. WAN Edge CLI (IOS-XE SD-WAN) — prove OMP is working Edge-Mumbai# show sdwan omp routes Edge-Mumbai# show sdwan omp peers Expected output PATH ATTRIBUTE VPN PREFIX FROM PEER STATUS TLOC IP COLOR ---------------------------------------------------------------- 1 192.168.20.0/24 10.0.0.5 C,I,R 10.20.20.1 mpls 1 192.168.30.0/24 10.0.0.5 C,I,R 10.30.30.1 biz-internet PEER TYPE DOMAIN-ID SITE-ID STATE 10.0.0.5 vsmart 1 1 up Quick check · Q3 of 10 Karthik at Flipkart asks: "We added a third vSmart for resilience. By default, how many vSmart control sessions does each edge keep?" What's the right answer and why? a) Zero — edges talk only to vManage b) All three, always — one per vSmart c) One, to save resources d) Two, by default (max-omp-sessions = 2) — for redundancy without overloading the edge Correct: d. The default max-omp-sessions (max control connections to vSmart) is 2, so each edge keeps two vSmart sessions for redundancy even if you deploy three or more. Keeping all three is possible but not the default; one removes redundancy; and edges absolutely peer with vSmart for OMP — that's the whole control plane. Pause & Predict Predict: an interviewer says "vSmart is down but my existing branch-to-branch calls still work. Explain." What do you say? Type your guess. Reveal answer Answer: Because vSmart only distributes routes and policy over OMP — it is never in the data path. Existing edges already installed their OMP routes and TLOCs and already have direct IPsec data tunnels to each other, so live traffic keeps flowing. What you lose with vSmart down is NEW route distribution and policy changes: a freshly added site won't be learned, and policy edits won't take effect, until a vSmart (or its redundant peer) is back. ## ④ vAnalytics, HA & how the trust is glued together The fourth piece isn't a forwarding controller at all — vAnalytics is a cloud-hosted SaaS that ingests telemetry from the whole fabric and turns it into insight. It gives you application and path visibility over time, bandwidth forecasting (predict when a circuit will run out of headroom), and Predictive Path Recommendations (PPR) that suggest a better path before users feel the pain. It is the dashboard on the wall, not a controller in the loop — there is no on-prem vAnalytics; it lives in Cisco's cloud. That brings up the deployment question students always ask: on-prem vs Cisco-hosted/cloud. vBond, vManage and vSmart can run on your own ESXi/KVM/UCS in your data centre (on-prem), in your own public-cloud VPC, or fully Cisco-hosted (Cisco runs and patches the controllers for you). vAnalytics is cloud-only. A common Indian-enterprise pattern: Cisco-hosted controllers for less ops burden, with edges at every branch from Lucknow to Chennai — the dual-SIM-failover idea, but for an entire WAN. 👉 So far: vAnalytics = cloud dashboard; controllers can be on-prem or Cisco-hosted. Next: how they all trust each other, and the cheat-sheet. Now the glue. Every control connection — edge↔vBond, edge↔vManage, edge↔vSmart, and controller↔controller — is an encrypted, mutually-authenticated DTLS (UDP) session, with TLS (TCP) as the alternative. Two things must line up or nothing comes up: (1) certificates — each side validates the other's cert against the installed root CA; and (2) the organization-name — a single string that must be identical on every controller and every edge in the overlay. Get the org-name wrong on one box and you'll watch its control connections flap with a very specific error code. Figure 3 — Bring-up order is fixed — vBond first, always: it is the only door that knows where every other controller lives The overlay bring-up sequence. Step 1 the WAN Edge opens a transient DTLS connection to vBond over every transport and certificates are exchanged. Step 2 vBond does NAT discovery as a STUN server and authenticates the edge. Step 3 vBond returns the IP addresses of vManage and vSmart and tells those controllers to expect the edge. Step 4 the edge builds a permanent DTLS connection to vManage and to the vSmarts, and the transient vBond session tears down. How a new edge joins — vBond is step 1, every time WAN Edge boots, behind NAT vBond STUN + cert auth the only public-IP door vManage vSmart x2 1 · transient DTLS + certs 2 · NAT discovery + auth OK 3 · "expect this edge" 3 · here are vManage + vSmart IPs 4 · PERMANENT DTLS to vManage + vSmart (1 transport to vManage) vBond session then TEARS DOWN — its job (intro) is done underlay / untrusted overlay / trusted control / policy key idea allowed / up Numbered steps 1→4. vBond does NAT discovery + auth (steps 1–2), returns the controller IPs (step 3), then the edge builds PERMANENT sessions to vManage + vSmart (step 4) and the vBond session tears down. WAN Edge CLI — the command you'll run a thousand times Edge-Mumbai# show sdwan control connections Edge-Mumbai# show sdwan control connections-history Expected output PEER PEER PEER SITE PsT PsT PUBLIC TYPE PROT SYSTEM IP ID PRIV PUB IP:PORT STATE ----------------------------------------------------------------- vbond dtls - 0 - - 203.0.113.10:12346 up vmanage dtls 10.0.0.1 1 - - 10.0.0.1:12346 up vsmart dtls 10.0.0.5 1 - - 10.0.0.5:12346 up # history shows LOCAL ERROR / REMOTE ERROR e.g. CTORGNMMIS, DCONFAIL Common mistake — the org-name typo that kills the whole overlay Symptom: an edge or controller's control connections flap, and show sdwan control connections-history shows CTORGNMMIS in the LOCAL/REMOTE ERROR column. Cause: the organization-name doesn't match across all devices (a stray space, different case, or a typo like Techclick-Infosec vs TechClick-Infosec ). The org-name is baked into the certificate check, so one mismatch fails authentication. Fix: set the identical organization-name on every controller and edge, then clear control connections . Common mistake — the firewall ate UDP 12346 Symptom: a branch edge is stuck in state connect or challenge to vBond, history shows DCONFAIL (DTLS connection failure). Cause: a firewall/NAT is dropping the control port — DTLS uses UDP 12346 by default and port-hops to 12366, 12386, 12406, 12426. Fix: permit UDP 12346 (and the hop range) to/from vBond, preserve the source port on the NAT for vManage/vSmart → vBond, then clear control connections . Bonus: try port-hop if NAT mappings are stuck. Figure 4 — Controllers cheat-sheet — the ports, show commands and one-line roles you need on the SOC floor and in the exam A nine-tile cheat sheet for Cisco SD-WAN controllers: control connection port 12346 and the port-hop ladder, the show sdwan control connections command, vBond role, vManage role, vSmart role, vAnalytics role, organization-name match rule, DTLS versus TLS, and the bring-up order vBond first. Controllers — your one-glance exam + SOC card Ports DTLS UDP 12346 (base) hop: 12366·12386·12406·12426 Verify command show sdwan control connections[-history] vBond · Validator public IP · STUN · cert auth hands out controller IPs vManage · Manager GUI + REST API · templates upgrades · certs · 3/6 cluster vSmart · Controller OMP · TLOCs · all policy route reflector, no traffic vAnalytics cloud SaaS · app insight bandwidth forecast + PPR org-name must MATCH all controllers + edges, else CTORGNMMIS DTLS vs TLS DTLS = UDP (default) TLS = TCP (alternative) bring-up order vBond FIRST → it returns vManage + vSmart, then teardown Your one-card revision sheet — keep it open while you build your first overlay and screenshot it before the 300-415. vManage → Monitor → Devices → (select a device) → Control Connections . The live state of every controller session. (Recreated for clarity — your console matches this.)"> 🖥️ This is where you watch the fabric's health — vManage → Monitor → Devices → (select a device) → Control Connections . The live state of every controller session. (Recreated for clarity — your console matches this.) vmanage.lab.local · Monitor · Devices · Control Connections 1 Peer Type vsmart 2 Protocol dtls 3 Peer System IP 10.0.0.5 4 State up Local Error NO_ERROR (else CTORGNMMIS) Uptime 4d 06:12:33 Refresh Prove you've got the controller model Take any real ask — "a new Surat branch won't onboard and another site can't be reached" — and answer cold: which controller is first contact (vBond), which carries routes/policy (vSmart over OMP), which is the GUI you'd check (vManage → Monitor/Certificates), which port you'd permit on the firewall (UDP 12346), and which error code points to an org-name mismatch (CTORGNMMIS). If you can do that without notes, you're ready for the cert and the SOC floor. Back: Cisco SD-WAN (Viptela) Fundamentals Next: WAN Edge Onboarding — vEdge vs cEdge, ZTP & PnP Quick check · Q4 of 10 An ICICI design review asks: "Where does vAnalytics run, and can we host it on-prem in our Mumbai data centre alongside the controllers?" Best answer? a) vAnalytics runs on the vSmart node, so yes b) vAnalytics replaces vManage, so you stop running vManage c) vAnalytics is a cloud-hosted SaaS only — controllers can be on-prem or Cisco-hosted, but vAnalytics cannot be self-hosted d) vAnalytics sits in the data path to measure traffic Correct: c. vAnalytics is delivered as a cloud-only SaaS for telemetry, forecasting and PPR — there is no on-prem build. The forwarding controllers (vBond, vManage, vSmart) can be on-prem, in your own cloud, or Cisco-hosted. vAnalytics doesn't run on vSmart, doesn't replace vManage, and is never in the data path. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Why is vBond the only controller that needs a public IP? If vManage goes down, does my network stop forwarding? What exactly does vSmart distribute, and to whom? DTLS or TLS — which one, and on what port? My control connections won't come up and I see CTORGNMMIS — what is it? How do I make the controllers highly available? 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 Which Cisco SD-WAN controller is the only one that must have a public, NATable IP address? a) vManage b) vSmart c) vBond d) vAnalytics Correct: c. vBond (Validator) runs as the STUN server for NAT discovery, so it must be reachable on a public IP for Internet-side edges behind NAT to be discovered. vManage and vSmart can sit behind NAT; vAnalytics is a cloud SaaS, not an on-prem controller. Q6 · Apply A new Bengaluru branch edge boots up behind a corporate NAT. In what order does it form its control connections? a) vBond first (auth + NAT discovery + controller list), then permanent connections to vManage and vSmart b) vSmart first, then vBond, then vManage c) vManage first, because it holds the config d) All three simultaneously, in any order Correct: a. vBond is always first contact: it authenticates the edge, does NAT discovery and returns the vManage/vSmart addresses, then its transient session tears down. Only after that does the edge build permanent DTLS connections to vManage and vSmart. vSmart/vManage can't be first because the edge doesn't yet know their addresses. Q7 · Apply You need to confirm that a Mumbai edge's session to vSmart is up and learning routes. Which two commands do the job? a) show ip route and show running-config b) show sdwan control connections (session state) and show sdwan omp routes (routes learned) c) ping vsmart and traceroute vbond d) show interfaces and show version Correct: b. 'show sdwan control connections' proves the DTLS session to vSmart is up; 'show sdwan omp routes' proves OMP is actually distributing prefixes/TLOCs. Plain 'show ip route' won't show OMP/TLOC detail, and ping/traceroute test reachability, not the control-plane state. Q8 · Analyze An edge shows control connections UP to vBond but DOWN to vSmart and vManage, and connections-history shows CTORGNMMIS. Steering and routing to vBond look fine. Most likely root cause? a) The vSmart node is powered off b) The organization-name doesn't match on this device, failing the certificate check for vSmart/vManage c) vAnalytics licence expired d) The data-plane IPsec tunnel MTU is wrong Correct: b. CTORGNMMIS is a certificate organization-name mismatch — the org-name must be identical across all devices, and a mismatch fails auth so the affected sessions flap. A powered-off vSmart would show a different/absent peer rather than an org-name error; vAnalytics and data-plane MTU don't affect control-connection auth. Q9 · Analyze vManage has been unreachable for 20 minutes during a maintenance window, yet branch-to-branch application traffic is completely healthy and no new sites are being added. Why is traffic unaffected? a) Because vManage forwards traffic only when idle b) Because vManage is the management plane and is never in the data path — edges keep their OMP routes from vSmart and forward over existing tunnels c) Because vBond took over forwarding d) Because vAnalytics is rerouting the packets Correct: b. vManage is management, not data or control plane; it never forwards traffic. The edges already hold their routes from vSmart and have direct IPsec tunnels, so forwarding continues. vBond and vAnalytics don't forward user traffic either — only the WAN Edge does. Q10 · Evaluate Two HA designs for a 4,000-device fabric: (A) one big vManage, one vSmart, one vBond — simplest to run; (B) a 3-node vManage cluster, two vSmarts (edges keep 2 OMP sessions), and multiple vBonds behind DNS. Which is stronger and why? a) A — fewer nodes means fewer things to break b) B — redundancy per controller role: a vManage cluster survives a node loss, two vSmarts keep OMP/policy alive, multiple vBonds keep onboarding working; single controllers are single points of failure c) A — one of each is all Cisco supports d) Identical — controllers aren't in the data path so HA doesn't matter Correct: b. Design B removes single points of failure at every control-plane role: the 3-node cluster tolerates one vManage failure, two vSmarts (default max-omp-sessions = 2) keep routing/policy on a single loss, and multiple vBonds keep onboarding alive. Design A's single controllers each fail the whole role. 'HA doesn't matter' is wrong — losing the only vSmart stops new routes/policy, and the only vBond stops onboarding, even though existing traffic survives. 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 the SD-WAN fabric keep forwarding traffic even when vManage AND vSmart are temporarily down? Then compare to the expert version. Compare with expert answer Expert version: Because none of the controllers sit in the data path — the edges already hold their OMP routes/TLOCs and direct IPsec data tunnels, so live forwarding continues; you only lose new config (vManage) and new route/policy distribution (vSmart) until they return. ### 🗣 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 Controllers at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary vBond (Validator) Orchestration plane: first contact, certificate auth, NAT discovery via STUN; the only controller that must own a public IP. vManage (SD-WAN Manager) Management plane: GUI + REST API, templates, software upgrades, certificates and monitoring. Never in the data path. vSmart (Controller) Control plane: runs OMP with every edge over DTLS, distributes routes/TLOCs and all centralized policy; a route reflector for the overlay. vAnalytics Cloud-hosted SaaS for application/path visibility, bandwidth forecasting and Predictive Path Recommendations; no on-prem build. OMP Overlay Management Protocol — BGP-like protocol between vSmart and edges advertising overlay routes, TLOCs and service routes. TLOC Transport Location — an edge's transport attachment identified by system-IP + color + encapsulation (e.g. 10.10.10.1 / mpls / ipsec). DTLS / TLS Encryption for control connections: DTLS over UDP (default, port 12346) or TLS over TCP (alternative). Both mutually authenticate by certificate. Control connection An encrypted DTLS/TLS session between an edge and a controller (or controller-to-controller); checked with show sdwan control connections. STUN (NAT discovery) RFC 5389 mechanism vBond uses to detect whether a device is behind NAT by comparing its private source IP to the public arrival IP. Organization-name A single string that must be identical on every controller and edge; a mismatch fails the cert check and shows CTORGNMMIS. max-omp-sessions How many vSmart control sessions an edge keeps; default is 2, giving redundancy without overloading the edge. vManage cluster Active/active HA for vManage: 3 nodes (one can fail) or 6 nodes for high scale (10,000+ devices), behind a quorum. #### 📚 Sources Cisco Catalyst SD-WAN Getting Started Guide — "The Cisco Catalyst SD-WAN Solution" & "Overlay Network Bring-Up Process" (planes, vBond as STUN/NAT discovery, bring-up order vBond first, transient vs permanent control connections). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-xe-gs-book/system-overview.html - Cisco — "Troubleshoot SD-WAN Control Connections" (show sdwan control connections / connections-history fields; error codes CTORGNMMIS = org-name mismatch, DCONFAIL = DTLS failure, CRTVERFL, BIDNTVRFD; ports 12346 + port-hop 12366/12386/12406/12426). cisco.com/c/en/us/support/docs/routers/sd-wan/214509-troubleshoot-control-connections.html - Cisco Community — "SD-WAN Routers: Troubleshoot Control Connections" & "cEdge stuck in state 'connect', DCONFAIL" (real practitioner thread: firewall dropping UDP 12346, NAT/port-preservation for vManage/vSmart→vBond, clear control connections recovery). community.cisco.com/t5/sd-wan-and-cloud-networking/cedge-stuck-in-state-quot-connect-quot-dconfail/td-p/4083314 - r/networking & r/CCNP / The Network DNA — "10 Error Codes while checking Control Connections on vEdge/cEdge" (unfiltered gotchas: org-name case/space typos and firewall port-hopping are the most common control-plane killers). thenetworkdna.com/2021/09/cisco-viptela-sdwan-10-error-codes.html - Cisco Catalyst SD-WAN Analytics Data Sheet & FAQ (vAnalytics = cloud-only SaaS: application/path visibility, Bandwidth Forecasting, Predictive Path Recommendations). cisco.com/c/en/us/solutions/collateral/enterprise-networks/sd-wan-analytics/nb-06-vanalytics-ds-cte-en.html - Cisco Catalyst SD-WAN High Availability Configuration Guide (vManage 3/6-node active/active cluster, ~1,000–1,500 devices per node / 10,000+ per 6-node cluster; vSmart redundancy; default max-omp-sessions = 2). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/ha-scaling/ios-xe-17/high-availability-book-xe/m-high-availability-and-scaling.html - Cisco Security Advisory (Apr 2025) — "Cisco Catalyst SD-WAN Manager Vulnerabilities" CVE-2026-20182 authentication bypass; fixed in 20.15.5 / Cloud 20.15.506 — keep Manager (vManage) patched. sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-mltvnps2-JxpWm7R - Cisco 300-415 ENSDWI exam topics — Architecture (orchestration/management/control/data planes) and Controller Deployment (vManage/vSmart/vBond redundancy, certificates, cloud vs on-prem). learningnetwork.cisco.com/s/ensdwi-exam-topics ### What's next? You now know who runs the fabric. Next: how a brand-new branch router actually joins it — the difference between a vEdge and a cEdge, and the two ways to onboard at scale, Zero-Touch Provisioning (ZTP) and Plug-and-Play (PnP). Next · WAN Edge Onboarding: vEdge vs cEdge, ZTP & PnP → 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