EIGRP Router ID

Lessons Discussion
1

This topic is to discuss the following lesson:

2

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

1 Like
3

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

1 Like
4

Hello Rene,

Can you please elaborate, what does this command do

redistribute connected metric 1 1 1 1 1

5

Hi Sahil,

This redistributes directly connected interfaces into EIGRP. When you configure redistribution, you have to manually configure the metric that you want to use.

These examples might be helpful:

Introduction to redistribution

Redistribution between EIGRP and RIP

Rene

6

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

1 Like
7

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

1 Like
8

Hi Rene,

I did a Lab, and configured the same Router ID on both routers, I ran “clear ip eigrp neig”, but the srouters continue to learn routes with same router ID in both.

image
image.png788×129 4.93 KB

image
image.png788×123 4.98 KB

image
image.png911×87 3.74 KB

image
image.png950×222 8.42 KB

Thx


9

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

10

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.

11

Hi,

In the lesson, you stated that this issue is seen with redistribution but at lab I used only ‘network 2.2.2.2 0.0.0.0’ not redistribution and R1 again can not learn the route? Can we say when the eigrp router ids’ are same, there is no way to learn a route from the neigbor router?

Router2#sh run | s r ei
router eigrp 12
 network 2.2.2.2 0.0.0.0
 network 192.168.12.0
 eigrp router-id 192.168.12.1
Router2#
Router2#sh ip ei
Router2#sh ip eigrp topo
EIGRP-IPv4 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, Ethernet0/0
P 2.2.2.0/24, 1 successors, FD is 128256
        via Connected, Loopback0



Router1#sh run | s r ei
router eigrp 12
 network 192.168.12.0
Router1#
Router1#sh ip ei
Router1#sh ip eigrp topo
EIGRP-IPv4 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, Ethernet0/0

Router1#
Router1#sh ip rou ei
Router1#sh ip rou eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

Router1#

regards,

12

Hello Murat

I believe that the problem here is the wording used. When Rene says that

“
if you don’t have access to the router that is doing the redistribution then you are out of luck.”

he is not referring to redistribution from one routing protocol to another. You are right that there is no redistribution here. What he means here is that if you are not looking at the specific router that is the original source of the information about that particular network, namely 2.2.2.2/32, which redistributes, or informs other routers about its existence, then you are out of luck.

I hope this has been helpful!

Laz

13

but just to confirm in this example there was no need to use “metric 11111” command right?
Am I right in saying that all was required was “redistribute connected” ?

14

Hello Joseph

Yes you are correct, the metric values are not mandatory. Depending on which routing protocol you are redistributing into, the default metric value will be used if it is not specified. You can find out more about this command at this Cisco command reference.

I hope this has been helpful!

Laz

15

Nice lesson thanks Rene. I labbed this, and even internal routes are being blocked. 22.22.22.22/32 is another loopback on R2.

R1#show run | sec eigrp
router eigrp 12
 network 192.168.12.0

R2#show run | sec eigr
router eigrp 12
 network 22.22.22.22 0.0.0.0
 network 192.168.12.0
 redistribute connected metric 1 1 1 1 1
 eigrp router-id 192.168.12.1

R1#show ip route eigrp | begin Gate
Gateway of last resort is not set

R1#

R1#show ip eigrp events
Event information for AS 12:
1    07:58:07.944 Ignored route, metric: 22.22.22.22/32 metric(409600)
2    07:58:07.944 Ignored route, dup routerid int: 192.168.12.1
3    07:58:07.944 Ignored route, metric: 2.2.2.0/24 metric(2560025856)
4    07:58:07.944 Ignored route, neighbor info: 192.168.12.2 Ethernet0/0
5    07:58:07.944 Ignored route, dup routerid ext: 192.168.12.1
16

Hello Bhawandeep.

This rule used to apply only to external routes but it later got changed to both internal + external. So both routes will be blocked if the RID is the same.

This came around the 15.x version where the RID became also relevant for internal routes. Maybe the lesson could be updated to include this information?

David

17

Hello Bhawandeep

@davidilles is correct. Here is a quote from the CCIE Routing and Switching v5.0 Official Cert Guide. It’s an older cert guide, but the comments it states are valid:

Originally, the primary use of the EIGRP RID has been to prevent routing loops in EIGRP environments using redistribution. The RID identifies the originating router for external routes injected into the EIGRP domain. Each external route was attached the RID of the router that redistributed it into EIGRP. If an external route is received with the same RID as the local router, the route is discarded. This feature is designed to reduce the possibility of routing loops in networks where route redistribution is being performed on more than one router. EIGRP RID was not originally advertised with internal routes.

With recent IOS releases, however, the EIGRP RID is also advertised with internal routes. As a result, each route advertised in EIGRP, internal or external, carries the RID of the router that injected it into EIGRP. The logic of using the RID remains the same—a router will discard every received route carrying the router’s own RID.

I will suggest to Rene that he update the lesson accordingly.

I hope this has been helpful!

Laz

1 Like
18

Thanks for following up on this

1 Like
19

Hi René/Laz
Great Article. I’m doing this lab on v8000 on EVE-NG and the redistribute connected doesn’t work for Loopback interfaces. It is working great for physical interfaces, but I do not manage to get the loopback redistribute

R1

hostname R1
interface GigabitEthernet1
 ip address 192.168.12.1 255.255.255.0
router eigrp 1
 network 192.168.12.0
 eigrp router-id 1.1.1.1

R2

hostname R2
interface Loopback0
 ip address 2.2.2.1 255.255.255.0
interface GigabitEthernet1
 ip address 192.168.12.2 255.255.255.0
interface GigabitEthernet3
 ip address 192.168.255.1 255.255.255.0
router eigrp 1
 network 192.168.12.0
 redistribute connected metric 1 1 1 1 1
 eigrp router-id 2.2.2.2

Verification

R1#sh ip route eigrp 
[...]
D EX  192.168.255.0/24 
           [170/2560000512] via 192.168.12.2, 00:05:15, GigabitEthernet1

As you see, the network of the loopback interface is missing. Am I missing something, or is it maybe due to the virualization?

Thanks, CĂ©dric

20

Hello CĂ©dric

That’s interesting. The redistribute connected command under EIGRP should include the loopback interfaces well. Try including the loopback networks using the network command and see what happens.

Try it out and let us know


I hope this has been helpful!

Laz