EIGRP feasible successor route failover

[urs.weiss]

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

[Jon Marshall · Accepted solution]

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]

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