Cisco: Policy Routing with IP SLA

Let’s assume that you have a Cisco router with 2 ISP connection. The first one it’s a 10Mbps connection with a decent latency and the second one it’s a 2Mbps connection with quite high latency.

Since you don’t want to load balance over this 2 connections for the obvious reasons described above, you decide to to use the 10Mbps connection as the primary link and the 2Mbps one as a backup, just in case that the primary link fails.

You have no dynamic routing protocol, just a default route pointing to the primary link peer router. To understand better, please have a look to the topology below:

Of course, the easiest method would be to configure the a secondary default route through 2Mbps line but with a higher metric so it would be less preferred.  In this case when the main line goes done the backup default route comes into play. But what if the main line doesn’t go down? Just there is no reachability to Internet or some branch offices? This method will not work very well.

The solution that I propose is first to configure an IP SLA to monitor a certain destination (IP address) that you know if should always be UP. Like a server in your remote datacenter. In my example I will monitor the IP address which is a server reachable over main provider:

ip sla 5
icmp-echo source-interface GigabitEthernet0/0
timeout 1000
frequency 2
ip sla schedule 5 life forever start-time now

I believe you have an idea what IP SLA does. In this example it ping every 2 second the IP address and it wait for reply (timeout) 1000ms before declare the host down.

Next we have to track this IP SLA for reachability:

track 1 ip sla 5 reachability

Pretty simple. I have a track number 1 which tracks IP SLA session 5 for reachability.

Now, most of the people (including I, in the beginning ) make a common mistake in setting the backup default route in the way that they set it based on the track 1:

ip route track 1

This is not going to work. Why? Because track 1 check that the IP is reachable! When it is reachable, it will add the backup default route to the routing table and we will have 2 default routes: one through primary line and one through secondary (backup) lines. That’s bad because we need the backup route there only when the primary line fails to transport traffic to in my example. We need somehow that this backup route to be applied when IP SLA 5 is NOT true. Here is is how:

track 2 list boolean and
object 1 not

In this track 2 we tell to track object 1 but to have the condition that this is not true. Now we can see the backup route:

ip route track 2

and this will work correctly.

Small hint: You saw that in the IP SLA I’ve specified the interface from which I want to ping This is not just a preferred method, but it’s mandatory! If you follow the steps above, when the backup default route will be in place, will be reachable again, making the track 1 being true and setting the track 2 to think that the primary link is UP again, so it will retract the backup route through Pinging with the source of the primary P2P link interface, you achieve the result that you want IP SLA 5 to be true only when pinging through the first line. Remember that we are not using dynamic routing protocols.

In case  you didn’t catch this until now Gi0/0 is the 10Mbps link and the Serial0/0 is the 2 Mbps.

Another method to obtain the same result will be to used EEM with IP SLA which I will present in some future posts.

Cisco: How to achieve network redundancy with 2 interfaces

Sometime ago, during my preparation for Cisco CCIE certification, I encountered a task that I had to admit made me think a little bit, even I should see the solution from the first minute. The idea, at least as I see it, is that as much as you learn for some certification you start to see only the complex and painful part of the networking and this made me skip over the simplest solution. Something like, I learn to fly to the moon but I forget how to step on earth…

Before I start please have a look to this network topology. The task was having some statement that due to the monthly cost, R1 should use only one line (Frame-Relay) to communicate to the networks behind R2 (I took in this example Loopback0: /32) and in case that the R1’s protocol interface to Frame-Relay cloud is going, the connection to R3 should become active and traffic should flow through there. The scope was to achive some redundancy from R1 to the rest of the network. As I said before the solution was much more simplest that I start initially to think of and you can see it immediately.

Regarding the routing since this is not the main point discussed here, I just add 2 static routes on R1 to; one route through R2  and another one through R3 (with higher distance metric). Of course I put the necessary static routes and tracking on R2 and R3.

One advice if you want to try this on your own with this topology. Do not manually shutdown the main interface to enable the backup one, as it will not work. For testing you have to find a way that the main interface is down, but not administratively down. This is just not to get angry that this method is not working.

cisco interface backup