Back
Lesson 4 of 7

Application-Aware Routing

Objective

In this lesson you will configure SLA classes (using IP SLA and object tracking) and an application-aware routing policy (using policy-based routing + SLA-tracked routes) to steer latency/jitter-sensitive traffic over the best WAN path. This matters because real-world SD-WAN controllers use similar SLA-based decisions to keep voice/video on low-latency links — here you will implement the equivalent on IOS routers so you understand the underlying mechanisms. Scenario: a branch router has two WAN links to HQ; you will measure latency, jitter and packet loss to HQ on the primary link and make RTP (voice) traffic prefer that link while failing over to the secondary when SLA thresholds are violated.

Quick Recap

We use the topology introduced in Lesson 1. No new physical devices are added in this lesson — we reuse the same Branch (BR1) and HQ routers and their WAN links. The branch will run IP SLA operations toward the HQ LAN IPs to determine link quality, create tracked SLA classes, and apply an app-aware policy that steers voice RTP across the preferred link.

Device table

DeviceHostnameRelevant Interfaces
Branch RouterBR1Gi0/0 (LAN 10.1.1.1/24), Gi0/1 (WAN-A 10.0.12.2/30), Gi0/2 (WAN-B 10.0.13.2/30)
HQ RouterHQGi0/1 (WAN-A 10.0.12.1/30), Gi0/2 (WAN-B 10.0.13.1/30)

ASCII topology (showing exact IPs on every interface)

[ Branch BR1 ]
Gi0/0 10.1.1.1/24 (LAN)
Gi0/1 10.0.12.2/30 -------------- Gi0/1 10.0.12.1/30 ------------- Gi0/1 [HQ]
Gi0/2 10.0.13.2/30 -------------- Gi0/2 10.0.13.1/30 ------------- Gi0/2 [HQ]

Domain names and passwords used in examples:

  • Domain: lab.nhprep.com
  • Passwords: Lab@123
  • Organization: NHPREP

Key Concepts

  • IP SLA (Active Measurements) — IP SLA generates probes (ICMP echo, UDP jitter, TCP connect) and measures RTT, jitter and packet loss. In production, controllers use these probes to quantify WAN-link quality so that policies can prefer the lowest-latency/jitter path for real-time apps.
    • Protocol behavior: IP SLA sends probe packets at the configured frequency. For ICMP echo the device measures round-trip time (RTT). For udp-jitter it measures one-way jitter and packet loss when both endpoints cooperate.
  • Object Tracking — IP SLA operations are associated with tracking objects (track N) so IOS can treat an SLA result as a boolean (up/down). Tracks can be combined with boolean logic (AND/OR) to build SLA classes.
    • Practical application: Combine latency and jitter tracks so the class is "good" only when both latency and jitter are within thresholds.
  • Application match (ACL) + PBR — Policy-Based Routing (PBR) lets you match flows (by ACL) and set a next-hop. Use PBR to steer RTP/voice traffic (UDP ports 16384–32767) onto the prioritized WAN link.
    • Real-world note: PBR is used at the edge to implement immediate forwarding decisions for specific applications while routing control plane remains unchanged.
  • Route/Static Failover based on Track — Use tracked static routes (ip route ... track ) to provide path-level failover for general traffic and as a fallback for PBR where needed. Combining PBR with tracked static routes provides application-aware steering + resilience.
  • Why jitter/loss thresholds matter — For voice/video, a small increase in jitter or packet loss has outsized user impact. A policy that only measures reachability will not protect voice from high jitter; measuring jitter and packet loss provides the necessary signal to move media flows.

Step-by-step configuration

Step 1: Configure IP SLA operations for latency and jitter

What we are doing: Create two IP SLA operations from BR1 to HQ: an ICMP echo (to measure RTT/latency) and a UDP-jitter operation (to measure jitter and packet loss for RTP-like traffic). Then schedule both operations to run continuously. These measurements are the raw telemetry used to decide whether the primary link meets our thresholds.

BR1# configure terminal
BR1(config)# ip sla 101
BR1(config-ip-sla)# icmp-echo 10.0.12.1 source-interface GigabitEthernet0/1
BR1(config-ip-sla-echo)# timeout 500
BR1(config-ip-sla-echo)# frequency 5
BR1(config-ip-sla)# exit
BR1(config)# ip sla schedule 101 life forever start-time now

BR1(config)# ip sla 102
BR1(config-ip-sla)# udp-jitter 10.0.12.1 5000 source-ip 10.0.12.2
BR1(config-ip-sla-jitter)# frequency 5
BR1(config-ip-sla-jitter)# exit
BR1(config)# ip sla schedule 102 life forever start-time now
BR1(config)# end

