# Cisco SD-WAN Centralized Policy: — Control Policy, Topology & VPN Membership Source: https://ai.techclick.in/blog_cisco_sdwan_centralized_policy Markdown: https://ai.techclick.in/blog_cisco_sdwan_centralized_policy.md Publisher: Techclick Infosec Pvt Ltd Cisco SD-WAN centralized policy explained: lists → policy definition → apply with a direction on vSmart, carving hub-and-spoke by filtering TLOC/OMP routes, VPN membership, inbound vs outbound, the default-action reject trap, and edge verification. ENSDWI 300-415. Cisco SD-WAN Centralized Policy: — Control Policy, Topology & VPN Membership student learning map A visual study map for Cisco SD-WAN Centralized Policy: — Control Policy, Topology & VPN Membership showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Cisco SD-WAN Centralized Policy: — Control Policy,... Cisco SD-WAN · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① The policy framework — the... 4. Practice ② Control policy use-cases —... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most engineers think SD-WAN topology is something you build with tunnels and access-lists — "to stop spoke-to-spoke I'll deny the subnets on each branch firewall." So they reach for an ACL on every edge. Wrong — and it won't scale past a handful of sites. In Cisco SD-WAN the topology is whatever vSmart chooses to advertise . A spoke can only build a tunnel to a TLOC it has heard about , so the cleanest way to stop spoke-to-spoke is to make vSmart not tell the spokes about each other — one outbound control policy applied to the spoke site-list. No ACL touches any edge. Change the policy once and 500 branches re-converge. ## ① 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). 👉 So far: every policy is lists → definition → apply-with-a-direction, and centralized policy lives on vSmart while localized lives on the edge. Next: see the shape as one picture. Figure 1 — Lists → Definition → Apply, and it lives on vSmart Left: lists of interest (site list, VPN list, TLOC list, prefix list) feed into a policy definition which is either a control policy or a data policy. The definition is applied to a site-list with an inbound or outbound direction. The whole object is pushed by vManage to the vSmart controller over NETCONF; the WAN Edge never sees the policy, only its filtered OMP results. - Lists → Definition → Apply (site-list + direction) → lives on vSmart groups of interest Site list VPN list TLOC list Prefix list Policy Definition control · or · data Apply to site-list 100,200 direction: in / out vSmart Controller centralized policy lives HERE vManage pushes via NETCONF WAN Edge Site 200 WAN Edge Site 100 edges receive only FILTERED OMP — never the policy itself Same shape every time: Lists → Definition → Apply with a direction to a site-list. Centralized = on vSmart. Localized = on the edge. That one split explains the whole chapter. filtered / blocked overlay route/TLOC control / policy key idea advertised / reachable Follow it left to right: lists of interest feed a policy definition, the definition is applied to a site-list with a direction, and the whole object is pushed by vManage to vSmart. The edges only ever see filtered OMP. 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. 📦 List of interest tap to flip A reusable named group — site list, VPN list, TLOC list, prefix list. The ingredients a policy sequence matches on. Build these first. 📜 Policy definition tap to flip The body: match/action sequences plus a default-action. Control (shapes OMP) or data (shapes packets). The recipe, not yet served. 🎯 Apply (site-list + direction) tap to flip You attach the definition to a site-list and pick inbound or outbound. Nothing happens until you apply — and direction changes everything. 🧠 Centralized = on vSmart tap to flip vManage pushes it to vSmart over NETCONF. Edges get only filtered OMP. So one screen reshapes the whole fabric. Localized = per-edge, local only. Quick check · Q1 of 10 Sneha at Infosys writes a perfect control policy with site and TLOC lists, saves it, and waits — but nothing changes on the fabric. What did she miss? a) She must reboot every WAN Edge b) The policy isn't applied to a site-list with a direction, and/or not activated c) Control policy can't use TLOC lists d) She needs an access-list on each edge too Correct: b. A definition does nothing until you APPLY it to a site-list (with a direction) and ACTIVATE the centralized policy so vManage pushes it to vSmart. No reboot is involved, control policy absolutely uses TLOC lists, and edges never need a matching ACL — that's the whole point of centralized policy. Pause & Predict Predict: if the centralized policy object lives only on vSmart and the edges receive just filtered OMP, what happens to the fabric the moment vSmart loses all its control connections? Type your guess. Reveal answer Answer: No NEW policy decisions or route changes propagate — vSmart is the brain that filters and reflects OMP. Existing tunnels keep forwarding on last-known OMP for a while (the data plane is decoupled), but the overlay stops re-converging: new sites can't learn routes and topology changes won't apply. That decoupling is exactly why you always run redundant vSmarts. ## ② 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. 👉 So far: default = full mesh because vSmart reflects every TLOC. Next we watch the policy carve that mesh down to hub-and-spoke. Figure 2 — Hub-and-spoke by hiding the other spokes' TLOCs By default vSmart reflects every spoke TLOC to every other spoke, so a full mesh forms. An outbound control policy applied to the spoke site-list rejects spoke TLOCs and keeps only the hub TLOC. Spoke A and Spoke B now each see only the hub's TLOC, so they each build one tunnel to the hub and none to each other. Spoke-to-spoke traffic hairpins through the hub. Hub-and-spoke = vSmart hides the other spokes' TLOCs DEFAULT — full mesh Hub Site 1 Spoke A Spoke B A↔B direct tunnel AFTER policy — hub & spoke Hub Site 1 Spoke A Spoke B A↔B blocked — no TLOC vSmart outbound policy to spoke site-list: reject spoke TLOCs A spoke can only build a tunnel to a TLOC it has heard about. Hide the peer TLOCs and the tunnel can't form — no access-list on any edge, just controlled advertisement. filtered / blocked overlay route/TLOC control / policy key idea advertised / reachable Left = the default full mesh (A talks straight to B). Right = after an outbound control policy on the spoke site-list rejects spoke TLOCs: A and B each see only the hub, so A↔B can't form. Spoke-to-spoke now hairpins through the hub. 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. ### ▶ Carve hub-and-spoke, step by step Watch one spoke's view of the fabric change as the policy is applied. Press Play for the healthy path, then Break it to see the failure. ① Default vSmart reflects ALL TLOCs → Spoke A sees hub + Spoke B ▼ ② List build a site-list of the spokes (sites 200,300,400) + a TLOC list = hub ▼ ③ Policy control policy: match spoke TLOCs → reject , accept hub TLOC, apply OUT to spoke-list ▼ ④ Result Spoke A's OMP now shows hub TLOC only → tunnel to hub forms, A↔B gone Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Aditya at TCS faces this Aditya rolls a hub-and-spoke control policy to 60 branches at 9pm. By 9:05 the NOC is on fire: branches can't even reach the data centre, and monitoring shows OMP routes for VPN 10 dropping across the fabric. Likely cause His control policy had sequences to reject spoke-to-spoke TLOCs, but no explicit default-action — so it inherited the implicit default-action reject . Every route that didn't hit one of his accept sequences (including the hub prefixes) was silently dropped on the way to the spokes. Diagnosis He compares an edge's OMP before/after and sees the route count collapse, confirming a filter that's too aggressive, not a transport failure. vManage > Monitor > Devices > (a spoke) > Real Time > OMP Received Routes (and on the edge: show sdwan omp routes vpn 10) Fix Add a final sequence / set the policy default-action to accept , re-activate the centralized policy so vManage re-pushes to vSmart, and keep the reject narrowly scoped to spoke→spoke TLOCs only. Verify On a spoke, 'show sdwan omp routes vpn 10' shows the hub prefixes back; 'show sdwan omp tlocs' shows the hub TLOC present and the peer-spoke TLOCs absent — exactly the intended shape. Common mistake — the default-action reject blackout Symptom: after you apply a control policy, branches lose routes they used to have and some sites go fully unreachable. Cause: a centralized control policy's default-action is reject — any route that doesn't match one of your sequences is dropped, not passed. Engineers write three 'reject these TLOCs' sequences and assume everything else flows; it doesn't. Fix: end the policy with an explicit default-action accept (or a final accept sequence) so only what you meant to filter is filtered. Quick check · Q2 of 10 Priya at ICICI needs spokes to reach the hub but not each other. Which single change delivers it, with no config on the edges? a) An outbound centralized control policy on the spoke site-list that rejects peer-spoke TLOCs and accepts the hub TLOC b) Deny spoke subnets in an ACL on every branch router c) Disable OMP on the spokes d) Put every spoke in its own VPN Correct: a. Hub-and-spoke is carved by controlling what vSmart advertises: reject the peer-spoke TLOCs outbound to the spoke site-list and accept the hub's. Per-edge ACLs don't scale and aren't how SD-WAN topology works; disabling OMP breaks the overlay entirely; separate VPNs change segmentation, not which TLOCs a site can tunnel to. Pause & Predict Predict: you build hub-and-spoke by rejecting spoke TLOCs outbound. A spoke still needs a backup path if the hub's primary transport dies. What must you NOT accidentally filter out? Type your guess. Reveal answer Answer: The hub's OTHER TLOC(s). A hub usually has two transports (e.g. MPLS + Internet), so it advertises two TLOCs — one per colour. If your TLOC list / accept only keeps one colour, the spoke loses its backup to the hub. Keep all of the hub's TLOCs in the accept set so the spoke can fail over between the hub's transports. ## ③ 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. 👉 So far: inbound = before vSmart's RIB, outbound = before advertising; topology is usually outbound. Next: VPN membership, the bluntest control of all. Figure 3 — Control vs Data vs Localized — what runs where A three-column comparison. Centralized control policy runs on vSmart, filters OMP routes and TLOCs, applied inbound or outbound to a site-list, and is invisible to the data plane. Centralized data policy also runs on vSmart but inspects packet headers in the forwarding path. Localized policy is configured per edge for ACLs, QoS and route maps and never touches the overlay topology. Default action on a control policy is reject. Control vs Data vs Localized — what runs where Centralized CONTROL runs on: vSmart shapes: OMP routes + TLOCs applied: site-list, in / out + builds topology / VPN-mship + invisible to the data plane − default-action = REJECT (unmatched routes vanish) topology · VPN membership Centralized DATA runs on: vSmart (pushed) shapes: the packet path applied: site-list + VPN-list + from-service / from-tunnel + AAR, NAT, service chains seen IN the forwarding path (this is the NEXT lesson) LOCALIZED runs on: each WAN Edge shapes: local interfaces applied: in the device template + ACLs, QoS, route maps + mirroring, policer never touches the overlay topology — local only one box's own behaviour Memory hook: CONTROL = the map (overlay), DATA = the traffic cop (per-packet), LOCALIZED = each gate's own rules. Three columns, two homes: control and data policy are centralized (on vSmart), localized policy is per-edge. Only control / VPN-membership shapes the overlay topology. Note the red default-action = reject warning on the control column. 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. vSmart CLI — a topology control policy (excerpt) + the apply policy control-policy HUB_AND_SPOKE sequence 10 match tloc site-list SPOKES action reject default-action accept ! Expected output 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 Quick check · Q3 of 10 Karthik at HCL wants branch sites to never even learn the PCI VPN's routes, enforced from the controller. Which tool, and which direction? a) An inbound control policy tagging PCI routes b) A localized ACL on each branch c) A data policy with from-tunnel match d) A VPN-membership policy applied outbound, omitting the PCI VPN for the branch site-list Correct: d. VPN-membership policy is the controller-side tool that decides which VPNs a site learns, and it is always applied outbound. Leave PCI off the branch site-list's membership and vSmart never advertises those routes there. Inbound tagging changes what vSmart stores, not what a branch learns; a localized ACL is per-edge and not controller-enforced; a data policy shapes packets, not VPN learning. Pause & Predict Predict: control policy never touches a packet, yet a misconfigured one can take a whole branch offline. How does something invisible to the data plane cause an outage? Type your guess. Reveal answer Answer: Because it shapes the MAP the data plane forwards on. If control policy filters out the routes/TLOCs a branch needs (e.g. default-action reject drops the hub prefixes), the branch's forwarding table has nowhere to send traffic — the tunnels it needed were never advertised. The data plane is fine; it just has no overlay left to forward across. Shape the map wrong and the packets have nowhere to go. ## ④ 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. vManage → Configuration → Policies → Add Policy → (step 4) Apply Policies to Sites and VPNs → Topology . Real wizard fields. (Recreated for clarity — your vManage matches this.)"> 🖥️ This is the screen you'll apply the policy on — vManage → Configuration → Policies → Add Policy → (step 4) Apply Policies to Sites and VPNs → Topology . Real wizard fields. (Recreated for clarity — your vManage matches this.) vmanage.lab.local · Configuration · Policies · Add Policy 1 Policy Name HUB_AND_SPOKE_CORP 2 Topology / Definition Custom Control (Route & TLOC) 3 Site List SPOKES (200, 300, 400) 4 Direction Outbound Default Action Accept Activate Push to vSmart (NETCONF) Save Policy → 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. cEdge CLI — verify the topology policy did exactly what you meant 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 Expected output TLOC ADDR COLOR ENCAP STATUS 10.0.0.1 mpls ipsec C,I,R Figure 4 — Centralized policy at a glance A nine-tile cheat sheet: the four wizard steps in vManage, control policy inbound vs outbound meaning, VPN membership direction, the default-action reject trap, the lists you build, topology vs VPN membership, and the three show commands used to verify a centralized policy from the edge. Centralized policy — your one-glance card Wizard, 4 steps 1 Groups of Interest (lists) 2 Topology + VPN Membership 3 Traffic Rules · 4 Apply Lists you build Site · VPN · TLOC · Prefix Color · App · Community = the match/action ingredients Default-action TRAP unmatched route → REJECT add 'default-action accept' or your fabric goes dark Direction (control) IN = before vSmart RIB OUT = before advertising topology usually = OUT VPN membership always OUTBOUND decides which VPNs a site even LEARNS routes for Where it lives vSmart only (centralized) vManage → NETCONF → vSmart edge gets filtered OMP only Verify from the WAN Edge (cEdge) show sdwan omp routes vpn 1 ← routes that survived the filter show sdwan omp tlocs ← which peer TLOCs you still see show sdwan policy from-vsmart ← the policy vSmart pushed to you Your one-card map of this lesson — the four wizard steps, inbound vs outbound, VPN-membership direction, the default-action reject trap, and the three verify commands. Keep it open while you build your first policy and before any ENSDWI question. Pro tip — the mental model that sticks For any centralized-policy task ask three questions: (1) What am I shaping? the overlay map (routes/TLOCs) → control policy; which VPNs a site learns → VPN membership. (2) Whose view? apply to that site-list. (3) Which moment? change what a site RECEIVES → outbound; change what vSmart STORES → inbound. Then always finish with default-action accept unless you genuinely want to drop everything unmatched. Prove you've got the centralized-policy model Take a real ask — "branches reach the data centre, never each other, and must not even learn the PCI VPN" — and name it cold: control policy rejecting peer-spoke TLOCs (topology) + VPN-membership omitting PCI, both applied OUTBOUND to the SPOKES site-list, with a default-action accept, activated so vManage pushes to vSmart, verified on a spoke with show sdwan omp tlocs / routes / policy from-vsmart. If you can say that without notes, you're ready for the 300-415 policy domain and the NOC floor. Recent gotcha — backup paths and OMP advertisement Symptom: after building a control policy, a site loses its backup path to a destination even though you didn't reject it. Cause: by default OMP advertises only the BEST route(s); applying an inbound policy can remove a backup path before best-path even evaluates it, and a tracked Cisco issue (CSCwh73408) covers vRoutes not being re-advertised in some failover cases. Fix: prefer outbound shaping for topology, and where you need backups, use omp send-backup-paths on the vSmarts so more than the single best route is advertised. Back: Segmentation — VPN 0, 512 & Service VPNs Next: Application-Aware Routing & QoS Quick check · Q4 of 10 You applied a hub-and-spoke control policy and now even the hub prefixes are missing on the spokes. Before changing any list, what's the single highest-probability fix? a) Reboot vSmart b) Add an explicit default-action accept (the implicit default is reject) c) Switch the policy from outbound to inbound d) Disable OMP and re-enable it Correct: b. A control policy's implicit default-action is reject, so any route not matching an accept sequence — including the hub prefixes — is dropped. Adding default-action accept restores everything you didn't intend to filter. Rebooting vSmart and toggling OMP don't address the filter; flipping to inbound changes what vSmart stores, not the blackout cause. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Why does hiding a TLOC stop a tunnel, with no ACL? Inbound vs outbound control policy — how do I choose? Why did half my routes disappear after I applied a policy? What's the difference between a topology policy and VPN membership? If control policy never sees a packet, how can it cause an outage? How do I verify a centralized policy actually applied, from the edge? Pre-curated from Cisco SD-WAN docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember On which device does a Cisco SD-WAN centralized policy actually run? a) On every WAN Edge router b) On the vBond / Validator c) On the vSmart controller d) On vManage's local database only Correct: c. Centralized policy lives on the vSmart controller; vManage pushes it there over NETCONF and the WAN Edges only receive the filtered OMP results. vBond handles onboarding/authentication, and while vManage authors and stores the policy, it isn't where the policy executes. Q6 · Apply You must stop spokes from tunnelling directly to each other while keeping their path to the hub, with zero config on the branches. What do you build? a) An outbound control policy on the spoke site-list that rejects peer-spoke TLOCs and accepts the hub TLOC (default-action accept) b) A deny ACL for spoke subnets on each branch router c) A data policy matching from-tunnel on the hub d) A VPN-membership policy putting each spoke in a unique VPN Correct: a. Hub-and-spoke is carved by controlling vSmart's advertisements: reject peer-spoke TLOCs outbound and keep the hub's, with default-action accept so nothing else is dropped. Per-edge ACLs don't scale, a from-tunnel data policy shapes packets not topology, and unique VPNs change segmentation rather than which TLOCs a site can reach. Q7 · Apply A branch should never even learn the PCI VPN's routes, enforced from the controller. Which tool and direction? a) An inbound control policy on the hub site-list b) A localized route-map on the branch c) A VPN-membership policy applied outbound, omitting the PCI VPN for the branch site-list d) A centralized data policy with a VPN list Correct: c. VPN-membership policy decides which VPNs a site learns and is always applied outbound from vSmart; leave PCI off the branch site-list's membership and those routes are never advertised there. Inbound policy changes what vSmart stores, a localized route-map is per-edge not controller-enforced, and a data policy shapes packet forwarding, not VPN learning. Q8 · Analyze After activating a topology control policy, multiple spokes lose ALL their routes — even the hub prefixes — though transport and BFD are healthy. Most likely root cause? a) vSmart lost its control connections b) OMP graceful-restart expired c) The site-list referenced the wrong colour d) The policy has no explicit default-action, so the implicit reject dropped every unmatched route Correct: d. A control policy's implicit default-action is reject, so any route not matching an accept sequence — including the hub prefixes — is filtered. Adding default-action accept fixes it. Healthy transport/BFD rules out a control-connection loss; graceful-restart and a colour mismatch wouldn't produce a clean ‘everything filtered on the spokes’ pattern tied to policy activation. Q9 · Analyze Two engineers debate the same goal — shape what a set of branch sites RECEIVE from vSmart. One applies the control policy inbound, the other outbound. Who is right and why? a) Inbound — it changes routes as they arrive from those branches b) Outbound — it's applied before vSmart advertises to those sites, so it controls what they receive c) Either works identically d) Neither — you need a data policy for this Correct: b. Outbound is applied after a route leaves vSmart's RIB but before advertisement to the site-list, so it shapes what those sites receive — exactly the goal. Inbound acts on updates coming FROM the branches before they enter vSmart's RIB (what vSmart stores), a different effect. They are not identical, and topology is a control-plane job, not a data policy. Q10 · Evaluate Two designs to enforce hub-and-spoke for 300 branches: (A) deny spoke-to-spoke subnets via an ACL on every branch router; (B) one outbound centralized control policy on the spoke site-list rejecting peer-spoke TLOCs with default-action accept. Which is stronger and why? a) A — local ACLs are more secure because they're on the device b) B — one controller-side policy reshapes all 300 spokes at once by controlling TLOC advertisement; no tunnel can even form, and there's nothing to drift per-edge c) A — ACLs are easier to audit d) Identical — pick by licence cost Correct: b. Design B works at the overlay layer: hide the peer TLOCs and the tunnel can never form, enforced from one place for all 300 sites with no per-edge config to drift or miss. Design A requires touching every branch, scales poorly, and only blocks traffic after tunnels still form — far more fragile and error-prone across 300 devices. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: In one line, why is stopping spoke-to-spoke traffic done by filtering TLOC advertisements on vSmart rather than by access-lists on the edges? Then compare to the expert version. Compare with expert answer Expert version: Because a WAN Edge can only tunnel to a TLOC it has learned over OMP, so making vSmart not advertise the peer-spoke TLOCs prevents the tunnel from ever forming — one outbound control policy reshapes every spoke at once, with zero config on the edges, where an ACL approach would mean touching every branch and wouldn't scale. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Centralized Control at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Centralized policy Policy that lives on the vSmart controller (Catalyst SD-WAN Controller), pushed by vManage over NETCONF; shapes OMP/TLOC or the data fabric. Localized policy Policy on an individual WAN Edge via its device template — ACLs, QoS, route maps; local to one box, never touches the overlay topology. Control policy Centralized policy that filters/modifies OMP routes and TLOCs; default-action is reject; applied inbound or outbound to a site-list. Topology policy A control policy whose job is to limit which routes/TLOCs vSmart redistributes — used to build hub-and-spoke or custom/regional mesh. VPN-membership policy Control policy applied outbound that decides which VPNs a site even learns OMP routes for; omit a VPN and that site never sees it. TLOC Transport Locator — the {system-IP, colour, encapsulation} tuple identifying a tunnel endpoint; a site can only tunnel to a TLOC it has learned. OMP Overlay Management Protocol — the BGP-like protocol between vSmart and WAN Edges that distributes routes, TLOCs and service routes. Site-list A named list of site-ids; every centralized policy is applied to a site-list, which selects which devices the policy affects. Direction (in/out) Inbound = applied before routes enter vSmart's RIB (what vSmart stores); Outbound = applied before vSmart advertises (what a site receives). Default-action What happens to a route that matches no sequence. On a control policy it is reject by default — add 'accept' or unmatched routes are dropped. vSmart / Controller The SD-WAN control-plane brain; reflects OMP between edges (route-reflector-like) and is the only place centralized policy runs. show sdwan policy from-vsmart Edge command that displays the centralized policy the vSmart controller has pushed down to this WAN Edge. #### 📚 Sources Cisco Catalyst SD-WAN Policies Configuration Guide, Cisco IOS XE Catalyst SD-WAN Release 17.x — “Centralized Policy” (wizard: Create Groups of Interest, Configure Topology and VPN Membership, Configure Traffic Rules, Apply Policies to Sites and VPNs; control policy pushed to vSmart via NETCONF). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/ios-xe-17/policies-book-xe/centralized-policy.html - Policies Configuration Guide for vEdge Routers, Cisco SD-WAN Release 20 — “Control Policy” & “Policy Overview” (inbound vs outbound, default full mesh, default-action reject, hub-and-spoke by filtering TLOCs). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/vedge-20-x/policies-book/centralized-policy.html - NetworkAcademy.IO — “What is a Centralized Control Policy?” (vManage pushes NETCONF to vSmart, edges receive only filtered OMP; inbound before RIB / outbound before advertising; single policy per controller; hub-and-spoke by rejecting spoke TLOCs). networkacademy.io/ccie-enterprise/sdwan/what-is-a-centralized-control-policy - The Network DNA — “Cisco Catalyst SD-WAN: Inbound vs. Outbound Control Policy” (Jan 2024; timing relative to the vSmart OMP RIB, preference impact, default-action accept vs reject). thenetworkdna.com/2024/01/cisco-catalyst-sdwan-inbound-vs.html - Cisco TAC docs & Bug — “Exclude Routes from Redistributing into OMP” and OMP best-path / backup-path notes (omp send-backup-paths is vSmart-only; CSCwh73408 vRoutes re-advertisement in failover). cisco.com/c/en/us/support/docs/routers/xe-sd-wan-routers/220599-exclude-routes-from-redistributing-into.html · bst.cisco.com/quickview/bug/CSCwh73408 - Cisco 300-415 ENSDWI v1.2 exam topics (Policies domain: centralized control policy, topology, VPN membership, application of policy to site-lists). learningcontent.cisco.com/documents/marketing/exam-topics/300-415-ENSDWI-v1.2.pdf ### What's next? You can now reshape the overlay from one screen. Next we move from the control plane to the forwarding path: Application-Aware Routing measures each link's loss, latency and jitter in real time and steers voice and apps onto the path that meets their SLA — plus how QoS classes and queues fit in. Next · Application-Aware Routing & QoS → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt