ENSDWI Part 8: Control Policies

16 July 2026 Cisco ENSDWI SDWAN

Domain 4.0 (Policies) is 20% of the exam and is where ENSDWI stops being a vocabulary test. Control policy — this part — manipulates routing information at vSmart to build topologies. Data policy (Part 9) manipulates packets at the edges. Keeping those two planes straight is half the domain’s marks.

The policy framework

One centralized policy is active on the fabric at a time. It’s built (GUI: Configuration → Policies, or CLI) from:

Lists — reusable match material: site lists, VPN lists, TLOC lists, prefix lists, color lists, app lists, SLA classes.
Control policy — evaluated on vSmart, against OMP routes and TLOC routes, per direction (in = from edges to vSmart, out = vSmart to edges).
Data policy / app-route policy / cflowd — defined centrally but pushed to and executed on edges (Part 9).
Apply-policy — binds each policy to site lists + direction; a site list can have at most one control policy per direction.

Two facts to burn in:

Control policy never leaves vSmart. It is not pushed to edges; it shapes what routing information edges receive (or what vSmart accepts). Exhibit questions asking “where is this policy enforced?” for a control-policy block: vSmart.
Default action is reject. Any control policy ends with an implicit reject-everything — omit the default-action accept and every route and TLOC not explicitly matched vanishes fabric-wide for the applied sites. This is the most classic Catalyst SD-WAN outage and the most classic exam question.

Anatomy of a control policy

policy
 control-policy HUB-SPOKE
  sequence 10
   match tloc
    site-list BRANCHES
   action reject
  !
  sequence 20
   match route
    site-list BRANCHES
   action accept
    set tloc-list HUB-TLOCS      ! rewrite next-hop TLOC to the hub
  !
  default-action accept
 !
apply-policy
 site-list BRANCHES
  control-policy HUB-SPOKE out

Evaluation model: sequences in ascending order, first match wins, unmatched traffic hits default-action. Each sequence matches either route (OMP/vRoutes) or tloc (TLOC routes) — never both in one sequence. Match criteria: site-id/site-list, vpn-list, prefix-list, color, TLOC, originator, preference, OMP tag. Actions: accept/reject, plus set modifiers on accept — preference, TLOC/tloc-list (next-hop rewrite), service (insertion), tag, omp-tag.

Direction subtlety the exam tests: applied out, the policy filters/modifies what vSmart advertises to the listed sites; applied in, it filters what vSmart accepts from them. Topology-building is nearly always out — you shape each site’s view of the world.

The canonical topologies

Hub-and-spoke

The policy above is the whole trick, two moves:

Reject branch TLOCs towards branches — spokes never learn each other’s tunnel endpoints, so no spoke-spoke tunnels form (BFD session list at a spoke shows hub colors only — the Part 6 exhibit).
Rewrite branch routes’ TLOC to the hub — spoke-to-spoke traffic still routes, via the hub, because the prefix’s next-hop TLOC now points there.

If you skip move 2 and only filter TLOCs, spoke routes still point at unreachable spoke TLOCs → routes stay in the RIB but resolve nowhere → blackhole. “Filtered TLOCs but forgot the route rewrite” is a standard troubleshooting question.

Regional mesh (or MRF-by-hand)

Full mesh within a region, hub-only between regions: site lists per region, accept TLOCs/routes intra-region, rewrite inter-region routes to the regional hub TLOCs. This is exactly what Multi-Region Fabric automates — a v1.2-aware exam answer may offer MRF as the alternative to hand-built regional control policy.

Traffic steering with preference

Prefer one hub/DC/TLOC fabric-wide: match the routes or TLOCs, set preference 200 (higher wins, per Part 7’s path-selection order). Active/standby DC exits, primary/backup hub designs — all just preference rewrites at vSmart.

Service insertion (preview)

set service FW on matched routes forces traffic through a firewall advertised as a service route elsewhere in the fabric — mechanics in Part 10 with the security domain.

Filtering direction summary table

Goal	Match	Action
Stop spoke-spoke tunnels	tloc, branch site-list	reject
Route spokes via hub	route, branch site-list	accept + set tloc-list HUB
Prefer DC1 fabric-wide	route/tloc from DC1	accept + set preference high
Hide a VPN’s routes from a region	route, vpn-list + site-list	reject
Chain traffic through FW	route	accept + set service FW

Verifying control policy

vSmart# show running-config policy          ! the active policy (CLI mode)
vSmart# show omp routes advertised <...>    ! what vSmart is sending a peer
Edge#   show sdwan omp routes vpn 10        ! what actually arrived (C/I/R flags)
Edge#   show sdwan bfd sessions             ! topology reality check — who has tunnels to whom
Edge#   show sdwan policy from-vsmart       ! data/app-route policy received (NOT control policy —
                                            !   control policy never arrives at the edge)

That last line is a deliberate trap-check: show sdwan policy from-vsmart on an edge shows centralized data policies pushed to it. Control policy will never appear there, because it executes on vSmart. If an exhibit shows an empty from-vsmart and asks why the topology changed anyway — control policy is the answer.

Also know: vSmart must be in vManage-managed mode (template attached) to receive centralized policy from vManage. A vSmart in CLI mode silently never gets the policy — activation fails. Tested regularly.

Worked example: the classic outage

You apply a new control policy to site-list ALL-BRANCHES matching three prefixes for preference steering. You forget default-action accept. Result: vSmart advertises only those three prefixes (everything else hits implicit reject) to every branch; all other routes and all TLOCs vanish from branch RIBs; every data-plane tunnel drops when the TLOC routes age out. The fix is one line, the lesson is permanent, and Cisco loves examining it: new policy + sudden fabric-wide route loss = check default-action first.

Exam traps for this domain

Control policy executes on vSmart; it is routing-information surgery, not packet filtering.
Default action = reject. Always account for it.
Sequences: first match wins; a sequence matches routes or TLOCs, not both.
Hub-and-spoke needs both halves: TLOC filtering + route TLOC-rewrite.
out = shaping what sites are told; one control policy per site-list per direction.
Edges never show control policy in show sdwan policy from-vsmart — that’s data/app-route territory.
vSmart must be template-managed for centralized policy activation.

Part 9 moves to the edge-executed half of the domain: centralized data policy, VPN segmentation and per-VPN topologies, application-aware routing with SLA classes, and direct Internet access.