In the first part of this series, we introduced and configured HSRP, which is useful for creating a virtual IP address that can be shared among routers, thus providing redundancy of (default) gateways. In this article, we will look at another technology—a group of technologies actually—that can be used to provide redundancy for links. We will call this technology “static route backup using IP SLA.” As we will discover, it is a group of technologies working together: Static routes, tracking, and IP SLA.
Why Do We Need Static Route Backup?
As usual, an example will help drive the point home better. Consider the network below: ISP-A is the better link and should be used to access the outside network; ISP-B should only be used when ISP-A becomes available.
We can configure static routes on the LAN router pointing to both ISP-A and ISP-B but we will assign ISP-B with a higher administrative distance so that it is less preferred. The relevant portions of the configuration on each router are shown below:
Notice that I have increased the delay on the link between the ISP-B router and the outside router as a simulation that this is the slower link (which in turn affects EIGRP calculations). Looking at the routing table of the outside router, we will notice that the LAN (184.108.40.206/32) is accessible through ISP-A router.
The EIGRP topology table of the outside router also reveals that ISP-B will be used as a feasible successor if ISP-A becomes unavailable.
The LAN router can ping 220.127.116.11 through the ISP-A router, as shown below:
Now, if I shut down the LAN interface of ISP-A router, the LAN router will install the static backup route through ISP-B and I will still be able to ping the 18.104.22.168/32 IP address.
It would have been enough to shut down the interface of ISP-A router on a real network, but the device on the other end of a shutdown link on GNS3 may not detect it and will remain as Up/Up.
As we have seen, this means that the LAN router can automatically install the backup static route when the primary connected link fails. But what if an upstream link is the one that failed; i.e., what happens when the 192.168.14.0/24 link fails? Let’s see. I will restore the normal configuration before shutting down the Fa0/1 interface on ISP-A router.
Notice that the LAN router did not detect the failure in the upstream link and the default gateway remains through ISP-A and, therefore, the ping will fail. Of course this will not be a problem if the entire network was running a dynamic routing protocol where failures can be detected automatically but it is hardly the case of running a dynamic routing protocol (except BGP which may not even be necessary) between ISPs and your network.
It means we need a way to check if the primary link is available (all the way to the resource we need) and when it becomes unavailable, we want to automatically install the backup route (the assumption is that the backup route will be available; if that is also down, then the network still doesn’t have another path out).
IP SLA Monitoring
According to the Cisco website, “Cisco IOS IP Service Level Agreements (IP SLAs) is a network performance measurement and diagnostics tool that uses active monitoring by generating traffic to measure network performance.” Although IP SLAs can be used for various purposes, our focus is using the ICMP echo operation of IP SLA to monitor the availability of the outside network through ISP-A. When this link becomes unavailable, the backup route is installed. Let’s look at the configuration.
From the above configuration, I created an ICMP echo IP SLA to monitor the IP address: 192.168.14.4 (the outside router’s link to ISP-A). I then created a tracked object for reachability and attached that tracked object to the primary route. Keep this in mind that the route you track is the one you want to monitor (the primary route) and not the backup route (although you can also track the backup route).
So let’s test this. Initially, when all links are up and running, the LAN router uses the primary link as its default gateway and I can ping 22.214.171.124/32.
We can view the state of the tracked object using the show track command.
Now, I will shut down the interfaces between the ISP-A router and the outside router.
The first message we see on the console shows us that the reachability state of the tracked object has gone from Up to Down. We confirm this using the show track command. When we view the routing table, we discover that the backup static route has been installed and we can therefore still reach the 126.96.36.199/32 network.
What happens when the primary link comes back up? (I will bring up the interface now).
The tracked object becomes reachable again and the primary link is restored as the default gateway as we can see from the above.
This brings us to the end of the second part of this mini-series about redundancy technologies on Cisco devices. In this article, we have seen that IP SLA with tracking for static routes can be used not only to detect failures on connected links (like HSRP for example) but also to detect failures in upstream links and take routing decisions based on the response. In the next article, we will consider the final piece to this triad- using NAT to achieve redundancy (or high availability).
I hope you have found this article informative and if you have any questions or comments, do not hesitate to add it in the comment section.
Reference and Further Reading
IP SLAs–Analyzing IP Service Levels Using the ICMP Echo Operation: http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsicmp.html
Using IPSLA to change routing: https://supportforums.cisco.com/docs/DOC-6078