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: OSPF conditional inject of a Default Route

I believe most of you are familiar how OSPF is injecting a default route in a normal area. If not, you can find here all the documentation that you need. Please be familiar with this concept before reading this article.

Now, let’s assume that we have the following topology (click on image to have a more detailed view) :cisco-ospf-conditional-default-route

As you can see we have a BGP peering between PE and CE router, with CE router having and OSPF connection with the Core. CE router is injecting a default route to Core:

router ospf 1
default-information originate always

This configuration is OK, but we can run into the following issue. Imagine that for some reason the BGP peering between PE and CE is broken (e.g. line being down), the CE router will have no clue about this and will still propagate the default route to the Core. In this situation, the Core will still forward all the packets without specific route to CE where it will have no further route to reach the destination, as the CE does not receive any route from the BGP peer. As you can imagine is better to avoid this situation, especially if for some reasons you are not monitoring the connection between PE and CE and you cannot react to change manually the route in case of a failure. We are lucky because some smart engineers have developed a solution to avoid this problem, called Conditional inject of a default route in OSPF.

With this solution, OSPF is monitoring the reachability of the point-to-point IP connection between PE and CE. When OSPF process on CE router notice that the IP connection is not available anymore, it automatically retract the propagation of the default route to the Core. The solution is simple an assume use of  an ACL or prefix-list then match this on a route-map and finally use this route-map under “router ospf” process. For step-by-step configuration check below.

First we will create and ACL matching the IP subnet between PE and CE. In this example I’m using a p2p subnet /30:

access-list 1 permit

Then I will match this into a route-map as follow:

route-map WAN-LINK permit 10
match ip address 1

Finall, we will use this route-map to implement the OSPF conditional injection of default route to Core router ( /30 is the p2p IP subnet between CE and Core):

router ospf 1
network area 0
default-information originate always route-map WAN-LINK

Now, the OSPF process on CE will inject a default route to the Core as long as the IP subnet between CE and PE is reachable.
IMPORTANT NOTE: This solution might not work if your connection from CE to PE is Ethernet and not Serial like in the example. I will explain why on the next post, when I’ll achieve the same behavior but using EEM together with an Ethernet based connection instead of a Serial one.

Please check below to see a small presentation how this is working on a test environment: