In an earlier post I already described how to set up IP SLA check a connection and how to bind it to a tracking object. Since then I’ve found out some differences between the IOS used on switches and the one used on routers. I used a hidden command ‘track 2 rtr 20’ to make a tracking object out of the IP SLA, but on a router, this command is not hidden. Also, on a layer 3 switch the IP SLA commands all start with ‘ip sla’, whereas on a router it’s ‘ip sla monitor‘. It may also be that my router is an older (EOL) device while my switch is relatively new. I guess I’ll have to know both to be sure.

I was also asked some interesting questions by Tomasz, and decided to expand the topic in a new post, describing some more options for these tracking objects. He also asked if it could be used as legal proof in case of a dispute. I’m not sure of it in case of my own ISP, but I think that on a corporate level, if enough details are mentioned in the contract, this may indeed be the case. After all, it’s an objective measurement of the connection.

So besides the simple logging, other things are possible. Take for example the following configuration:

The two routers have HRSP configured for the user subnet. Both routers have preempt configured. The left router has priority 200, the left router 190. The result is that in a normal situation, the left router will be the active router.

You can bind a tracking object to HRSP, for exampe, track the state of a connected interface. You can set that if an interface is down, priority of the router is decreased by 20. Okay, but is that really a safe solution? If both routers have a different number of connected interfaces, how do you determine which ones are important? And, say those interfaces stay up, but the problem occurs one hop away? It will go undetected, the link will stay up, packets will be sent through it, and dropped at the next hop.

Of course, you can also track the presence of certain routes in the routing table. This makes a lot more sense already: if the subnet can be reached, everything is fine, if it can’t, something is wrong, and it’s better that the other router takes the active role in that case. But it might still be insufficient for some types of data. There will be convergence by the routing protocols, which takes time. A network redesign or failure might change the route advertised into a more or less specific route (bigger or smaller subnet mask). E.g. a route to is present in the routing table pointing to f0/1, the route is being tracked. Something fails in the network, the route is removed from the routing table, but a working default route pointing to f0/2 is still present. Despite connectivity the router will still lose HRSP active status! And what if the route still works but suddenly experiences very high latency, while the other HRSP router is working fine?

IP SLA is a perfect solution here. The only downside is that it takes a bit of CPU on the router and some bandwidth, but we’re talking about just a few packets. For example, we configure the IP SLA to track the state of an important production server ( every 3 seconds using pings. If high latency (+100ms) is experienced or the ping fails, HRSP priority will decrease by 20.

Router(config)#ip sla monitor 50
Router(config-sla-monitor)#type echo protocol ipIcmpEcho
Router(config-sla-monitor-echo)#frequency 3
Router(config-sla-monitor-echo)#timeout 100
Router(config)#track 5 rtr 50
Router(config)#interface FastEthernet0/0
Router(config-if)#standby 1 preempt
Router(config-if)#standby 1 ip
Router(config-if)#standby 1 priority 200
Router(config-if)#standby 1 track 5 decrement 20

Note that you can track more than one object. So you can do this for multiple important points in the network. The router that can reach the most of these points with the least latency will have the active HRSP role. This ensures high availability of network services to users. Don’t forget the preempt command, otherwise the routers will not change active roles until one fails completely.