routing | IPNET

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 http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_home.html. 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 172.82.100.1 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: 1.3.6.1.4.1.9.9.42.1.2.9.1.6

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 1.3.6.1.4.1.9.9.42.1.2.9.1.6.5 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5
action 1.0 syslog msg “172.82.100.1 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 0.0.0.0 0.0.0.0 10.10.10.1”

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 1.3.6.1.4.1.9.9.42.1.2.9.1.6.5 get-type exact entry-op eq entry-val 2 exit-op eq exit-val 1 poll-interval 5
action 1.0 syslog msg “172.82.100.1 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 0.0.0.0 0.0.0.0 10.10.10.1”

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 172.82.100.1 which is a server reachable over main provider:

ip sla 5

icmp-echo 172.82.100.1 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 172.82.100.1 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 0.0.0.0 0.0.0.0 10.10.10.1 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 172.82.100.1 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 0.0.0.0 0.0.0.0 10.10.10.1 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 172.82.100.1. 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, 172.82.100.1 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 10.10.10.1. 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 172.82.100.1 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 IP Routing Overview – Part IV

Fourth part from IP Routing Overview.

All this material is produced by RouteHub Group consultants, so all the copyrights and greetings have to be directed to them. If was free shared on the Internet so, I hope that I’m not breaking any copyright rules here. All that i want is to make this material more visible on the Internet. This is true also for the more to come materials from them.

If you are curious who is RouteHub Group, I have found this simple explanation on their site: RouteHub Group is a Premium Cisco Consulting provider of Cisco Products, Solutions, Training, and Professional Services for small, medium, and large-sized businesses.

[flv w=640 h=505]https://ipnet.xyz/vid/routehub/Cisco-IP-Routing-part4.flv[/flv]

Please find below:

– 1st part

– 2nd part

– 3rd part

of this presentation

Cisco IP Routing Overview – Part III

Third part from IP Routing Overview.

[flv w=640 h=505]https://ipnet.xyz/vid/routehub/Cisco-IP-Routing-part3.flv[/flv]

Please find below:

– 1st part

– 2nd part

– 4th part

of this presentation

Cisco: How to configure HSRP

In this post I proposed to discuss a little bit about Hot Standby Router Protocol and how it can be configured on a Cisco device. For this I have chosen the following topology:

I had in mind this scenario due to the fact that the traffic can take multiple paths in case of link being down and this give us the possibility to have a little bit of conversation on HSRP topic.
HSRP is defined in the document RFC2281 and according to the definition in this document: “The Hot Standby Router Protocol, HSRP, provides a mechanism which is designed to support non-disruptive failover of IP traffic in certain circumstances.” If you want to read more about the details how HSRP is working, please the RFC2281. I think there is not point in reproducing here what is already written there.
Regarding our topology, what you should know is that after configuring HSRP on R1 and R2 we will achieve a failover mechanism for the traffic from the Client (192.168.0.10) to the Server(10.10.10.10). From the beginning we will assume that R1 and R2 have the proper routing already configured to reach this destinations.

In the below presentation, you will see how the failover is achieved and what’s happening when you have a proper HSRP configuration in case that the link SC – R1 is broken:

So, how to achieve this behavior? From the topology you notice that proper configuration of HSRP involves 3 IP addresses from the same subnet (in our case this is 192.168.0.0 /24). One of the IP is configured on R1 the second one on R2 and the third one is HSRP IP address, which will be announced to the Client as gateway.

Configuration is straight forward on R1:

configure terminal
interface fa0/0
ip address 192.168.0.1 255.255.255.0
standby 1 ip 192.168.0.254
standby 1 priority 110

and on R2:

configure terminal
interface fa0/0
ip address 192.168.0.2 255.255.255.0
standby 1 ip 192.168.0.254

First we configure an IP address on the interface. Then we configure HSRP by typing the command “standby” followed by HSRP group (in our case group 1) and then the IP address. HSRP default priority is 100, and the principle is the higher the better. To force the path R1-SC to be the preferred one, we increse the priority to 110, making R1 to be the “Active” one. The other router, in our case R2, will have the HSRP status “Standby“. Maybe you are wondering what happens if you don’t configure the priority and both routers are having the same value 100. In this case HSRP has a mechanism that help it to chose the active router by comparing the IP addresses and chosing the one with the higher value. In our case this would be R2 (192.168.0.2 > 192.168.0.1).
Another useful feature that I recommend to configure for HSRP is “preemption“. The HSRP preemption feature enables the router with highest priority to immediately become the Active router. The configuration is also very simple and inquire only one additional line to the above ones:

standby 1 preempt

Also recommended is to configure “authentication“ between the HSRP participants:

standby 1 authentication somepassword

where “somepassword” can be what ever you want.

Going back to the topology, another scenario can take place. What if the link R1 – SC remains active, and instead the R1 – SS goes down. Since the R1 – SC is UP, the router R1 has no intention to cease the HSRP Active status. If you are having some kind of dynamic routing between R1 and R2, then you are on the safe side as the traffic will flow like in the scenario below (I’m assuming R1 to be the Active one for both R1-SC and R1-SS):

Remember that if do not have some routing between R1 and R2, the packets will be dropped on R1 as they will not have any path to the Server IP address 10.10.10.10.

This situation can be avoid with another HSRP feature, that will force the R1 to change it’s status from Active to Standby by monitoring the interface from R1 to SS. This feature is called “interface tracking“. This HSRP feature you have to configure at least on the router which is usual in Active mode:

standby 1 track FastEthernet1/0 30

In this scenario I assume that interface Fa1/0 is the connection to SS switch. This tracking command is watching for the status on the interface Fa1/0. When it’s status changes to “down” the “priority” value (110 in this example) is decremented with 30 (or whatever you will configure in the command line). After decremental, the “priority”
will have a value of 80 which is lower than the default one (100), forcing R2 to become the Active router and changing the R1 status to Standby.

Checking the status of an HSRP participant is very easy, and you can see this in the output below:

R1#show standby brief
P indicates configured to preempt.
|
Interface   Grp Prio P State    Active          Standby         Virtual IP
Fa0/0       1   110 P Active   local           192.168.0.2 192.168.0.254

R2#show standby brief
P indicates configured to preempt.
|
Interface   Grp Prio P State    Active          Standby         Virtual IP
Fa0/0       1   100 P Standby 192.168.0.1     local   192.168.0.254

All the HSRP configuration from this article can be fine tuned or extended according to your needs. I have presented here only the basics about the HSRP configuration. If you want don’t be afraid to explore and to “play” with the commands. Of course I would recommend to do that in test environment first.