IP SLA is a great tool on Cisco routers that allows us to generate traffic which can be used to check delay/latency, and jitter but can also be combined with object tracking. This allows us to check the reachability of a certain IP address (by pinging) or a certain service by connecting to it (using TCP). If the IP address/service is unreachable, we can apply a certain action. A simple example to demonstrate IP SLA is when you have a single router that is connected to two ISPs:
Above is a router (R1) connected to two ISPs. We want to use ISP1 as the primary and ISP2 as the backup link. All traffic will be sent toward ISP1 but when it’s unreachable, we’ll switch over to ISP2. You can achieve this by using two default routes:
R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2 R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.13.3 2
By default, a static route has an AD (Administrative Distance) of 1, that’s why I configured the second static route toward ISP2 to have an AD of 2. A static route with a higher administrative distance is also called a floating static route. When we look at the routing table of R1, this is what you’ll see:
R1#show ip route static S* 0.0.0.0/0 [1/0] via 192.168.12.2
Above, you will only see the route toward ISP1 because it has a lower AD. Now let’s shut the interface towards ISP1 to see what will happen with the routing table:
R1(config)#interface fa0/0 R1(config-if)#shutdown R1(config-if)#exit
This is what you will find:
R1#show ip route static S* 0.0.0.0/0 [2/0] via 192.168.13.3
Now everything will be sent to ISP2, which is great. This solution is quick and simple, but it has some potential problems…a static route will always remain in the routing table unless the interface goes down. It’s possible that the link towards ISP1 is up and running but that the ISP1 router itself is unreachable or that ISP1 has problems on their network that prevents us from reaching the Internet through them. This is why we’ll use IP SLA to make our default route more reliable. First, let’s unshut the interface:
R1(config)#interface fa0/0 R1(config-if)#no shutdown
I will create an IP SLA instance that pings the IP address of the ISP1 router:
R1(config)#ip sla 1 R1(config-ip-sla)#icmp-echo 192.168.12.2 R1(config-ip-sla-echo)#timeout 100 R1(config-ip-sla-echo)#frequency 1 R1(config-ip-sla-echo)#exit R1(config)#ip sla schedule 1 start-time now life forever
We will ping IP address 192.168.12.2 each second, and when we don’t get a response within 100 Ms, we will believe it’s unreachable. You might want to play with these values a bit on a production network. Let’s see if IP SLA works:
R1#show ip sla statistics Round Trip Time (RTT) for Index 1 Latest RTT: 4 milliseconds Latest operation start time: *00:09:07.235 UTC Fri Mar 1 2002 Latest operation return code: OK Number of successes: 43 Number of failures: 1 Operation time to live: Forever
It seems to be working. Right now, it only takes 4 milliseconds to get a response. As long as it stays below 100 milliseconds, we’ll be fine. Let’s configure the default route to use IP SLA:
R1(config)#no ip route 0.0.0.0 0.0.0.0 192.168.12.2 R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2 track 1
First, I’ll remove the old default route and replace it with one that says “track 1”. I can’t connect IP SLA directly with the static route. I have to do this with object tracking. This is how you combine object tracking with IP SLA:
In same scenario can you please repost the configuration for Load balancing. Thank you so much you are very helpful.
The configuration is 99% the same. Just make sure you have two equal default routes, in this example the second static route has an AD of 2. Remove that so they both have an AD of 1.
Secondly create an IP SLA instance for each default route so that you can ping IP addresses of each ISP.
I have this configuration but when main interface go down, the second default route is not going up. what can i check?
When the main interface goes down, do you see it being removed from the routing table?
Is the router able to reach 190.yy.yy.20? Is there any other default route that has a better AD than 10 which prevents it from being installed?
I was testing a similar scenario and the below logs started to appear:
I have configured a static route towards the router which I need to monitor and also have enabled object tracking. Could you please let me know, what c... Continue reading in our forum