Cisco IP SLA

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.

Diagram

**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 200.1.1.2 source-interface Serial0/0 PolicyRouter(config-ip-sl.a-echo)#timeout 1000 PolicyRouter(config-ip-sla-echo)#frequency 3

Start Probe PolicyRouter(config)#ip sla schedule 1 start-time now life forever

Track Probe Status PolicyRouter(config)#track 1 rtr 1 reachability

ACL PolicyRouter(config)#ip access-list extended ROUTER PolicyRouter(config-ext-nacl)#permit ip any any

Route Map 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 200.1.1.2 10 track 1 PolicyRouter(config-route-map)#set ip next-hop 201.1.1.2


**Apply Policy-Based Routing to Locally Generated Traffic **PolicyRouter(config)#ip local policy route-map ROUTER-TRAFFIC

Result

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.

The Problem

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 200.1.1.2 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.

Solution

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.

ACL PolicyRouter(config)#ip access-list extended RTR_PING_S0/0 PolicyRouter(config-ext-nacl)#permit icmp host 200.1.1.1 host 200.1.1.2 echo

Route Map PolicyRouter(config)#route-map ROUTER-TRAFFIC 5 PolicyRouter(config-route-map)#match ip address RTR_PING_S0/0

Result

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.

comments powered by Disqus