IP SLA fine tuning

[Kaushik Ray]

Hello All

I have two routers connected using two links on different service providers and they act as a back up to one another. I have IP SLA running to between them to failover.

I would however want the failover to NOT being instantaneous and would like the service to keep on Link A and if the link does not establish in 5 seconds to failover to the other Link B. However despite configuring the SLA as below, I am seeing the failover to be almost intantaneous and not waiting for the 5 seconds. Is there somewhere I am going wrong; or there is something I would need to do?

Config snippets as follows:

RTR A

track 10 rtr 10 reachability

!

track 20 rtr 20 reachability

!

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

ip address 10.10.10.1 255.255.255.252

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 192.168.0.1 255.255.255.252

duplex auto

speed auto

!

ip route 0.0.0.0 0.0.0.0 10.10.10.2 track 10

ip route 0.0.0.0 0.0.0.0 192.168.0.2 track 20

!

!

ip sla 10

icmp-echo 10.10.10.2 source-ip 10.10.10.1

frequency 10

ip sla schedule 10 start-time now

ip sla 20

icmp-echo 192.168.0.2 source-ip 192.168.0.1

frequency 10

ip sla schedule 20 start-time now

RTR B

!

track 10 ip sla 10 reachability

!

track 20 ip sla 20 reachability

!

!

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

ip address 10.10.10.2 255.255.255.252

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 192.168.0.2 255.255.255.252

duplex auto

speed auto

!

!

ip route 0.0.0.0 0.0.0.0 10.10.10.1 track 10

ip route 0.0.0.0 0.0.0.0 192.168.0.1 track 20

!

ip sla 10

icmp-echo 10.10.10.1 source-ip 10.10.10.2

frequency 10

ip sla schedule 10 start-time now

ip sla 20

icmp-echo 192.168.0.1 source-ip 192.168.0.2

frequency 10

ip sla schedule 20 start-time now

!

!

[Sindhu_kumar]

Hi you can configure timeout option in IP SLA. Default timeout is 5 seconds I guess due to that it taking 5 second to switch over.

Timeout: Helps you to set how much time your router will wait before declaring that specific probe as failed,

R1(config-sla-monitor-echo)#timeout ?

  <0-604800000>  Timeout in milliseconds

RTR A

!

ip sla 10

icmp-echo 10.10.10.2 source-ip 10.10.10.1

timeout 1000

frequency 10

ip sla schedule 10 start-time now

ip sla 20

icmp-echo 192.168.0.2 source-ip 192.168.0.1

timeout 1000

frequency 10

ip sla schedule 20 start-time now

RTR B

!

ip sla 10

icmp-echo 10.10.10.1 source-ip 10.10.10.2

timeout 1000

frequency 10

ip sla schedule 10 start-time now

ip sla 20

icmp-echo 192.168.0.1 source-ip 192.168.0.2

timeout 1000

frequency 10

ip sla schedule 20 start-time now

!

[blau grana]

Hello,

I do not think you are right.

timeout

(Optional) Sets the amount of time an IP SLAs operation waits for a response from its request packet.

http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsicmp.html

To delay installing/uninstalling route use delay parameters under tracking rtr.

track 10 ip sla 10 reachability

delay up XY down XY

Here is some example:

http://packetpushers.net/using-ip-sla-delay-feature-to-safely-monitor-lossy-links/

Best Regards

Please rate all helpful posts and close solved questions

[Paul Morgan]

Additionally to using the 'delay up down', you may want to fine tune what your IP SLA is monitoring. Does a simple ping test failing confirm that the line is down?

You can configure a group of tracked objects in an object list, include boolean operators and add your delay up down timers to really nail down the confirmation of line failure.

eg

track 11 list boolean and

object 21

object 22

object 23

!

track 12 list boolean and

object 31

object 32

object 33

!

track 21 interface Dialer0 line-protocol

delay down 5 up 5

!

track 22 interface ATM0/0/0 line-protocol

delay down 5 up 5

!

track 23 interface Tunnel0 line-protocol

delay down 15 up 5

!

track 31 interface Dialer1 line-protocol

delay down 5 up 5

!

track 32 interface ATM0/1/0 line-protocol

delay down 5 up 5

!

track 33 interface Tunnel2 line-protocol

delay down 15 up 5

[Kaushik Ray]

Hello All Thanks for your reply. I was trying the delay down option and see the following

RTR A

!

track 10 rtr 10 reachability

delay down 25

!

track 20 rtr 20 reachability

delay down 25

!

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

