cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8056
Views
25
Helpful
8
Replies

IP SLA - tracking a far IP

vlad.vlaicu
Level 1
Level 1

Hello guys!

I am trying to set up a routing policy that is dependent on tracking an IP that is not a next hop but a far IP, from the Internet. In the attached topology Internet router has an ip of 8.8.8.8

I want to implement on the Client the following logic:

- If you can reach 8.8.8.8 via ISP1 than use this route, else use the route via ISP2.

The issue is so simple when tracking a next-hop, but I've never done it trying to track an object that pings a far IP address.

How can I do it?

I can also provide the configs if necessary.

Thanks

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Vlad,

Try this:

ip route 8.8.8.8 255.255.255.255 Ethernet0/0 10.0.0.1

ip route 8.8.8.8 255.255.255.255 Null0 2

!

ip sla 1

icmp-echo 8.8.8.8 source-interface Ethernet0/0

threshold 800

timeout 1000

frequency 30

!

ip sla schedule 1 start-time now life forever

!

track 1 rtr 1 reachability

!

ip route 0.0.0.0 0.0.0.0 10.0.0.1 track 1

ip route 0.0.0.0 0.0.0.0 20.0.0.1 2

The first two static routes are there to make sure that the tested IP address inside the ISP1 is truly reached only via link to ISP1, and if that link is down, then the pings are going to be thrown away (this is to prevent pinging 8.8.8.8 via ISP2 thanks to the default route).

Then there is the configuration of the IP SLA probe. It will ping the 8.8.8.8 using the source IP taken from E0/0 each 30 seconds. The ping will be considered over threshold but still successful if it returns in more than 800 msec (we won't be using this result anyway), and will be considered unsuccessful if it does not return in 1000 msec. Then, the IP SLA probe is scheduled to start immediately and to run continuously.

Subsequently, we create a track object. The track object is an interface between the IP SLA probe and its "users", in this case, the static route. When different subsystems in IOS perform tracking, they refer to track objects, and the track objects in turn hold the state of the particular test or probe they are associated with. In this case, the track object 1 will hold the result of the IP SLA probe 1.

And finally, we create two static default routes. The first one is through ISP1 but is subjected to a successful result stored in the track object 1. If the track object 1 reports failure, this route will be removed from the routing table and replaced with the backup default route that has worse administrative distance.

Please note that the IP SLA syntax has changed considerably in the recent IOSes. If the current syntax is not accepted by your router please let me know, I will try to rewrite it to the "old" format.

And of course, feel welcome to ask further!

Best regards,

Peter

View solution in original post

8 Replies 8

Peter Paluch
Cisco Employee
Cisco Employee

Hi Vlad,

Try this:

ip route 8.8.8.8 255.255.255.255 Ethernet0/0 10.0.0.1

ip route 8.8.8.8 255.255.255.255 Null0 2

!

ip sla 1

icmp-echo 8.8.8.8 source-interface Ethernet0/0

threshold 800

timeout 1000

frequency 30

!

ip sla schedule 1 start-time now life forever

!

track 1 rtr 1 reachability

!

ip route 0.0.0.0 0.0.0.0 10.0.0.1 track 1

ip route 0.0.0.0 0.0.0.0 20.0.0.1 2

The first two static routes are there to make sure that the tested IP address inside the ISP1 is truly reached only via link to ISP1, and if that link is down, then the pings are going to be thrown away (this is to prevent pinging 8.8.8.8 via ISP2 thanks to the default route).

Then there is the configuration of the IP SLA probe. It will ping the 8.8.8.8 using the source IP taken from E0/0 each 30 seconds. The ping will be considered over threshold but still successful if it returns in more than 800 msec (we won't be using this result anyway), and will be considered unsuccessful if it does not return in 1000 msec. Then, the IP SLA probe is scheduled to start immediately and to run continuously.

Subsequently, we create a track object. The track object is an interface between the IP SLA probe and its "users", in this case, the static route. When different subsystems in IOS perform tracking, they refer to track objects, and the track objects in turn hold the state of the particular test or probe they are associated with. In this case, the track object 1 will hold the result of the IP SLA probe 1.

And finally, we create two static default routes. The first one is through ISP1 but is subjected to a successful result stored in the track object 1. If the track object 1 reports failure, this route will be removed from the routing table and replaced with the backup default route that has worse administrative distance.

Please note that the IP SLA syntax has changed considerably in the recent IOSes. If the current syntax is not accepted by your router please let me know, I will try to rewrite it to the "old" format.

And of course, feel welcome to ask further!

Best regards,

Peter

Hello Peter.

Thank you for such a fast and detailed response. I pretty much got the idea but there are still some points I'd like to discuss.

1) The commands are indeed a bit different. I adapted them for my IOS and I also decresed the frequency for a faster response and dropped the threshold.

ip sla monitor 1

type echo protocol ipIcmpEcho 8.8.8.8 source-interface Ethernet0/0

timeout 1000

frequency 2

ip sla monitor schedule 1 life forever start-time now

!

2) Why are you using this command

