Cisco SD-WAN Controllers Deep-Dive: vManage, vSmart, vBond & vAnalytics

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

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 edgesb) vSmart needs the public IP, not vBondc) vManage must be in the cloudd) 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.

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.

🖥️ 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

Controller

vBond (Validator) — Site 1

Certificate

Installed · Cisco signed

Organization Name

Techclick-Infosec-Overlay

Control Connections

Up · vManage + vSmart

vBond IP / Public

203.0.113.10 (public)

Action

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 GUIb) All traffic has stopped — declare a Sev-1 outagec) vSmart must also be downd) 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.

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

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.

① OriginatePune edge 10.20.20.1 learns local subnet 192.168.20.0/24, builds an OMP route + its TLOC

▼

② Advertiseedge sends the OMP route + TLOC up the DTLS session to vSmart

▼

③ ReflectvSmart applies centralized policy, then reflects the route down to Mumbai edge 10.10.10.1

▼

④ InstallMumbai 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.

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 vManageb) All three, always — one per vSmartc) One, to save resourcesd) 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.

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

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

Your one-card revision sheet — keep it open while you build your first overlay and screenshot it before the 300-415.

🖥️ 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

Peer Type

vsmart

Protocol

dtls

Peer System IP

10.0.0.5

State

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 yesb) vAnalytics replaces vManage, so you stop running vManagec) vAnalytics is a cloud-hosted SaaS only — controllers can be on-prem or Cisco-hosted, but vAnalytics cannot be self-hostedd) 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.

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.

🧠 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.

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.

📩 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 →

Cisco SD-WAN Controllers Deep-Dive: — vManage, vSmart, vBond & vAnalytics

🎯 By the end you will be able to

Pick where you want to start

vBond / Validator

vManage / Manager

vSmart / Controller

vAnalytics, HA & trust

① vBond (Validator) — the bouncer at the gate

Four things to lock about vBond

② vManage (SD-WAN Manager) — the control room

③ vSmart (Controller) — the route-and-policy brain

▶ Follow one route advertisement through OMP

④ vAnalytics, HA & how the trust is glued together

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?