Cisco Catalyst SD-WAN Deep Dive Part 10: Failure Modes, Scale Limits, and a Vendor Comparison
Nine parts in, the architecture, the protocols, the policy model, the cloud and security integrations, and the migration path are all on the table. This closing post does two things: name what actually breaks in this architecture and what survives when it does, and put OMP/TLOC side by side with the three other SD-WAN architectures already covered on this site.
Failure modes, plane by plane
The four-plane separation from Part 1 isn’t just an organizational convenience — it directly determines blast radius when something fails.
vBond down: vBond’s job is initial onboarding and ongoing NAT-traversal assistance (Part 1); it’s stateless and not in the path for tunnels that are already established. Lose vBond and the existing fabric keeps forwarding traffic exactly as before — what breaks is a new device’s ability to onboard, or an existing device’s ability to recover from certain NAT-related reconnection scenarios. Annoying, not an outage.
vSmart down: This is the control plane, so losing it stops new OMP route advertisement and withdrawal — but WAN Edges hold the OMP routes and policy they last received and keep forwarding on that cached state. A single vSmart failure with no redundancy eventually goes stale as the network changes underneath it without anyone telling the edges; this is exactly why production designs run multiple vSmarts and have every edge connect to more than one simultaneously; the realistic failure mode is “lost a vSmart, still have N-1,” not “lost the fabric.”
vManage down: Templates can’t be pushed, the GUI/API is unavailable, Part 8’s automation has nothing to talk to — but nothing about already-running TLOCs, OMP routes, or forwarding depends on vManage being reachable at that moment. The bigger vManage risk isn’t an outage, it’s scale: vManage’s configuration database is the documented bottleneck, with single-cluster designs generally planned to stay under roughly 2,000–3,000 edges before that database itself becomes the limiting factor rather than any compute or bandwidth constraint. Past that ceiling, the answer is horizontal — clustering vManage, or partitioning a very large estate into multiple separate Catalyst SD-WAN overlays — rather than expecting one management plane to scale unboundedly.
WAN Edge down: the smallest blast radius of all, by design — this is exactly what BFD-fed OMP withdrawal (Part 4) exists to detect and route around fast, at the scope of one site rather than the whole fabric.
The pattern across all four: the architecture’s blast radius shrinks as you move from orchestration (vBond) through control (vSmart) to data (WAN Edge), and management plane (vManage) failures are an operations problem, not a forwarding problem — confirmation that separating these four roles was the right call in Part 1, not just an interesting design footnote.
Head-to-head: OMP/TLOC against the other three architectures this site has covered
| Cisco Catalyst SD-WAN | Fortinet ADVPN | Arista DMPO | VMware VeloCloud | |
|---|---|---|---|---|
| Control-plane model | OMP — purpose-built path-vector protocol, ground-up for SD-WAN | BGP over IPsec, hub-and-spoke with on-demand spoke-to-spoke tunnels | Separate BGP-based overlay control plane plus dynamic full-mesh tunnel formation | Centralized orchestrator with gateway-mediated reachability |
| Path-selection unit | TLOC (system-IP + color + encapsulation) | BGP next-hop over a specific IPsec tunnel | BGP next-hop over a DMPO-formed tunnel | Per-edge measured path to gateway/peer |
| SLA-aware steering | App-route policy, fed continuously by BFD | SD-WAN rules driven by performance-SLA health checks | Application-aware path selection over the dynamic mesh | Dynamic Multipath Optimization, continuous per-path scoring |
| Management plane | vManage (templates, API-first) | FortiManager (centralized policy push) | CloudVision | VeloCloud Orchestrator (cloud-hosted) |
| Architectural lineage | Acquired (Viptela) and integrated into IOS-XE over time | Built on existing FortiOS/BGP primitives | Built on existing EOS/BGP primitives | Acquired (VeloCloud) and run largely as its own stack inside VMware/Broadcom |
The honest takeaway isn’t that one of these is simply better — it’s that Cisco is the only one of the four that built an entirely new protocol (OMP) rather than extending BGP, which buys cleaner SD-WAN-native semantics (TLOC as a first-class object, service routes, the multipath model from Part 2) at the cost of being a Cisco-specific protocol with no relationship to anything a non-Catalyst network already runs. The BGP-based architectures (Fortinet, Arista) trade some of that cleanliness for interoperability with existing BGP tooling, skills, and in some designs even existing BGP infrastructure. VeloCloud’s gateway-centric model is the odd one out architecturally, and it’s also the one most overtly built for ISP/MSP-delivered SD-WAN-as-a-service rather than enterprise-self-managed.
What’s next on this site
This closes the Cisco Catalyst SD-WAN series. Two threads are already queued for later: a Cisco SD-WAN certification study series, mirroring the NSE4/NSE5/NSE6 study guides already on this site, and a planned deep dive into Palo Alto Prisma SD-WAN — which will give this site head-to-head architecture coverage of all the major enterprise SD-WAN platforms in one place. Watch this space.