What just happened:

  • ip sla 101 created an ICMP echo operation to HQ (10.0.12.1) sourced from the link A interface. timeout controls how long to wait for a reply; frequency 5 causes a probe every 5 seconds. The schedule activates the operation immediately.
  • ip sla 102 created a UDP-jitter operation which sends UDP probes to destination port 5000; UDP-jitter measures jitter and packet loss relevant to RTP-style traffic. Running both operations supplies RTT and jitter/loss metrics that we will turn into tracked boolean states.

Real-world note: UDP-jitter requires the far-end to respond appropriately for accurate one-way jitter; in many labs a router will respond to UDP-jitter probes and produce jitter/loss metrics. In production SD-WAN controllers coordinate paired agents for accurate one-way metrics.

Verify:

BR1# show ip sla configuration
IP SLAs configuration:
  IP SLAs operation id: 101
    Type: icmp-echo
    Target address: 10.0.12.1
    Source interface: GigabitEthernet0/1
    Timeout: 500 ms
    Frequency: 5 seconds
    Latest RTT: 18 ms
    Status: OK

  IP SLAs operation id: 102
    Type: udp-jitter
    Target address: 10.0.12.1
    Destination port: 5000
    Source address: 10.0.12.2
    Frequency: 5 seconds
    Latest Jitter (avg): 3 ms
    Latest Loss: 0 packets
    Status: OK

Step 2: Create tracked objects and SLA class logic

What we are doing: Create track objects that map to the IP SLA operations, and then combine them in a boolean track that represents the SLA class (both latency and jitter must be acceptable). This boolean allows routing constructs to use a single tracked object to represent "link quality is good".

BR1# configure terminal
BR1(config)# track 1 ip sla 101 reachability
BR1(config-track)# exit
BR1(config)# track 2 ip sla 102 reachability
BR1(config-track)# exit
BR1(config)# track 10 list boolean and 1 2
BR1(config-track)# end

What just happened:

  • track 1 ip sla 101 reachability binds track 1 to SLA 101; it will be "up" when the ICMP SLA shows the destination reachable and within configured behavior.
  • track 2 similarly binds to UDP-jitter SLA 102.
  • track 10 list boolean and 1 2 creates a Boolean track that is up only when both track 1 AND track 2 are up — this is our SLA class for "latency AND jitter acceptable".

Real-world note: Boolean combination of tracks is how you create rich SLA classes (e.g., latency < X AND jitter < Y AND loss < Z). Controllers perform the same logical combination when evaluating paths.

Verify:

BR1# show track
Track 1
  Type: IP SLA
  Track state: Enabled, Up
  Object: 101
  Reachability via IP SLA operation id 101

Track 2
  Type: IP SLA
  Track state: Enabled, Up
  Object: 102
  Reachability via IP SLA operation id 102

Track 10
  Type: Boolean
  Track state: Enabled, Up
  Operator: AND
  Members: 1 2

Step 3: Define an application ACL for RTP (voice) traffic

What we are doing: Create an extended ACL named VOICE-ACL that matches typical RTP UDP port ranges (16384–32767). This ACL will be used in policy-based routing so voice traffic can be matched and steered.

BR1# configure terminal
BR1(config)# ip access-list extended VOICE-ACL
BR1(config-ext-nacl)# permit udp any any range 16384 32767
BR1(config-ext-nacl)# permit udp any any eq 5060
BR1(config-ext-nacl)# exit
BR1(config)# end

What just happened:

  • The ACL matches UDP flows commonly used for RTP (large dynamic port range) and SIP (5060). Matching these flows is central to application-aware routing: once matched, we will instruct forwarding to prefer the SLA-class-preferred link.

Real-world note: Port-based matching is an approximation for real application identification. SD-WAN controllers use deep packet inspection and application-level identification for more accurate classification.

Verify:

BR1# show access-lists VOICE-ACL
Extended IP access list VOICE-ACL
    10 permit udp any any range 16384 32767
    20 permit udp any any eq 5060

Step 4: Configure Policy-Based Routing (PBR) to prefer the primary link for voice

What we are doing: Create a route-map that matches VOICE-ACL and sets the next-hop to the HQ address reachable over link A (10.0.12.1). Then apply the PBR inbound on the LAN interface so outgoing branch-originated voice flows are redirected to the preferred WAN link.

BR1# configure terminal
BR1(config)# route-map APP-VOICE permit 10
BR1(config-route-map)# match ip address VOICE-ACL
BR1(config-route-map)# set ip next-hop 10.0.12.1
BR1(config-route-map)# exit
BR1(config)# interface GigabitEthernet0/0
BR1(config-if)# ip policy route-map APP-VOICE
BR1(config-if)# exit
BR1(config)# end

What just happened:

  • The route-map matches voice traffic and sets the next hop to 10.0.12.1 (HQ via WAN-A). By applying the PBR on the LAN-facing interface (Gi0/0), we ensure branch-originating voice packets are forwarded out WAN-A when possible.
  • Note: This PBR does not itself perform SLA checks — it always points voice to 10.0.12.1. SLA-based failover for voice is provided by the tracked static routes and/or by additional verify-availability constructs in IOS (see Real-world note).

