PBR and IP SLA: Traffic Steering, Path Monitoring, and Conditional Routing

March 13, 2026·10 min read

Overview

The routing table is the same for every packet. PBR breaks that assumption — it intercepts packets before the routing table lookup and routes them based on source IP, destination IP, DSCP marking, packet length, or protocol. IP SLA adds the intelligence: it continuously probes the next-hops and only steers traffic there if the path is actually up.

PBR vs Routing Table

Scenario	Use PBR	Use Routing Table
Route based on source IP	Yes — routing table only knows destination	No
Send VoIP out ISP-A, data out ISP-B	Yes — DSCP or ACL match per flow type	No
Forward all traffic from a specific VLAN to a firewall	Yes — match source subnet	No — would need static route affecting everyone
Failover when primary next-hop goes down	PBR + verify-availability + IP SLA	Floating static route + track
Route based on destination only	No — overkill	Yes — normal routing is simpler

Topology: PBR for Dual-ISP Traffic Steering

Part 1 — Traffic Classification with Extended ACLs

cisco

! Classify VoIP traffic (RTP UDP + SIP)ip access-list extended ACL-VOIP permit udp 10.0.0.0 0.255.255.255 any range 16384 32767 ! RTP audio streams permit udp 10.0.0.0 0.255.255.255 any eq 5060 ! SIP signaling! Classify DSCP-marked real-time traffic (EF = DSCP 46)ip access-list extended ACL-DSCP-PRIORITY permit ip 10.0.0.0 0.255.255.255 any dscp ef permit ip 10.0.0.0 0.255.255.255 any dscp cs5! Classify specific user subnet (e.g., executive VLAN)ip access-list extended ACL-EXEC-VLAN permit ip 10.10.50.0 0.0.0.255 any

Part 2 — IP SLA Probes

cisco

! Probe ISP-A gateway every 5 secondsip sla 1 icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0 frequency 5 threshold 500 timeout 2000ip sla schedule 1 life forever start-time now! Probe ISP-B gatewayip sla 2 icmp-echo 198.51.100.1 source-interface GigabitEthernet0/1 frequency 5 threshold 500 timeout 2000ip sla schedule 2 life forever start-time now! Track objects — add delay to prevent flappingtrack 1 ip sla 1 reachability delay down 10 up 20track 2 ip sla 2 reachability delay down 10 up 20

Part 3 — PBR Route-Map with verify-availability

cisco

route-map RM-PBR-DUAL-ISP permit 10 description VoIP and real-time traffic -> ISP-A match ip address ACL-VOIP ACL-DSCP-PRIORITY set ip next-hop verify-availability 203.0.113.1 1 track 1 ! "verify-availability 203.0.113.1 1 track 1" ! Sequence 1, use this next-hop only if track 1 is Up set ip next-hop verify-availability 198.51.100.1 2 track 2 ! Fallback to ISP-B if ISP-A track is Downroute-map RM-PBR-DUAL-ISP permit 20 description Executive VLAN -> ISP-B primary match ip address ACL-EXEC-VLAN set ip next-hop verify-availability 198.51.100.1 1 track 2 set ip next-hop verify-availability 203.0.113.1 2 track 1route-map RM-PBR-DUAL-ISP permit 30 description Everything else -> follow routing table ! No set statement = falls through to normal routing table! Apply to LAN-facing interface (where traffic enters the router)interface GigabitEthernet0/2 description TO-LAN ip policy route-map RM-PBR-DUAL-ISP

Warning: PBR applies to incoming packets on the interface. Apply it to the LAN-facing interface, not the WAN interfaces. Applying to WAN interfaces affects return traffic incorrectly.

Part 4 — PBR for Local Traffic (Router-Originated)

By default, ip policy on an interface doesn't affect traffic the router itself generates (BGP updates, SNMP, NTP). Use ip local policy for that.

cisco

! Make the router's own management traffic use ISP-B (out-of-band)ip access-list extended ACL-ROUTER-MGMT permit tcp host 10.0.0.1 any eq 22 ! SSH from router permit udp host 10.0.0.1 any eq 161 ! SNMProute-map RM-LOCAL-PBR permit 10 match ip address ACL-ROUTER-MGMT set ip next-hop 198.51.100.1ip local policy route-map RM-LOCAL-PBR

Part 5 — Verify PBR is Working

cisco

! Show PBR hit counters per route-map clauseR1# show route-map RM-PBR-DUAL-ISP! "Policy routing matches: X packets, Y bytes" per permit statement! If counter is 0, the ACL isn't matching any traffic — check ACL! Debug PBR in real time (use sparingly — can be verbose)R1# debug ip policy! Shows each packet being evaluated, which clause matched, which next-hop set! Show track state (IP SLA result)R1# show track! "Track 1 ... State: Up" = ISP-A reachable, PBR will use it! "Track 1 ... State: Down" = ISP-A unreachable, PBR falls to sequence 2! Show IP SLA statisticsR1# show ip sla statistics 1! "Latest operation return code: OK" = probe succeeding! "Number of successes: NNN, failures: NNN"

R1 — show route-map + show track + show ip sla statistics
R1# show route-map RM-PBR-DUAL-ISP
route-map RM-PBR-DUAL-ISP, permit, sequence 10
  Match clauses:
    ip address (access-lists): ACL-VOIP ACL-DSCP-PRIORITY  <-- RTP UDP 16384-32767 + SIP/5060
  Set clauses:
    ip next-hop verify-availability 203.0.113.1 1 track 1 [up]   <-- ISP-A primary for VoIP
    ip next-hop verify-availability 198.51.100.1 2 track 2 [up]  <-- ISP-B fallback
  Policy routing matches: 5,214 packets, 4,171,200 bytes
route-map RM-PBR-DUAL-ISP, permit, sequence 20
  Match clauses:
    ip address (access-lists): ACL-EXEC-VLAN  <-- 10.10.50.0/24 executive VLAN
  Set clauses:
    ip next-hop verify-availability 198.51.100.1 1 track 2 [up]   <-- ISP-B primary for execs
    ip next-hop verify-availability 203.0.113.1 2 track 1 [up]   <-- ISP-A fallback
  Policy routing matches: 342 packets, 273,600 bytes
route-map RM-PBR-DUAL-ISP, permit, sequence 30
  Match clauses: none (all other traffic — falls through to routing table)
  Policy routing matches: 19,802 packets
R1# show track
Track 1
  IP SLA 1 reachability — icmp-echo 203.0.113.1 source Gi0/0, frequency 5s
  Reachability is Up    1 change, last change 03:14:22
Track 2
  IP SLA 2 reachability — icmp-echo 198.51.100.1 source Gi0/1, frequency 5s
  Reachability is Up    3 changes, last change 00:08:17
VoIP traffic
ISP-A 203.0.113.1
primary — track 1 [up]
ISP-B as automatic failover
Executive VLAN
ISP-B 198.51.100.1
primary — track 2 [up]
ISP-A as automatic failover
seq 30 hits counter
19,802 pkts
routing table (default route)
if 0 — seq 10/20 ACL miss

Real-World Scenario

The situation: A branch office has two ISP links. VoIP calls through ISP-B (secondary) have 30ms jitter and drop every 10 minutes. ISP-A (primary) has 2ms jitter and no drops. The routing table shows all traffic going via ISP-A, but VoIP is still going via ISP-B.

Root cause investigation:

cisco

R1# show route-map RM-PBR-DUAL-ISP! Policy routing matches: 0 packets — PBR not matching anything!R1# show ip policy! Interface GigabitEthernet0/2 (LAN): route-map RM-PBR-DUAL-ISP! Looks correct... check the ACLR1# show ip access-lists ACL-VOIP! "permit udp 10.0.0.0 0.255.255.255 any range 16384 32767 (0 matches)"! Zero matches — the VoIP source IPs are 192.168.10.x not 10.0.0.x! Fix: correct the source subnet in the ACLip access-list extended ACL-VOIP no permit udp 10.0.0.0 0.255.255.255 any range 16384 32767 permit udp 192.168.10.0 0.0.0.255 any range 16384 32767R1# show route-map RM-PBR-DUAL-ISP! Policy routing matches: 847 packets — VoIP now being steered to ISP-A

Troubleshooting

PBR configured but traffic still using routing table

Symptom: show route-map shows 0 matches. Traffic using default route, not PBR next-hop.

Cause: ACL not matching — wrong source IP, interface applied to wrong direction, or ip policy on wrong interface.

Fix:

cisco

! Verify ACL matches with a test packetR1# show ip access-lists ACL-VOIP! Check the "matches" counter after sending some VoIP traffic! Verify policy applied to correct interfaceR1# show ip policy! Must show the LAN-facing interface, not the WAN

verify-availability: PBR sending to down next-hop

Symptom: ISP link is physically up but SLA probe fails. Traffic still being sent to that next-hop.

Cause: IP SLA probe sending from wrong source interface, or probe target is firewalled.

Fix:

cisco

ip sla 1 icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0 ! Source must be the interface that faces ISP-A ! Without source-interface, probe may go out a different path! Test manuallyR1# ping 203.0.113.1 source GigabitEthernet0/0! If this succeeds but SLA fails: check timeout/threshold values

PBR causes asymmetric routing — return traffic takes different path

Symptom: Sessions established via PBR to ISP-A, but replies arrive via ISP-B. TCP sessions drop.

Cause: Routing table for source IP lookup uses default route via ISP-B. Return traffic bypasses PBR (PBR only applies inbound).

Fix:

cisco

! Apply PBR on both LAN-side interfaces! Or use NAT on each ISP interface so return traffic follows the same path! Per-source NAT (overload) on each ISP interface:interface GigabitEthernet0/0 ip nat outsideinterface GigabitEthernet0/1 ip nat outsideinterface GigabitEthernet0/2 ip nat inside! NAT policy: VoIP (PBR to ISP-A Gi0/0) uses ISP-A public IPip nat inside source route-map NAT-ISP-A interface GigabitEthernet0/0 overloadroute-map NAT-ISP-A permit 10 match ip address ACL-VOIP match interface GigabitEthernet0/0

PBR + IP SLA Deployment Checklist

verify-availability used on every PBR set ip next-hop — without it, PBR forwards to a dead next-hop
IP SLA source interface explicitly set — probe must use the actual WAN interface, not a management path
delay down 10 up 20 on track objects — prevents flapping on momentary packet loss
Route-map permit 30 with no match/set — catch-all to fall through to routing table for unmatched traffic
ip policy applied to LAN-facing interface (inbound direction) — NOT the WAN interface
ip local policy for router-originated traffic if it also needs steering (NTP, BGP updates, SNMP)
PBR counters checked after deployment: show route-map — every clause matching traffic should have non-zero counters
Return traffic symmetry verified — if using multiple ISPs, ensure NAT pins return packets to the correct ISP
Packet capture at ISP interfaces to verify VoIP actually using correct ISP before sign-off