Hands-On Lab: Configuring SD-WAN Centralized Data Policy for Application-Aware Routing

Lab Objective

Define an SLA class specifying acceptable loss, latency, and jitter thresholds, configure a centralized data policy matching voice traffic and applying that SLA class with a preferred transport color, and verify voice traffic is steered onto the compliant path while other traffic uses the default path.

Lab Purpose

Policy-Based Routing, covered earlier in this series, required configuring a route-map on each individual router to steer specific traffic. SD-WAN's centralized data policy achieves a conceptually similar outcome — steering traffic based on criteria beyond simple destination-based routing — but is authored once at the controller and pushed to every relevant edge device automatically.

Lab Topology

Edge1 (Site 100) has two transports:
  biz-internet color (higher latency)
  mpls color (lower latency, preferred
              for voice)

Edge2 (Site 200) reachable via both colors

Goal: voice traffic (UDP 16384-32767) should
prefer the mpls transport when it meets SLA

Task 1: Define an SLA Class

Create an SLA class specifying maximum acceptable loss, latency, and jitter for voice-quality traffic.

Task 2: Create a Centralized Data Policy Matching Voice Traffic

Define a data policy matching the UDP port range typically used for RTP voice traffic.

Task 3: Apply the SLA Class with a Preferred Color

Configure the policy action to apply the SLA class, preferring the mpls color when SLA is met.

Task 4: Apply the Policy to the Relevant Site

Apply the centralized policy to Site 100's edge devices.

Task 5: Verify Voice Traffic Follows the Preferred Path

Generate voice-pattern traffic and confirm it uses the mpls transport, while other traffic continues using the default path selection.

Solution and Verification

-- Centralized policy configuration
-- (conceptually entered at the controller,
--  shown here in policy CLI form):

policy
 sla-class VOICE-SLA
  loss 1
  latency 150
  jitter 30

 data-policy VOICE-STEERING
  vpn-list VPN-1
   sequence 10
    match
     source-data-prefix-list ANY
     dscp 46
    action accept
     set-service sla-class VOICE-SLA preferred-color mpls

policy
 apply-policy site-list SITE-100
  data-policy VOICE-STEERING from-service

Edge1# show sdwan policy from-vsmart

...
data-policy VOICE-STEERING
  vpn-list VPN-1
    sequence 10
      match: dscp 46
      action: accept, sla-class VOICE-SLA,
              preferred-color mpls
-- Confirms the centrally authored policy
-- has been pushed down and is active on
-- this edge, without any local CLI policy
-- configuration having been typed on Edge1
-- itself

IPPhone1> [places a call, generating RTP
           traffic marked DSCP EF/46]

Edge1# show sdwan app-route stats

TLOC-COLOR   LOSS   LATENCY   JITTER   SLA-CLASS
mpls          0       28ms      3ms    VOICE-SLA (met)
biz-internet  0       95ms     18ms    VOICE-SLA (met)
-- Both paths currently meet the SLA, but
-- mpls is the configured preferred-color,
-- so voice traffic is steered there
-- specifically

Edge1# show sdwan policy app-route-stats | include mpls

...voice flow matched, using tloc mpls...
-- Confirms voice-marked traffic is
-- following the mpls path as intended

OtherApp-PC> [generates non-voice traffic]

Edge1# show ... (non-voice flow)
...default path selection applied, not
subject to VOICE-STEERING policy...
-- Non-matching traffic continues using
-- ordinary path selection, unaffected by
-- the voice-specific policy

Key Takeaway

SD-WAN's centralized data policy is authored once and automatically distributed to every applicable edge, in contrast to the earlier PBR lab where the identical route-map logic would need to be manually replicated on every router requiring the same steering behavior — this centralization is precisely what makes consistent application-aware routing practical across dozens or hundreds of sites, since a single policy change at the controller propagates everywhere it applies without touching individual device configurations.