ip address 10.10.10.1 255.255.255.252

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 192.168.0.1 255.255.255.252

duplex auto

speed auto

!

ip route 0.0.0.0 0.0.0.0 10.10.10.2 track 10

ip route 0.0.0.0 0.0.0.0 192.168.0.2 track 20

!

!

ip sla 10

icmp-echo 10.10.10.2 source-ip 10.10.10.1

timeout 1000

threshold 1000

frequency 10

ip sla schedule 10 start-time now

ip sla 20

icmp-echo 192.168.0.2 source-ip 192.168.0.1

timeout 1000

threshold 1000

frequency 10

ip sla schedule 20 start-time now

!

  And when i take the main interface down it still changes instantaneously as shown below despite the delay down command! with just 1 drop in ping it switches over to the other interface.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

*Jun  6 08:28:34.875: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up.!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Please can you advice where I may be going wrong?

thanks again

[Kaushik Ray]

I increased the delay down to 150 to give the Router 15 chances (as frequency is 10) to look for the main link but it still fails over instantly.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

*Jun  6 08:41:32.539: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!

track 10 rtr 10 reachability

delay down 150

!

track 20 rtr 20 reachability

delay down 150

!

[Paul Morgan]

Firstly, you havent set any metrics on those default routes to fix a primary and secondary.

This may mean that both routes are active which is why you see an 'instant' failover. Its already using the other route.

Its also possible (I cant remember this for certain) that when you disable an interface in this way, it brings a tracked object down immediately; some sort of coup message, like in HSRP. Im thinking out loud there though

[Kaushik Ray]

Paul

Thanks for your reply. So you suggest that instead of using the second route as track 20 i use it as something like metric 100?

Regards

Kaushik

[Paul Morgan · Accepted solution]

The best way to do it is like this example:

ip route 0.0.0.0 0.0.0.0 Dialer0 3 track 11

ip route 0.0.0.0 0.0.0.0 Dialer1 4 track 12

ip route 0.0.0.0 0.0.0.0 Dialer0 6

ip route 0.0.0.0 0.0.0.0 Dialer1 6

This means that whilst your lines are coming up and your tracked objects arent up (as your ping wont complete), it will have the fallback to load balanced default routes so both lines can come up before it naturally selects the lower metric default route once they are stable and your tracks are working.

(Be careful if you are doing this in production. Get it wrong and you can lock yourself out of a remote site.)

[blau grana]

Hello Kaushik&Paul,

@Paul

This config will also cause immediate failover to backup link. If tracking 11 fails, default route with AD 4 will be use immediately. Default routes with AD 6 will be used only in case both tracking are down, but I see no point in doing that.

@Kaushik

If you are afraid of flapping default route in and out from routing table, just configure both tracking delays [up and down].

I think best solution for will be this:

- ip sla 20 and track 20 will be deleted

ip route 0.0.0.0 0.0.0.0 10.10.10.1 track 10

ip route 0.0.0.0 0.0.0.0 192.168.0.1 10

ip route 0.0.0.0 0.0.0.0 null 0 250 name discarding_route

Best Regards

Please rate all helpful posts and close solved questions

[Paul Morgan]

Thanks blau grana

When you test this config, if the router is rebooted, there will be no default routes if both have tracked objects that tie them to successful pings. That is why you need the two matched metric default routes as a backup.

But I fully agree that if the intention is to use one primary route then your answer is best for this.

[blau grana]

Hello Paul,

When you test this config, if the router is rebooted, there will be no default routes if both have tracked objects that tie them to successful pings. That is why you need the two matched metric default routes as a backup.
But I fully agree that if the intention is to use one primary route then your answer is best for this.

You are right in general, but not in this case. If you look at original post you will see that no default route is necessary. IP SLA is pinging targets which are on same subnets, 10.10.10.0/30 and 192.168.0.0/30.

Best Regards

Please rate all helpful posts and close solved questions

[blau grana · Accepted solution]

Hello,

There is no point to track two connections, just set admin distance on backup link to higher value.

ip route 0.0.0.0 0.0.0.0 10.10.10.1 track 10

ip route 0.0.0.0 0.0.0.0 192.168.0.1 10

If primary link fails, default route with higher AD will be used. And if this link also fails, traffic will be blackholed anyway because there is no other gateway.

Regarding immediate failover.

If you shut down primary interface Fa0/0 or if for some other reason interface goes down, failover is immediate and no delay can help you. Because of interface failure, default route via this interface is deleted from routing table and another is used.

Best Regards

Please rate all helpful posts and close solved questions