Reliable Static Routing with IP SLA


(Lazaros Agapides) #41

Hello Heng

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.

I hope this has been helpful!

Laz


(Heng S) #42

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


(Lazaros Agapides) #43

Hello 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 hope this has been helpful!

Laz


(Dominique R) #46

Hi Rene and staff,

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:

  1. 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

  2. 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


(Lazaros Agapides) #47

Hello Dominique

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:

Can you specify where in the lesson you see that the interface on R1 remains up?

I hope this has been helpful!

Laz