Cisco Catalyst SD-WAN Architecture: Planes and Components - 夜莺博客

Cisco Catalyst SD-WAN Architecture: Planes and Components

Cisco Catalyst SD-WAN (the platform formerly named Viptela) gets easier to operate once you stop thinking of it as "routers with a controller" and start mapping every fault to one of four planes. This article lays out the components, the protocols between them, the onboarding sequence, and - most useful in an incident - which failures stop forwarding and which do not.

The Four Planes

Plane Component Job
Management SD-WAN Manager (vManage) Configuration templates, policy authoring, monitoring, image management, APIs
Orchestration SD-WAN Validator (vBond) Admits devices (whitelist), distributes controller lists, NAT traversal
Control SD-WAN Controller (vSmart) Route aggregation and distribution over OMP, policy enforcement
Data WAN Edge (cEdge on IOS-XE, vEdge on Viptela OS) Actual forwarding between sites and to the internet

Two exam-relevant facts that matter in production as well: vManage is not in the forwarding path, so data keeps flowing when it is down; and vBond is only consulted at onboarding or re-authentication, which is why a vBond outage rarely takes down established tunnels but blocks every new site.

Protocols Between the Planes

  • OMP - the overlay routing protocol between WAN Edge and vSmart. Mismatched organisation names or a duplicate system IP break OMP adjacency.
  • DTLS/TLS - control and management sessions between edges and controllers. Strict firewalls often force TLS.
  • IPsec/GRE - tunnels between TLOCs, with BFD probing per tunnel for sub-second detection.
  • NETCONF/gRPC over TLS - vManage pushing configuration and collecting telemetry.

Onboarding a WAN Edge

  1. Edge boots with a bootstrap configuration: system-ip, site-id, organisation name, and the vBond address.
  2. Edge authenticates to vBond and receives the controller list.
  3. Edge builds DTLS/TLS sessions to vSmart and to vManage.
  4. vManage pushes a device template; the edge forms IPsec tunnels with its TLOC peers and starts OMP with vSmart.
sdwan
 system-ip 10.255.0.11
 site-id 101
 organization-name ACME-Global
 vbond 198.51.100.10
!

Failure Modes Worth Memorising

  • Duplicate system IP or site ID - control anomalies, tunnels suppressed, OMP flapping.
  • Organisation-name mismatch - OMP adjacency never forms; the error is explicit if you read show sdwan control connections.
  • Certificate expiry or revocation - devices are rejected at re-authentication; a fleet-wide CA rollover without a staged plan is a classic self-inflicted outage.
  • Clock skew - certificate validation fails; NTP is a hard dependency, not a nicety.

Verification Commands

show sdwan control connections
show sdwan control local-properties
show sdwan omp peers
show sdwan bfd sessions
show sdwan ipsec inbound-connections

Read them in that order: control connections first (trust and reachability), then OMP peers (routing), then BFD and IPsec (forwarding). Automation is the norm in these fabrics, so keep configuration work in templates and validate changes with the same expectation as any other platform - the tooling patterns are in NETCONF, RESTCONF and gNMI compared and Ansible network modules. For path preference and health tracking on classic IOS, the older mechanisms still appear in hybrid designs - see IP SLA and track objects.

原文链接:https://nhprep.com/course/sdwan-lab-01-architecture/lesson/sdwan-architecture-overview