Control Policy: The Topology Is What Each Site Was Told

An SD-WAN overlay is a full mesh because nobody told it not to be. The controller reflects every tunnel endpoint to every edge, each edge builds a tunnel to everything it can reach, and the result is a topology that grows with the square of the site count. For thirty sites that is fine and mostly invisible. For four hundred it is the constraint that decides what hardware each branch needs.

Control policy is how that shape is changed, and it works by a mechanism worth stating precisely: it does not configure a topology, it filters and rewrites what each site is told. A spoke that cannot see another spoke's tunnel endpoint has no way to build a tunnel to it, so the topology is a consequence of the information each site receives rather than something declared anywhere.

This article covers why the default is a full mesh and when that stops working, the two distinct mechanisms a control policy has for changing the shape, how to build hub-and-spoke and regional meshes concretely, and the mistakes that isolate sites — which in this area means every site at once, because the policy is a single central object. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.

The same sites with different information produce different topologies. A policy either withholds an endpoint so no tunnel can form, or rewrites it so traffic reaches the destination by another route.

Why Is the Default a Full Mesh, and When Is That Wrong?

What makes it the default?

Nothing in the system chooses a full mesh — it is what happens when the controller reflects everything to everybody and each edge acts on all of it. Every endpoint an edge learns is an endpoint it will attempt a tunnel to, so complete information produces complete connectivity. That is the right default because it is the behaviour that needs no configuration and serves a small deployment perfectly.

A Deeper Dive into the Default

What actually grows

Not the route table, which is proportional to the number of prefixes, but the tunnel count — and that grows with the number of site pairs multiplied by the transports they share. The number that matters to a branch router is how many tunnels it individually maintains, and in a full mesh that is every other site times every colour pairing. A four-hundred-site estate with two transports asks a branch to hold something close to eight hundred.

! What a branch is actually holding
SPOKE-1# show sdwan bfd sessions | count up
SPOKE-1# show sdwan omp tlocs | count
!
! And the platform's own view of the pressure
SPOKE-1# show platform resources
SPOKE-1# show processes cpu sorted | include five seconds
!
! These are the numbers that decide whether a full mesh
! is still viable at this estate size.

Why it is not only about hardware

A large tunnel count costs memory and processing on the branch, and it also costs time. Every session is probed for liveness, every topology event touches many peers, and a site restarting has to re-establish everything it holds. Sites that take an unexpectedly long time to become fully useful after a reboot are frequently sites holding far more tunnels than their role requires.

The cost is paid by the smallest devices

A full mesh distributes its burden unevenly in a way the topology diagram hides. The data centre routers holding four hundred tunnels are large devices sized for exactly that. The branch router in a small office is holding the same four hundred, on hardware chosen because the site has twelve users. The constraint therefore appears at the branches first, and it appears as a hardware refresh proposal rather than as a topology conversation.

That framing is worth making explicit when the decision is being taken, because the alternatives are genuinely comparable: restrict the topology, or buy larger branch routers. One is a policy change and the other is a capital programme, and they are rarely presented side by side because they arrive from different directions.

When a full mesh is genuinely right

When sites actually talk to each other. A voice deployment where any office calls any office, or a design where applications are distributed regionally rather than centrally, gets real value from direct paths and would pay for a restricted topology in added latency through a hub. The question is a traffic question, and it is answerable from flow data rather than from preference.

The reflection limit interacts with this

Before reaching for policy, it is worth knowing that the controller already limits how many paths per prefix it reflects, and that limit shapes the overlay independently of any topology decision. A site with four transports whose paths are being truncated is already not a full mesh in the sense its designers assumed, and raising or lowering that limit changes tunnel counts without a single policy sequence.

The two mechanisms are easy to confuse when investigating why a site holds fewer endpoints than expected. A truncated path list affects every site equally and follows no pattern related to site lists; a policy effect follows the lists exactly. Checking which explanation fits the observed pattern takes one comparison and avoids editing a policy that was not responsible.

Measuring before deciding

The argument for restricting a topology is usually made on scale grounds and should be checked against traffic. If ten per cent of a site's traffic is to other branches, routing it through a hub is a real cost imposed on real users. If it is nought point one per cent, the direct tunnels were maintained for nothing. Flow records answer this, and the answer occasionally contradicts what everybody assumed. It is also worth repeating periodically, because application deployment patterns change and a topology decision taken three years ago was taken about a different network.

How Does a Control Policy Actually Change the Topology?

What are the two mechanisms?

