Cisco SD-WAN Architecture: Manager, Controller and OMP - 夜莺博客

Cisco SD-WAN Architecture: Manager, Controller and OMP

Cisco Catalyst SD-WAN (formerly Viptela) replaces per-router routing decisions with a centralised controller that distributes routes, policies and encryption keys over an OMP session, while the routers themselves build IPsec tunnels directly with each other. If you can describe four components, two protocols and one attribute (TLOC), you can read any SD-WAN design or troubleshooting document. This article is that mental model, plus the verification commands that prove each plane is up.

The Four Components

  • SD-WAN Manager (vManage) - management plane: inventory, templates, policies, monitoring. The only stateful component, so it is the one that needs backups.
  • SD-WAN Controller (vSmart) - control plane: acts as a route reflector for OMP, holds policy and distributes crypto keys so no IKE runs between sites.
  • SD-WAN Validator (vBond) - orchestration plane: the only component that must be reachable on a public IP; it authenticates edge devices and points them at Manager and Controller, and handles NAT traversal.
  • WAN Edge routers - data plane: vEdge or IOS XE SD-WAN devices that forward traffic, encrypt it, apply QoS and connect the local site.

Control Connections and Where They Go

Every WAN Edge device brings up DTLS or TLS control connections to the Validator first (to learn the addresses of Manager and Controllers), then to Manager and to each Controller over each transport. Those connections live in VPN 0 (transport), while VPN 512 carries out-of-band management. A typical onboarding sequence is visible in the control connection history:

show sdwan control connections
show sdwan control connection-history detail
show sdwan control local-properties
show sdwan system status

If a router shows only a connection to the Validator, the organisation name, certificate or port mapping is wrong. If it connects to Manager but not to Controllers, check the controller group list and the maximum control connection count.

OMP: The Overlay Routing Protocol

OMP runs over those control connections and is the only routing protocol that carries all three SD-WAN route types:

  • OMP routes (vRoutes) - prefixes learned at a site (connected, static, OSPF, BGP) plus attributes such as origin, preference, site ID, VPN and TLOC.
  • TLOC routes - the transport attachment points, made of system IP, colour and encapsulation; this is SD-WAN's equivalent of a next hop.
  • Service routes - services (firewall, IPS, optimisation) available for insertion at a site.
show sdwan omp routes
show sdwan omp tlocs
show sdwan omp peers
show sdwan omp summary

A route is installed in the forwarding table only if the TLOC it points at is up and BFD over the IPsec tunnel is healthy, which is why BFD state is the first thing to check when traffic stops flowing between two sites:

show sdwan bfd sessions
show sdwan bfd history detail
show sdwan tunnel statistics

Design Points That Cause Most Trouble

  • System IP and site ID are unique per device and per site; duplicates break OMP and tunnel formation.
  • OMP advertises only the best path by default - enable backup paths so the edge can make its own decisions, and raise the path limit from 4 to 16 for multi-transport sites.
  • Track a prefix list rather than OMP for VRRP failover; tracking OMP waits for the hold timer and delays convergence.
  • Never use the same colour twice on one edge router, and keep the carrier setting consistent.

For the security side of the same architecture see IPsec/IKEv2 troubleshooting and BGP communities and AS-path filtering for the service-side routing you redistribute into OMP. Campus fabric equivalents are covered in Cisco SD-Access underlay and LISP/VXLAN roles.

原文链接:https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-design-guide.html