IP SLA Default Route state down to much

[afgitdepartment]

Hello,

I am attempting to use IP SLA trackers to dynamically set the default route going out over a DSL connection.  if the sla trackers are down the default route learned from the WAN will take over, but normally we want to send internet/default route bound traffic out over the DSL connection.  

ip route 208.67.220.220 255.255.255.255 1.2.3.4
ip route 208.67.222.222 255.255.255.255 1.2.3.4
ip route 0.0.0.0 0.0.0.0 1.2.3.4 track 3

track 1 ip sla 1
 delay down 60 up 60
track 2 ip sla 2
 delay down 60 up 60
track 3 list boolean or
 object 1
 object 2

ip sla 1
 icmp-echo 208.67.222.222 source-ip 1.2.3.5
 threshold 1000
 frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo 208.67.220.220 source-ip 1.2.3.5
 threshold 1000
 frequency 10
ip sla schedule 2 life forever start-time now

the issue we are having is if the SLA threshold is breached, it immediately sends the trackers into a delay down state.  the tracker delays down for 60 seconds, then very quickly comes back up.  What we want to accomplish is only if the sla tracker has breached the threshold or is down for 60 seconds, then put the tracker into a down state.

Thanks.

[e.ciollaro]

I think your problems is because when the tracker go down the static route is removed form routing table and you router starts to use the route learned from WAN. At that point you ping 208.67.222.222 or 208.67.220.220 through the new path and, therefore, the static route is back in routing table.

Enrico

PS rate if useful

[afgitdepartment]

we have two static routes in place that always force the sla destinations to go out over the internet DSL:

ip route 208.67.220.220 255.255.255.255 71.32.39.46
ip route 208.67.222.222 255.255.255.255 71.32.39.46

[e.ciollaro]

this two static route just force the router to use 71.32.39.46 as next hop but which is the route for 71.32.39.46 ? 

[afgitdepartment]

71.32.39.46 is the DSL modem which always is doing static routing towards the internet.

[e.ciollaro]

Is it 71.32.39.46 directly connected to this router ? If so, when DSL modem go down, your router remove the static routes and use the default route received from WAN to  route icmp packet to 208.67.222.222 or 208.67.220.220

[afgitdepartment]

Hi, first thanks for that last comment because I hadn't thought of that..good conversation.

Yes the DSL modem is directly connected to router.  Yes, if the DSL modem goes down, we would loose connectivity to the static routes and the default route, and that would move the default route over to the WAN, which is what we want.  

I'm mostly concerned here about ensuring that a couple packets lost during the normal operation doesn't inadvertently put the tracker down.  I want to ensure that we have a solid 60 seconds of dropped pings before the tracker goes down.

[e.ciollaro]

The configuration seems to be correct: IP SLA change as soon as the icmp fail but the tracker delay should ensure the it changes its state after 60seconds of icmp failure. Do you experience a different behaviour ?

What I'm worried about is that, after the default router through the WAN is in routing table,  the ip sla ping will be successful and therefore the static route 

ip route 0.0.0.0 0.0.0.0 71.32.39.46 track 3

will be used but, at that point, which is the path to 71.32.39.46 ? 

Another thing is that, in case of DSL link failure, this configuration will not automatically revert to WAN link because 71.32.39.46 will be still up and running, isn't it ?

Let me know,

enrico

[e.ciollaro · Accepted solution]

Sorry, it was too late yesterday evening to post: obviously routing for 208.67.222.222 or 208.67.220.220 is based on static routers without any track so no problem.

My first question is still valid: did you experiences any problem with track delay ?

[afgitdepartment]

Hi,

I do believe we have this setup properly as well. It has really started to show how poor the ISP is. we've had to increase our thresholds because we frequently had RTT of 500+ ms causing this to flap a lot.  we're addressing that with the ISP.