Reliable Static Routing with IP SLA

(abdimalik m) #26

Hi rene,

sla configure does not accept "timeout 100 ". It shows error "timeout is less than treshold 5000.


(Rene Molenaar) #27

You should configure the threshold first before setting the timeout.

(Srinivas M) #28


1)Getting following error when defining timeout:
%Error: timeout value is less than threshold 5000

So the threshold and timeout should be same as follows:

R1(config-ip-sla-echo)#threshold 300
R1(config-ip-sla-echo)#timeout 300

2)Configure Tracking Object.

track 1 rtr 1 ------ Don’t accept
R1(config)#track 1 ip sla 1 reachability ---- works

(FABIAN M) #29


I need some advice here. In my lab I have 2 Ibgp routers going to the make believe web, I have 1 being prefered over the the other. My core isn’t participating in bgp, so Im trying to dynamically fail over when my primary goes down. the issue im running into is that when I bring up the primary router the default route isn’t pointing to the primary but staying on the secondary.In other words not failing over back to the primary. Is this a good method for this situation?

Here’s the config:

ip sla monitor 2
 type echo protocol ipIcmpEcho source-ipaddr
 frequency 10
ip sla monitor schedule 2 life forever start-time now

core1#sh run | sec track
track 1 rtr 2
ip route track 2


(Andrew P) #30

It generally looks like you have the right idea, but if I am understanding your situation, you are also going to need a what is called a floating static route using a higher administrative distance. So general terms, this is how it works:

For your primary ISP, create a static default route which references a track object. It looks like you have done this.

For your secondary ISP, create a static default route, but define the administrative distance as being something higher than default (1). It would look like this:

ip route <secondary gateway ip> 2

The number “2” above is defining the administrative distance. What will happen is that when your track object fails, the primary default route will be withdrawn, but unless you have a floating static route, nothing will replace it. By doing that second ip route statement, that route will only pop in after your primary route drops out because of the tracked object failure.

(FABIAN M) #31

Hi Andrew,

Thanks for your reply. I added my floating route like below:

core1#sh run | i  ip route
ip route track 2
ip route 250

now I’m seeing some peculiar things, when i shut down the primary router’s interface, my default route from isp is pointing to back up router. But when i bring up the primary, the back router points to the primary but my core is still pointing to my secondary router. Im going to try tracking another ip and see what happens.

I’ll let you know what I see.

(Rafa) #32

Isnt this the same as hsrp? Im not understanding the difference and the actual application of these two seem the same.

(Andrew P) #33

They are a bit different in both scope and purpose.

HSRP devices monitor each other to determine who should be the gateway, whereas IP SLA allows you to monitor just about anything. With HSRP, it is an all or nothing affair, meaning that upon a failure detection, the HSRP partner would completely take over the virtual IP and MAC address that other devices are using as a gateway. IP SLA can be more granular in its actions. For example, you could control whether a single route is published based on some failure condition being watched by an SLA monitor.

(Networklessons Admin) split this topic #34

19 posts were merged into an existing topic: Reliable Static Routing with IP SLA

(Mohammad Hasanuz Zaman) #35

Hi Rene,
I am little bit confused about timers of IP SLA .

threshold 100
timeout 1000
frequency 3

Could you please make it clear about all above timers in your simple way .Thanks


(Lazaros Agapides) #36

Hello Mohammad

The three parameters that you mention above are used like so:

* The threshold is the amount of time in milliseconds above which an ip sla is activated. In other words, if the response is less than the threshold, the network is functioning normally. If it is above the threshold, statistics are gathered and some action that is configured takes place.
* The timeout is the number of milliseconds the system waits for a response. If this time is exceeded, the attempt is considered lost.
* The frequency is how often the SLA operation takes place.

For example, if you create an IP sla where a specific IP address is pinged, and you set the threshold to be 500, the timeout to be 2000 and the frequency to be 10, then the following will occur:

* A ping will be sent out every 10 seconds.
* If the response is below the threshold, it is considered normal network behaviour
* If the response is above the threshold but below the timeout, statistics are updated and the configured action takes place
* If the response is above the timeout, the attempt is considered lost, statistics are gathered and the system no longer waits for a response.

I hope this has been helpful!


(I Ian L) #37

Hi Rene/Moderators,

When is not reachable from dialer0, default route via cellular takes over.
The traffic is not failing back from cellular to dialer, would it be because timeout and threshold have not been defined?

track 234 ip sla 1 reachability

ip sla 1
 icmp-echo source-interface Dialer0
 frequency 5

ip sla schedule 1 life forever start-time now

ip route Dialer0 track 234
ip route Cellular0 254

(Rene Molenaar) #38

Hi @mrleeiian

Your IP SLA configuration looks fine, even if you haven’t configured a timeout/threshold, there are default values:

