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-16-2013 12:36 PM
Hi,
could you explain your setup in a little more detail? From where are you trying to ping the backup interface? From somewhere inside or from outside? Or from inside via primary link to the internet to the backup link?
Are you using 2 different providers for these links?
Regards
Pille
03-19-2013 01:39 PM
Pille1234,
A crude diagram is below (LAN segment omitted)
The backup interface is trying to be pinged from outside (via the internet). This is being done by a monitoring server in a colo datacenter that is independent of either connection provider.
The providers are different; FA0/1 is a cable link (primary) and FA0/2/0 is a DSL link.
While it isn't imperative that the secondary interface responds to pings when it is not the default route, it would be nice to ensure that the interface is up, accessible, and ready to go if needed.
03-19-2013 02:18 PM
Mike,
I am a little guessing here, but you may have the same problem like above:
the icmp reply from fa0/2/0 is following the route table entry pointing to your cable ISP. Now it is good practice from service providers to do unicast reverse path forwading or at least ACL filtering on their customer facing interfaces. As a result only "expected" traffic is allowed to enter the provider's network, all other packets were to be dropped. In your case, the cable provider would only allow packets sourced by 68.xx.xx.yy, while dropping 199.x.x.187.
Try a local policy map this time for icmp sourced by fa0/2/0 destined for your management station.
As I said it's just wild guessing...
Regards
Pille
03-19-2013 03:01 PM
Pille,
Would that be any different than what I tried? This (I typo'd the IP on the map, it's supposted to be 199.x.x.197):
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
I also tried to replace the any statement with the IP of the management box, but it didn't make any difference.
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-19-2013 03:30 PM
You're right. I added echo-reply and the interface came up. Now just to reboot everything a few times and make sure it still works.
Thanks for sticking with me on this - it's much appreciated.
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