NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

Configure Centralized Data Policies in a Cisco SD‑WAN fabric to perform traffic steering based on match conditions (application, source VPN, prefix) and actions (preferred path selection). You will build a policy that steers SaaS traffic from a remote site to the best Internet DIA exit or to the regional gateway when the local DIA fails SLA. In production networks this enables predictable SaaS performance, automated failover, and simplified operational control from a central controller.

Topology (quick ASCII diagram)

This lesson references the same topology used in Lesson 1. No new physical devices are added — we configure a centralized policy applied to the existing WAN‑edge routers and the regional gateway.

Note: Every interface lists the exact IP used in this lesson.

                          +-----------------------+
                          | Regional Gateway (RG) |
                          | Router name: RG-DC    |
                          | Gi0/0: 198.51.100.1/30|
                          +----------+------------+
                                     |
                                     | 198.51.100.0/30
                                     |
                 +-------------------+-------------------+
                 |                                       |
        +--------+--------+                      +--------+--------+
        | WAN Edge: B1    |                      | Internet: ISP1  |
        | Router name: B1 |                      | Router name: ISP1-RTR |
        | Gi0/0: 203.0.113.2/30 (to ISP2)        | Gi0/0: 203.0.113.1/30|
        | Gi0/1: 10.10.10.1/24 (LAN)             +-------------------+
        | Mgmt/VPN512: 192.0.2.10/24 |
        +-----------------+---------------------+
                          |
                          | Local DIA to ISP2
                          |
                   +------v------+
                   | Internet: ISP2 |
                   | Router name: ISP2-RTR |
                   | Gi0/0: 203.0.113.5/30 |
                   +-------------------+

LAN at branch B1: 10.10.10.0/24
Management address (VPN512) on B1: 192.0.2.10/24
Transport links use documentation/test IP space: 198.51.100.0/30 and 203.0.113.0/30

Device Table

Device	Hostname	Relevant Interfaces / IPs
Branch WAN Edge	B1	Gi0/0: 203.0.113.2/30 (to ISP2), Gi0/1: 10.10.10.1/24 (LAN), Mgmt (VPN512): 192.0.2.10/24
Regional Gateway	RG-DC	Gi0/0: 198.51.100.1/30 (to fabric)
Internet Provider 1	ISP1-RTR	Gi0/0: 203.0.113.1/30
Internet Provider 2	ISP2-RTR	Gi0/0: 203.0.113.5/30

Tip: We use reserved documentation ranges (203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24) so this lab is safe to run in a lab environment.

Quick Recap

The SD‑WAN fabric is already established from earlier lessons: OMP advertises routes and VPNs partition traffic (VPN0 transport, VPN512 management, VPNn service).
Remote site B1 has two Internet exits; the goal is to steer HTTP/HTTPS (SaaS) traffic either to the local DIA (preferred when vQoE is good) or to the Regional Gateway if the local DIA does not meet SLA.

Key Concepts (theory + practical implications)

Centralized Data Policy: A policy created centrally (on vManage/vSmart) that matches traffic conditions and instructs WAN‑edge routers how to forward flows. Think of it as a traffic ruleset distributed to edge routers so they act consistently.
Match vs Action: Match clauses identify traffic (application name, source VPN, prefix); actions specify what to do (set path, drop, prefer certain tunnel). This separation allows clear, re-usable policies.
vQoE and App‑Aware Routing: The fabric performs active probing (HTTP ping) to compute vQoE scores for SaaS across available Internet exits. Policies reference SLA classes (latency, loss, jitter) and the router uses vQoE to decide which path meets the SLA.
VPN isolation: SD‑WAN uses VPNs like VRFs — VPN0 for transport, VPN512 for management, and VPNn for service. Policies can be scoped per‑VPN so only the intended traffic is affected.
Control Plane distribution: Policies are distributed by controllers (vManage/vSmart). Once pushed, each WAN edge enforces match/actions locally — this scales better than per‑device manual config in production.

Real-world analogy: Think of a centralized data policy as a city traffic ordinance — the law (policy) is published centrally, and every local traffic officer (WAN edge) enforces the same rules for their neighborhood.

Step-by-step configuration

Step 1: Define the SLA class used by the policy

What we are doing: Create an SLA definition that represents the performance required by SaaS (e.g., Latency < 150ms and Loss < 2%). This SLA will be referenced by the centralized data policy to choose only paths that meet the application QoE requirements.

