The Three Planes: Management, Control, and Data — and Why Every SD-WAN Argument Comes Back to Them

Why stop and define terms

Every SD-WAN post on this site so far has used the words “management plane,” “control plane,” and “data plane” and quietly assumed you already had a working definition. That’s fine when you’re reading one vendor’s documentation. It stops being fine the moment you’re comparing several — which is exactly what the next two posts on this site do, and what a certain ten-part Cisco Catalyst SD-WAN series starting here on the 6th of July is going to do constantly, often in the same paragraph as words like “OMP” and “TLOC.”

So: one post, no vendor logo in sight, just the vocabulary. Because almost every SD-WAN architecture argument that sounds like a religious dispute — “controllers are a single point of failure,” “you need centralized policy,” “collapsing control into the data plane doesn’t scale” — is actually just two people disagreeing about where a plane should physically live, without ever saying so out loud.

The split is older than SD-WAN

This isn’t an SD-WAN invention. Pull apart any modular router or switch built in the last twenty-five years and you’ll find the same three-way division baked into the chassis. A route processor or supervisor engine runs routing protocols, builds a RIB, computes best paths, and programs the result down into a FIB on every line card. The line cards themselves — ASICs, mostly — do nothing but match a destination against that FIB and forward at line rate. The CPU deciding where packets should go and the silicon actually moving them have been physically separate components inside a single box for decades, for the obvious reason that route computation is comparatively slow and packet forwarding needs to happen at wire speed regardless of how busy the CPU is doing something else.

If you’ve ever reloaded a route processor on a modular chassis and watched the data plane keep forwarding off the last-programmed FIB for several seconds — sometimes longer, on platforms with graceful restart or NSF — before routes start aging out, you’ve already watched this distinction matter in practice. The control plane went away. The data plane, for a while, didn’t notice. That gap between “the brain stopped” and “the hands stopped” is the entire reason this taxonomy exists, and it’s the same gap every SD-WAN vendor is making a deliberate, opinionated choice about when they decide where vSmart, or a Gateway, or nothing at all, should sit relative to the box forwarding your traffic.

Three definitions that actually hold up

It’s worth being precise here, because the three terms get used loosely enough in casual conversation that the looseness itself causes design mistakes.

Data plane

The data plane is whatever actually touches every byte of user traffic. It receives a packet, makes a forwarding decision based on state someone else gave it, and sends the packet on its way — encapsulating it, decapsulating it, applying a NAT translation, dropping it against a firewall policy, whatever the local job requires. The defining property of the data plane is that it operates at the speed and volume of the traffic itself: every packet, every flow, no exceptions, and it has to keep doing this even if every other plane in the architecture has gone quiet.

Control plane

The control plane decides what the data plane should do, without touching the traffic itself. It exchanges routing or reachability information with its peers — other control-plane instances, or in some architectures the data-plane devices acting as their own peers — and the output of that exchange is state: a RIB, a set of TLOCs, a policy decision, something that eventually gets installed somewhere the data plane can act on it. A control plane that goes silent doesn’t directly drop a single packet. What it stops doing is updating the picture — new routes don’t get learned, withdrawn routes don’t get cleaned up, and the data plane keeps forwarding against an increasingly stale view of the world until something ages out.

Management plane

The management plane is where humans, and the tools humans built, look at and change the system. Dashboards, APIs, templates, certificate lifecycle, telemetry collection, alerting. The defining property — and the one most often gotten wrong — is that the management plane has no business being in the per-packet decision loop at all. It configures the control plane and observes the data plane. It doesn’t compute routes and it doesn’t forward bytes.

The distinction everyone blurs

In practice, the pair that gets conflated isn’t control-vs-data — that one’s usually obvious. It’s management vs. control, because in a lot of vendor UIs the dashboard you use to configure policy feels like it’s making routing decisions, even when it categorically isn’t.

