Lesson 5 of 7

Traffic Engineering with Policies

Objective

In this lesson you will configure SD-WAN policies to control path preference, perform active-active load balancing across multiple transport links, and define backup path selection. These techniques let you steer critical application traffic over preferred, higher-quality links while keeping less-critical flows on cheaper Internet links — a common requirement in production WANs where MPLS and Internet coexist. Real-world scenario: a retail HQ with MPLS + Broadband must ensure ERP traffic uses MPLS primarily, use broadband for web traffic, and fail over ERP to broadband if MPLS experiences packet-loss or latency beyond thresholds.

Note: This is Lesson 5 of 7 in Lab 40: SD-WAN Policies Deep Dive. We reference the site topology introduced in Lesson 1 and only add elements specific to traffic-engineering policies in this lesson.


Quick Recap

We continue with the topology used in Lesson 1. No new devices are added for this lesson; we will apply policy objects on the controller (vSmart) and propagate them to the edge routers (SD‑WAN edges). The topology (management and WAN IPs) used throughout this lab:

ASCII topology (management plane + WAN interfaces)

                             +---------------------+
                             |     vManage         |
                             |  mgmt: 10.0.0.10    |
                             +---------------------+
                                     |
                                     |
                             +---------------------+
                             |     vSmart          |
                             |  mgmt: 10.0.0.11    |
                             +---------------------+
                                     |
                                     |
          ---------------------------+---------------------------
          |                          |                          |
+----------------+         +-------------------+        +------------------+
|  HQ-CSR1000    |         |  BR1-CSR1000      |        |  BR2-CSR1000     |
| mgmt:10.0.1.1  |         | mgmt:10.0.2.1     |        | mgmt:10.0.3.1    |
| Gi0/0:203.0.113.1 (ISP-A)| Gi0/0:203.0.113.2 (ISP-A)| Gi0/0:198.51.100.2 (ISP-B) |
| Gi0/1:198.51.100.1 (ISP-B)| Gi0/1:198.51.100.2 (ISP-B)| Gi0/1:203.0.113.3 (ISP-A) |
+----------------+         +-------------------+        +------------------+

Management domain: lab.nhprep.com
Default management password used in examples: Lab@123

All subsequent configuration commands reference these devices and interfaces.


Key Concepts (theory + packet flow)

Before touching CLI/GUI, understand these essential SD‑WAN traffic‑engineering concepts:

  • Policy Types and Roles

    • Control policies (distributed from vSmart) influence routing/control-plane behavior; Data policies (also pushed from controller) shape packet forwarding in the data plane.
    • Why it matters: the control plane decides which TLOCs (transport locators) are known; data plane policies decide which tunnel a packet actually traverses.
  • TLOC and Path Preference

    • A TLOC is the tuple (system IP, color, transport IP) representing a reachable transport. Policies reference TLOCs by color (e.g., mpls, public-internet) to choose paths.
    • Packet flow: when a packet matches a data policy, the edge encapsulates traffic into a DTLS/UDP tunnel toward the selected TLOC.
  • Active-Active Load Balancing

    • You can distribute flows across multiple TLOCs based on match criteria (prefix, application, DSCP). Per-flow hashing helps maintain session affinity.
    • Production context: use active-active to utilize multiple costly links rather than keeping one idle.
  • Backup and Failover

    • Policies can specify primary and secondary paths; health probes (path monitoring) and route metrics guide failover.
    • This matters because planned backup ensures SLA for critical apps under link degradation.
  • Policy Priority and Order

    • Policies are evaluated top-down. First match wins. Always plan sequence numbers to guarantee critical traffic is intercepted by high-priority policies.

Analogy: Think of TLOCs as different highways to the same city — policy is the GPS that chooses which highway each car (packet) takes based on destination, car type, and traffic conditions.


Step-by-step configuration

Each step below follows the pattern: What we are doing, exact commands, explanation, real-world note, and verification showing full expected output.

Step 1: Create prefix sets to identify critical and non-critical traffic

What we are doing: Define prefix sets that match ERP traffic (critical) and web traffic (non-critical). Prefix sets are used by policies to match destinations. This matters so we can steer ERP traffic differently from general web traffic.

vsmart# configure terminal
vsmart(config)# policy
vsmart(config-policy)# prefix-set prefixes-ERP
vsmart(config-prefix-set)# 10.10.10.0/24
vsmart(config-prefix-set)# exit
vsmart(config-policy)# prefix-set prefixes-WEB
vsmart(config-prefix-set)# 0.0.0.0/0
vsmart(config-prefix-set)# exit
vsmart(config-policy)# end
vsmart#

