Cisco SD-WAN Centralized Policy: — Control Policy, Topology & VPN Membership

① The policy framework — the universal shape

Cisco SD-WAN policy looks scary because the menus are deep, but every policy you will ever write has the same three-part shape. First you build lists (a site list, a VPN list, a TLOC list, a prefix list). Then you write a policy definition — either a control policy (shapes the overlay's routes) or a data policy (shapes packets in the forwarding path). Finally you apply that definition to a site-list with a direction. Lists → definition → apply. That's it.

The split that organises the whole chapter: centralized policy lives on vSmart; localized policy lives on the edge. When you define and activate a centralized policy in vManage, vManage pushes it to the vSmart controllers as a NETCONF transaction. The WAN Edges never receive the policy itself — they only receive the filtered OMP results vSmart sends them. Hold that thought; it explains why control policy is invisible to the data plane (section 3).

Think of it like a dabbawala sorting hub in Mumbai. The dabbawalas (WAN Edges) don't decide the routing — they just carry tiffins. The sorting code that says "this box goes to that office, not that one" is decided centrally at the hub (vSmart) and the carriers simply follow what they're handed. Change the sorting rule at the hub and every carrier's route changes — nobody re-trains 5,000 dabbawalas one by one. That central rule sheet is your centralized policy.

Four words you'll use every day

Tap each card — these are the vocabulary anchors for the whole lesson.

② Control policy use-cases — topology

By default, Cisco SD-WAN builds a full mesh. Every WAN Edge sends all its local prefixes, TLOCs and service routes up to vSmart; vSmart accepts them all and reflects them to every other edge. So every site hears about every other site's TLOC, and a tunnel forms between all of them. Great for a small overlay; a nightmare of tunnels and exposure once you have 400 branches.

A topology policy is a centralized control policy whose whole job is to limit which routes and TLOCs vSmart redistributes to a list of sites. The classic example: hub-and-spoke. You want every spoke to reach the data centre, but spokes must never tunnel directly to each other (compliance, blast-radius, simplicity). The trick is not to block anything on the spokes — it's to make vSmart only advertise the hub's TLOC to the spokes and reject the other spokes' TLOCs.

Why does merely not advertising a TLOC stop the tunnel? Because a WAN Edge can only build an IPsec tunnel to a TLOC it has heard about over OMP. No TLOC, no tunnel — there is literally nothing to point at. This is the elegance students miss: in SD-WAN, visibility equals reachability at the overlay layer. Control the advertisement and you control the topology, without a single deny statement on any edge.

③ VPN membership + direction

Now the part that trips people up: direction. A centralized control policy is applied to a site-list either inbound or outbound, and they hit OMP at different moments. Inbound acts on the route updates coming from the edges at those sites, before they're installed in vSmart's routing table — so it controls what vSmart even keeps. Outbound acts after a route is pulled from vSmart's table but before vSmart advertises it to those sites — so it controls what the sites receive.

For topology, the everyday answer is outbound: you're shaping what the spokes receive, so you reject peer TLOCs on the way out to the spoke site-list. Inbound is for changing what vSmart stores in the first place — for example tagging or dropping routes as they arrive from a particular region before best-path even runs. Same policy engine, two very different blast radii. A classic exam trap is choosing inbound when you meant to shape what a site receives.

A VPN-membership policy is the bluntest topology control there is, and it's always applied outbound from vSmart. It decides which VPNs a site even learns about. If a branch only needs Corp (VPN 10) and Guest (VPN 30), a VPN-membership policy that lists VPNs 10 and 30 for that site-list means vSmart never sends it OMP routes for PCI (VPN 50) at all. The branch can't reach what it never learns — segmentation enforced by silence, not by an ACL.

And here is the whole reason this lesson sits before the data-plane lessons: control policy is invisible to the data plane. It never inspects a packet, never sits in the forwarding path, never adds latency. It works purely by shaping the map — the OMP routes and TLOCs each site holds. Yet by shaping that map it decides which tunnels can exist and which destinations a site can reach. The data plane just forwards along whatever overlay the control policy left standing. Map first, packets later.

policy
 control-policy HUB_AND_SPOKE
  sequence 10
   match tloc
    site-list SPOKES
   action reject
  default-action accept            ! <-- the line that saves your fabric
!
apply-policy
 site-list SPOKES
  control-policy HUB_AND_SPOKE out
!

vSmart# show running-config apply-policy
apply-policy
 site-list SPOKES
  control-policy HUB_AND_SPOKE out
vSmart# show omp routes summary
 received  advertised
   842        611      <- fewer advertised: the filter is working

④ Build + activate in vManage, then verify on the edge

Time to build one end-to-end. In vManage you go to Configuration > Policies and the wizard walks you through four steps in order: Create Groups of Interest (your lists), Configure Topology and VPN Membership (the control / VPN-membership definitions), Configure Traffic Rules (data / AAR policy — skip for pure topology), and Apply Policies to Sites and VPNs (attach to a site-list with a direction, name it, then Save Policy and Activate). Activating is what triggers the NETCONF push to vSmart.

Step 1 is where you build the SPOKES site-list (the spoke site-ids) and a TLOC list for the hub. Step 2 is where, under Add Topology > Custom Control (Route & TLOC), you create the control policy: a sequence that matches the spoke TLOCs and rejects them, and — say it with me — a default-action of accept. Step 4 applies it outbound to the SPOKES site-list. Name, Save, Activate.

Now prove it from a spoke — because a centralized policy is invisible, the only honest test is what disappeared on the edge. The routes and TLOCs that vanished are your filter working. On a cEdge: show sdwan omp routes vpn 10 should no longer list peer-spoke prefixes, show sdwan omp tlocs should show the hub TLOC but not the other spokes', and show sdwan policy from-vsmart shows the actual policy vSmart pushed to you. If the hub prefixes are also gone, you hit the default-action trap.

Spoke-A# show sdwan omp tlocs | i 10.0.0
Spoke-A# show sdwan omp routes vpn 10 | i C,I,R
Spoke-A# show sdwan policy from-vsmart

TLOC ADDR        COLOR    ENCAP   STATUS
10.0.0.1         mpls     ipsec   C,I,R     <- HUB only, good
10.0.0.1         biz-internet ipsec C,I,R   <- hub backup kept
                                            (no 10.0.0.2/.3 spoke TLOCs = filtered)
policy-from-vsmart control-policy HUB_AND_SPOKE