Concrete example, drawn straight from coverage already on this site: the Arista/VeloCloud Orchestrator is pure management plane. It holds source-of-truth config, pushes it to Edges, and renders dashboards from telemetry. If it falls over at 3 AM, nothing in the data plane stops, because the actual route exchange between sites happens on the Cloud Gateway, not the Orchestrator — a distinction that post calls out explicitly as the thing people get wrong most often. Fortinet’s FortiManager is the same shape: a management-plane device that pushes configuration to FortiGates and is, deliberately, never in the path of an actual ADVPN negotiation or a forwarded packet.

Now contrast that with a fully decoupled control plane — the kind we’ll see Cisco run with vSmart, where the controller genuinely is computing and reflecting overlay routes between edges, not just storing config for them. Pull that controller and you don’t lose visibility, you lose the ongoing exchange of reachability itself. Existing routes that have already been learned and installed keep working for a while. New ones don’t show up, and withdrawn ones don’t get cleaned up, until something reconnects. That’s a control-plane outage with data-plane consequences on a delay — a fundamentally different failure mode than losing a dashboard.

If you can’t immediately say which of those two failure modes a given vendor’s “controller” produces, you don’t yet know whether you’re looking at a management-plane component or a control-plane one wearing a management-plane-sounding name. That ambiguity is exactly why this post exists.

A fourth plane, briefly

Three planes covers most of networking history, but it doesn’t quite cover every SD-WAN architecture. Some platforms carve out a separate orchestration role: a function whose entire job is first contact — validating a new device’s identity, handling NAT detection, and handing out the addresses of the real management and control plane components — without ever holding ongoing state about routes or configuration itself. It’s deliberately the most stateless, most disposable role in the stack, precisely because its job only matters once, at bring-up.

I’m not going to name names on this one yet. It’s a bigger deal in some architectures than others, and one vendor on this site’s upcoming schedule leans on it heavily enough to earn its own discussion later. For now, just file away that “three planes” is the floor, not the ceiling.

Why SD-WAN reopens a settled argument

Inside a single chassis, all three planes physically coexist on one box, because they have to — there’s nowhere else for them to go. SD-WAN’s entire premise is that this is no longer true. Once your “router” is a fleet of boxes connected over an arbitrary underlay instead of a backplane, every vendor gets an actual architectural choice about where each plane lives relative to the devices doing the forwarding, and that choice is the single biggest fork in the SD-WAN market.

Broadly, there are two shapes this takes:

1. Collapse control onto the data-plane device itself. Every box runs its own routing protocol and decides for itself, the way a traditional router always has — just stitched together over tunnels instead of physical links. Operationally simple, no separate controller to keep alive, but you lose centralized visibility and policy enforcement unless something else — usually a management-plane tool, explicitly out of the decision loop — provides it by pushing consistent configuration everywhere.
2. Decouple control onto a dedicated component, separate from both the forwarding devices and the management tooling. This centralizes decision-making and makes site-to-site policy a single point of authority instead of an emergent property of identical configs — at the cost of introducing a component whose specific failure mode you now have to reason about precisely, in the management-vs-control sense above.

Every SD-WAN vendor on this site so far has picked a point on that spectrum, and picked it for reasons that made sense given who built the product and when. The next post is a look at exactly where those choices came from — three companies, founded within a year of each other, who answered this question three different ways and then mostly got bought by people who wanted the answer they’d built. The post after that lines the surviving architectures up side by side.

A test you can run on any SD-WAN platform

Three questions, regardless of vendor:

1. Where do bytes actually get forwarded?
2. Where does the path decision get made?
3. Where does a human change configuration?

If the answer to (1) and (2) is the same box, you’re looking at a collapsed architecture. If they’re different boxes, you’re looking at a decoupled one — and the real follow-up question, the one that separates a good decoupled design from a fragile one, is: what happens to already-established sessions if the box answering (2) disappears for ten minutes? Everything interesting about SD-WAN control-plane design is hiding behind that one question.

What’s next

Next up: where these philosophies actually came from. Three startups, all founded within about a year of each other in the early 2010s, all solving the same control-plane problem, and — this is the part that’s easy to forget once a technology has settled into “the way things are” — only one of them still exists as an independent product line you can buy under its original name. We’ll also get to the answer for why Cisco, of all vendors, ended up running two completely unrelated SD-WAN architectures in parallel, sold to two different markets, with neither one going away.