Yes, I understand your problem. Once the failover occurs, the SLA destination is reachable again, so it thinks that connectivity has been restored so it goes back to the original connection. This connection is still down so it fails over again and so on.
In order to differentiate between which connection is down, it is possible to indicate from which specific interface your IP SLA will be tested using the following command:
icmp-echo a.b.c.d source-interface gig0/0
In this way you can set up the ping to occur on the interface that connects to ISP 1. This means when the failover occurs, the SLA pings will still be sent from the âfailedâ connection, thus they continue to fail until the specific connection recovers.
Hi Laz
I follow your introduction, but it still the problem once My IP SLA which ping to 8.8.8.8 through ISP1 using source interface that direct connect to ISP1 fail, it will use secondary route , after failover to secondary route, IP SLA keep fail, as it never can reach 8.8.8.8 with source interface connect to ISP1 using secondary route which go through ISP2.
Please help on this problem
Thank you
Sovandara Heng
I see what youâre saying. Yes, it would still find the 8.8.8.8 IP address. Now one option you can use is to use the DNS server of ISP1 as the destination address of the SLA. DNS servers are often only accessible via their own ISP networks and cannot be reached via another ISP. Another option is to add an extended ACL to Ge1/0 that blocks all ICMP packets from a source IP address of G0/0 to a destination IP address of 8.8.8.8 so that no pings can be sent successfully from the Ge0/0 interface to 8.8.8.8 via the Gi1/0 interface.
i lab the lesson and read the forum (there is so stuff to pass certifications, and reading forum is so time consuming, that you canât read it perfectly well)
Please, could you answer two (perhaps basic) questions:
how the track object work with the probe ? Suppose the probe ip sla return only one single fail (RTT > timeout setting) among success: does the track object trigger the action just for one fail ?
And if the probe returns on single fail between threshold and time out ? you said in a earlier post that between threshold and time out, action takes place too
most of the time i am studying for advanced concepts, and i realize that sometimes i could not answer what seems basic question ! In the lesson topology, before setting ip sla, Rene shut the R1 Fa0/0 to demonstrate the backup default route taking place: OK. But, when you shut the ISP1 Fa0/0, why the R1 Fa0/0 remains UP ? they are directly connected and line protocol is down for the ISP1 Fa0/0
I will greatly appreciate your answers
Regards
The answer is yes, even for one fail, the action is taken immediately. It is the threshold that is taken into account as far as if the action is to take place. The timeout is there so that a device will not be waiting for multiple âunresponsiveâ probes as time goes on, resulting in the use of resources.
Now this brings up a good question. What happens if the SLA is triggered over and over due to a flapping state. This would mean that actions would be taken continuously resulting in degradation in service. There is an additional parameter that can be configured, in object tracking which is the delay. You can delay the action taking place for several seconds. You can also delay the action that is taken upon restoration of the SLA state. You can find out more about this command on page 12 of the following documentation:
As for your second question, when Rene shutdown the port on the ISP, we get the following:
In command track 1 rtr 1 what rtr mean and the no we are using after track and rtr when same and when different or these no does have something mean to sla instance which is 1?
This particular command combines the track instance configured in the static route, with the IP SLA instance. The first number (track 1) refers to the track number used in the static route. The second number (rtr 1) refers to the IP SLA instance.
This lesson is relatively old and the syntax used has changed since IOS 12.2(33). Rene will be updating this soon, but you can see the newer syntax at the following link:
i am running vios version 15.6 & track command along with rtr does not run but as mentioned in one o the post by Laz i tried couple of other things still exist
Issue is once i give the ip route command along with track ânoâ i dont see it on the route table bt i can see the next route
if somebody can let me know what could be the issue
If you donât initially see it in the routing table, then this means that the tracking condition for the IP SLA has not been fulfilled. The tracking mechanism sees that the check fails, and removes it from the routing table. This is the only reason that you would not see it there. Can you recheck the IP SLA condition and make sure that it is as it should be?
You mention in note to try some IP in internet for SLA⌠I wonder if you have any reliable IP/service in the internet. Certainly 8.8.8.8 is UP but if you have any suggestion to point direction on what criteria should i follow ?
As Rene states in the lesson, it can be of benefit to use IP addresses on the Internet as destinations for your IP SLA to check your Internet connectivity. Of course most peopleâs faviourite is 8.8.8.8 because it is easy to remember and because it is Google, so you assume that itâs always up. But actually, this is a very good choice to use because this address does not change often (as a DNS service, it shouldnât!), and because, no matter where you are in the world, 8.8.8.8 will be somewhere relatively close to you. This IP address is not geographically stationary, but belongs to multiple Google datacentres. For example, using a geographical traceroute tool such as geotraceroute, you can see that tracing this IP address from a location on the West cost of Canada will bring you to Seattle USA. When tracing from my location in southern Europe, it traces it to northern Italy. So you will never be too far away from this particular IP address.
Now there are other alternatives, and you can choose them based primarily on their reliability, as well as on the expected changes that may be made to them. For example, you shouldnât choose the IP address associated with www.facebook.com for example, because this may change constantly. It should be an address of a service that is expected to remain constant such as a DNS server. Any DNS IP address such as OpenDNS at 208.67.222.222, or Cloudflare at 1.1.1.1 are good options. You can also find the IP address of a telco that is local to your country. Other IP addresses that are good are NTP server IP addresses.
Hi Rene ,
I have question in this topic . the lab is working god with me but if i have inside LAN and all PC go outside through the router i use NAT on the Main interface if i shutdown this interface the route table changed to second line but the pc canât reach internet do you have any solution to this issues
thanks
If you are running NAT on your router, you will need some additional configurations to ensure that NAT translations will take place correctly once routing changes. You will need to create a couple of route maps to match IP addresses to the appropriate exit interface. You can find detailed information on how to configure this correctly at the following Cisco documentation:
Hi,
You would need to add a static route for the 200.xx.xx.xx.
If your primary route is through 192.xx.xx.33, then you need to add the following static route to tell your router that the host 200.xx.xx.xx is only reachable via the primary link, and this way you prevent the route flapping.
ip route 200.xx.xx.xx 255.255.255.255 190.xx.xx.33 1
without this static route, the IP SLA operation 123 will think that the primary link backs up when it start receiving icmp-reply through the backup route/link.
It all depends on what you want to achieve. The features described in this lesson are useful when you have multiple options for getting to a particular destination. Reliable static routing was applied to be able to deliver a redundant default route via two different ISPs.
In a scenario where you have HQ and a branch office, you will typically have one path to get to remote site. So reliable static routing wouldnât be helpful there.
However, if you have multiple paths, such as via two or more ISPs, then you can achieve the same redundancy by simply applying the same logic to the router that is connected to those multiple ISPs.
Any routing configuration that is applied to a router will affect the behavior of that particular router. So if you have an arrangement with a branch and HQ site, and if you want redundancy via reliable static routing in both directions, then you must configure it on both the HQ and the branch routers.
