SD-WAN Centralized Control Policy: Shaping the Overlay

Here is the thing that makes SD-WAN fundamentally different from a traditional WAN: you do not configure routing policy on the routers. You configure it once, centrally, on the Controller, and it shapes what every WAN Edge sees. A centralised control policy is a single document that decides the topology, the path preferences, and the reachability of your entire overlay - and no edge device holds a copy.

This article covers centralized control policy: what it is, how it shapes the fabric, and the classic use cases. It extends the complete SD-WAN guide. Command and policy syntax is drawn from Cisco's current 20.x documentation, clearly labelled as a documented reference.

The mental model: policy at the route reflector

Recall from the OMP deep dive that the Controller (vSmart) is a route reflector - every edge peers with it, and it redistributes OMP routes and TLOCs between them. A centralised control policy is a filter applied at that reflector, on the OMP updates flowing through it.

Because it sits at the reflector, one policy controls what every edge learns. Change the policy once on the Controller, and the entire overlay's topology and path preferences change. This is the direct analogue of applying a route-map at a BGP route reflector - except here it is the standard operating model, not an advanced trick.

The crucial consequence: control policy shapes the control plane, not the data plane. It decides which routes and TLOCs an edge learns, and with what preferences. It does not touch individual packets - that is data policy's job (covered next). Control policy draws the map; data policy directs the traffic on it.

Anatomy of a control policy

A centralised control policy has a familiar structure - a list of sequences, each with a match and an action, applied in a direction to a list of sites:

policy
 control-policy PREFER-MPLS
  sequence 10
   match tloc
    color mpls
   !
   action accept
    set
     preference 200          ! make MPLS TLOCs more preferred
    !
   !
  !
  sequence 20
   match route
    prefix-list CORPORATE-PREFIXES
   !
   action accept
    set
     preference 100
    !
   !
  !
  default-action accept
 !
!
apply-policy
 site-list BRANCH-SITES
  control-policy PREFER-MPLS out       ! 'out' = toward the edges
 !
!

Read that structure and it is BGP policy in different clothing: match on TLOC (colour) or route (prefix), take an action (accept/reject), set an attribute (preference), and apply it in a direction to a set of sites. The out direction means "as OMP updates leave the Controller toward these edges" - which is how you control what those edges learn.

The classic use cases

1. Path preference (prefer one transport)

The most common control policy: make branches prefer MPLS over internet (or vice versa) by setting a higher preference on one colour's TLOCs, as in the example above. Every branch in the site-list now prefers the chosen transport, set in one place. To flip the whole estate to prefer internet, you change one number on the Controller.

2. Topology control: hub-and-spoke vs full mesh

By default SD-WAN is a full mesh - every edge can build a direct tunnel to every other edge. Often you do not want that; you want spokes to reach each other only via a hub (for a firewall, for scale, for simplicity). Control policy builds the topology by controlling which TLOCs each site learns:

control-policy HUB-AND-SPOKE
 sequence 10
  match route
   prefix-list SPOKE-PREFIXES
  !
  action accept
   set
    tloc-list HUB-TLOCS          ! rewrite the next-hop TLOC to the hub
   !
  !
 !

By rewriting the TLOC of spoke prefixes to point at the hub, spokes reach each other through the hub - a hub-and-spoke overlay built entirely by policy, with no per-device configuration. This is the SD-WAN version of building topology, and it is one policy document.

3. Reachability / segmentation

Control policy can also decide which sites even learn about which prefixes - reject the OMP routes for a VPN toward sites that should not reach it, and those sites simply never see the prefix. This is segmentation at the control-plane level, complementary to VPN-based isolation.

4. Extranet and shared services

Leak specific prefixes between VPNs (a shared services VPN reachable from several customer VPNs) by accepting and re-originating those routes across VPN boundaries in policy - the SD-WAN analogue of VRF route-leaking, done centrally.

Direction matters, and it is from the Controller's view

The single most common mistake with control policy is the direction. It is applied from the Controller's perspective:

Get the direction backwards and your policy either does nothing or does the opposite of what you intended. Always reason from the Controller: "as these updates leave me toward those sites" (out) versus "as these updates arrive at me from those sites" (in).

Verifying the effect on the edge

The policy lives on the Controller, but its effect is visible on the edge - the routes and preferences an edge learned are what the policy shaped:

Edge# show sdwan omp routes vpn 1 10.20.0.0/24 detail
 ... PREFERENCE 200 ...          ! the preference the control policy set
 ... TLOC 10.0.0.11 mpls ipsec ...

Edge# show sdwan policy from-vsmart          ! the policy the Controller pushed
from-vsmart control-policy PREFER-MPLS
 ...

show sdwan policy from-vsmart is the key troubleshooting command: it shows the edge what centralised policy the Controller has applied to it. If a branch is not behaving as your policy intends, this tells you whether the policy actually reached it.

Control policy vs the other policy types

• Centralised control policy (this article): shapes OMP - routes, TLOCs, topology, preferences. Control plane. Applied at the Controller.
• Centralised data policy (next article): matches actual traffic flows and steers them - the packet-level decisions, including application-aware routing. Also at the Controller.
• Localised policy: ACLs, QoS, route policy applied on the edge itself. The per-device stuff.

The division is clean and worth memorising: control policy = which routes exist and where they point; data policy = which packets go where; localised policy = per-device forwarding treatment. Most topology and path-preference work is control policy; most application steering is data policy.

Key takeaways

• A centralised control policy is applied at the Controller and shapes what every WAN Edge learns via OMP - one document controls the whole overlay's topology and path preferences.
• It shapes the control plane (which routes and TLOCs exist, with what preference), not individual packets. It draws the map; data policy directs the traffic.
• Classic use cases: path preference (prefer a transport), topology (build hub-and-spoke by rewriting TLOCs), reachability/segmentation (reject routes toward sites), and extranet (leak between VPNs).
• Direction is from the Controller's perspective: out controls what edges learn (the common case), in controls what the Controller accepts. Getting it backwards is the number-one mistake.
• show sdwan policy from-vsmart on an edge shows what centralised policy the Controller actually applied to it - the first troubleshooting command.
• Remember the split: control policy (routes/topology) vs data policy (packet steering) vs localised policy (per-device forwarding).

Next: SD-WAN data policy and application-aware routing (AAR). The full cluster index lives on the SD-WAN pillar.