IP SLA - Status not reachable

Answered Question
Apr 15th, 2012

Hello All

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

Wondering the issue

ip sla 1 

icmp-echo 10.10.31.161. source-interface FastEthernet0/0

frequency 5

ip sla schedule 1 life forever start-time now

ip sla 2

icmp-echo 10.20.0.254 source-interface FastEthernet0/1

frequency 5

ip sla schedule 2 life forever start-time now

track 1 rtr 1 reachability

!

track 2 rtr 2 reachability

ip route 192.168.1.0 255.255.255.0 FastEthernet0/0 track 1

ip route 192.168.2.0 255.255.255.0 FastEthernet0/0 track 1

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 10 track 1

ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 track 2

ip route 10.10.10.0 255.255.255.0 10.100.200.1

ip nat inside source route-map FA0 interface FastEthernet0/0 overload

ip nat inside source route-map FA1 interface FastEthernet0/1 overload

thanks

ST

I have this problem too.
0 votes
Correct Answer by Richard Burts about 1 year 11 months ago

ST

add routes that look something like this

ip route 8.8.8.8 255.255.255.255 FastEthernet0/1 64.x.x.81

ip route 4.4.4.4 255.255.255.255 FastEthernet0/0 64.z.z.81

so that you specify both the outbound interface and the next hop.

HTH

Rick

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
Richard Burts Fri, 04/20/2012 - 04:09

ST

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.

HTH

Rick

saquib.tandel Sun, 04/22/2012 - 06:29

Hello Rick, sorry to miss interface information, i pasted missing information

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

crypto isakmp key 1111 address 84.x.x.x

crypto isakmp keepalive 10

!

crypto ipsec security-association lifetime seconds 86400

crypto ipsec transform-set GLOBAL esp-3des esp-md5-hmac

crypto map GLOBAL 10 ipsec-isakmp

set peer 84.x.x.x

set transform-set GLOBAL

match address ACL

interface fa 0/0

desc Internet-Link-1

ip address 78.x.x.x 255.255.255.240

ip nat outside

crypto map GLOBAL

interface fa 0/1

desc Internet-Link-2

ip address 64.x.x.x 255.255.255.248

ip nat outside

crypto map GLOBAL

interface fa 0/1/1

no shut

interface vlan 1

ip address 10.100.200.2 255.255.255.248

ip nat inside

NEXT-NEXT-HOP for Internet-Link 1 - 10.10.31.161

NEXT-NEXT-HOP for Internet-Link 2 - 10.20.0.254

I tested Public DNS server it pings most of the time and sometimes it doesnt

8.8.8.8 or 8.8.4.4 or 4.2.2.2

Thanks a TON

ST

Richard Burts Sun, 04/22/2012 - 19:25

ST

Thanks for the additional information. It does raise a couple more questions.

- you say that 10.20.0.254 is the next hop out FA0/1. But with this address on that interface ip address 64.x.x.x 255.255.255.248, how does the router know to use FA0/1 to get to that address?

- if you are trying to get to 10.20.0.254 (a private network address) by going out an interface with a public address, are you translating the address of the icmp-echo as it goes out FA0/1?

- can you verify that the device at 10.20.0.254 has a route back to the address of FA0/1?

- with the crypto map on the interface can you tell us whether the ACL referenced in the crypto map would match the icmp-echo packets and therefore would encrypt them?

HTH

Rick

saquib.tandel Mon, 04/23/2012 - 02:36

Hi Rick

I pasted the information

Next Hop address for Fa 0/1 -  64.x.x.81, ( its wimax device having this IP on my premises )

traceroute 8.8.4.4 source fastEthernet 0/1

Type escape sequence to abort.

Tracing the route to 8.8.4.4

  1 64.x.x.81 64 msec 28 msec 48 msec

  2 10.20.0.254 56 msec 40 msec 52 msec

  3 x.x.x.x 48 msec 68 msec 40 msec

ip access-list extended ACL

permit ip 10.10.10.0 0.0.0.255 172.16.5.0 0.0.0.255

permit ip 10.10.10.0 0.0.0.255 172.16.32.0 0.0.255

Local Subnet : 10.10.10.0/24

Remote office Subnet : 172.16.5.0/24 , 172.16.32.0/24

thanks aTON

ST

Richard Burts Mon, 04/23/2012 - 04:40

ST

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.

HTH

Rick

saquib.tandel Mon, 04/23/2012 - 05:29

Thanks Rick for replying. On tracing with traceroute command couple of times I notice another IP constantly appearing

216.239.x.x ( public IP - routable )  but after sometimes IP SLA shows down when use this IP. The ISP here is not very cooperative and notice link are very stable

Do you feel anything else missing in my config, can you ellaborate more on similar setup you did. is it correct to set icmp-echo pointing to 8.8.8.8.

ip sla 1 

icmp-echo 8.8.8.8 source-interface FastEthernet0/0

frequency 5

** public ip 8.8.8.8 in principle is reachable by both ISP then how logically it works **

Richard Burts Mon, 04/23/2012 - 06:11

ST

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.

HTH

Rick

saquib.tandel Mon, 04/23/2012 - 06:22

Rick when you say

^  I made sure that we got to the tracking address by specifying a route  to that destination that specified the outbound interface. ^

You added Two more static routes then the existing ones or something different

Existing Routes

ip route 192.168.1.0 255.255.255.0 FastEthernet0/0 track 1

ip route 192.168.2.0 255.255.255.0 FastEthernet0/0 track 1

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 10 track 1

ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 track 2

ip route 10.10.10.0 255.255.255.0 10.100.200.1

additional route ( example )

ip route 8.8.8.8 255.255.255.255 FastEthernet0/1

ip route 4.4.4.4 255.255.255.255 FastEthernet0/0

Correct Answer
Richard Burts Mon, 04/23/2012 - 08:09

ST

add routes that look something like this

ip route 8.8.8.8 255.255.255.255 FastEthernet0/1 64.x.x.81

ip route 4.4.4.4 255.255.255.255 FastEthernet0/0 64.z.z.81

so that you specify both the outbound interface and the next hop.

HTH

Rick

Vasileios Bouloukos Sun, 04/22/2012 - 14:34

Hi saquib,

I have a few more questions.

Do you encrypt the traffic (interesting traffic - you did not provide the AL in crypto) that is used for the sla?

Do you have the subnets to the ISP as connected to your routing table? Did you try traceroute to these destinations?

Maybe the routing to the next hop ips of the ISP does not go as you think. Could you provide also this info.

When the sla fails, i assume that you have also tested that the ping with the same source/destination fails.

Finally a general question, i wonder why you need to track your "last backup" default route AD=10? Do you have any other backup option?

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 10 track 1

ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 track 2

You could just track the primary default route

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 10

ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 track 2

Hope that helps,

Vasilis

Actions

Login or Register to take actions

This Discussion

Posted April 15, 2012 at 4:08 PM
Stats:
Replies:11 Avg. Rating:5
Views:586 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard