Cisco Catalyst SD-WAN Deep Dive Part 3: TLOCs, Color, and Centralized Policy

6 July 2026 Cisco SDWAN

Part 2 deferred two things: what TLOC color actually constrains, and how vSmart turns raw OMP reachability into enforced topology. Both questions have the same answer underneath — centralized policy — so this post covers them together.

Color is metadata that does real work

Every TLOC carries a color attribute, and it’s tempting to read it as a free-text label — “this is the MPLS link, that one’s the cable modem” — but color does three concrete things in the architecture, not just one:

It’s a policy match key. Control policy, data policy, and app-route policy can all match on color directly. “Prefer mpls over biz-internet for this site-list” is a one-line policy statement because color is a first-class field, not something you’d have to derive from an interface name or an IP range.
It implies a trust/NAT posture. Colors are split into two buckets out of the box. Private colors — mpls, metro-ethernet, private1 through private6 — are treated as direct, non-NAT’d underlay transports by default: an edge assumes it can reach another edge’s private-color TLOC at the address advertised, no NAT traversal expected. Public colors — biz-internet, public-internet, lte, 3g, red, blue, green, gold, silver, bronze, and the rest of the “default” bucket — are assumed to potentially sit behind NAT, which is exactly the NAT type Part 1’s vBond handshake detected. This split is why a TLOC route (Part 2) carries both private and public IP/port: the receiving edge needs to know which address to actually try, and that decision leans on color.
It gates tunnel formation via restrict/no-restrict. This is the one worth a full section.

restrict and no-restrict

Every color carries a restrict or no-restrict setting. no-restrict is the default and the permissive case: an edge with a no-restrict color can build a data-plane tunnel to a remote TLOC of any color, mixing transports freely — an mpls TLOC can tunnel to a biz-internet TLOC on the other end without complaint. restrict flips that: an edge can only build tunnels to remote TLOCs of the same color. Set mpls to restrict and your MPLS-sourced tunnels will only ever terminate on another site’s mpls TLOC — never accidentally riding out over a cheaper Internet circuit because that happened to be the best OMP path by some other metric.

Two practical reasons this knob exists, both encountered constantly in real deployments:

Cost and capacity intent. A customer paying for guaranteed MPLS bandwidth between two specific sites usually doesn’t want that traffic silently falling back to a consumer Internet circuit if the policy engine decides it’s “available” — restrict keeps committed-bandwidth transports segregated from best-effort ones unless you explicitly design a cross-color path.
Security segmentation. A site with a deliberately untrusted or lower-assurance transport (think: a temporary LTE failover link, or a transport handed to you by a third party at a shared site) can be restricted so it never becomes an accidental tunnel endpoint for traffic that should only ever ride trusted transports.

This is also where the IPsec mechanics underneath get genuinely relevant — restrict/no-restrict and the public/private color split are essentially policy-level decisions about NAT traversal behavior, and if you want the wire-level detail of what changes about an ESP exchange once NAT is in the picture, the IPsec deep dive’s NAT post covers exactly that — NAT-T, the three ways NAT breaks plain IPsec, port-4500 encapsulation. Everything in that post is happening underneath every public-color TLOC pairing described here.

Centralized policy: three kinds, one enforcement point

vManage is where you author policy; vSmart is where it’s enforced, applied as OMP routes are reflected between edges. There are three distinct policy types, and conflating them is a common source of “why didn’t my policy do anything” confusion:

Policy type	Acts on	Typical use
Control policy	OMP route advertisement itself — which routes get reflected to which edges at all	Topology enforcement: hub-and-spoke, regional mesh, site isolation
Data policy	Actual data-plane forwarding decisions on traffic already matching a 5-tuple or app	ACL-like behavior, traffic redirection to a service (firewall, IDS)
App-route policy	Path selection driven by measured SLA (loss/latency/jitter) per TLOC pair	SLA-class-based path steering — its own deep topic, picked up properly in the QoS comparison in Part 4

This post is about control policy, because it’s the one that directly answers “how do you turn flat OMP reachability into an actual enforced topology.”

Site-lists and TLOC-lists are the building blocks

Centralized control policy is built from named, reusable objects defined once on vManage:

Site-list — a set of site IDs, e.g. SPOKES = 100-199, HUBS = 1-2.
TLOC-list — a set of specific (system-ip, color, encap) TLOCs, used when you need to steer toward particular transports rather than whole sites.
Prefix-list — ordinary destination-prefix matching, same idea as a BGP prefix-list.

A control policy then combines these into match/action sequences applied in a direction (inbound from a site-list, typically) at the vSmart, and the action is usually some combination of: accept/reject the route, rewrite its TLOC list to prefer or restrict to specific TLOCs, or set preference.

Worked example: enforcing hub-and-spoke

Take a site-list SPOKES (every branch) and HUBS (two DC hubs). The goal: spokes can reach hubs and anything behind them, but spokes cannot build direct tunnels to each other — every inter-branch flow must transit a hub. The shape of the policy, conceptually:

policy
 control-policy DENY-SPOKE-TO-SPOKE
  sequence 10
   match route
    site-list SPOKES
   action reject
  default-action accept
!
apply-policy
 site-list SPOKES
  control-policy DENY-SPOKE-TO-SPOKE in

Applied inbound at vSmart for routes arriving from spoke sites, this rejects spoke-originated OMP routes from being reflected to other spoke sites — a spoke’s prefixes still get reflected to the hubs (no match against the spoke site-list when the receiving side is a hub), but spoke-to-spoke reflection is suppressed. The result: every spoke edge only ever learns hub-originated and hub-reachable routes, so the only TLOCs it can build tunnels toward are at the hubs, and inter-branch traffic is forced through hub forwarding by construction — no static routing tricks needed, no manual tunnel suppression on each edge. This is the direct architectural analogue to what the Fortinet hub-placement series achieves with ADVPN shortcut suppression and hub-anchored design — same business outcome (force traffic through a hub for inspection or simplicity), different mechanism (OMP route filtering at a central controller vs. shortcut/spoke-to-spoke negotiation suppression at the data-plane device itself).

The reverse — letting any two spokes that need to talk build a direct shortcut tunnel once both have learned of each other — is the no-policy default behavior, and it’s worth remembering that centralized control policy is opt-in restriction on top of an otherwise any-to-any overlay, not the other way around. Cisco Catalyst SD-WAN’s default posture is full mesh; you carve hub-and-spoke or regional segmentation out of it deliberately.

Localized policy: the other half, deliberately separate

Everything above lives on vManage and is enforced by vSmart — it’s fabric-wide by definition. Localized policy is the opposite: configured per-device, applied directly to that WAN Edge’s own behavior, and it never touches vSmart’s route-reflection logic. Typical contents: route redistribution into OMP from a locally-running OSPF or BGP process (how a site’s existing IGP-learned routes actually become OMP routes in the first place), QoS class maps and queuing on physical interfaces, ACLs on underlay-facing interfaces, and any local BGP/OSPF peering toward on-site infrastructure that isn’t itself part of the SD-WAN fabric.

The distinction matters operationally: if a route isn’t propagating fabric-wide, the bug is almost always in centralized control policy or in how a site is redistributing routes into OMP via localized policy — not in some third place. Two policy domains, two separate places to look, and conflating them wastes troubleshooting time.

Part 4 moves off policy and onto the actual forwarding path: BFD running per-tunnel for failure detection, app-route policy’s SLA-class steering in practice, and where vEdge and cEdge genuinely diverge in how they push packets once OMP and policy have already decided where those packets are allowed to go.