EIGRP Router ID

Each EIGRP router has a unique 32-bit router ID (RID) number that is represented the same way as an IP address.

EIGRP automatically selects the highest IP address on any active loopback interface as the router ID. If there is no loopback interface then the highest IP address on any active interface is used. You can also overrule this by manually setting the router ID.




Even though each router should have a unique router ID, it doesn’t matter all that much. Two EIGRP routers with the same router ID will still form a neighbor adjacency. When we use OSPF, the router ID is important to know if you are digging in the OSPF LSDB. When we use EIGRP we don’t really care about the router ID, you don’t need to know it if you are looking at the topology table.

Something will go wrong though with duplicate router IDs. Before IOS 15.x, when an EIGRP router receives an external route (redistributed route) from a neighbor that has the same router ID then it will not accept it. It would still accepts regular internal routes that are advertised with the network command. Somewhere since IOS 15.x, the router will also refuse these internal routes.

This is an interesting scenario for a troubleshooting lab and difficult to figure out so let’s take a closer look at it.

Configuration

To demonstrate this, I’ll use the following two routers:

R1 R2 Two Loopbacks Behind R2

We only need two routers for this. R2 has a loopback interface that we will redistribute in EIGRP. Let’s look at a “normal” scenario first where we have unique router IDs.

EIGRP Unique router IDs

Let’s start with the EIGRP configuration:

R1(config)#router eigrp 12
R1(config-router)#no auto-summary 
R1(config-router)#network 192.168.12.0
R2(config)#router eigrp 12
R2(config-router)#no auto-summary              
R2(config-router)#network 192.168.12.0         
R2(config-router)#redistribute connected metric 1 1 1 1 1

Let’s check the router IDs of these routers:

R1#show ip eigrp topology | include ID
IP-EIGRP Topology Table for AS(12)/ID(192.168.12.1)
R2#show ip eigrp topology | include ID
IP-EIGRP Topology Table for AS(12)/ID(2.2.2.2)

R1 is using the IP address on its GigabitEthernet interface as the router ID, R2 is using the one on its loopback interface. Let’s verify that R1 has learned network 2.2.2.0 /24:

R1#show ip route eigrp 
     2.0.0.0/24 is subnetted, 1 subnets
D EX    2.2.2.0 [170/2560025856] via 192.168.12.2, 00:04:52, GigabitEthernet0/1

There it is as expected. This is how it should work…now let’s mess things up by using a duplicate router ID!

EIGRP Duplicate router IDs

Let’s change the router ID of R2 so that it’s the same as the one on R1:

R2(config)#router eigrp 12
R2(config-router)#eigrp router-id 192.168.12.1
R2#show ip eigrp topology 
IP-EIGRP Topology Table for AS(12)/ID(192.168.12.1)
R2#clear ip eigrp neighbors

Even though the router ID is the same, our routers will still become neighbors:

R1#show ip eigrp neighbors 
IP-EIGRP neighbors for process 12
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.12.2            Fa0/0             14 00:00:05   73   438  0  25

Unfortunately R1 no longer has network 2.2.2.0 /24 in its topology or routing table:

R1#show ip eigrp topology 
IP-EIGRP Topology Table for AS(12)/ID(192.168.12.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 192.168.12.0/24, 1 successors, FD is 281600
        via Connected, GigabitEthernet0/1
R1#show ip route eigrp
    

This issue might be hard to spot. You could check all the router IDs by looking at the EIGRP topology table of each router but if you don’t have access to the router that is doing the redistribution then you are out of luck. Maybe a debug will help?

R1#debug ip eigrp    
IP-EIGRP Route Events debugging is on
R1#clear ip eigrp neighbors 
IP-EIGRP(Default-IP-Routing-Table:12): Processing incoming UPDATE packet
IP-EIGRP(Default-IP-Routing-Table:12): ExtS 2.2.2.0/24 M 2560025856 - 2560000000 25856 SM 2560000256 - 2560000000 256

Our debug tells us that we received 2.2.2.0 /24, so this doesn’t help us; everything looks ok here. There is one hidden command, however that will give us the answer:

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

If you like to keep on reading, Become a Member Now!

  • 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 804 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)
464 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. Hi Mauro,

    This is indeed a pain to troubleshoot, it’s not the first thing you would think of. There’s a small chance that you would encounter this on a production network…it’s a typical troubleshooting scenario for a lab.

    More EIGRP material is on the way…

    Rene

  3. Hello Rene,

    Can you please elaborate, what does this command do

    redistribute connected metric 1 1 1 1 1

  4. Great lesson. Until now I always assumed that EIGRP router IDs had to be unique.
    And that it blocks redistributed routes is something that has to be seen to understand.

    Just ran through the lab in GNS 3 and it seams that in IOS 15.x the show ip eigrp events command is no longer “hidden”.

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