×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

EIGRP feasible successor route failover

Answered Question
Nov 24th, 2013
User Badges:

Screen Shot 2013-11-24 at 23.51.28.png

Hi,


I created the topology above in GNS3. If i ping GNS002 from GNS001 and disable the interface of the successor route (s1/1 on R1) it takes 15 seconds to fail over. This is correct, because "show ip eigrp topology" doesn't shows R2 as a feasible route. So far so good.


Then i adjusted that by adding an access-list and offset-list on R1:

-----------

access-list 11 permit 10.0.3.0 0.0.0.255


router eigrp 1

passive-interface FastEthernet0/0

passive-interface FastEthernet0/1

offset-list 11 in 3 Serial1/1

network 10.0.0.0

auto-summary


-----------


Same on R3 for the path back with 10.0.1.0 instead of 10.0.3.0.


"show ip eigrp topology" now looks correct:

-----------

....

P 10.0.3.0/24, 1 successors, FD is 2195459

        via 10.0.100.6 (2195459/281600), Serial1/1

        via 10.0.100.2 (2707456/2195456), Serial1/0

....


-----------


But the time to fail over to the alternate route still is 15 seconds. In CCNP ROUTE cert guide i read:

"The elapsed time from noticing that the route failed, until the route is re- placed, is typically less than 1 second. (A Cisco Live conference presentation asserts this convergence approaches 200 milliseconds.)"


Did i misunderstood or forgot something?


Thank you

Urs

Correct Answer by Jon Marshall about 3 years 8 months ago

Urs


I suspect the issue is with return traffic from GNS002. When you shutdown the s1/1 interface on R1 then that router knows straight away the interface is down and will use the route via R2. R2 sends the packet to R3 and then R3 to GNS002.


But R3 does not yet realise that the R1 s1/1 is down. Serial interfaces use keepalives to determine whether the other end of the link is still up.  And because it takes 15 seconds i suspect what is happening is that the EIGRP hold timer is expiring first ie. on serial point to point links the EIGRP timers are 5 seconds for the hello packets and 15 seconds for the hold time (ie. 3 x the hello interval). So before R3 has realised that the link is down the hold timer expires and EIGRP then uses the R3 -> R2 link.


Notice that with and without a feasible successor it still took about the same time. This is probably because you have a very small network in your example so there is little difference between transitioning to the feasible successor route and having to query for a new route first.


A way to verify whether this is the issue is to shutdown the s1/1 interface on R1 and run a traceroute from GNS001 and see if it goes R1 -> R2 -> R3 and then what happens on the return path. If it is failing at R3 then i suspect the above is the problem.


You could play around with the keepalives on the serial interfaces and/or the hello and hold time for EIGRP and you may see a difference but you may not.  Because  your setup only involves 3 routers and if you look at the topology you can see that R1 and R3 even without feasible successors only ever have to send a query to R2 to get a response because R2 never loses it's routes to 10.0.1.0/24 and 10.0.3.0/24. In larger networks with multiple redundant paths you do indeed see the benefit of having feasible successors in the topology table.


What you should do is run debugging on the EIGRP process while doing this on all routers to see exactly what is happening and when.


Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Jon Marshall Sun, 11/24/2013 - 17:23
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Urs


I suspect the issue is with return traffic from GNS002. When you shutdown the s1/1 interface on R1 then that router knows straight away the interface is down and will use the route via R2. R2 sends the packet to R3 and then R3 to GNS002.


But R3 does not yet realise that the R1 s1/1 is down. Serial interfaces use keepalives to determine whether the other end of the link is still up.  And because it takes 15 seconds i suspect what is happening is that the EIGRP hold timer is expiring first ie. on serial point to point links the EIGRP timers are 5 seconds for the hello packets and 15 seconds for the hold time (ie. 3 x the hello interval). So before R3 has realised that the link is down the hold timer expires and EIGRP then uses the R3 -> R2 link.


Notice that with and without a feasible successor it still took about the same time. This is probably because you have a very small network in your example so there is little difference between transitioning to the feasible successor route and having to query for a new route first.


A way to verify whether this is the issue is to shutdown the s1/1 interface on R1 and run a traceroute from GNS001 and see if it goes R1 -> R2 -> R3 and then what happens on the return path. If it is failing at R3 then i suspect the above is the problem.


You could play around with the keepalives on the serial interfaces and/or the hello and hold time for EIGRP and you may see a difference but you may not.  Because  your setup only involves 3 routers and if you look at the topology you can see that R1 and R3 even without feasible successors only ever have to send a query to R2 to get a response because R2 never loses it's routes to 10.0.1.0/24 and 10.0.3.0/24. In larger networks with multiple redundant paths you do indeed see the benefit of having feasible successors in the topology table.


What you should do is run debugging on the EIGRP process while doing this on all routers to see exactly what is happening and when.


Jon

urs.weiss Mon, 11/25/2013 - 11:43
User Badges:

Hi Jon


Thanks for the detailed explanation.

At the beginning i removed the serial link completely, but had the same effect. Just shutdown the interface because it was done faster.


You're correct with the keepalive of the serial link.

keepalive 10 (default) => 15s until failover

keepalive 3 => 12s

keepalive 1 => 5s

Actions

This Discussion

Related Content