IP SLA questions

[MikeAW2010]

'm studying for CCNP and recently did an IP SLA lab and have a few questions about how it works...

The lab is intended to reroute traffic coming  from R1 to the default route to R4 via 10.1.4.4 to the backup link via SW2 to R4's 20.1.4.4 interface in the event it loses connectivity to 10.1.4.4.

##Configure an IP SLA## 
R1(config)#ip sla 1 

##Send ICMP packets to 10.1.4.4 (R4) via the main default route## 
R1(config-ip-sla)#icmp-echo 10.1.4.4 source-interface f0/0 

##Set frequency to 5 and timeout to 1000## 
R1(config-ip-sla-echo)#frequency 5 
R1(config-ip-sla-echo)#timeout 1000 

##Set the schedule to last indefinitely and start the schedule now## 
R1(config)#ip sla schedule 1 life forever start-time now 

##Configure a track to use as the default route. Refer to the 
IP SLA we configured. It will be based on reachability of 10.1.4.4## 
R1(config)#track 1 rtr 1 reachability 

##Specify the time that the track must wait after determining the SLA is reachable## 
R1(config-track)#delay up 2 

##Specify the time that the track must wait after determining the SLA is unreachable## 
R1(config-track)#delay down 2 

##Configure a default route to 10.1.4.4  and refer to track 1## 
R1(config)#ip route 0.0.0.0 0.0.0.0 10.1.4.4 track 1 

So I want to see if I have a clear understanding of what I did...

I configured ip sla 1 and set an echo to 10.1.4.4 (on R4) via my source interface f0/0 (on R1). It will send a packet every 5 seconds. If it does not receive a reply in 1,000 seconds it will consider it a 'timeout' condition. I then set the ip sla 1 to start now and last indefinitely.

Now I need to set a track (this is the area that Im alittle unclear on). I set track 1 - I'm unsure what rtr 1 means or its intended function - ...I then set delay up 2 (I'm guessing this means it does not consider the link to be up unless 2 icmp's successfully make it to the intended destination) and set delay down 2 (and assuming similarly that it doesn't consider the link to be down unless 2 icmp's fail to reach the destination)

Finally I set my default route to 10.1.4.4 based on track 1...

actually I'm pretty confused...if someone could explain to me what I just did I would greatly appreciate it

[Georg Pauwen]

Hello,

your understanding of the IP SLA is correct. The only thing you are missing is the secondary static route that gets installed if the tracked default route is down, due to the IP SLA being down. So, all your assumptions are right on the money.

ip sla 1
icmp-echo 10.1.4.4 source-interface f0/0
frequency 5
timeout 1000
!
ip sla schedule 1 life forever start-time now
!
track 1 rtr 1 reachability
delay up 2
delay down 2
!
ip route 0.0.0.0 0.0.0.0 10.1.4.4 track 1
--> ip route 0.0.0.0 0.0.0.0 20.1.4.4 10

[paul driver]

Hello
So with your ipsla you are monitoring the reachability to the destination of host 10.1.4.4 sourcing ping/echo from your rtrs directly connect interface to sw1

Those echos are sent out at each frequency of 5000msec (5 second) will an expected echo-reply within a time frame of 1000msec (1 sec)

Now IPSLA can relate its monitoring to the object tracking feature that will allow tracking to trigger an action based on its reachability like you have specified above.

This tracking can then be appended to different features such has first hop routing protocols ( hsrp,vrrp,glbp), static/dynamic/policy-based routing etc and in your case its static routing.

When you have appended tracking to the static route showing in your post then that route now becomes conditional meaning the default route will exist ONLY if the condition is true ( iplsa monitoring is reachable)  if/when that reachability fails, tracking will initiate and so then the condition of the static route becomes untrue and its subsequently removed from the routing table.

Lastly as shown by @Georg Pauwen  you would require a second default route with a specified higher administrative distance pointing to an alternative default next-hop to take precedence ONLY after the preferred conditional default route ( which was preferred due to its route administrative distance  being lower-  (static routes default value is 1) is removed.

On a side note as in this case you are monitoring a directly connected interface you wouldn’t even require IPSLA you can just use tracking to monitor the line -protocol of the directly connected interface and this would also be sufficient

no ip sla 1
track 1 interface xx line-protocol

[Sergey Lisitsin]

Paul,

The interface monitoring would only be sufficient to detect if local side of the link fails. But as the routers connected via the switch, it might happen that the R4's side of the link fails and R1's side stays up. This won't be detected by interface monitoring. The IP SLA covers both sides of the link, so it is a little more versatile.

[paul driver]

Hello

@Sergey Lisitsin  good catch what you say is indeed applicable the OP shows the monitored ip address is not a directly connected interface i was looking at the switch addressing not the router.

[MikeAW2010]

Thanks for the help.

I still have a few questions...

I'm trying to figure out what this does:

track 1 rtr 1 reachability
delay up 2
delay down 2

I'm assuming track 1 is the track and sequence number, and then rtr 1 refers to the ipsla 1 which I defined beforehand right?

What does delay up 2 and delay down 2 do and how do they correlate with the frequency and timeout counters defined in ipsla 1? That is what is confusing me.

[Georg Pauwen]

Hello,

the track delay up/down simply mean that nothing will happen to the tracked object (the route) if the SLA fails until the period specified expires. If the SLA is down, a track delay down means that 2 seconds will expire before the tracked route is removed. Delay up of 2 seconds means the opposite, the tracked route is installed two seconds after the SLA is up again.

The SLA frequency and timeout values determine the operation of the SLA. Frequency 3 means that a ping i sent evert 3 seonds, timeout 5000 means that a ping is considered failed when no response is returned after 5000 mseconds. That is why the timeout value cannot be lower than the frequency.