[c-nsp] EIGRP feasible successors

Howard, Christopher Christopher-Howard at utc.edu
Fri Oct 3 10:03:21 EDT 2014


I'm hoping for some clarification as to whether I'm incorrect or my switch
is incorrect.

I have a switch (4500X) that has 3 different routes to another switch.
Two routes traverse 10G links and the other is a 1G link.  However,
traffic is getting transferred through the 1G link thanks to EIGRP.  I
think EIGRP is wrong.


First, the topology table says it has 3 successors, but only lists 2.  I
have filtered out to just one subnet, but there are others this way.

switch#sh ip eigrp vrf green topology
P 172.1.2.0/24, 3 successors, FD is 3072
        via 10.1.1.6 (3072/2816), Vlan910
        via 10.1.9.6 (3072/2816), Vlan2910


If I tell it to show me all links in the topology table, I can see the
third route.

switch#sh ip eigrp vrf green topology all-links
P 172.1.2.0/24, 3 successors, FD is 3072, serno 25436
        via 10.1.1.6 (3072/2816), Vlan910
        via 10.1.9.6 (3072/2816), Vlan2910
        via 10.1.5.3 (3328/3072), Vlan1910


Now, as I understand it, the first two routes are successors because they
have the lowest feasible distance.  The third route should not be
considered a feasible successor because the advertised distance is equal
to the feasible distance of the successors (the feasibility condition
explicitly states less than).  However, it appears that the switch is
considering this third route as a successor.


And worse, due to the use of the variance command, the switch is using the
third route as the active one.

switch#sh ip route vrf green 172.1.2.0
  Last update from 10.1.9.6 on Vlan2910, 3w5d ago
    10.1.9.6, from 10.1.9.6, 3w5d ago, via Vlan2910
      Route metric is 3072, traffic share count is 40
  * 10.1.5.3, from 10.1.5.3, 3w5d ago, via Vlan1910
      Route metric is 3328, traffic share count is 37
    10.1.1.6, from 10.1.1.6, 3w5d ago, via Vlan910
      Route metric is 3072, traffic share count is 40


I can remove the variance from EIGRP so that route will drop from the
route table, but am I incorrect in thinking that route should not be a
feasible successor in the first place?


-Christopher




More information about the cisco-nsp mailing list