So while studying for CCNP Route, I came across the concept of IP SLA and utilizing probes to check availability of next-hop addresses prior to instating them inside a route-map. An objective was to have two ISP’s listed in a route-map statement, and set all traffic originating from the local router with a next-hop IP of ISP1 as long as it was deemed reachable by the IP SLA tracker probe status.
The Configuration (Cisco 2691 – IOS ADVENTERPRISE 12.4(15)T14)
Define IP SLA Policy
PolicyRouter(config)#ip sla 1
PolicyRouter(config-ip-sla)icmp-echo 22.214.171.124 source-interface Serial0/0
PolicyRouter(config)#ip sla schedule 1 start-time now life forever
Track Probe Status
PolicyRouter(config)#track 1 rtr 1 reachability
PolicyRouter(config)#ip access-list extended ROUTER
PolicyRouter(config-ext-nacl)#permit ip any any
PolicyRouter(config)#route-map ROUTER-TRAFFIC 10
PolicyRouter(config-route-map)#match ip address ROUTER
PolicyRouter(config-route-map)#set ip next-hop verify-availability 126.96.36.199 10 track 1
PolicyRouter(config-route-map)#set ip next-hop 188.8.131.52
Apply Policy-Based Routing to Locally Generated Traffic
PolicyRouter(config)#ip local policy route-map ROUTER-TRAFFIC
Route Map Status
Traceroute with Both ISP’s Reachable
Traceroute with ISP1 Down
The result was good. The next probe was working and traffic was being routed fine. The fail-over to ISP2 upon failure of Serial0/0 also works fine.
When Serial0/0 comes back on-line, the PBR sticks with the route through ISP2. After looking at the route map again after the failover and the restoration of Serial0/0, I saw that the tracker was still registering the next-hop as down.
I did some testing and noticed that pings to 184.108.40.206 would fail. This is because of the route-map applied to locally generated traffic. The locally-generated ICMP-echo probes were being set with the route-map’s active next-hop interface, sending the probe incorrectly to ISP2. For the purpose of the probe, it is necessary the probe traffic to be permitted to travel to the correct next-hop of ISP1 regardless of where other traffic is destined.
To correct this issue, I created an ACL to catch the probe traffic and inserted a sequence above the current statement in the route-map. This sequence allows the probe traffic to utilize the correct destination rather than be affected by the fail-over next-hop functionality.
PolicyRouter(config)#ip access-list extended RTR_PING_S0/0
PolicyRouter(config-ext-nacl)#permit icmp host 220.127.116.11 host 18.104.22.168 echo
PolicyRouter(config)#route-map ROUTER-TRAFFIC 5
PolicyRouter(config-route-map)#match ip address RTR_PING_S0/0
This fix resulted in next-hop redundancy including preempting when the specified next-hop ISP comes back on-line. This could be applied to a router with more ISP connections, so long as an ACL and route-map are created with respect to the necessary traffic-flow characteristics.
NOTE: Be very careful applying route-maps to locally-generated traffic. You must be aware of the implications to router functionality.