R1#show ip sla configuration 
IP SLAs Infrastructure Engine-III
Entry number: 1
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source interface:
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Data pattern: 0xABCDABCD
Verify data: No
Vrf Name: 
   Operation frequency (seconds): 5  (not considered if randomly scheduled)
   Next Scheduled Start Time: Start Time already passed
   Group Scheduled : FALSE
   Randomly Scheduled : FALSE
   Life (seconds): Forever
   Entry Ageout (seconds): never
   Recurring (Starting Everyday): FALSE
   Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
   Number of statistic hours kept: 2
   Number of statistic distribution buckets kept: 1
   Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
   Number of history Lives kept: 0
   Number of history Buckets kept: 15
   History Filter Type: None 


(Kuoch K) #39

Hi Rene
I have read this !

You recommend to ping something on internet and i have try and apply IP SLA on my primary static route, so when some thing wrong with my first static route to ISP1 it can’t reach Then it will show %TRACKING-5-STATE: 1 rtr 1 state Up->Down, then it will pick up the secondary static route install in routing table then mean it can reach It make my IP sla keep up and down up and down.
Can you help me on this, Thank you!

(Heng S) #40

Hi Rene
I have read this !

You recommend to ping something on internet and i have try and apply IP SLA on my primary static route, so when some thing wrong with my first static route to ISP1 it can’t reach Then it will show %TRACKING-5-STATE: 1 rtr 1 state Up->Down, then it will pick up the secondary static route install in routing table then mean it can reach It make my IP sla keep up and down up and down.
Can you help me on this.
Thank you so much
Sovandara !

(Lazaros Agapides) #41

Hello Heng

Yes, I understand your problem. Once the failover occurs, the SLA destination is reachable again, so it thinks that connectivity has been restored so it goes back to the original connection. This connection is still down so it fails over again and so on.

In order to differentiate between which connection is down, it is possible to indicate from which specific interface your IP SLA will be tested using the following command:

icmp-echo a.b.c.d source-interface gig0/0

In this way you can set up the ping to occur on the interface that connects to ISP 1. This means when the failover occurs, the SLA pings will still be sent from the “failed” connection, thus they continue to fail until the specific connection recovers.

I hope this has been helpful!


(Heng S) #42

Hi Laz

I follow your introduction, but it still the problem once My IP SLA which ping to through ISP1 using source interface that direct connect to ISP1 fail, it will use secondary route , after failover to secondary route, IP SLA keep fail, as it never can reach with source interface connect to ISP1 using secondary route which go through ISP2.
Please help on this problem
Thank you
Sovandara Heng

(Lazaros Agapides) #43

Hello Heng

I see what you’re saying. Yes, it would still find the IP address. Now one option you can use is to use the DNS server of ISP1 as the destination address of the SLA. DNS servers are often only accessible via their own ISP networks and cannot be reached via another ISP. Another option is to add an extended ACL to Ge1/0 that blocks all ICMP packets from a source IP address of G0/0 to a destination IP address of so that no pings can be sent successfully from the Ge0/0 interface to via the Gi1/0 interface.

I hope this has been helpful!


(Dominique R) #46

Hi Rene and staff,

i lab the lesson and read the forum (there is so stuff to pass certifications, and reading forum is so time consuming, that you can’t read it perfectly well)

Please, could you answer two (perhaps basic) questions:

  1. how the track object work with the probe ? Suppose the probe ip sla return only one single fail (RTT > timeout setting) among success: does the track object trigger the action just for one fail ?
    And if the probe returns on single fail between threshold and time out ? you said in a earlier post that between threshold and time out, action takes place too

  2. most of the time i am studying for advanced concepts, and i realize that sometimes i could not answer what seems basic question ! In the lesson topology, before setting ip sla, Rene shut the R1 Fa0/0 to demonstrate the backup default route taking place: OK. But, when you shut the ISP1 Fa0/0, why the R1 Fa0/0 remains UP ? they are directly connected and line protocol is down for the ISP1 Fa0/0
    I will greatly appreciate your answers

(Lazaros Agapides) #47

Hello Dominique

The answer is yes, even for one fail, the action is taken immediately. It is the threshold that is taken into account as far as if the action is to take place. The timeout is there so that a device will not be waiting for multiple “unresponsive” probes as time goes on, resulting in the use of resources.

Now this brings up a good question. What happens if the SLA is triggered over and over due to a flapping state. This would mean that actions would be taken continuously resulting in degradation in service. There is an additional parameter that can be configured, in object tracking which is the delay. You can delay the action taking place for several seconds. You can also delay the action that is taken upon restoration of the SLA state. You can find out more about this command on page 12 of the following documentation:

As for your second question, when Rene shutdown the port on the ISP, we get the following:

Can you specify where in the lesson you see that the interface on R1 remains up?

I hope this has been helpful!