Withholding and rewriting, and they produce different outcomes. Rejecting an endpoint means the receiving site never learns the peer exists, so no tunnel to it is possible and reachability must come from somewhere else. Rewriting a route's endpoint means the site still learns the destination and is told to reach it through a different tunnel — typically the hub's. Most real topologies use both: reject the peer endpoints, and rewrite the peer prefixes to point at the hub.

A Deeper Dive into the Mechanisms

Matching endpoints and matching routes

A control policy sequence matches either one or the other, and confusing them is the most common structural mistake. A sequence matching endpoints governs which tunnels can be built; a sequence matching routes governs which destinations are known and how they are reached. A policy that rejects peer endpoints but says nothing about peer routes leaves sites knowing about destinations they have no path to.

! Two different things to match, doing two different jobs
policy
 control-policy EXAMPLE
  sequence 10
   match tloc
    site-list SPOKES
   action reject
   ! ^ spokes will not learn each other's endpoints,
   !   so no spoke-to-spoke tunnel can be built
  !
  sequence 20
   match route
    site-list SPOKES
   action accept
    set
     tloc-list HUB-TLOCS
    !
   ! ^ spokes still learn each other's prefixes, but
   !   reach them through the hub
  !
 !
!

Direction, restated because it decides everything

A policy applied outbound governs what the controller advertises to the sites in the list. Applied inbound it governs what the controller accepts from them. Topology work is almost always outbound, because the shape is determined by what each site learns. An inbound policy is for controlling what a site is permitted to inject, which is a different and less common requirement.

! Topology policy is applied OUT, to the sites being shaped
apply-policy
 site-list SPOKES
  control-policy SPOKE-TOPOLOGY out
 !
!
! Applied 'in' it would filter what spokes advertise TO
! the controller - a different job entirely, and a common
! way to write a policy that appears to do nothing.
!
vSmart# show running-config apply-policy

The default action

Every control policy ends with a default action, and it decides the fate of everything the sequences did not match. Set to reject, the policy becomes an allow-list and anything forgotten disappears. Set to accept, it becomes a deny-list and only what is explicitly rejected is removed. Both are legitimate; choosing without noticing is how a policy intended to restrict spoke-to-spoke traffic removes a site's route to the data centre as well.

! Allow-list: safer to reason about, easier to get wrong
control-policy STRICT
 sequence 10
  match route
   site-list HUBS
  action accept
 !
 default-action reject
 ! ^ anything not listed above is GONE, including
 !   things you did not think about
!
! Deny-list: only removes what you name
control-policy PERMISSIVE
 sequence 10
  match tloc
   site-list SPOKES
  action reject
 !
 default-action accept
!

Sequence order, and why it is not like an access list

Sequences are evaluated in order and the first match wins, which is familiar. What is less familiar is that endpoint sequences and route sequences are effectively independent lanes — an advertisement is either one or the other, so a route sequence placed before an endpoint sequence does not shadow it. Reading a policy therefore means reading two interleaved lists rather than one.

The practical consequence is that grouping by type rather than strictly by number makes a policy far easier to follow. Putting every endpoint sequence together and every route sequence together, with exceptions at the top of each group, produces something a colleague can reason about. Interleaving them by accident produces a policy that is correct and unreadable, which is its own kind of risk.

What policy cannot do

Control policy shapes the overlay's control information and has no effect on packets. It cannot drop traffic, cannot inspect it, and cannot make a forwarding decision — those are the data policy's job. A requirement phrased as "stop these sites talking to each other" can be met by control policy only in the sense of removing the direct path; if the traffic can still reach its destination through the hub, control policy has not blocked anything.

How Do I Build Hub-and-Spoke?

What does the policy need to say?

Four things. Spokes may learn the hubs' endpoints. Spokes may not learn each other's endpoints. Spokes may learn each other's prefixes, rewritten to point at a hub. And the hubs themselves are left alone, because they need to see everything in order to forward between spokes. The fourth is the one omitted most often, usually by applying the policy to a site list that accidentally includes the hubs.

A Deeper Dive into Hub-and-Spoke

The lists first

Every control policy is built on site lists and endpoint lists, and getting those right is most of the work. A site list that is defined by a range rather than an enumeration will pick up new sites automatically, which is usually what you want and occasionally a surprise when a new site lands inside the range and inherits the spoke policy before anyone intended.

