IP SLA Not Recovering

[mike.hendricks]

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.

[pille1234]

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

[mike.hendricks]

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.

[pille1234]

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

[mike.hendricks]

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.

[pille1234 · Accepted solution]

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.

[mike.hendricks]

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.