Real-world note: Commercial SD-WAN products bind application policies to SLA classes and perform seamless, per-flow path selection including graceful migration. On IOS with PBR, additional mechanisms (like dynamic next-hop verification or tracked next-hop prefixes) are used to achieve resilience.

Verify:

BR1# show route-map APP-VOICE
route-map APP-VOICE, permit, sequence 10
 Match clauses: 
  ip address: VOICE-ACL
 Set clauses:
  ip next-hop: 10.0.12.1

BR1# show ip policy
Interface GigabitEthernet0/0
  Route map name: APP-VOICE
  Stats: PBR not bound to route map on this interface: 0 packets matched

Step 5: Configure tracked static default routes for failover and integrate with SLA class

What we are doing: Create a primary default route via WAN-A that is only installed when the SLA class (track 10) is up, and a backup default via WAN-B with higher administrative distance. That way, if SLA class 10 fails (latency/jitter/loss exceeded), general traffic and PBR-steered traffic will fail over to WAN-B.

BR1# configure terminal
BR1(config)# ip route 0.0.0.0 0.0.0.0 10.0.12.1 track 10
BR1(config)# ip route 0.0.0.0 0.0.0.0 10.0.13.1 250
BR1(config)# end

What just happened:

  • The first default route uses the tracked object 10 (our SLA class). It is present in the routing table only when both latency and jitter tracks are up. The second default route is a floating static (administrative distance 250) that becomes the active default when the primary is removed.
  • Combined with the PBR, voice flows will be forwarded to 10.0.12.1 while the tracked route is present. If SLA class 10 goes down, the tracked static will be withdrawn and the backup will be used.

Real-world note: In production, controllers often perform per-flow path changes for in-flight media — IOS static route failover is coarser-grained (affects new flows immediately).

Verify:

BR1# show ip route static
S* 0.0.0.0/0 [1/0] via 10.0.12.1, GigabitEthernet0/1, track 10
S   0.0.0.0/0 [250/0] via 10.0.13.1, GigabitEthernet0/2

Also verify track state influences routing:

BR1# show ip route 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.12.1, GigabitEthernet0/1, track 10

If SLA deteriorates (simulated by shutting Gi0/1), show track will show Track 10 DOWN and the static default via 10.0.12.1 will be removed from the routing table — traffic will use the floating route via 10.0.13.1.

Verification Checklist

  • Check 1: IP SLA operations are running and reporting values — verify with show ip sla configuration and confirm Latest RTT / Jitter / Loss values.
    • Command: show ip sla configuration
  • Check 2: The boolean SLA class (track 10) is UP when both latency and jitter meet thresholds — verify with show track.
    • Command: show track
  • Check 3: Voice flows from the LAN are steered to 10.0.12.1 when SLA is OK and fail over to 10.0.13.1 when SLA degrades — verify with show ip route, show route-map, show ip policy, and live traffic tests (e.g., generate RTP-like UDP streams and observe next-hop).
    • Commands: show ip route, show ip policy, show route-map APP-VOICE

Common Mistakes

SymptomCauseFix
IP SLA shows “Not Running” or “No Response”IP SLA target address unreachable or source-interface mismatchedConfirm reachability (ping), set correct source-interface in IP SLA, ensure HQ replies to probes
Track remains DOWN though route to HQ existsUsing reachability alone while thresholds for latency/jitter are exceededVerify IP SLA results (RTT/jitter/loss). Adjust IP SLA timeout/frequency or the boolean logic if thresholds are too strict
Voice still uses bad link after SLA failoverPBR points at primary next-hop and PBR does not verify next-hop availabilityUse tracked static route as fallback (as in this lesson), or implement verify-availability if supported on platform
UDP-jitter shows zero packets or invalid metricsThe far-end doesn’t respond to UDP-jitter probes or source/destination ports mismatchedEnsure the destination will respond to UDP-jitter probes (some routers do) and source/dest port settings are correct

Key Takeaways

  • IP SLA + object tracking are the building blocks for SLA classes; combine multiple SLA operations with boolean tracking to represent complex quality requirements (latency AND jitter AND loss).
  • Application-aware routing in IOS is achieved by classifying flows (ACL), steering them with PBR, and ensuring resilience via SLA-tracked static routes; SD-WAN controllers implement this logic centrally but the underlying principles are the same.
  • Jitter and packet loss are as important as latency for real-time media; measuring only reachability will not protect voice quality.
  • In production, use centralized controllers (or platform features) for per-flow, in-flight path migration; when implementing on IOS, be aware that PBR + static route failover is effective for new flows but has limitations for in-progress media.

Tip: When moving to controller-based SD-WAN, map each SLA class you test here to the controller’s SLA profile so that you understand how thresholds translate into path selection decisions in production.

Practice with Hands-On Labs

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