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

    ------------------------------------------------------

     


    Rack1R2#sh ver | i IOS

    Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(19), RELEASE SOFTWARE (fc1)

    Rack1R2#








    think its a bug.

     

     

     

  • 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


  •  

    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.

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

    Ahhh come on how many beers did you have?? ;) ... just kidding

     

    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:

    .

    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!

     

     

     

     

     

     

  • the prefix with one of them is feasible successor? My impression is that when you shutdown the primary link, FD was not updated immediately

    Generally it happens almost immediately without any delay.

  •  

    Ahhh come on how many beers did you have?? ;) ... just kidding

    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.

     

  • no drinking period , till i get my #

    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.

     

    and beer is for babies my friend..and college kids...

    Depends on how much of beer you drink :D. I´m from Germany, Beer is like water for us ;).

     

    Regards!

     

     

  • 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!

    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!

  • 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! :-)

Sign In or Register to comment.