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.

[jawad-mukhtar]

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***

[mike.hendricks]

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

[jawad-mukhtar]

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

[mike.hendricks]

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.

[jawad-mukhtar]

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.

[mike.hendricks]

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)

[pille1234 · Accepted solution]

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.

[jawad-mukhtar]

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***

[John Blakley]

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 ***

[pille1234]

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.

[mike.hendricks]

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 ..

[Abzal]

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

[pille1234 · Accepted solution]

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.

[mike.hendricks]

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.