Back
Lesson 2 of 7

Centralized Control Policies

Objective

In this lesson you will configure centralized control policies on the vSmart controller: create route policies for route manipulation, build TLOC lists, and apply topology control so that the SD‑WAN fabric prefers or suppresses specific TLOCs. This matters in production because centralized policies let you shape routing behavior across hundreds of WAN edges from one place — for example, steering SaaS traffic over a low‑latency Internet transport while keeping backup traffic on MPLS. The lab demonstrates how route attributes are changed centrally and how those attributes affect OMP/TLOC decision making across the data plane.

Topology

ASCII diagram showing the three logical devices used in this lesson. The IPs and interface names below are taken from the reference material; where additional addresses are required for links we use RFC1918 addresses.

Note: vSmart uses System IP 10.0.0.1 (from the reference) as the controller System IP.

Switches and cloud/Internet are implicit; we show only the SD‑WAN controllers and two WAN Edges used for policy testing.

                          Internet
                             |
                             |
                       +-----------+
                       |  Cloud    |
                       +-----------+
                           | 203.0.113.1
                           |
                +---------------------------+
                |        WAN-Edge-1         |
                |  (Edge Router)            |
                |  G0/0: 198.51.100.10/30   |
                |  G0/1: 10.1.1.1/24 (Mgmt) |
                +---------------------------+
                         |       |
                         |mpls   |
                    10.0.0.2|   |
                         |   |
                +---------------------------+
                |        vSmart             |
                | (Controller)              |
                | System IP: 10.0.0.1       |
                | (control-plane identity)  |
                +---------------------------+
                         |   |
                    10.0.0.3|   |
                         |   |
                +---------------------------+
                |        WAN-Edge-2         |
                |  (Edge Router)            |
                |  G0/0: 198.51.100.14/30   |
                |  G0/1: 10.2.2.1/24 (Mgmt) |
                +---------------------------+
  • vSmart System IP: 10.0.0.1 (taken from the reference)
  • WAN-Edge-1 and WAN-Edge-2 connected to vSmart (control connections) over the control plane network using 10.0.0.2 and 10.0.0.3 (RFC1918 used for the fabric control connectivity in this lab diagram).
  • Each WAN Edge also has a public-facing interface G0/0 that maps to its TLOC (198.51.100.10 and .14).

Device Table

DeviceRoleSystem IP / Interface IPs shown in topology
vSmartControllerSystem IP: 10.0.0.1
WAN-Edge-1WAN EdgeG0/0: 198.51.100.10/30, G0/1: 10.1.1.1/24
WAN-Edge-2WAN EdgeG0/0: 198.51.100.14/30, G0/1: 10.2.2.1/24

Tip: In production, vSmart typically sits behind a public IP or in a secured control plane network. The System IP is the control-plane identity used by OMP (Overlay Management Protocol) to exchange routing and policy information.

Quick Recap

This lesson builds on the fabric established previously (Lesson 1). We already have WAN Edges authenticated and connected to the control plane; vSmart is reachable with System IP 10.0.0.1. In this lesson we add centralized route policies and TLOC list objects on the vSmart so that the fabric can:

  • Manipulate route attributes (e.g., set preference, community or MED-like attributes used by OMP)
  • Define TLOC lists that represent groups of transport links (for example, all MPLS TLOCs)
  • Create topology‑control decisions (prefer or suppress specific TLOCs)

No additional physical devices are added in this lesson.

Key Concepts

  • OMP (Overlay Management Protocol): The control plane protocol used between vSmart and WAN Edges to exchange routes and next‑hop (TLOC) information. When the vSmart modifies an attribute in a route policy, it changes the OMP route attributes distributed to all WAN Edges.

    Packet‑level note: OMP is carried on the control connection established between System IPs (e.g., 10.0.0.1) and does not encapsulate user traffic — it controls how traffic will be forwarded in the data plane.

  • TLOC (Transport Locator) and Color: A TLOC identifies a transport endpoint (System IP + color + encapsulation). Color is an abstraction (Internet, MPLS, etc.) used to create policy. If you create a TLOC list of color MPLS, you target all MPLS transports for policy rules.

  • Route manipulation on vSmart: Centralized policies can set preference or tag routes to influence path selection on WAN Edges. Think of vSmart like a traffic director: it can assign attributes akin to BGP local‑pref so that edges choose the desired TLOC for a prefix.

  • TLOC lists and topology policies: A TLOC list groups one or more TLOCs. Topology policies (or route policies that reference TLOC lists) can steer traffic to a subset of transports. In production, use this to route critical application traffic over secure/private MPLS and casual traffic over Internet.

  • Policy distribution and enforcement: Policies are authored centrally (on vSmart/vManage) and distributed to WAN Edges. Once distributed, the WAN Edge enforces the decision when installing forwarding entries in the FIB and when selecting a next hop TLOC.