configure terminal
sdwan
  sla-class SaaS-SLA
    sla-type probe-http
    latency 150
    loss 2
exit
exit
write memory

What just happened:

sdwan sla-class SaaS-SLA creates an SLA profile named "SaaS-SLA".
sla-type probe-http selects HTTP probing (the fabric uses HTTP ping to simulate client connections and measure vQoE).
latency and loss set thresholds; the fabric will consider a path meeting the SLA only if probes show latency < 150ms and loss < 2%.

Real-world note: SLA classes let you translate business requirements (e.g., "Salesforce must be snappy") into network decision criteria.

Verify:

show sdwan sla-class SaaS-SLA

Expected output:

SLA Class: SaaS-SLA
  Type: probe-http
  Thresholds:
    Latency (ms): 150
    Loss (%): 2
  Status: Active

Step 2: Create a centralized data policy that matches SaaS traffic

What we are doing: Build a data policy that matches HTTP/HTTPS application traffic from the service VPN (assume VPN10 for LAN) and instructs routers to prefer the local DIA if it meets the SLA, otherwise steer to the Regional Gateway.

configure terminal
sdwan
  policy data-policy Centralized-SaaS-Steer
    sequence 10
      match
        source vpn 10
        application http https
      action
        set path preference local-dialer preferred
        set sla SaaS-SLA
        set failover next-hop 198.51.100.1
    sequence 20
      match
        source vpn 10
        application any
      action
        set path preference default
exit
exit
write memory

What just happened:

policy data-policy Centralized-SaaS-Steer creates a centralized data policy.
Sequence 10 matches traffic from VPN10 identified as HTTP/HTTPS and attaches the SLA "SaaS-SLA".
set path preference local-dialer preferred tells the edge to prefer the local DIA exit if probes show it meets the SLA.
set failover next-hop 198.51.100.1 provides the Regional Gateway (RG‑DC) as the next-hop failover when the SLA is not met.
Sequence 20 is a catch-all to preserve default behavior for non-matching traffic.

Real-world note: Putting the regional gateway as next-hop ensures consistent security or inspection for SaaS traffic when local Internet is poor.

Verify:

show sdwan policy data-policy Centralized-SaaS-Steer

Expected output:

Data Policy: Centralized-SaaS-Steer
  Sequence 10:
    Match: source vpn 10, application http, https
    Action:
      set path preference local-dialer preferred
      set sla SaaS-SLA
      set failover next-hop 198.51.100.1
  Sequence 20:
    Match: source vpn 10, application any
    Action:
      set path preference default
Status: Distributed to devices

Step 3: Attach the data policy to the device template or site‑list (central application)

What we are doing: Bind the centralized data policy to the site(s) (e.g., B1) so the WAN edge enforces it. This is performed centrally so multiple sites can reuse the same policy.

configure terminal
sdwan
  policy attach data Centralized-SaaS-Steer
    sites add site-list Branches
exit
exit
write memory

What just happened:

policy attach data instructs the controller to push the named data policy to the devices in the "Branches" site-list (which includes B1).
The SD‑WAN controller converts the policy to device‑local instructions and distributes it via the control plane (OMP). Each WAN edge receives the policy and enforces it locally.

Real-world note: Attaching centrally avoids per-device mistakes and ensures consistent behavior across many branches.

Verify:

show sdwan policy attached

Expected output:

Attached Data Policies:
  Centralized-SaaS-Steer
    Applied to site-list: Branches
    Devices:
      B1 - Applied - Last pushed: 00:05:23
Status: All devices present and policy active

Step 4: Observe vQoE probing and live path selection on the edge

What we are doing: Confirm that B1 is performing HTTP probes, that vQoE scores are computed, and that paths are chosen according to the SLA and policy.

show sdwan appqoe probe status

Expected output:

AppQoE Probe Status - Device: B1
  Active Probes:
    Probe ID: 1001
      Application: http
      Destinations being probed:
        Local DIA (ISP2): 203.0.113.5 - vQoE: 92 (Latency: 30ms Loss: 0.1%)
        Regional Gateway (RG-DC): 198.51.100.1 - vQoE: 75 (Latency: 160ms Loss: 1.5%)
      Last probe time: 00:00:10 ago
  SLA Compliance (SaaS-SLA):
    Local DIA: Meets SLA
    Regional Gateway: Fails SLA (latency > 150ms)