! Lists, which the whole policy depends on
policy
 lists
  site-list HUBS
   site-id 1-10
  !
  site-list SPOKES
   site-id 100-999
  !
  tloc-list HUB-TLOCS
   tloc 10.255.0.11 color mpls encap ipsec preference 200
   tloc 10.255.0.11 color biz-internet encap ipsec preference 100
   tloc 10.255.0.12 color mpls encap ipsec preference 200
   tloc 10.255.0.12 color biz-internet encap ipsec preference 100
  !
 !
!
! Two hubs, two transports each: four endpoints that
! spoke traffic can be pointed at, with preferences.

The policy itself

! Hub and spoke, complete
policy
 control-policy SPOKE-TOPOLOGY
  ! 1. spokes keep the hubs' endpoints
  sequence 10
   match tloc
    site-list HUBS
   action accept
  !
  ! 2. spokes do NOT learn each other's endpoints
  sequence 20
   match tloc
    site-list SPOKES
   action reject
  !
  ! 3. spoke prefixes are reachable, via a hub
  sequence 30
   match route
    site-list SPOKES
   action accept
    set
     tloc-list HUB-TLOCS
    !
  !
  ! 4. everything else - hub prefixes included - accepted
  default-action accept
 !
!
apply-policy
 site-list SPOKES
  control-policy SPOKE-TOPOLOGY out
 !
!
! ^ applied only to SPOKES. The hubs get no policy and
!   therefore keep full visibility, which they need.

Verifying from a spoke

The check is on a spoke, not on the controller, because the controller shows what it holds rather than what it sent. A correctly shaped spoke holds the hub endpoints and no peer endpoints, holds peer prefixes pointing at a hub, and has tunnel sessions only to the hubs. Four observations, and any one of them being wrong identifies which sequence misbehaved.

! On a spoke, after the policy is activated
SPOKE-1# show sdwan omp tlocs
! ^ hub endpoints only - no other spokes
!
SPOKE-1# show sdwan omp routes vpn 10 | include 10.10.20
! ^ the peer's prefix IS present...
SPOKE-1# show sdwan omp routes vpn 10 10.10.20.0/24 detail | include tloc
   tloc   10.255.0.11, mpls, ipsec
! ^ ...pointing at the HUB. That is the rewrite working.
!
SPOKE-1# show sdwan bfd sessions
! ^ sessions to hubs only
!
SPOKE-1# show sdwan policy from-vsmart

Preference inside the endpoint list

When peer routes are rewritten to a list of hub endpoints, the preferences inside that list decide which hub a spoke actually uses and over which transport. That makes the endpoint list a piece of traffic engineering rather than a bare enumeration: listing the primary hub's private transport with the highest value sends normal traffic there, and the lower entries become the failover order.

It also means the failover behaviour for spoke-to-spoke traffic is defined in one place, centrally, for every spoke at once. Changing which hub is primary is an edit to one list rather than a change at each site, which is the same benefit central policy provides everywhere and is easy to overlook here because the list looks like configuration rather than policy. Treating it as policy, and reviewing it when the hub design changes, keeps the two in step.

Confirming the hub can still forward

Spoke-to-spoke traffic now arrives at the hub and must leave it again towards the other spoke, which requires the hub to hold both spokes' prefixes and endpoints. It does, because no policy was applied to the hubs — but it is worth confirming rather than assuming, since an over-broad site list is the one thing that would break it and the symptom would be spoke-to-spoke traffic dying at the hub. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.

! The hub must still see everything
HUB-1# show sdwan omp tlocs | count
HUB-1# show sdwan bfd sessions | count up
! ^ should be the full spoke count, not a reduced one
!
HUB-1# show sdwan policy from-vsmart
! ^ ideally empty: no policy applied to the hubs
!
! And an end-to-end test that exercises the path
SPOKE-1# ping vrf 10 <address at SPOKE-2>
SPOKE-1# traceroute vrf 10 <address at SPOKE-2>
! ^ the hub should appear as a hop

How Do I Build Regional Meshes and Other Shapes?

What is the general pattern?

One policy per group of sites, each expressing what that group may see. A regional mesh is hub-and-spoke with one addition: a site also accepts the endpoints of other sites in its own region. That single extra sequence turns a star into a set of regional meshes joined through the hubs, and the tunnel count per site falls from the estate size to the region size.

A Deeper Dive into Other Shapes

Regional mesh

! Region lists, then one policy per region
policy
 lists
  site-list REGION-EMEA
   site-id 100-299
  site-list REGION-AMER
   site-id 300-499
  site-list HUBS
   site-id 1-10
 !
 control-policy EMEA-TOPOLOGY
  ! peers within my own region: full visibility
  sequence 10
   match tloc
    site-list REGION-EMEA
   action accept
  !
  ! the hubs, always
  sequence 20
   match tloc
    site-list HUBS
   action accept
  !
  ! everything else: no endpoint, route via a hub
  sequence 30
   match route
    site-list REGION-AMER
   action accept
    set
     tloc-list HUB-TLOCS
    !
  !
  sequence 40
   match tloc
    site-list REGION-AMER
   action reject
  !
  default-action accept
 !
!
apply-policy
 site-list REGION-EMEA
  control-policy EMEA-TOPOLOGY out
 !
 site-list REGION-AMER
  control-policy AMER-TOPOLOGY out
 !
!

What the tunnel count becomes

The arithmetic is the justification, and it is worth computing for the actual estate rather than reasoning about it qualitatively. A site's tunnel count in a regional mesh is its region size rather than the estate size, which for a four-hundred-site estate split into four regions is a reduction of roughly four times — and the traffic that matters most, which is usually within a region, still takes a direct path. That combination — most of the reduction, none of the latency cost on the traffic that matters — is why regional meshes are the common landing point rather than either extreme.

On-demand tunnels as a middle ground

Some deployments support building a direct tunnel only when traffic actually needs one, then tearing it down when the conversation ends. That gives hub-and-spoke's steady-state tunnel count with a full mesh's paths for the conversations that occur, at the cost of a brief hub detour at the start of each one. Where it is available it is often the best answer for an estate whose branch-to-branch traffic is real but sparse.

Choosing the region boundaries

Regions in this context are policy constructs rather than geography, and the useful boundary is the one traffic respects. Sites that talk to each other belong in a region together; sites that only ever talk to the data centre can be in whichever region is administratively convenient, because they will never use the direct paths their region membership grants them.

Getting this wrong in the generous direction costs tunnels that are never used. Getting it wrong in the restrictive direction costs latency on traffic that now detours through a hub. Flow data answers it, and the answer tends to follow organisational structure — sites in the same business unit talk to each other — more closely than it follows the map.

Partial exceptions

Real estates have exceptions — two branches that must talk directly because of a specific application, a site that should reach everything, a group being migrated. These are extra sequences with tighter matches placed before the general ones, and the ordering matters because the first matching sequence wins. Keeping exceptions at the top and general rules at the bottom is the convention that makes a policy readable a year later.

! Exceptions first, general rules after
control-policy SPOKE-TOPOLOGY
 ! exception: these two branches talk directly
 sequence 5
  match tloc
   site-list DIRECT-PAIR
  action accept
 !
 ! general rule: spokes do not see each other
 sequence 20
  match tloc
   site-list SPOKES
  action reject
 !
 default-action accept
!
! Sequence 5 is evaluated first, so the pair survives
! the rejection that applies to every other spoke.

Which Topology Policy Mistakes Cut Sites Off?

What are the failures worth memorising?

Four, and they share the property that the blast radius is the estate rather than a site. A default action of reject that silently removes what the sequences forgot. A policy applied to a list that includes the hubs. Endpoints withheld without the routes being rewritten. And a site range that captured a site nobody intended, giving it a role it was never designed for.

A Deeper Dive into the Failure Catalogue

The default action nobody read

The over-broad site list

The site that landed in the wrong range

Activating safely

A topology policy is a single central object whose activation affects every site it applies to simultaneously, which makes the usual change discipline more than a formality. Knowing which version was previously active, having a verification step that reads a real site rather than the policy, and being able to reactivate the previous version quickly are the three things that turn a bad activation into a short one.

! Before activating: record what a representative site holds
SPOKE-1# show sdwan omp tlocs | count
SPOKE-1# show sdwan omp routes vpn 10 | count
SPOKE-1# show sdwan bfd sessions | count up
HUB-1#   show sdwan omp tlocs | count
!
! After activating: the same four, compared
! Spoke counts should FALL. Hub counts should NOT.
!
! And confirm the shape rather than the numbers
SPOKE-1# show sdwan omp routes vpn 10 <peer prefix> detail | include tloc
! ^ should name a HUB endpoint
!
! Rollback is reactivating the previous policy version.

Why these failures are worse than they sound

A misconfigured routing protocol usually breaks one adjacency or one prefix. A misconfigured central policy breaks the same thing at every site it applies to, simultaneously, within seconds of activation. The technology is doing exactly what central control is supposed to do — apply one decision everywhere — and that property cuts both ways.

The mitigation is not to avoid central policy, which would discard its main benefit, but to treat activation as a change with estate-wide scope. That means the same care a firewall rule change gets: a reviewer, a recorded previous state, a defined verification, and a rollback that somebody has actually performed before rather than read about.

What to monitor afterwards

Endpoint count per site against the designed value for its role. In a shaped topology that number is predictable — a spoke should hold the hub endpoints and nothing else, a regional site should hold its region — and a site holding more or fewer than its role implies is either a policy that did not apply or a site in the wrong group. It is one number, it is constant, and nothing else detects this class of problem.

Migrating an existing estate

Restricting the topology of a running full mesh removes tunnels that traffic is currently using, so the order of operations matters. Rewriting the peer routes to point at a hub first, verifying that traffic still flows, and only then rejecting the peer endpoints means the alternative path is proven before the direct one is removed. Doing it the other way round removes the direct path and tests the alternative simultaneously.

Doing it region by region rather than estate-wide is the other half of the same discipline. One region shaped and observed for a few days surfaces whatever assumption was wrong — a branch-to-branch application nobody documented, a latency budget that the hub detour breaks — while the blast radius is still a quarter of the estate rather than all of it.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers SD-WAN policy within the software-defined infrastructure domain, and topology questions are usually phrased as an outcome: make these sites reach each other only through the hub. That maps onto rejecting the peer endpoints and rewriting the peer routes, applied outbound to the spoke list, with the hubs left untouched — four decisions, and the marks are in remembering all four.

Conclusion

The overlay is a full mesh by default because every site is told about every endpoint, and an endpoint an edge knows about is one it will build a tunnel to. Changing the topology therefore means changing what sites are told, and the shape that results is emergent rather than declared. Nothing in the configuration says hub-and-spoke; a policy withholds endpoints from spokes and hub-and-spoke is what happens.

Two mechanisms do the work and most topologies need both. Rejecting an endpoint makes a tunnel impossible. Rewriting a route's endpoint provides the alternative path that keeps the destination reachable. A policy that does only the first leaves sites holding routes they cannot resolve, which is the single most common way a topology change breaks connectivity it was not meant to touch.

Everything else is about blast radius. The policy is one central object, it activates everywhere at once, and the two settings most likely to cause damage — the default action and the site list it is applied to — are both easy to set without deciding. Recording a representative site's endpoint and route counts before activation, and comparing them afterwards, takes a minute and is the difference between noticing immediately and being told by users. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.

External Links

• RFC 4271 — A Border Gateway Protocol 4 (BGP-4)
• RFC 4456 — BGP Route Reflection
• RFC 4301 — Security Architecture for the Internet Protocol
• RFC 5880 — Bidirectional Forwarding Detection (BFD)
• Cisco — Cisco SD-WAN Policies Configuration Guide
• Cisco — Cisco SD-WAN Routing Configuration Guide
• Cisco Learning Network — CCIE Enterprise Infrastructure

Reference Notes

1. Cisco SD-WAN documentation describes centralised control policy as applied on vSmart to OMP advertisements, in the inbound or outbound direction relative to a site list.
2. Cisco documentation states that in the absence of control policy every WAN Edge receives all TLOC and OMP route advertisements, producing a full mesh of data plane tunnels.
3. Cisco documentation describes match tloc and match route as distinct control policy match types, governing tunnel establishment and route reachability respectively.
4. Cisco documentation describes the set tloc-list action, which rewrites the TLOC associated with an accepted route so that traffic reaches the destination through a different tunnel endpoint.
5. Cisco documentation describes the control policy default action, which applies to advertisements not matched by any sequence and may be set to accept or reject.
6. Cisco documentation describes site lists defined by individual site identifiers or ranges, used both for matching within a policy and for applying it.
7. Cisco documentation describes TLOC lists, which may carry preference values used when a route's TLOC is rewritten to a set of alternatives.
8. Cisco documentation states that one centralised policy is active on the controllers at a time, and that changes are made by editing and reactivating it.
9. Cisco documentation notes that control policy affects OMP advertisements only and does not act on data traffic, which is the role of centralised data policy.
10. RFC 4456 defines BGP route reflection, the model vSmart follows when reflecting OMP advertisements between WAN Edge devices.
11. Cisco documentation describes show sdwan policy from-vsmart on a WAN Edge, which reports the policy received from the controller after it has been applied.
12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include SD-WAN policy within the software-defined infrastructure domain.