SD-WAN Control Plane Showdown: Three Philosophies for Solving the Same Problem
The same problem, three answers
Two posts ago we drew the line between collapsed and decoupled control planes. Last post traced where the decoupled answer actually came from. This post is where that builds to something useful: every major SD-WAN architecture this site has covered so far — Fortinet, Arista/VeloCloud, and the Cisco/Viptela series starting on the 6th — sits at a different point on that spectrum, and once you’ve seen all three side by side, the differences stop being trivia and start being a checklist you can run against any vendor’s pitch deck.
Three questions, same as before: where does forwarding happen, where does the path decision get made, and what happens when the thing answering that second question goes quiet. Let’s run all three vendors through it.
Philosophy 1: collapse it — Fortinet’s ADVPN and BGP
Fortinet’s answer is the simplest to state and the easiest to underestimate: there is no separate control-plane device, full stop. Every FortiGate — hub or spoke — runs its own routing protocol instance and makes its own forwarding decisions, the same way a traditional router always has. ADVPN dynamically negotiates direct spoke-to-spoke tunnels on demand instead of forcing all traffic through a hub, and BGP running over the overlay is what actually exchanges reachability between sites — IBGP typically, with the hub frequently acting as route reflector for exactly the iBGP-scaling reason any route reflector exists.
FortiManager sits entirely outside this loop. It pushes configuration templates to FortiGates and has no part in route exchange or packet forwarding — pure management plane, by design. Pull it, and every FortiGate keeps doing exactly what it was already doing: negotiating ADVPN shortcuts, exchanging BGP routes, forwarding traffic. You lose the ability to push a new policy. You lose nothing about the overlay’s ability to keep running itself.
The trade-off is the one you’d expect from collapsing control onto the data plane: there’s no single place to query “what does the whole overlay’s routing table look like right now” — you’re reading BGP tables off individual FortiGates, the same way you would on any BGP network that predates SD-WAN entirely. Centralized policy exists, but it’s an emergent property of every box running consistent configuration, not an enforced property of a controller refusing to advertise a route it doesn’t like. PKI-based IPsec and resilience design on this architecture are both about making that emergent property trustworthy at scale, because there’s no controller doing it for you.
Philosophy 2: co-locate it — Arista/VeloCloud’s Gateway
Arista/VeloCloud splits the difference. There’s no separate “controller” appliance — but there is a separate device from the Edge: the Cloud Gateway (or Partner Gateway), a multi-tenant component that runs control and data-plane-relay functions together, in the same process, while staying physically distinct from both the Edges doing local forwarding and the Orchestrator doing management.
Every Edge advertises what it can reach to its assigned Gateways; the Gateway redistributes that to every other Edge in the tenant — functionally a route reflector, even though the protocol underneath isn’t BGP and isn’t OMP, it’s VeloCloud’s own overlay exchange. The Orchestrator, true to the management-plane definition from two posts back, never participates in that exchange at all — config and telemetry only, over HTTPS, completely separate from the VCMP tunnels carrying both the control exchange and the user data.
Pull every Gateway an Edge is homed to, and the failure mode is genuinely nuanced: that Edge stops learning new routes, but tunnels it already built keep forwarding against last-known-good state for as long as DMPO’s path measurements stay current. That’s a meaningfully softer failure than either of the other two philosophies, precisely because the Gateway never held exclusive forwarding responsibility for anyone else’s traffic — Direct mode lets Edges bypass the Gateway in the data plane entirely, even while depending on it for control.
Philosophy 3: decouple it fully — Cisco/Viptela’s vSmart and OMP
Cisco’s Viptela-lineage architecture goes further than either: it has a dedicated, stateful controller — vSmart — that does nothing else except hold and reflect overlay routing state via OMP, a protocol deliberately modeled on BGP closely enough that the route-reflector analogy is structural, not a loose metaphor. Every WAN Edge peers with every vSmart in its domain — never with other edges directly for route exchange — and vSmart reflects between them. Management (vManage) and orchestration (vBond) are separate components again, neither one touching OMP at all.
This is the most thoroughly decoupled of the three philosophies on this site, and the trade-off cuts both ways. The upside: vSmart is the one place with full visibility into the overlay’s routing state, and the one enforcement point for centralized control policy — no emergent consistency required, because there’s a single authority. The downside is the one Fortinet’s model sidesteps entirely: vManage’s own scaling story gets genuinely difficult north of a few thousand edges, because every template render and every statistics poll lands on the same database, in a way that has no equivalent bottleneck in a fully collapsed architecture where there’s no central database at all.
And the failure mode, worked through with the same rigor as the other two: pull every vSmart an edge is connected to, and — structurally identical to losing every Gateway in the Arista model — that edge stops learning new OMP routes and stops cleaning up withdrawn ones, while already-built IPsec tunnels keep forwarding until BFD or route aging eventually catches up. Decoupled doesn’t mean fragile. It means the failure shows up as staleness, not an immediate outage — exactly the management-vs-control distinction from two posts ago, just one level deeper, applied to a control plane that’s lost its own upstream.
Side by side
| Fortinet | Arista/VeloCloud | Cisco/Viptela | |
|---|---|---|---|
| Control plane location | Collapsed onto every data-plane device | Collocated with data-plane relay on the Gateway | Fully separate (vSmart) |
| Route exchange protocol | BGP (typically iBGP over the overlay) | Proprietary overlay exchange | OMP (BGP-flavoured) |
| Management plane | FortiManager — push-only, out of loop | Orchestrator — push/pull, out of loop | vManage — push/pull, out of loop |
| Orchestration plane | None — no separate first-contact role | None distinct from Orchestrator/Gateway | vBond — dedicated, stateless |
| Central routing authority | None — emergent from consistent config | Gateway, per tenant | vSmart, per domain |
| If the control function disappears | Nothing — every box already had its own view | New routes stop; existing tunnels keep forwarding | New routes stop; existing tunnels keep forwarding |
| Known scaling pressure point | Mesh/hub design at the data-plane layer | Gateway capacity per tenant | vManage database past ~2-3k edges |
Why this isn’t an arbitrary choice
None of these three philosophies is “more correct.” Each one is the right answer for the constraints its builders were actually solving for. Fortinet’s collapsed model comes from a company whose every device was already a capable router and firewall before SD-WAN existed — collapsing control onto hardware that was already doing routing was the path of least resistance, and it inherits decades of BGP operational tooling for free. Arista/VeloCloud’s Gateway model comes from a company building a clean-slate, cloud-hosted overlay aimed at exactly the MPLS-to-internet transition problem, where a multi-tenant cloud relay was the whole point from day one. Cisco/Viptela’s fully decoupled model comes from a company whose founders had explicitly built route-reflector-scale thinking into the architecture from the start, aimed at the largest, most policy-heavy enterprise WANs on the planet.
The practical upshot for anyone evaluating or operating one of these: don’t ask “is the controller a single point of failure” as a yes-or-no question. Ask what specifically stops working, on what timescale, and what keeps running regardless. All three answers in this post survive a controller outage better than the phrase “single point of failure” implies — they just degrade in different, specific, knowable ways, and now you know what to actually test in each one.
What’s next
Next up, starting on the 6th: ten parts on Cisco Catalyst SD-WAN, going considerably deeper than this post had room for — vBond’s NAT-detection handshake, OMP’s actual route types, the certificate trust model underneath every control connection, and eventually the cutover playbook, automation, and scale-limit numbers this post only gestured at. If the vSmart/OMP section above raised more questions than it answered, that’s by design — Part 2 picks up exactly there.