What just happened: We entered policy configuration and defined two prefix sets. prefixes-ERP contains the ERP application subnet (10.10.10.0/24); prefixes-WEB is a catch‑all 0.0.0.0/0 to match general Internet traffic. Policy constructs like prefix sets give a reusable, human-readable object to reference in route/data policies.

Real-world note: Using precise prefix sets prevents accidental policy matches that could affect many flows; always favor specific prefixes for critical apps.

Verify:

vsmart# show policy prefix-set
prefix-set: prefixes-ERP
  10.10.10.0/24
prefix-set: prefixes-WEB
  0.0.0.0/0

Step 2: Define TLOC sets for MPLS and Internet transports

What we are doing: Create TLOC sets labeled MPLS-TLOC and INTERNET-TLOC corresponding to the MPLS and broadband transports. Policies will reference these sets to choose preferred or backup paths.

vsmart# configure terminal
vsmart(config)# policy
vsmart(config-policy)# tloc-set MPLS-TLOC
vsmart(config-tloc-set)# color mpls
vsmart(config-tloc-set)# exit
vsmart(config-policy)# tloc-set INTERNET-TLOC
vsmart(config-tloc-set)# color public-internet
vsmart(config-tloc-set)# exit
vsmart(config-policy)# end
vsmart#

What just happened: We defined two TLOC sets by color. The color property groups TLOCs that share a transport type. Policy objects now can target these groups rather than individual transport IPs, making policies portable across sites.

Real-world note: In production, color naming often follows service names from your service provider (e.g., mpls, internet, cellular) — consistent naming simplifies policies.

Verify:

vsmart# show policy tloc-set
tloc-set: MPLS-TLOC
  color: mpls
tloc-set: INTERNET-TLOC
  color: public-internet

Step 3: Create route preference policy for ERP traffic (prefer MPLS, fallback to Internet)

What we are doing: Build a route/data policy that matches ERP prefixes and prefers MPLS TLOC best-effort, falling back to Internet if MPLS is degraded. This enforces path preference and backup selection.

vsmart# configure terminal
vsmart(config)# policy
vsmart(config-policy)# data-policy ERP-Prefer-MPLS
vsmart(config-data-policy)# sequence 10
vsmart(config-seq)# match prefix-set prefixes-ERP
vsmart(config-seq)# set path-preference
vsmart(config-path-pref)# primary tloc-set MPLS-TLOC
vsmart(config-path-pref)# backup tloc-set INTERNET-TLOC
vsmart(config-path-pref)# exit
vsmart(config-seq)# exit
vsmart(config-data-policy)# end
vsmart(config)# end
vsmart#

What just happened: We created a data policy ERP-Prefer-MPLS that, when a packet matches prefixes-ERP, instructs the edge to use MPLS TLOCs as primary; if MPLS health worsens beyond thresholds, the policy permits using INTERNET-TLOC as backup. Under the hood, the data plane uses tunnel and path-monitoring metrics to detect degradation and switch.

Real-world note: Backup must be tested — uncontrolled failover can create asymmetric routing or violate security controls if backup path bypasses inspection.

Verify:

vsmart# show data-policy ERP-Prefer-MPLS
Policy name: ERP-Prefer-MPLS
 Sequence 10:
  Match: prefix-set prefixes-ERP
  Action: set path-preference
   Primary: tloc-set MPLS-TLOC
   Backup: tloc-set INTERNET-TLOC

Step 4: Configure a load-balancing policy for web traffic (active-active)

What we are doing: Define a policy that load-balances web traffic over both MPLS and Internet transports by setting both as active (weighted). This spreads flows and increases aggregate throughput for non-critical traffic.

vsmart# configure terminal
vsmart(config)# policy
vsmart(config-policy)# data-policy WEB-LoadBalance
vsmart(config-data-policy)# sequence 10
vsmart(config-seq)# match prefix-set prefixes-WEB
vsmart(config-seq)# set path-preference
vsmart(config-path-pref)# primary tloc-set MPLS-TLOC weight 50
vsmart(config-path-pref)# primary tloc-set INTERNET-TLOC weight 50
vsmart(config-path-pref)# exit
vsmart(config-seq)# exit
vsmart(config-data-policy)# end
vsmart(config)# end
vsmart#

What just happened: The WEB-LoadBalance data policy matches general web traffic and defines both MPLS and Internet as primary with equal weights — implementing active-active distribution. The edge performs per-flow hashing and uses weights to proportionally distribute new flows.

Real-world note: Use active-active for non-sensitive traffic where session affinity over a single TLOC is not required. Also consider stateful services (firewalls) that may be affected by multiple egress paths.

