EIGRP connundrum?????? EDIT*** BUG found***
sometimes i wanna punch EIGRP in the face....true story...
Rack1R1#show ip eigrp top 155.1.9.0/24
IP-EIGRP (AS 100): Topology entry for 155.1.9.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 5632 <<<<<<<whats this?? why does it not match?????
Routing Descriptor Blocks:
155.1.13.3 (Serial0/1), from 155.1.13.3, Send flag is 0x0
Composite metric is (515072/3072), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20120 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Rack1R1#sh ip route | i 155.1.9.0
D 155.1.9.0 [90/515072] via 155.1.13.3, 00:32:16, Serial0/1
why is the FD showing up as the wrong FD in that command????
Rack1R1#sh ver | i IOS
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(19), RELEASE SOFTWARE (fc1)
Comments
Rack1R2#sh ip route 150.1.4.0
Routing entry for 150.1.4.0/24
Known via "eigrp 100", distance 90, metric 1152000, type internal
Redistributing via eigrp 100, rip
Advertised by rip metric 1
Last update from 155.1.0.5 on Serial0/0.1, 02:06:49 ago
Routing Descriptor Blocks:
* 155.1.0.5, from 155.1.0.5, 02:06:49 ago, via Serial0/0.1
Route metric is 1152000, traffic share count is 1
Total delay is 45000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
--------------------------------------------------------------
Rack1R2#sh ip route | i 150.1.4.0
D 150.1.4.0 [90/1152000] via 155.1.0.5, 02:08:15, Serial0/0.1
------------------------------------------------------------------------------
Rack1R2#show ip eigrp top
Rack1R2#show ip eigrp topology 150.1.4.0/24
IP-EIGRP (AS 100): Topology entry for 150.1.4.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 645376
Routing Descriptor Blocks:
155.1.0.5 (Serial0/0.1), from 155.1.0.5, Send flag is 0x0
Composite metric is (1152000/640000), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 45000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Well...sound a little newbie like, but have you saved the config and reloaded the machine to see if it is still there?
Did you clear the eigrp neighbors?
Have you deconfigured eigrp and reconfigured it again?
Regards!
no..yes...no
if you notice its 2 different routers that are doing it..with the specific IOS
the other routes in my topology are running the T train and are working normally...
besides the effect seems to be cosmetic only...
Well even though its cosmetic its interesting
.
Ok 2 different machines, same problem, same ios.
Well I searched the bug toolkit for any bugs here...but nothing found that is concerning this problem. Maybe it is a new one or the machine just got weird.
EDIT: Try rebooting it (if it is possible and not a production router) and share your experience. That´ll be nice!
i did not do ANYTHING...i didn't even reload...i ws just doing other tasks and taking notes..and..well ya see..now it seems to be working fine...wierd..
Rack1R1#show ip eigrp 100 topology 155.1.9.0/24
IP-EIGRP (AS 100): Topology entry for 155.1.9.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1024
Routing Descriptor Blocks:
155.1.13.3 (Serial0/1), from 155.1.13.3, Send flag is 0x0
Composite metric is (1024/768), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 40 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Did you have two paths to reach the prefix with one of them is feasible successor? My impression is that when you shutdown the primary link, FD was not updated immediately.
Ahhh come on how many beers did you have??
... just kidding
.Well If there was a feasible successor then this would have been in the output before or am I wrong with that? Well there is no information that there is a feasible successor but if within the topology there is the information "1 successor" and ohter paths are listed, then the other paths are feasible successors.
Like this:
P 172.16.1.0/24, 1 successors, FD is 2585600
via Connected, Ethernet2/0
via 172.16.31.2 (286720/284160), FastEthernet1/1
via 172.16.0.2 (284160/281600), FastEthernet1/0
R1#sh ip eigrp top 1 172.16.1.0/24
IP-EIGRP (AS 1): Topology entry for 172.16.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2585600
Routing Descriptor Blocks:
<< output shortened>>
172.16.31.2 (FastEthernet1/1), from 172.16.31.2, Send flag is 0x0
Composite metric is (286720/284160), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 1200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
172.16.0.2 (FastEthernet1/0), from 172.16.0.2, Send flag is 0x0
Composite metric is (284160/281600), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 1100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Regards and good night!
Generally it happens almost immediately without any delay.
no drinking period , till i get my #
and beer is for babies my friend..and college kids...
then you grow up and drink good scotch! :-)
on the above problem....i power offed my lab...i shall try that question again first thing in the morning and see if the problem re occurs...
Hi all,
This is not BUG, it is just EIGRP feature. So while the successor FD gets modified in the topology table, in the first line, where the prefix is shown, it still shows the old FD. It is written in many EIGRP books. Why, after a while, it gets updated? Cause the EIGRP cleaner process comes into play and also updates that value. Three of the books were this is written are: EIGRP Design, Routing Protocols Troubleshooting and CCIE RS Certification Guide (version i don't remember)
Good luck with your studies!
Thanks cristian for the answer! I havent read it yet, but I think thats one of those small details one does not really care about if you didnt ran into this issue / feature until that point of time.
http://goo.gl/PKLbu
Well...I think this period is quite long isnt it? At least for me it will. So sometimes a small chemical reset is not the worst thing one can do.
Depends on how much of beer you drink
. I´m from Germany, Beer is like water for us 
.
Regards!
ooo..great!
Thankyou Christian! My only source of EIGRP is Doyle. It showed the old FD for quite a while...ads in longer than 10 minutes...but live and learn huh!
Thankyou again! :-)
i STILL think its a bug though...disguised as a feature...what would be the point of keeping the old FD and displaying it?
to actively confuse and annoy people?
Hi,
So you can see the old FD and the new FD for a while, within one command! This is the way it was build.
Good luck with your studies!
lol Thanx man!
next time i hurt myself i'll tell myself i did it on purpose, just to check that my pain receptors are functioning properly! i shall even write a book about it to validate that claim!
one can simply write the old FD down if needed! the newer T train IOSes dont seem to do this!
but Cisco's games aside...again you came thru with an obascure answer that few if any probably know and for that i'm grateful! :-)