> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Control Plane vs Data Plane vs Management Plane in SD-WAN - URL: https://www.pinglabz.com/sd-wan-control-plane/ - Published: 2026-11-05T15:58:11.000Z - Updated: 2026-11-05T15:58:11.000Z - Description: Cisco SD-WAN splits the job into control, data and management planes. I captured 1,000 pings in my home lab to prove it: user traffic went edge to edge over IPsec, and the Controller saw none of it. - Author: Jaime - Tags: SD-WAN, Cisco You ping from one branch to another and it works. So which box carried the packets? Many people new to Cisco SD-WAN guess the Controller, because it sounds like the center of everything. It isn't. The Controller tells routers where to send traffic, but it never forwards a single user packet. This post splits SD-WAN into its planes, says which box works in each one, and then proves the split with a packet capture and interface counters. I built the overlay in my home lab on Cisco Catalyst SD-WAN 20.18.2.1, with C8000v WAN Edge routers on IOS XE 17.18.02. This is part of the [Cisco SD-WAN series](https://www.pinglabz.com/cisco-sd-wan/). The previous part, [Cisco Catalyst SD-WAN Components](https://www.pinglabz.com/cisco-sd-wan-components/), covers what each box is. New to the topic? Start with [What is SD-WAN?](https://www.pinglabz.com/what-is-sd-wan/). If you learned the old names, keep the [name map](https://www.pinglabz.com/vmanage-vsmart-vbond-names/) handy: SD-WAN Manager (formerly vManage), SD-WAN Controller (formerly vSmart) and SD-WAN Validator (formerly vBond). ## The problem: one router did all three jobs On a classic router, three jobs share one box. You configure it (management). It runs OSPF or BGP to work out where prefixes live (control). It moves packets out the right interface (data). When a router's CPU is busy with a routing storm, the same box is also trying to forward your traffic. SD-WAN pulls those jobs apart and gives each one its own home. ## The idea: planes are jobs, not boxes Think of a taxi company. The office takes bookings and keeps the records. The dispatcher tells each driver where to go. The drivers carry the passengers. The dispatcher never drives anyone anywhere, and the office never talks to drivers about routes. Cisco's design guide describes four planes: | Plane | Job | Box in Cisco Catalyst SD-WAN | Taxi company | | ------------- | --------------------------------------------------- | ---------------------------- | -------------------------------------- | | Management | Central configuration and monitoring | SD-WAN Manager | The office | | Control | Builds the topology and decides where traffic flows | SD-WAN Controller | The dispatcher | | Orchestration | Onboards new routers and helps with NAT | SD-WAN Validator | The front desk that checks new drivers | | Data | Forwards packets based on control-plane decisions | WAN Edge router | The drivers | The Validator's job is mostly done once a router has joined, so this post focuses on the other three. ## The parts: what each plane carries **Management plane.** The Manager pushes configuration to the routers and collects statistics. It talks to each router over a DTLS control connection. In my lab, each edge has exactly one connection to the Manager, on the mpls color only. **Control plane.** The Controller runs OMP (Overlay Management Protocol) with every WAN Edge router. Routers send it their prefixes, their transport details (TLOCs) and their IPsec keys. The Controller reflects them to the other routers. Cisco calls it a route reflector, and like a route reflector it is not in the forwarding path. **Data plane.** The WAN Edge routers build IPsec tunnels straight to each other, one per pair of transport colors that are allowed to talk. BFD runs inside each tunnel to check that it is alive. User traffic only ever rides these tunnels. Here is the split in one routing table. edge1 learned the remote LAN from OMP (code `m`), but the next hop is edge2's system IP, 10.0.0.2\. It is not the Controller, 1.1.1.2: ``` edge1#show ip route vrf 10 ... C 192.168.10.0/24 is directly connected, GigabitEthernet4 L 192.168.10.1/32 is directly connected, GigabitEthernet4 m 192.168.20.0/24 [251/0] via 10.0.0.2, 10:25:13, Sdwan-system-intf ``` The Controller handed out the route, but the route points at the other edge. ## The lab | Device | Role | System IP | Transport address | | ----------------- | ------------- | --------- | ---------------------------------------- | | SD-WAN Manager | Management | 1.1.1.1 | 172.16.10.10 | | SD-WAN Controller | Control | 1.1.1.2 | 172.16.20.20 | | SD-WAN Validator | Orchestration | 1.1.1.3 | 172.16.30.30 | | edge1 (site 100) | Data | 10.0.0.1 | 10.10.1.11 mpls, 10.20.1.11 biz-internet | | edge2 (site 200) | Data | 10.0.0.2 | 10.10.2.12 mpls, 10.20.2.12 biz-internet | h1 (192.168.10.10) sits behind edge1 and h2 (192.168.20.10) sits behind edge2, both in service VPN 10\. A small router in the middle plays the WAN. It has one port facing each control component and one facing each edge transport, so I can capture on any link. ### Who talks to whom First, the control plane. edge1 has DTLS sessions to the Controller (`vsmart`) on both colors, to the Validator (`vbond`) on both colors, and to the Manager (`vmanage`) on mpls only: ``` edge1#show sdwan control connections PEER PEER PEER SITE ... PEER PRIVATE IP PORT ... LOCAL COLOR PROXY STATE UPTIME TYPE PROT SYSTEM IP ID vsmart dtls 1.1.1.2 1000 ... 172.16.20.20 12346 ... mpls No up 0:10:28:01 vsmart dtls 1.1.1.2 1000 ... 172.16.20.20 12346 ... biz-internet No up 0:10:28:01 vbond dtls 0.0.0.0 0 ... 172.16.30.30 12346 ... mpls - up 0:10:28:01 vbond dtls 0.0.0.0 0 ... 172.16.30.30 12346 ... biz-internet - up 0:10:28:01 vmanage dtls 1.1.1.1 1000 ... 172.16.10.10 12746 ... mpls No up 0:10:28:01 ``` (Columns trimmed to fit. The Validator sessions stay up here because there is only one Controller. That is covered in the components post.) Then the data plane. edge1 has IPsec tunnels with BFD to edge2, one on each color, and to nothing else: ``` edge1#show sdwan bfd sessions SYSTEM IP SITE ID STATE SOURCE TLOC COLOR REMOTE TLOC COLOR SOURCE IP DST PUBLIC IP DST PUBLIC PORT ENCAP 10.0.0.2 200 up mpls mpls 10.10.1.11 10.10.2.12 12426 ipsec 10.0.0.2 200 up biz-internet biz-internet 10.20.1.11 10.20.2.12 12426 ipsec ``` No BFD session or tunnel points at 1.1.1.1, 1.1.1.2 or 1.1.1.3. ## Proof 1: a packet capture on every link I captured for 30 seconds on four links at once while h1 pinged h2 twenty times with 1000-byte payloads: ``` h1$ ping -c 20 -s 1000 192.168.20.10 20 packets transmitted, 20 received, 0% packet loss rtt min/avg/max = 1.250/2.006/4.034 ms ``` A 1000-byte ping inside IPsec shows up on the wire as a 1062-byte UDP packet (that is what tcpdump printed as the UDP length). So the question is simple: which links carried 1062-byte packets? | Link captured | Top conversations | Packets of 1000 bytes or more | | -------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------- | | Controller transport | Only UDP 12346 (DTLS) with the Manager, Validator and both edges, plus a little ARP and ICMP | **0** (largest packet: 553 bytes) | | edge1 biz-internet | 10.20.1.11:12406 ↔ 10.20.2.12:12426 | 20 (edge1 to edge2, the echo requests) | | edge1 mpls | 10.10.1.11:12406 ↔ 10.10.2.12:12426 | 20 (edge2 to edge1, the echo replies) | | edge2 mpls | same tunnel, seen from edge2's side | 20 (edge2 to edge1, the echo replies) | The summary for the Controller link, from tcpdump: ``` 38 172.16.20.20.12346 > 172.16.10.10.12346 36 172.16.10.10.12346 > 172.16.20.20.12346 29 172.16.20.20.12346 > 10.20.2.12.12426 29 172.16.20.20.12346 > 10.20.1.11.12406 29 172.16.20.20.12346 > 10.10.2.12.12426 29 172.16.20.20.12346 > 10.10.1.11.12406 29 10.20.2.12.12426 > 172.16.20.20.12346 29 10.20.1.11.12406 > 172.16.20.20.12346 big(>=1000): ``` That last line is empty. Every packet the Controller sent or received was a control packet on port 12346. One detail is a bonus lesson. The requests went out on biz-internet and the replies came back on mpls. Each edge picks a tunnel on its own from the equal-cost paths OMP gave it. That is normal, and it is the data plane making its own decisions with the routes the control plane handed over. [![Diagram: Packet capture result of 1,000 pings between two SD-WAN sites. Requests travel host to edge1 to edge2 to host over the biz-internet IPsec tunnel (1062 B); replies return over mpls (dashed). Thin orange DTLS 12346, OMP only links climb from each WAN Edge to the SD-WAN Controller at 1.1.1.2. Callouts note the Controller link carried 0 packets of 1000 bytes or more (largest 553) and that Controller RX rose by only +121 packets during the 1,000 pings.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-control-plane.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-control-plane.png?ref=pinglabz.com) ## Proof 2: counters before and after 1000 pings A capture shows twenty packets. Counters show scale. I read the Controller's transport interface and edge1's tunnel counters, sent 1000 pings of 1000 bytes from h1 to h2, and read them again. It took about 28 seconds. ``` controller# show interface vpn 0 eth1 | tab (RX PACKETS / TX PACKETS) before: 251509 242493 after: 251630 242609 ``` ``` edge1#show sdwan tunnel statistics before after mpls tx_pkts 83179 83223 (+44) mpls rx_pkts 83226 84270 (+1044) biz-internet tx_pkts 83239 84283 (+1044) biz-internet rx_pkts 83191 83235 (+44) ``` edge1 sent 1044 packets on its biz-internet tunnel and received 1044 on its mpls tunnel: the 1000 pings plus the BFD hellos. The Controller moved 121 packets in and 116 out during the same time. That is its normal background of DTLS keepalives and OMP hellos, roughly four packets a second, with or without the ping. If the Controller were in the path, its counters would have jumped by at least 2000. ## Verify it yourself You don't need a capture to see the split. Three commands tell the story: 1. On the Controller, `show omp summary`. Mine shows `routes-received 18` and `routes-installed 0`. It learns routes and installs none, so it has nothing to forward with. 2. On an edge, `show ip route vrf `. OMP routes (`m`) point at the remote edge's system IP, never at the Controller. 3. On an edge, `show sdwan bfd sessions`. Every session is to another WAN Edge router. ``` controller# show omp summary personality vsmart routes-received 18 routes-installed 0 routes-sent 6 tlocs-received 4 tlocs-installed 4 vedge-peers 2 ``` ## What breaks, and in which plane Knowing the plane tells you where to look. | Symptom | Plane | First place to look | | ---------------------------------------------------------------------------- | ------------- | -------------------------------------------------- | | Can't push a config, device shows unreachable in the GUI, but users are fine | Management | show sdwan control connections for the vmanage row | | A new branch never learns remote prefixes | Control | show sdwan omp peers (state up, R/I/S counts) | | Routes are there but pings fail or are slow | Data | show sdwan bfd sessions, then the tunnel counters | | A new router never gets past the Validator | Orchestration | Org name, root CA, device list and clock | What happens if the Controller goes away? Cisco's design guide says OMP graceful restart keeps the edges forwarding on the last routes and keys they learned, for 12 hours by default. Traffic keeps flowing on the existing tunnels, but nothing new is learned until the Controller comes back. I did not test this in the lab, so take it from the design guide for now. The Manager going down is gentler still. You lose the GUI, the API and the statistics. Routing and forwarding don't notice. ## Key takeaways - Planes are jobs. Management configures, control decides, data forwards. Orchestration helps new routers join. - The SD-WAN Controller is a route reflector. In my lab it learned 18 routes and installed none. - User traffic rides IPsec tunnels straight between WAN Edge routers. My capture found zero user-sized packets on the Controller's link, and 1000 pings barely moved its counters. - When something breaks, name the plane first. It tells you which command to run. Next in the series: OMP itself, and why it feels so much like BGP.