Cisco PBR: Policy-Based Routing with verify-availability

Policy-Based Routing (PBR) on Cisco IOS lets you override the destination-based forwarding decision for selected traffic: a route-map matches packets and sets a next hop, an interface, or an IP precedence value. It is the tool of choice for source-based routing, directing specific subnets over a secondary ISP, or steering traffic into a tunnel. The feature is easy to configure and equally easy to break, because the most common failure mode — a dead next hop that the router still treats as reachable — is exactly what set ip next-hop verify-availability was designed to prevent.

How PBR changes the lookup

Without PBR, a router does a route table lookup on the destination address. With PBR applied to an interface, the router first evaluates the route-map attached as ip policy route-map. If a route-map permit entry matches and sets a next hop, that next hop wins regardless of what the routing table says. If no entry matches, normal routing resumes — which is why the trailing permit 10 with no match conditions is the standard pattern for "PBR for this list, normal routing for everything else".

Step 1 — match the traffic

ip access-list standard FROM-LAN-SUBNET
 permit 10.10.20.0 0.0.0.255

ip access-list extended VOICE-RTP
 permit udp 10.10.20.0 0.0.0.255 any range 16384 32767

Standard ACLs match source address only and are ideal for source-based routing. Extended ACLs give you protocol and port granularity when only part of a subnet should be steered.

Step 2 — build the route-map

route-map PBR-ISP2 permit 10
 match ip address FROM-LAN-SUBNET
 set ip next-hop verify-availability 203.0.113.2 1 track 10
 set ip next-hop verify-availability 203.0.113.6 2 track 20

route-map PBR-ISP2 permit 20
 match ip address VOICE-RTP
 set ip next-hop verify-availability 203.0.113.2 1 track 10

Two details make this robust. First, the numeric field after the next-hop address is the sequence number, and the tracked next hops are evaluated in ascending order — so the primary is tried before the backup. Second, track binds each next hop to a tracking object created by IP SLA, which is what turns "the router believes the next hop exists" into "the next hop answered a probe recently".

Step 3 — make reachability real with IP SLA

ip sla 1
 icmp-echo 203.0.113.2 source-interface GigabitEthernet0/1
 frequency 5
ip sla schedule 1 life forever start-time now

ip sla 2
 icmp-echo 203.0.113.6 source-interface GigabitEthernet0/1
 frequency 5
ip sla schedule 2 life forever start-time now

track 10 ip sla 1 reachability
 delay down 10 up 10
track 20 ip sla 2 reachability
 delay down 10 up 10

Without verify-availability, IOS treats a next hop as usable if the interface toward it is up — even when the provider is dropping everything beyond the first hop. The two-ISP branch is where this bites hardest.

Step 4 — apply PBR to the interface

interface GigabitEthernet0/0
 ip policy route-map PBR-ISP2

Local traffic generated by the router itself does not traverse interface PBR. Use ip local policy route-map for router-originated traffic such as management sessions or syslog.

Verification

show route-map PBR-ISP2
show ip policy
show track
show ip sla statistics
show ip nat translations
show access-lists FROM-LAN-SUBNET

show route-map prints a policy-routing match counter per entry, which is the fastest way to prove the route-map is being consulted. A zero counter next to a populated ACL almost always means the policy is attached to the wrong interface or the traffic is arriving on a different one.

Design notes

• Keep PBR ACLs tight. A route-map that matches too much silently becomes a second, undocumented routing table.
• Prefer set ip next-hop verify-availability with tracking over bare set ip next-hop; the failure mode of the bare form is a black hole, not a fallback.
• When PBR points at a tunnel, ensure the tunnel is up before the probe fires, or tracking will keep the next hop down and PBR never activates.
• Document the ACL and route-map pair together. Six months later nobody remembers why a subnet is pinned to ISP2.

If the failover scenario involves a tunnel rather than a plain next hop, combine this with Cisco GRE tunnel configuration; for automated detection of the kind used above, the tracking details are covered in Cisco IP SLA object tracking and failover.

原文链接：https://www.cisco.com/c/en/us/td/docs/routers/ios-xe/ip-routing/b-ip-routing/m_iri-pbr-next-hop-verify-availability-for-vrf.html