What just happened:

The show sdwan appqoe probe status command displays probe activity and computed vQoE.
The local DIA (ISP2) shows a vQoE that meets the SaaS-SLA; RG‑DC fails the latency threshold, so the edge will prefer the local DIA.

Real-world note: Initial flows may be suboptimal until the DPI cache populates — AppQoE probes help the router converge quickly to the correct exit.

Verify forwarding decision for a sample flow:

show sdwan flow table

Expected output:

Flow Table - Device: B1
  Flow: src 10.10.10.50:50432 -> dst 8.8.8.8:80 (application http)
    Matched Policy: Centralized-SaaS-Steer (seq 10)
    Selected Path: Local DIA via ISP2 (203.0.113.5)
    Path vQoE: 92 (meets SaaS-SLA)
    Failover: 198.51.100.1 if local-dialer degrades

Step 5: Simulate local DIA degradation and validate failover to Regional Gateway

What we are doing: Force the local DIA to fail the SLA (for example by introducing delay/loss in the lab) and confirm that B1 steers traffic to RG‑DC per the policy.

! Simulate degradation (lab command — e.g., apply interface delay or ACL). Example:
configure terminal
interface GigabitEthernet0/0
  description TO_ISP2
  ip access-group DROP-PROBES in
exit
ip access-list extended DROP-PROBES
  deny icmp any any
  deny tcp any any eq 80
  permit ip any any
exit
write memory

What just happened:

We simulated a degradation by denying probe traffic on the local DIA, causing probes to indicate high loss or failure. The edge will mark the local path as failing the SLA and will select the configured failover (RG‑DC).

Warning: In production, introduce degradation only in maintenance windows; use synthetic labs for testing.

Verify failover behavior:

show sdwan appqoe probe status

Expected output:

AppQoE Probe Status - Device: B1
  Active Probes:
    Local DIA (ISP2): vQoE: 20 (Latency: 300ms Loss: 5%) - Fails SaaS-SLA
    Regional Gateway (RG-DC): vQoE: 80 (Latency: 120ms Loss: 0.5%) - Meets SaaS-SLA

show sdwan flow table

Expected output:

Flow Table - Device: B1
  Flow: src 10.10.10.50:50432 -> dst 8.8.8.8:80 (application http)
    Matched Policy: Centralized-SaaS-Steer (seq 10)
    Selected Path: Regional Gateway via 198.51.100.1 (failover)
    Path vQoE: 80 (meets SaaS-SLA)

Verification Checklist

Check 1: SLA class exists — verify with show sdwan sla-class SaaS-SLA (expected: shows probe-http, latency 150, loss 2).
Check 2: Data policy is present and distributed — verify with show sdwan policy data-policy Centralized-SaaS-Steer (expected: sequences and actions visible; "Distributed to devices").
Check 3: Edge is probing and selecting correct path — verify with show sdwan appqoe probe status and show sdwan flow table (expected: vQoE values and active path selection per SLA).

Common Mistakes

Symptom	Cause	Fix
Policy shows "Not Applied" on device	Policy not attached to the correct site-list or device	Re-run `policy attach data` and verify site-list contains the target device
Probes show "No response" for all destinations	Probe traffic blocked by ISP or ACL on edge	Ensure HTTP probe traffic allowed out of the interface; remove restrictive ACLs
Traffic still uses default path despite policy	Match criteria do not match real traffic (wrong VPN, app name mismatch)	Verify source VPN and application-id; use `show sdwan flow table` to confirm matches
Failover not occurring when local DIA degrades	Failover next-hop unreachable or SLA not applied to sequence	Verify failover next-hop IP (198.51.100.1) is reachable and SLA is referenced in action

Key Takeaways

Centralized data policies let you define consistent traffic steering rules from one place; the controller distributes them so each WAN edge enforces locally.
Use SLA classes (vQoE via HTTP probes) to make policies application‑aware and avoid steering traffic to poor quality paths.
Always scope policies by VPN and application to avoid unintended disruption; verify matches with flow table and probe status commands.
In production, attach policies to site‑lists or device groups, and test failover behavior in a lab before wide deployment.

Final real-world note: Centralized policies reduce operational overhead and enable rapid, consistent traffic steering across hundreds of branches — this is why enterprises adopt SD‑WAN for SaaS optimization and resilient access.