Verify:

vsmart# show data-policy WEB-LoadBalance
Policy name: WEB-LoadBalance
 Sequence 10:
  Match: prefix-set prefixes-WEB
  Action: set path-preference
   Primary: tloc-set MPLS-TLOC weight 50
   Primary: tloc-set INTERNET-TLOC weight 50

Step 5: Attach policies to site VPNs and deploy

What we are doing: Bind the data policies to the relevant VPNs (site-local data plane). Attaching policies ensures that only the intended traffic on the intended VRF/VPN is influenced by the policy. Then commit/deploy the configuration so edges receive the policy.

vsmart# configure terminal
vsmart(config)# policy
vsmart(config-policy)# attach-policy site cpe-HQ vpn 0 data-policy ERP-Prefer-MPLS in
vsmart(config-policy)# attach-policy site cpe-HQ vpn 0 data-policy WEB-LoadBalance in
vsmart(config-policy)# commit
vsmart(config)# end
vsmart#

What just happened: We attached both policies to VPN 0 (global/data plane) on the HQ site; ordering matters — top-down evaluation will apply ERP policy before the broad WEB policy. commit pushes the policies to controllers and they distribute to edges. At the edge, the data plane applies the policies to live traffic.

Real-world note: Always verify policy scope (site, vpn, direction) before committing — incorrectly scoped policies can match unintended traffic and cause outages.

Verify:

vsmart# show policy attachments
Site: cpe-HQ, VPN: 0, Direction: in
  ERP-Prefer-MPLS (data-policy)
  WEB-LoadBalance (data-policy)

Full deployment status:

vsmart# show controllers status
Controller: vManage (10.0.0.10)  Status: reachable
Controller: vSmart  (10.0.0.11)  Status: reachable
Policies: pushed to 3 edges

Verification Checklist

  • Check 1: ERP traffic takes MPLS path by default. Verify with packet counters or show commands on HQ edge:
    • Command: show tunnel statistics and show policy counters on edge — look for ERP flows traversing MPLS TLOC.
  • Check 2: Web traffic is load-balanced between MPLS and Internet. Verify with show flow/show policy counters and observe session distribution.
  • Check 3: MPLS failure causes ERP failover to Internet. Simulate MPLS degradation (e.g., apply high-loss on MPLS interface) and verify that ERP flows move to Internet TLOC; use show policy events and show tloc to confirm TLOC selection change.

Example verification commands (on an edge device) and expected outputs:

hq-csr# show policy counters
Policy: ERP-Prefer-MPLS
  Matched flows: 12
  Bytes: 2345678
  Active TLOC: 203.0.113.1 (color: mpls)

Policy: WEB-LoadBalance
  Matched flows: 128
  Bytes: 98765432
  TLOC distribution:
    203.0.113.1 (mpls) : 60 flows
    198.51.100.1 (internet) : 68 flows

hq-csr# show tloc
TLOC: 203.0.113.1 color mpls state up metrics latency 12ms loss 0.1%
TLOC: 198.51.100.1 color public-internet state up metrics latency 35ms loss 0.2%

Common Mistakes

SymptomCauseFix
ERP still uses Internet even though policy existsPolicy not attached to correct VPN or directionVerify policy attachment with show policy attachments, reattach to VPN 0 in on appropriate site
Load-balancing uneven or one path unusedWeighting misconfigured or TLOC marked down by health probesCheck TLOC health with show tloc and adjust weights; ensure path-monitor thresholds are appropriate
Failover not occurring during MPLS degradationHealth-probe thresholds too permissive or policy backup not configuredVerify policy includes backup TLOC; tune path-monitor thresholds so path is considered down when SLA violated
Policy applied but no matches for trafficPrefix set too specific / wrong prefix spaceConfirm prefixes with show ip route and use appropriate prefix-set entries; consider ip-prefix vs application match types

Key Takeaways

  • Policies are the SD‑WAN tool to implement traffic engineering: choose the right policy type (control vs data), scope, and order.
  • Use prefix and TLOC sets to build reusable and readable policy constructs; prefer specific prefixes for critical services.
  • Active-active load balancing distributes flows across transports by weight; backup paths provide resilience but require proper health monitoring.
  • Always verify policy attachments and use controller status and TLOC health commands to debug path selection and failover behavior.

Final tip: In production, pair policy changes with staged deployment and monitoring (A/B, canary) so that any unintended traffic steering can be detected quickly and rolled back.


This lesson demonstrated how to build path-preference, load-balancing, and backup behaviors with SD‑WAN policies. Next lesson we will deep-dive into application-aware steering (policy by app-ID) and how that interacts with the policies built here.