IP SLA - Status not reachable

While configuring IP SLA as following, reachability to fa 0/1 status not reachable, when I remove the IP SLA and test only one link at a time it works. Both links are working but with IP SLA link fa 0/1 status not reachable

Share:

Replies

If we had some additional information it might help us figure out what is the issue here. As a start can you post the configuration of the interfaces? Also can you clarify for us what are the addresses that you are testing in the icmp-echo commands?

I will also point out that configuring static routes that just point to Ethernet interfaces is sometimes problematic. It may work or may not work depending on whether the next hop router has enabled proxy arp or not (and increasingly service providers are not supporting proxy arp). And even when it does work (as seems to be the case here) it makes the router work harder than a static route that specifies the next hop address.

Thanks for the additional information. It does clarify the relationship of 10.20.0.254 with FA0/1. I wonder if the issue is trying to send icmp-echo to a network 10 address via the ISP connection. Since network 10 is not routable in the Internet I wonder what the ISP does when you send it icmp-echo with a destination address of 10.20.0.254? Would it route it on to the next hop or would it drop the packet as un-routable?

I think I understand what you are trying to do here. You do not want to verify the connected device as much as to verify connectivity further into the provider network. I have done similar things with customer networks. I suggest that as a test you find some other resource within the provider network that has a public routable address and use that as your tracking address.

You have correctly identified at least one of the potential problems if you use 8.8.8.8 for IP SLA tracking. If it could be reachable via both providers then how do you know that a provider is down (the provider you are tracking could be down but the site is still reachable via the other provider). When I was configuring IP SLA for the customer I made sure that we got to the tracking address by specifying a route to that destination that specified the outbound interface.

There are some other potential issues in using something like 8.8.8.8 for tracking. For example if the tracking indicates that it is down, how do you know whether it is a problem with your provider that you are tracking, or a problem with that site, or a problem with something in the path to that remote site but not a problem in your provider.

For that reason I suggest that you find some public accessible sites within the network of your provider (they probably have a web site or an Email server that are accessible) and use that for the tracking address. Then if there is a problem accessing the tracking site you are fairly sure that it is a problem within the network of the provider.