ip route 8.8.8.8 255.255.255.255 Null0 2

Unless interface e0/0 fails, it will never be used. Correct?

3) Say ISP1 has lost connectivity to 8.8.8.8. The track returns Down and the static route (track dependend) is removed and the one with distance 2 via ISP2 remains. However the first command ip route 8.8.8.8 255.255.255.255 Ethernet0/0 10.0.0.1 will stick so I will not be able to reach 8.8.8.8 via ISP2. How can we overcome this?

Thanks

Hello Vlad,

You are very much welcome!

1) The commands are indeed a bit different. I adapted them for my IOS  and I also decresed the frequency for a faster response and dropped the  threshold.

ip sla monitor 1

type echo protocol ipIcmpEcho 8.8.8.8 source-interface Ethernet0/0

timeout 1000

frequency 2

ip sla monitor schedule 1 life forever start-time now

!

This looks fine.

2) Why are you using this command

ip route 8.8.8.8 255.255.255.255 Null0 2

Unless interface e0/0 fails, it will never be used. Correct?

Correct. What I am trying to accomplish here is to make sure that if 8.8.8.8 is pinged, it is always pinged only via E0/0 towards ISP1. Should the E0/0 be down, the pings towards 8.8.8.8 shall not be routed through any other route, in particular not through ISP2. Simply, the test of ISP1 should be tied to connection ISP1.

3) Say ISP1 has lost connectivity to 8.8.8.8. The track returns Down and  the static route (track dependend) is removed and the one with distance  2 via ISP2 remains. However the first command ip route 8.8.8.8  255.255.255.255 Ethernet0/0 10.0.0.1 will stick so I will not be able to  reach 8.8.8.8 via ISP2. How can we overcome this?

Basically, you do not want to overcome this. The reachability of 8.8.8.8 is your chosen test of the ISP1's functionality. If the ping to 8.8.8.8 fails for whatever reason, you declare ISP1 untrustworthy and move over to using ISP2 until 8.8.8.8 becomes reachable again.

Does this make sense? Of course, please do ask further!

Best regards,

Peter

vlad.vlaicu
Level 1
Level 1

Yes, it makes sense. Probably the choice 8.8.8.8 is not the best option since it is the Free DNS service of Google. What IP would actually be recommened to be used? How about the DNS server of the ISP? Or which option is used in real-life to sustain this scenario?

Thank you

Hello Vlad,

What IP would actually be recommened to be used? How about the DNS server of the ISP?

The DNS server is a fine choice. Other important servers, such as mail server, WWW server, web proxy (if any), perhaps even a DHCP server, all these are fine candidates. You can also check the output of a traceroute command towards 8.8.8.8 routed via ISP1 and choose some of the hops in this traceroute as the test target (it may be difficult to know, however, which of those routers still belong to ISP1, and they may come and go as ISP1's topology changes over time). If your ISP1 has a connection to a national or regional peering center where several ISPs interconect, you may want to ping the ISP1's boundary router that connects to this peering center.

There are many options to choose from, in fact The important thing is to primarily choose an IP address that is guaranteedly operated by ISP1 and that has a chance of not changing too often.

Best regards,

Peter

Peter, thank you again for all the support. You've been really helpful.

Hello Vlad,

Thank you very much! It has been a pleasure. Thank you for the generous ratings!

Best regards,

Peter

Hi,

 

I would like to configure IPSLA tracking with google DNS but when i implement the below solution ipsla came down and track not reachable but when i implement the soure and destination ip track reachable .Kindly advise me what i can do .

 

ip route 8.8.8.8 255.255.255.255 GigabitEthernet0/0/0.221 ISP1-GW track 3

ip route 8.8.8.8 255.255.255.255 Null0 10 track 2

 

ip sla 1
icmp-echo 8.8.8.8 source-ip WAN-IP
threshold 1000
frequency 10
ip sla schedule 1 life forever start-time now

------------

ip sla 2
icmp-echo 8.8.8.8 source-ip WAN-IP
threshold 1000
frequency 10
ip sla schedule 2 life forever start-time now

Review Cisco Networking products for a $25 gift card