How the SD-WAN Controller (vSmart) runs OMP with every WAN Edge, applies centralized control policy, and decides which routes each site learns.
Intermediate · 11 min read
You'll learn to explain why the Controller is the centre of the control plane, say what a centralized control policy can change, and tell a route that was not advertised from one the Controller held back.
Technical definition
SD-WAN Controller (formerly vSmart) is the control plane of Cisco SD-WAN. Every WAN Edge keeps an OMP session with it. It collects the routes, transport locators and services the edges advertise, applies centralized control policy, and sends the resulting routes to the other edges. It also distributes centralized data policy and application-aware routing policy to the edges.
Why BR-02 can see HUB-01's prefixes but not BR-01's
An organisation wants branches to reach the hubs but not each other: BR-01 and BR-02 should send everything through HUB-01 or HUB-02. Nothing is wrong with the routers. The restriction is one line of intent applied on the Controller, which lets BR-01's routes reach the hubs and keeps them from BR-02. This is the Controller's special position: it decides what each site learns, and that is why a missing route in this fabric is often a control policy question and not a fault.
What the Controller holds and sends
Each WAN Edge advertises three kinds of information over OMP, which the OMP lesson describes in detail: OMP routes for prefixes, TLOC routes for transports (see TLOC components) and service routes. The Controller keeps all of it, applies policy, and sends the result to each edge.
What the Controller holds
On small screens, swipe sideways or focus the diagram and use the arrow keys.
It is the routing brain of the overlay.
What the Controller holds and sends
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Read each row across: the left box names the item, the others describe it.
Two kinds of centralized policy
Policy is written once, in the Manager, and activated so the Controller uses it. It is useful to ask where each policy acts, because that decides where to look when it misbehaves.
Control and data policy
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Know which one you need.
Two kinds of centralized policy
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Read each row across: the left box names the item, the others describe it.
This lesson is about the first row. Data policy is covered with application-aware routing in its own lesson.
What a control policy can do
Accept or reject a route, TLOC or service, so a site does not learn about it.
Change an attribute, such as a TLOC preference, so a chosen path is preferred.
Redirect a route to a different TLOC or to a service, for example to force traffic through a hub or a firewall.
Apply to chosen sites, by site list and direction, so the same prefix can look different to two sites.
Hub-and-spoke is the standard example: the Controller keeps branch routes from the other branches and gives each branch the hubs as the way to reach the rest. The branches then only build tunnels to the hubs. The topology in the fabric is a result of control policy, not of how the routers are cabled.
A control policy at work
A control policy example
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Sites then see different topologies.
BR-01 advertises 10.10.1.0/24. The route reaches CTRL-01 over OMP with BR-01's TLOC as the next hop.
The policy is evaluated. CTRL-01 checks the route against the sequences of the active control policy, in order.
A sequence matches. Say it matches routes from site 101 and the action is to send them only to the hubs.
The Controller sends the result. HUB-01 and HUB-02 receive the route. BR-02 does not.
BR-02 has no route. Its OMP table lacks the prefix, and no amount of work on BR-02's tunnels will fix that.
Looking at the Controller's view
show omp peers
On CTRL-01: which OMP peers exist and are they up? The peers are the edges and any other Controllers. On an IOS XE edge the equivalent is show sdwan omp peers.
Example output written for this lesson, simplified; real output has more fields and a different layout
CTRL-01#show omp peers
PEER TYPE DOMAIN OVERLAY SITE STATE R/I/S
10.255.1.1 vedge 1 1 10 up 3/3/4
10.255.1.2 vedge 1 1 20 up 3/3/4
10.255.2.1 vedge 1 1 101 up 4/4/3
10.255.2.2 vedge 1 1 102 up 4/4/3
The Controller has four edge peers, all up. R/I/S is routes received, installed and sent on each. The numbers differ between hubs and branches because policy sends different routes to each. A branch that sends four routes but is sent only the hubs' routes is the hub-and-spoke pattern in the table. The peer type reads vedge in older naming even for IOS XE routers, and the command prefix can differ between platforms and releases.
For one prefix, compare three places in order: the origin edge's OMP advertised routes, the Controller's received routes, and the destination edge's received routes. The first place the prefix is missing shows where it was held back.
Looking at the Controller view
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Compare with the edge.
Where the Controller sits in a failure
Where the Controller sits in a failure
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Each item on the left, with what it means on the right.
Mistakes to avoid
Debugging tunnels on the receiving router when the route did not arrive. Tunnels only matter once the route is in the OMP table.
Assuming a control policy applies to every site. It is attached to site lists and to a direction, so a policy that looks active can still miss the site in question.
Treating the Controller as a forwarding device. It is not in the data path, so it needs no bandwidth for user traffic.
Confusing the Controller with the Validator. The Controller holds routes; the Validator only helps devices join.
Test yourself on the Controller
Predict · scenario 1
What is the Controller's main job in the fabric?
Predict · scenario 2
A control policy on CTRL-01 sends BR-01's routes only to the hubs. What does BR-02 see for 10.10.1.0/24?
Predict · scenario 3
Where is a centralized control policy applied?
Predict · scenario 4
BR-01's prefix is in CTRL-01's received routes but not in BR-02's OMP table. The OMP session to BR-02 is up. What is the most useful next check?
FAQ
Why is a Controller needed if the edges build tunnels to each other?
Because the tunnels need information the edges do not have: which prefixes sit behind which site, and which transport addresses to use. The Controller collects that and passes it on. Without it, every edge would have to be configured with every other edge's details, or run its own full-mesh protocol.
Does the Controller change the data that users send?
No. User packets go from edge to edge in tunnels. The Controller changes what edges know: which routes they receive, which next hops those routes have, and which policy they apply. The effect on traffic is indirect, through those routes.
How many Controllers should a network have?
More than one in production, so one failure does not remove the control plane. The supported numbers and how edges are spread across them depend on the release and the platform, so check your release and design guide rather than a general figure.