How does “IP SLA” work and in what scenario we can make use of it.
IP SLA configuration & Its implementation
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
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 126.96.36.199/32 i.e. thru 10.1.1.2 and 188.8.131.52. Under normal calculation, OSPF has picked Best path towards 10.1.1.2 to reach 184.108.40.206/32. Now, we added a static route at R1 “ip route 220.127.116.11 255.255.255.255 18.104.22.168” so that preferred path is 22.214.171.124 for 126.96.36.199/32.
Problem is that when we Shut e0/0 at Router R3, we still see that route remains present in R1 routing table for 188.8.131.52/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 184.108.40.206 with Source IP 220.127.116.11 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 18.104.22.168 source-interface Ethernet1/0
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 22.214.171.124 255.255.255.255 126.96.36.199 track 1 ( Note :-track “1 “ is tracking object number we used)
Testing without shutting down of Interface
It goes via 188.8.131.52 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 184.108.40.206 (We haven’t implemented IP SLA as yet)
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.
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 220.127.116.11 1 track 1”