Skip to content
Log in Sign up My account

3.4 Cisco SD-WAN Architecture

Blueprint 3.4: Cisco SD-WAN architecture

  • Orchestration plane
  • Management plane
  • Control plane
  • Data plane
  • Onboarding and provisioning
  • Security

The ENSLD angle is the design consequences of each plane: what each component needs, what happens when it fails, and why the architecture is built this way. The element list and the OMP basics are on the ENCOR SD-WAN page, so this page does not repeat them. Cisco now calls the solution Catalyst SD-WAN. Former names are in brackets.

The four planes and what fails when they fail

Plane Component Job If it is unavailable
Orchestration SD-WAN Validator (vBond) First contact, authenticates devices, tells them where Controllers and Manager are, helps with NAT traversal New devices cannot join. Existing sites keep working.
Management SD-WAN Manager (vManage) Templates and configuration groups, monitoring, policy authoring, software upgrades, API No configuration changes or new monitoring data. Running network is unaffected.
Control SD-WAN Controller (vSmart) OMP route, TLOC and key distribution, centralised policy Edges keep forwarding with the last known state for a graceful-restart period. Then routes age out.
Data WAN Edge (cEdge, vEdge) IPsec tunnels, BFD, forwarding, local policy, QoS, security features The site is down.

This table is the heart of the high-availability discussion: the data plane is autonomous in the short term. A Manager outage is an operations problem. A Controller outage becomes a forwarding problem only if it lasts longer than the OMP graceful-restart timer. A Validator outage matters only when devices need to (re)join.

graph TB
  subgraph Mgmt ["Management plane"]
    M["SD-WAN Manager cluster"]
  end
  subgraph Orch ["Orchestration plane"]
    V1["Validator 1"]
    V2["Validator 2"]
  end
  subgraph Ctl ["Control plane"]
    C1["Controller 1"]
    C2["Controller 2"]
  end
  subgraph DP ["Data plane"]
    E1["WAN Edge A"]
    E2["WAN Edge B"]
  end
  M -- "NETCONF" --- E1
  M -- "NETCONF" --- E2
  V1 -. "initial auth, DTLS" .- E1
  C1 -- "OMP over DTLS or TLS" --- E1
  C2 -- "OMP over DTLS or TLS" --- E2
  C1 -- "OMP" --- C2
  E1 == "IPsec tunnels + BFD" ==> E2

Overlay concepts you need for design

Term Meaning Design use
System IP Unique router ID of the device in the overlay Must be unique per device
Site ID Numeric site identifier. Both edges at one site share it Policy is applied per site. Two sites with the same ID is an error
TLOC Transport Locator: system IP + colour + encapsulation. The address of a tunnel endpoint Policy chooses between TLOCs
Colour Label for a transport (mpls, biz-internet, lte, and so on) Public colours expect NAT. Private colours (such as mpls) expect direct reachability.
VPN (segment) VRF-like service segment. VPN 0 is transport, VPN 512 is management Segmentation across the whole fabric
OMP Overlay Management Protocol: carries routes, TLOCs and service routes between edges and controllers Overlay control plane

Public versus private colour matters in design. Public colours (the Internet, LTE) tell the edge to expect that the other side may sit behind NAT, so it uses the Validator-learned public address. Private colours use the private address. If two private-colour TLOCs would need to talk across the Internet, the tunnel does not form unless you adjust the colour behaviour. Carrier colour restrictions can be set to avoid trying certain pairs. The restrict option on a tunnel interface stops it forming tunnels with TLOCs of a different colour, which reduces tunnel count.

Control plane

Each edge builds a control connection (DTLS by default, or TLS) to the Controllers over each transport, and a control connection to the Manager. The Controllers form a full mesh among themselves. OMP then carries:

  • OMP routes: prefixes learned on the LAN side (connected, static, OSPF, EIGRP, BGP), tagged with their VPN, origin and TLOC.
  • TLOC routes: where the tunnel endpoints are and what colours and encryption they use.
  • Service routes: where services such as firewalls are attached.
  • Encryption keys for the data plane (in modern deployments, one per edge per transport).

The Controller acts like a route reflector and also applies centralised control policy. By default every edge learns every route. A control policy can change that, for example to make branches reach each other only through a hub, or to influence the next TLOC.

Data plane

Edges build IPsec tunnels directly to each other across every transport they have, so the data plane is any-to-any by default, subject to policy. There is no IKE between edges. The Controller distributes the keys over OMP, which is why the fabric scales to thousands of sites without a pairwise negotiation. BFD runs inside every tunnel to detect failure and to measure loss, latency and jitter. Those measurements feed application-aware routing policy, which picks a path per application that meets an SLA class.

Centralised data policy acts on traffic passing through the edge (for example, send voice over MPLS), while localised policy is configured on the edge itself (QoS, ACLs, and route policy toward the LAN).

Management plane

The Manager is the single pane for configuration and monitoring and the home of the REST API. Design aspects:

  • Templates vs configuration groups. Feature and device templates are the older model. Configuration groups and policy groups are the newer workflow with less template sprawl. Use one consistently.
  • Cluster. A Manager cluster (multiple nodes) provides scale and availability. A single node is a single point of failure for operations.
  • Deployment model. Controllers and Manager can be cloud-hosted by Cisco, hosted by a partner, or on-premises. Cloud-hosted lowers operational effort. On-premises satisfies data-residency or air-gapped requirements.
  • Multitenancy is supported for service providers and large enterprises that need separation of administration.

