An EIGRP router ID is a 32-bit unique identifier assigned to each router in the EIGRP domain, represented in the same dotted-decimal format as an IPv4 address. This guide covers exactly how EIGRP selects a router ID automatically, how to configure one manually, a genuinely useful “sticky” behavior that catches people off guard when they add a new loopback interface later, and how the router ID actually gets used in preventing routing loops during redistribution.
This is a companion to The “router eigrp” Command, which covers enabling the EIGRP process itself before router ID selection ever comes into play.
How EIGRP Selects a Router ID Automatically
When no router ID has been manually configured, EIGRP determines one automatically, following a strict priority order:
- Highest active loopback interface IP address, if any loopback interfaces are configured.
- Highest active physical interface IP address, if no loopback interfaces exist.
A loopback interface is a virtual interface that automatically transitions to the up/up state the moment it’s configured — it has no physical cabling or neighboring device to depend on, which is exactly why it’s preferred: a loopback interface can’t fail the way a physical interface can if a cable is unplugged or a neighboring switch goes down. This makes a loopback-based router ID meaningfully more stable than one tied to a physical interface that could go down for reasons entirely unrelated to EIGRP itself.
Notably, a loopback interface does not need to be included in EIGRP’s network statements at all to be eligible as a router ID source — it only needs to exist and be in the up/up state. This is a small but easy-to-miss detail: an administrator can dedicate a loopback interface purely for router ID stability, without that loopback’s network ever actually being advertised through EIGRP.
To create a loopback interface for this purpose:
Router(config)# interface loopback <number>
Router(config-if)# ip address <ipv4-address> <subnet-mask>Manually Configuring the Router ID
The router ID can also be set explicitly, which takes priority over any automatically selected loopback or physical interface address:
Router(config)# router eigrp <autonomous-system>
Router(config-router)# eigrp router-id <ipv4-address>Some IOS versions also accept the shorter router-id command without the eigrp prefix, though using the explicit eigrp router-id form is generally clearer and less ambiguous, especially on a router also running other protocols that have their own router-id commands.
The value used for the router ID is any 32-bit number in dotted-decimal notation — it doesn’t need to correspond to a real, in-use IP address anywhere on the network, since it functions purely as an identifier, not an actual routable address. Two specific values are excluded: 0.0.0.0 and 255.255.255.255 cannot be used as a router ID. Whatever value is chosen, it must be unique across the entire EIGRP routing domain — a duplicate router ID between two routers can cause routes to be silently rejected rather than properly installed in the routing table.
The “Sticky” Router ID Behavior
Here’s a detail that catches a lot of people off guard: once EIGRP has selected a router ID — whether automatically or manually — it does not change on its own, even if circumstances that would otherwise produce a different selection change afterward. Specifically, if a router later gets a new loopback interface configured with a higher IP address than the one currently in use as the router ID, the router ID does not automatically update to the new, higher address, contrary to what the standard automatic-selection priority order might otherwise suggest.
This “sticky” behavior exists because changing a router ID mid-operation is disruptive — it effectively looks like a brand new router joining the domain from DUAL’s perspective, which can trigger unnecessary route recalculation and adjacency churn across the affected neighbors. To force a router ID to actually update after adding a new loopback (or after any other change that would otherwise produce a different automatic selection), the EIGRP process needs to be reset. The two ways to do this:
- Remove and re-add the EIGRP process with
no router eigrp <autonomous-system>followed by re-enabling it, which forces a completely fresh router ID selection. - Manually configure the router ID explicitly with
eigrp router-id <ipv4-address>, which immediately overrides whatever was previously in use, whether that was automatically selected or itself a different manual value.
Simply adding a new, higher-IP loopback interface and waiting is not enough on its own — the change won’t take effect until one of the two actions above actually happens.
Router ID and Route Loop Prevention
Beyond simply identifying a router, EIGRP’s router ID plays a direct role in preventing routing loops during redistribution. When a route is redistributed into EIGRP from another source (a static route, a connected route, or another routing protocol), it’s tagged with the router ID of the router that performed the redistribution. If that route later gets advertised back around the network and arrives at a router whose own router ID matches the one attached to the route, that router recognizes it as a route it originally injected and discards it — preventing the route from looping back on itself indefinitely.
This is exactly why duplicate router IDs cause real problems specifically with redistributed routes: if two different routers share the same router ID and both redistribute routes into EIGRP, a router receiving a redistributed route tagged with “its own” router ID (which actually belongs to a different physical router entirely) may incorrectly discard a legitimate route, believing it originated the route itself. This kind of failure can be subtle to diagnose, since the routers involved might otherwise appear to be functioning normally — the missing routes are the main symptom, without any obvious error message pointing directly at the router ID collision.
Verifying the EIGRP Router ID
show ip protocols displays the currently active router ID for each running routing process, including EIGRP:
Router# show ip protocols
Routing Protocol is "eigrp 1"
EIGRP-IPv4 Protocol for AS(1)
...
Router-ID: 1.1.1.1show ip eigrp neighbors and show ip eigrp topology also reference router IDs indirectly when displaying route origins, particularly useful when troubleshooting redistributed routes or checking for duplicate router IDs across the domain.
For EIGRP Named Mode, router ID configuration moves under the address-family block rather than being a direct router-configuration-mode command:
Router(config)# router eigrp <process-name>
Router(config-eigrp)# address-family ipv4 autonomous-system <as-number>
Router(config-eigrp-af)# eigrp router-id <ipv4-address>The underlying selection rules and priority — manual overrides automatic, loopback preferred over physical, and the sticky behavior described above — apply identically in Named Mode; only the configuration syntax location changes.
How This Compares to OSPF’s Router ID
Router IDs exist in both EIGRP and OSPF, and the selection rules are nearly identical — highest loopback address preferred, falling back to the highest physical interface address, with manual configuration always taking priority. The key difference is how much each protocol actually relies on the router ID for its core operation, rather than the mechanics of how the value itself is chosen in the first place. In OSPF, the router ID is fundamental to nearly everything: it identifies the originating router in every LSA, and mismatches or duplicates can cause serious adjacency and database synchronization problems.
In EIGRP, the router ID plays a narrower role — primarily loop prevention for redistributed routes, as covered above — and EIGRP’s neighbor relationships and normal route exchange rely more directly on IP addressing and the DUAL algorithm than on the router ID specifically. This is why EIGRP documentation sometimes describes the router ID as being used “for administrative purposes” rather than as a truly foundational part of the protocol’s core operation the way OSPF treats it.
Common Mistakes
Assuming a new, higher-IP loopback will automatically become the router ID. As covered above, this doesn’t happen without a process reset or manual reconfiguration — the existing router ID stays in place indefinitely otherwise.
Using duplicate router IDs across the EIGRP domain. While two EIGRP routers can sometimes still form a neighbor adjacency with duplicate router IDs, this creates real problems for redistributed routes and can cause routes to be silently discarded, since EIGRP uses the router ID to detect whether a route is looping back to its own originator. Treating router ID uniqueness as mandatory, not optional, avoids this entirely, and is a cheap habit to build into any deployment from the start.
Forgetting the router ID doesn’t need to be a real, routable address. Because it’s formatted like an IP address, it’s easy to assume it needs to correspond to something real on the network. It doesn’t — it’s purely an identifier, and many network designs deliberately use an address scheme for router IDs (like 1.1.1.1, 2.2.2.2, matching each router’s number) that’s never actually used for real traffic.
Frequently Asked Questions
What is an EIGRP router ID?
A unique 32-bit identifier assigned to each EIGRP-speaking router, displayed in the same dotted-decimal format as an IPv4 address, used to identify the originating router for routes and to detect potential routing loops.
How is an EIGRP router ID determined automatically?
EIGRP selects the highest IP address on any active loopback interface, if one exists. If no loopback interfaces are configured, it falls back to the highest IP address on any active physical interface.
Why does EIGRP need a router ID at all?
It uniquely identifies each router within the EIGRP autonomous system, and plays a role in detecting routing loops — if a router receives a route carrying its own router ID, it recognizes that route as having originated from itself and discards it rather than accepting a loop.
Can two EIGRP routers have the same router ID?
They technically can form neighbor adjacencies with duplicate router IDs in some circumstances, but this is not a supported best practice and can cause real problems, particularly with redistributed routes potentially being silently discarded. Router IDs should always be kept unique across the EIGRP domain.
If I add a new loopback interface with a higher IP address, will the router ID update automatically?
No. Once selected, a router ID is “sticky” and does not change on its own, even if a later change (like a new higher-IP loopback) would otherwise produce a different automatic selection. Forcing an update requires either resetting the EIGRP process or manually configuring the router ID directly.
How do you manually configure an EIGRP router ID?
Using the eigrp router-id <ipv4-address> command in router configuration mode (classic mode), or under the address-family block in Named Mode. A manually configured router ID always takes priority over whatever would otherwise be automatically selected.
Does the EIGRP router ID need to be a real IP address that exists somewhere on the network?
No. Despite being formatted like an IPv4 address, it functions purely as an identifier and doesn’t need to correspond to any actual interface or reachable address. Many network designs deliberately use a memorable, purpose-built scheme for router IDs (like 1.1.1.1 for R1, 2.2.2.2 for R2) specifically because it’s never used for real traffic and never needs to be.
Conclusion
EIGRP’s router ID selection follows a clear priority: manual configuration always wins, loopback interfaces are preferred over physical ones when nothing is manually set, and once a router ID is chosen — by either method — it stays fixed until the process is explicitly reset or reconfigured, regardless of what other interface changes happen afterward. Understanding this “sticky” behavior specifically saves real confusion when a newly added loopback interface doesn’t seem to be doing what might be expected, and knowing that router ID uniqueness matters across the whole domain, not just locally, helps avoid a subtle but real source of redistributed-route problems.