Step-by-step configuration

We perform four main actions:

  1. Create a route policy on vSmart that matches a prefix and sets an OMP attribute (preference).
  2. Create a TLOC list that groups MPLS TLOCs.
  3. Create and attach a topology/route policy that uses the TLOC list to steer selected prefixes to MPLS.
  4. Verify the policy distribution and the OMP route table on WAN Edges.

Each step below follows the required pattern: what we’re doing, commands, explanation, real-world note, and verification.

Step 1: Create a route policy on vSmart to set route preference

What we are doing: We configure a centralized route policy on the vSmart to match a particular prefix and set a higher preference so WAN Edges prefer a specific path for that prefix. This ensures the selected traffic uses the intended TLOC in the fabric.

configure terminal
policy
  route-policy PREFER-MPLS
    sequence 10
      match ip prefix-list PREFIX-SALES
      set preference 200
    exit
exit
ip prefix-list PREFIX-SALES seq 5 permit 10.1.10.0/24
end

What just happened:

  • Entered global configuration and created a route policy named PREFER-MPLS.
  • The policy matches the prefix-list PREFIX-SALES (10.1.10.0/24) and sets its OMP preference to 200. A higher preference (numerically larger in Cisco SD‑WAN OMP terms) signals WAN Edges to prefer the path that carries that attribute.
  • The prefix-list defines the matched subnet.

Real-world note: Use centralized preference changes to steer application traffic (e.g., voice or finance apps) to the most reliable transport without touching each edge device.

Verify:

show policy route-policy PREFER-MPLS
policy route-policy PREFER-MPLS
  sequence 10
    match ip prefix-list PREFIX-SALES
    set preference 200
  end

Step 2: Define a TLOC list for MPLS transports

What we are doing: We create a TLOC list object that represents MPLS transport TLOCs. Topology and route policies will reference this list to direct traffic specifically to MPLS TLOCs.

configure terminal
tloc-list MPLS-TLOCS
  member 10.0.0.2 color mpls encap ipsec
  member 10.0.0.3 color mpls encap ipsec
exit
end

What just happened:

  • Created a TLOC list named MPLS-TLOCS and added members: the control plane System IPs 10.0.0.2 and 10.0.0.3 mapped to color mpls with ipsec encapsulation. These entries represent MPLS TLOCs in the fabric that can be targeted by policies.

Real-world note: In production, the TLOC list would include all MPLS-facing TLOCs from various WAN Edges (and could also include multiple encapsulation types like DTLS/IPSec). Grouping simplifies policy authoring.

Verify:

show tloc-list MPLS-TLOCS
TLOC List: MPLS-TLOCS
  Member: System IP 10.0.0.2, Color mpls, Encap ipsec
  Member: System IP 10.0.0.3, Color mpls, Encap ipsec

Step 3: Create a topology/route policy to steer prefix to the MPLS TLOC list

What we are doing: We create a topology policy that matches the same prefix and forwards (steers) it to the MPLS‑TLOCS group. This effectively pins the traffic to MPLS transports when possible.

configure terminal
policy
  route-policy STEER-TO-MPLS
    sequence 10
      match ip prefix-list PREFIX-SALES
      set tloc-list MPLS-TLOCS
    exit
exit
end

What just happened:

  • Added STEER-TO-MPLS policy that matches 10.1.10.0/24 and assigns the route’s preferred TLOC list to MPLS-TLOCS. When vSmart distributes this policy, edges will prefer TLOCs in that list for forwarding decisions related to the matched prefix. The policy modifies the OMP next-hop selection metadata rather than altering packet payloads.

