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 statisticsandshow policy counterson edge — look for ERP flows traversing MPLS TLOC.
- Command:
- Check 2: Web traffic is load-balanced between MPLS and Internet. Verify with
show flow/show policy countersand 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 eventsandshow tlocto 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
| Symptom | Cause | Fix |
|---|---|---|
| ERP still uses Internet even though policy exists | Policy not attached to correct VPN or direction | Verify policy attachment with show policy attachments, reattach to VPN 0 in on appropriate site |
| Load-balancing uneven or one path unused | Weighting misconfigured or TLOC marked down by health probes | Check TLOC health with show tloc and adjust weights; ensure path-monitor thresholds are appropriate |
| Failover not occurring during MPLS degradation | Health-probe thresholds too permissive or policy backup not configured | Verify policy includes backup TLOC; tune path-monitor thresholds so path is considered down when SLA violated |
| Policy applied but no matches for traffic | Prefix set too specific / wrong prefix space | Confirm 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.