We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 642 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

470 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Great stuff Rene,

    This tshoot is the ones to push our hairs out. Is very hard to spot. But on the other hand is very hard for 2 neighbors to have the same ID. But the debug was a Abracadabra on this story. Nice article. Will wait for more on eigrp if there is more. :slight_smile:

    Mauro P

  2. This is why I signed up for this site. “show ip eigrp events” is very useful.
    Thanks Rene and Laz for your contents

  3. Hello Fabio

    This is expected behaviour. Like Rene mentioned in the lab, unlike OSPF, EIGRP doesn’t care if it the router ID is the same or not. It will still exchange routes normally and will function correctly.

    The only exception to this rule is when we have an external or redistributed route. If R1 for example receives such an external route from R2 (which is running a second routing protocol such as OSPF for example), and if R1 and R2 have the same router ID, only then will R1 reject the route from R2.

    I hope this has been helpful!

    Laz

  4. Hello @fabio.hperez85, to test the issue of having same router IDs, you can create a loopback1 on R1 and redistribute it into eigrp (not advertising it):

    int lo1
    ip add 11.11.11.11 255.255.255.0
    exit
    
    router eigrp 1
    redistribute connected
    exit
    

    If you run **show ip route eigrp** on R2, you won’t see this loopback 1 installed.

4 more replies! Ask a question or join the discussion by visiting our Community Forum