03-01-2013 10:53 AM - edited 03-04-2019 07:10 PM
This is driving me crazy. IP SLA works for failing over to the secondary connection (from Cable to DSL), however the SLA can never reach 4.2.2.2 from the cable, even when it is up. I can ping the interface from the outside world and get responses, but the SLA still thinks the connection is down. I think it has something to do with the NAT, but I seem to be spinning my wheels.
On the SLA, when the source isn't specified, it toggles up/down - I'm assuming because it's going out the backup connection, then the SLA comes up thinking all is well, realizes its down, and jumps back. When I specify source IP (or interface), it stops doing this, but never recovers from the failover.
Reloading the router causes it to switch back to the cable and all is well again until the cable drops and comes back up.
I'm 99% sure that I've overlooked something quite elementry, I just can't think of it.
Thanks in advance.
Solved! Go to Solution.
03-01-2013 02:17 PM
Besides possible additional connection problems the up-/down-flapping of the IP-sla is the expected behaviour with your design in case of a primary link failure.
The route selection for icmp sla packets is based soley on the routing table, not the source interface. If track 1 goes down, your ip sla is using the remaining route. Assuming the backup link is working properly, the IP sla is successfull again and track 1 comes up. Now IP sla is using the 68.x.x.201 route again, although the primary link is still down, so ip sla goes down and here we go...
Your backup link is not going to work this way. You need to make sure the icmp sla always uses the primary way no matter wether the primary route is installed in the routing table. One way would be to use
ip local policy route-map
matching on icmp and the source interface ip.
Best regards.
03-02-2013 06:07 AM
The only question left, is how to get the backup WAN interface (FA0/2/0) to respond to pings from the internet. I'm assuming this will require a similar local route map, but I'm not too sure how to swing that without conflicting with the new addition above ..
Just refine your ACL:
access-list 129 permit icmp 68.x.x.204 4.2.2.2
Now it is only applied for this specific router generated traffic.
03-19-2013 03:26 PM
I am not sure about your ACL. AFAR echo includes only echo-requests, not replies.
Try the following first, you can narrow it down afterwards:
access-list 130 permit icmp host 199.x.x.197 any log
Then check if you see any matches at all.
03-01-2013 12:29 PM
Are you able to ping 4.2.2.2 using source ip 68.x.x.204 by using extended ping command in router.
*** Do Rate Helpful Posts***
03-01-2013 12:39 PM
Jawad,
Thanks for the reply.
No, it times out. The interesting part is that I can ping 68.x.x.201 (the modem/gateway) using source 68.x.x.204
03-01-2013 01:36 PM
Re Configure SLA by deleting Old One.
Check again.
If u check then check 4.2.2.2.2 your source ip should be 68.x.x.204 by using extend ping command in router.
also check show ip route which route is active at that time.
68.x.x.204#sthash.Gf0SJD2U.dpuf
03-01-2013 01:48 PM
Jawad,
I'm not sure what you're asking. If I reconfigure the SLA, it works until the primary connection drops, then it goes to the secondary and never comes back until the router is rebooted. But even when the interface is up (and the connection is verified working on another router), I cannot ping 4.2.2.2 from source 68.x.x.201
sh ip route shows that 199.x.x.193 is the active route.
03-01-2013 02:06 PM
Configurate that u have attached is of actual router. Also provider route platform and IOS version.
If Primary is UP can u ping its Nex Hope IP. Its very strange you can't even ping 4.2.2.2 from primary when its up.
03-01-2013 02:15 PM
I can ping 4.2.2.2 from the primary when it is up. That's not the problem. When the primary goes down, the SLA switches, and when the primary connection recovers, the SLA ping still fails, leaving it in backup.
I can ping primary next hop when it's up or down.
Router is a 2811 with HWIC-2FE, running IOS Advanced Enterprise 12.4-20(T5)
03-01-2013 02:17 PM
Besides possible additional connection problems the up-/down-flapping of the IP-sla is the expected behaviour with your design in case of a primary link failure.
The route selection for icmp sla packets is based soley on the routing table, not the source interface. If track 1 goes down, your ip sla is using the remaining route. Assuming the backup link is working properly, the IP sla is successfull again and track 1 comes up. Now IP sla is using the 68.x.x.201 route again, although the primary link is still down, so ip sla goes down and here we go...
Your backup link is not going to work this way. You need to make sure the icmp sla always uses the primary way no matter wether the primary route is installed in the routing table. One way would be to use
ip local policy route-map
matching on icmp and the source interface ip.
Best regards.
03-01-2013 02:21 PM
You can add a static route of
ip route 4.2.2.2 255.255.255.255 (Primary next Hope IP)
Check by using that.
I agree with Pille
*** Do Rate All Helpful Posts***
03-01-2013 05:20 PM
Mike,
In addition to what everyone else stated here, I would only suggest that you absolutely not ping a dns providers IP in order to track your connection. You should configure your sla to ping your default gateway. If the provider, for some reason, were to go down then you're failing over for nothing. You should change your sla to ping your provider only and your other problems may magically disappear.
Oh, and without looking further, you're probably seeing that without the source command on the icmp statement you never fail back over is because your track is still up going out the other interface. I don't think you're going to need to get creative with local policy maps or anything like that though....
HTH,
John
*** Please rate all useful posts ***
03-02-2013 06:00 AM
Jawad Mukhtar schrieb:
You can add a static route of
ip route 4.2.2.2 255.255.255.255 (Primary next Hope IP)
I thought about that as well, but it wouldn't work. The route would disappear from the routing table in the moment the outgoing interface goes down.
03-01-2013 08:28 PM
pille1234 - That did work after I added the following:
ip local policy route-map local
!
access-list 129 permit icmp any any
!
route-map local permit 10
match ip address 129
set ip next-hop 68.x.x.201
John - I've toyed with the idea, however the primary provider has yet to be able to provide me with a reliable IP to use for this. Since this still has yet to go into production, 4.2.2.2 is doing the job just fine. Maybe when it's time to cross that bridge, they'll have their act together.
The only question left, is how to get the backup WAN interface (FA0/2/0) to respond to pings from the internet. I'm assuming this will require a similar local route map, but I'm not too sure how to swing that without conflicting with the new addition above ..
03-02-2013 04:28 AM
Hi,
I believe for such situation as yours as John already mentioned adding source interface to IP SLA should help you
ip sla 1
Icmp-echo 4.2.2.2 source-interface {primary interface here}
Sent from Cisco Technical Support iPhone App
03-02-2013 06:07 AM
The only question left, is how to get the backup WAN interface (FA0/2/0) to respond to pings from the internet. I'm assuming this will require a similar local route map, but I'm not too sure how to swing that without conflicting with the new addition above ..
Just refine your ACL:
access-list 129 permit icmp 68.x.x.204 4.2.2.2
Now it is only applied for this specific router generated traffic.
03-14-2013 10:06 AM
Thanks for the advice. I finally had a chance to try this, and while it didn't break the SLA, it still didn't allow me to get responses from the backup interface while traffic was still being routed out of the primary. This is what ACL 129 looks like now:
access-list 129 permit icmp 68.x.x.204 0.0.0.1 4.2.2.2 0.0.0.1 echo
When the SLA determines the primary interface is down, the secondary responds to pings, but our monitoring gear wants to poll that interface whether or not it's being used to ensure that it's up and ready to go if needed. As a shot in the dark, I tried this, but it didn't make any difference:
route-map local permit 20
match ip address 130
set ip next-hop 199.x.x.193
access-list 130 permit icmp 199.x.x.197 0.0.0.1 any echo
Thanks in advance.
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