01-12-2015 06:35 AM - edited 03-05-2019 12:32 AM
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.
Solved! Go to Solution.
01-15-2015 12:37 AM
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 ?
01-12-2015 07:34 AM
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
01-12-2015 07:45 AM
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
01-12-2015 07:58 AM
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 ?
01-12-2015 08:00 AM
71.32.39.46 is the DSL modem which always is doing static routing towards the internet.
01-12-2015 08:08 AM
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
01-12-2015 08:12 AM
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.
01-14-2015 01:14 PM
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
01-15-2015 12:37 AM
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 ?
01-16-2015 07:52 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide