Cisco: IP Policy Routing with IP SLA and EEM

Considering the same environment like in the post Cisco: Policy Routing with IP SLA, there is another way to achieve the same behavior using again IP SLA and EEM (Embedded Event Manager).

For those of you who are not so familiar with EEM please read You will find a nice explanation and some examples how to use EEM to achieve the desired result.

Now, going back to our example, please conside the same topology like in the previous post:

We start by configuring again the IP SLA (explanation in this post):

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

We have the path measured. Instead of tracking this and applying the route based on tracking, we have now a different approach. We use EEM to check the conditions of IP SLA, and according to the result we configure the necessary IP routing. For EEM to work we need to know and Object name and the OID associated with it. In my example I will use the SNMP Object name rttMonCtrlOperTimeoutOccurred with OID value:

According to Cisco’s explanation “This object is set to true when an operation times out, and set to false when an operation completes under rttMonCtrlAdminTimeout. When this value changes, a reaction may occur, as defined by rttMonReactAdminTimeoutEnable

As a summary, we will check the IP SLA with EEM using a certain SNMP Object. When a change occur in the monitored IP SLA, EEM will apply a certain configuration defined by us:

event manager applet IP-SLA-5-TIMEOUT
event snmp oid get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5
action 1.0 syslog msg “ not reachable – primary line NOK”
action 1.1 cli command “enable”
action 1.2 cli command “configure terminal”
action 1.3 cli command “ip route”

EEM is based on a SNMP event. It is monitoring the OID value explained above. You may notice that at the end of the OID value, has been added another value .5 This is important as it defines the relation between EEM and IP SLA. In my case this number is 5, as the IP SLA session is defined, but in your case it may be different. This is checking if the TruthValue is 1 (true) or 2(false), on a 5 second interval and it’s applying the defined configuration. The EEM triggers on value 1 (true), so when the timeout occurs in IP SLA.

You might wonder, what will happen when the primary line is working. Well nothing in this conditions, because EEM is not configure for the case when the primary line is OK. In other words, EEM will not retract the backup default IP route. For this we need another EEM to be configured with a small modification:

event manager applet IP-SLA-5-OK
event snmp oid get-type exact entry-op eq entry-val 2 exit-op eq exit-val 1 poll-interval 5
action 1.0 syslog msg “ is reachable – primary line OK”
action 1.1 cli command “enable”
action 1.2 cli command “configure terminal”
action 1.3 cli command “no ip route”

Now the EEM is triggered on the value 2 (false), so when no timeout occurs in IP SLA.

You might be interested in another EEM configuration, which send an e-mail notification when a certain condition occur. Check it here.

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: