IP SLA configuration & Its implementation

How does “IP SLA” work and in what scenario we can make use of it.

We need to understand the Layer 1 i.e. Physical layer before we can talk about IP SLA. Let’s assume that we have a point to point Serial Link between two Routers and suddenly it goes down, then many a times we see that the physical status of Link remains UP. There may be Repeaters or other devices present in between that – and this will not let the status of physical end of one device change when other end of interface is shut or down. In cases, where we have multiple ISP links and we want to track the interfaces e.g. in HSRP or in VRRP – Then we may not see change in state even if the ISP link goes down, which is a problem i.e. outage and additional administrative overhead because we have manually shut the interface to converge to Better Link. Therefore, we need to have a mechanism in place which tracks other applications reachability too.  IP SLA is one of the features. It can use ICMP, TELNET, FTP, DNS IP  etc application to do continuous polling which means it’s not just for physical layer

We can use IP SLA in static routes as well as in Policy Based Routing. . We will use both scenarios to discuss on this.

First) Usage of IP SLA with static route and OSPF implementation

screenshot

In above OSPF area 0 is implemented on every router with advertising all of its local subnets or networks.  R1 has two paths to reach 1.1.1.1/32 i.e. thru 10.1.1.2 and 11.1.1.2. Under normal calculation, OSPF has picked Best path towards 10.1.1.2 to reach 1.1.1.1/32. Now, we added a static route at R1 “ip route 1.1.1.1 255.255.255.255 11.1.1.2” so that preferred path is 11.1.1.2 for 1.1.1.1/32.

Problem is that when we Shut e0/0 at Router R3, we still see that route remains present in R1 routing table for 1.1.1.1/32. Here we get the issue, till the time route remains in routing table even if next hop is unreachable, OSPF will not come in use. So, we will use “IP SLA” here.

We will track 11.1.1.2 with Source IP 11.1.1.1 for icmp and set frequency of the tracking, timeout. Don’t forget to enable it by setting schedule i.e. start time and end time.

R1#sh run | section sla

ip sla monitor 1

 type echo protocol ipIcmpEcho 11.1.1.2 source-interface Ethernet1/0

 timeout 2000

 frequency 3

ip sla monitor schedule 1 life forever start-time now

Now, we need to attach this “IP SLA” configuration to a tracking Object using “track 1 rtr 1 reachability”. Keep its further sub commands as default i.e. do not change it.

Now, attach this Tracking Object to either Static Route or a Route-Map. In this case, we are using static route, so let’s do it using below command

ip route 1.1.1.1 255.255.255.255 11.1.1.2 track 1                       ( Note :-track “1 “ is tracking object number we used)

Testing  without shutting down of Interface

1

It goes via 11.1.1.2 as expected since we have static route in place.  Now, we will try to shut the interface e0/0 R3 and See the status of Interface e0/0 at R1 and Traceroute and ping to 1.1.1.1 (We haven’t implemented IP SLA as yet)

.

.

2

Now , we can see that without “IP SLA “in place ping stops working, Traceroute doesn’t show any path, Route is still present in routing table even though other end of interface is down. Also R1 e0/0 interface shows UP even though other end of interface i.e. e0/0 R3 is down.

3

.

.

.

.

Now, we will implement “ip sla” and shut R3 e0/0 and see if situation changes or not.

See traffic restored, path has changed, and ping is working fine. And static route is gone from Routing table. It is the benefit using “IP SLA”

Second)  In the same scenario we can use Route-Map, we need not use static route with tracking.

We can also use IP SLA with Route-map. Create a route-map, match it with an access-list. Instead of using “Set ip next-hop IP-ADDRESS”. We need to use “R1(config-route-map)#set ip next-hop verify-availability 11.1.1.2 1 track 1

Sitewide-15dollars640x480