Real-world note: Topology control is frequently used to ensure critical traffic traverses private transports (MPLS) for predictability and SLAs, while best-effort traffic uses internet.

Verify:

show policy route-policy STEER-TO-MPLS
policy route-policy STEER-TO-MPLS
  sequence 10
    match ip prefix-list PREFIX-SALES
    set tloc-list MPLS-TLOCS
  end

Step 4: Verify on a WAN Edge that the OMP route and TLOC selection reflect the policy

What we are doing: On a WAN Edge (e.g., WAN-Edge-1), we verify that the OMP route for 10.1.10.0/24 shows the preference and selected TLOC membership provided by vSmart policy.

show sdwan omp routes
OMP Route: 10.1.10.0/24
  Source: vSmart (10.0.0.1)
  Preference: 200
  Installed Next Hop TLOC: 10.0.0.2 (color mpls)
  Advertised by: System IP 10.0.0.2 (WAN-Edge-1)

What just happened:

  • The WAN Edge shows the OMP route for 10.1.10.0/24 with the centrally set preference of 200. The selected next hop TLOC is one of the MPLS TLOCs (10.0.0.2), demonstrating policy steering took effect. The route was distributed by vSmart and installed into the OMP route table on the edge.

Real-world note: If the specified MPLS TLOC becomes unreachable, the fabric will fail over per OMP rules to the next available TLOC (unless you explicitly suppress failover). Always test failover behavior after applying strict topology constraints.

Verify additional control-plane state:

show sdwan tlocs
TLOCs known to controller:
  System IP: 10.0.0.2, Color: mpls, Encap: ipsec, Public IP: 198.51.100.10
  System IP: 10.0.0.3, Color: mpls, Encap: ipsec, Public IP: 198.51.100.14

Verification Checklist

  • Check 1: vSmart route policy exists and matches PREFIX-SALES — verify with show policy route-policy PREFER-MPLS.
  • Check 2: TLOC list contains the expected System IPs and color — verify with show tloc-list MPLS-TLOCS.
  • Check 3: WAN Edge OMP route shows the modified preference and chosen MPLS TLOC — verify with show sdwan omp routes and show sdwan tlocs on the edge.

Common Mistakes

SymptomCauseFix
Policy present on vSmart but WAN Edge still uses Internet TLOCTLOC list references wrong System IP or wrong colorConfirm System IPs in TLOC list match the edge’s System IPs (use show sdwan tlocs) and color matches (e.g., mpls)
Route not matched by policyPrefix list typo or incorrect prefix maskCheck ip prefix-list PREFIX-SALES content and ensure prefix is exact (10.1.10.0/24)
Preference set but route not installedPolicy not distributed to WAN Edges or vSmart did not commit changesVerify policy present on vSmart (show policy *) and check control connections are up; ensure vSmart committed configuration
No failover to Internet when MPLS failsTopology policy pinned to MPLS without fallbackFor production, create a secondary policy or allow fallback by not setting strict tloc-list enforcement; test failure scenarios

Key Takeaways

  • vSmart route policies and TLOC lists provide centralized control to influence how routes are installed and which transport (TLOC) is used in the data plane. Think of vSmart as a centralized route‑attribute editor distributing OMP routes.
  • TLOC color abstraction is critical: group transports by color (e.g., MPLS, Internet) and use TLOC lists to simplify steering policies across many edges.
  • Always verify both policy objects on vSmart and the resultant OMP routes and TLOC selection on the WAN Edge; control-plane verification and data-plane failover tests are both necessary in production.
  • In real networks, use centralized policies to enforce SLA-driven routing (send Voice over MPLS, SaaS over low-latency internet), but plan for graceful failover and avoid overly rigid policies that prevent availability.

Warning: When you set strict topology constraints (steering to a specific TLOC list), you may prevent automatic failover to other transports. Always test failover behavior as part of policy deployment and include fallbacks where necessary.

If you want, the next lesson will cover advanced policy chaining (combining data-policy and control-policy) and how to create conditional path selection based on application SLA measurements.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security