04-15-2012 04:08 PM - edited 03-04-2019 04:01 PM
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
Solved! Go to Solution.
04-23-2012 08:09 AM
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
04-20-2012 04:09 AM
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
04-22-2012 06:29 AM
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
04-22-2012 07:25 PM
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
04-23-2012 02:36 AM
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
04-23-2012 04:40 AM
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
04-23-2012 05:29 AM
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 **
04-23-2012 06:11 AM
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
04-23-2012 06:22 AM
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
04-23-2012 08:09 AM
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
04-23-2012 10:11 AM
Many Many Many Thanks
04-22-2012 02:34 PM
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
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