Onboarding and provisioning

sequenceDiagram
  participant E as New WAN Edge
  participant P as Plug and Play portal
  participant V as Validator
  participant C as Controller
  participant M as Manager
  E->>P: Ask for the Validator address (zero-touch)
  P-->>E: Validator address
  E->>V: DTLS, mutual certificate authentication
  V-->>E: Controller and Manager addresses
  E->>C: Control connection, OMP
  E->>M: Control connection
  M-->>E: Configuration pushed via template or group

The steps and design points:

  1. Device identity. Each edge has a certificate (from the device chassis or from your enterprise CA, depending on platform and design) and a serial number.
  2. Authorised list. The serial numbers are loaded into the Manager (via the Cisco Smart Account and Plug and Play connect portal) and the Validator checks the device against that list.
  3. Zero-touch. The edge finds the Validator through Plug and Play, DNS or a bootstrap file. It needs only basic IP connectivity on one transport (DHCP on a WAN port is typical).
  4. Initial configuration. The Manager pushes the full configuration after the device joins.
  5. Manual bootstrap. Where there is no ZTP path (for example, a locked-down site), engineers load a minimal configuration with Validator address, organisation name, site ID and system IP.

The organisation name must match across all controllers and edges. Time must be consistent because certificates are time-sensitive. A router with the wrong clock cannot join.

Security architecture

Layer Mechanism
Authentication Mutual certificate authentication between every device and the controllers. Only devices on the authorised list can join.
Control plane DTLS or TLS between edge and Controller/Manager.
Data plane IPsec tunnels between edges. Keys are generated and rotated centrally (rekey timer is configurable) and distributed over OMP. Anti-replay is built in.
Segmentation VPNs (segments) are carried over the overlay with a label in the data packet, so traffic from one VPN cannot reach another unless leaked by policy or routed through a firewall.
Enterprise firewall and IPS Zone-based firewall, and on supported platforms Snort IPS, URL filtering, advanced malware protection and DNS-layer security as integrated features.
Cloud security Integration with a secure internet gateway or security service edge for branch Internet traffic.
Access control Role-based access on the Manager. Control-plane allow-lists.

The edge firewall for the transport interface should allow only the control-plane and IPsec ports needed. The Validator and Controllers must be reachable on public addresses from edges across the Internet, so they sit in a DMZ or the cloud with controlled exposure.

Design exercise

Scenario. A manufacturer with 800 sites is moving to SD-WAN. The security team requires that no device can join the network without being on an approved list, that data-plane traffic is encrypted without a manual key process, and that a loss of management systems must never stop plant traffic. Operations wants new branches to be deployed by a non-technical person plugging in a box.

Requirements and constraints.

  • Only approved devices may join.
  • Encrypted data plane at scale with no pairwise IKE management.
  • Management outage must not stop forwarding.
  • Zero-touch deployment.
Model answer
  • Onboarding: use zero-touch provisioning with Plug and Play and the authorised device list on the Validator. The edge finds the Validator, presents its certificate and serial number and is only admitted if listed. The Manager then pushes configuration.
  • Encryption at scale: the Controllers generate and distribute data-plane keys over OMP. Edges form IPsec tunnels without IKE negotiation. This is the reason the fabric scales to hundreds of sites without a key-management project.
  • Failure behaviour: the data plane runs on the last-known control state, so a Manager outage only blocks change and monitoring. Deploy at least two Controllers and two Validators, ideally in different locations or clouds, and a Manager cluster, because the Controller is the only component whose long outage affects forwarding.
  • Rejected: a DMVPN overlay with per-hub IPsec and manual provisioning would meet encryption but not ZTP or centralised policy. Cloud-only management without any redundancy would be a single point of failure for operations.

Exam trap

The Validator is not in the data or control path. It is used at the start and for NAT discovery. Losing it does not break existing tunnels. Candidates often choose the Controller or Validator as the "device that forwards data". Only WAN Edges forward user traffic.

Exam trap

SD-WAN edges do not run IKE to each other. The key comes from the Controller via OMP. A scenario asking why SD-WAN scales better than DMVPN or IPsec for any-to-any encryption points to centralised key distribution.

Exam trap

Colour is not just a label. Public colours (such as biz-internet and lte) imply NAT traversal behaviour. Private colours (such as mpls) imply direct reachability. A mismatch is a common reason tunnels between two transports do not form.

Quick check

A Manager cluster is down for two hours. What happens to user traffic?

Nothing. The data plane and the control plane keep running. Operators cannot change configuration or see new monitoring data until the Manager returns.

What does the Validator tell a new edge?

Where the Controllers and the Manager are. It also authenticates the edge and learns its public address, which helps with NAT traversal. The connection is then closed.

Why is there no IKE negotiation between edges?

The Controller distributes the data-plane encryption keys to the edges over OMP, so each edge already has the keys it needs to build IPsec tunnels with its peers.

References

  • Cisco Catalyst SD-WAN Design Guide and Getting Started Guide: search "Cisco Catalyst SD-WAN Design Guide" on cisco.com or the Cisco SD-WAN product pages at developer.cisco.com
  • Cisco Live On-Demand Library: search "SD-WAN architecture", "SD-WAN onboarding", "SD-WAN security"
  • RFC 6347 (DTLS 1.2), RFC 4303 (ESP)