OSPF Router ID

One neighbour, three different numbers

R1 and R2 are routers connected by one Ethernet cable in area 0. R1’s Gi0/1 port uses 10.0.12.1/30; R2’s Gi0/0 uses 10.0.12.2/30. The /30 mask places both ports in subnet 10.0.12.0/30. The names Gi0/1 and Gi0/0 identify the physical interfaces; they do not have to match.

The RID is the router’s name inside OSPF. In this example R1 is 1.1.1.1 and R2 is 2.2.2.2. Although each looks like an IPv4 address, a manually configured RID does not have to be assigned to a port or respond to ping. R1’s neighbour table can therefore identify R2 as 2.2.2.2 while showing 10.0.12.2 in the Address column.

The process ID identifies a local OSPF configuration instance. R1 uses process 1 and R2 uses process 20; they can still become neighbours. Process IDs may differ, but two routers must not share an OSPF router ID. The RID also identifies the originator of an LSA, so duplicate identities can cause database and routing faults, not just a confusing display.

Which address will Cisco choose?

For the conventional IOS/IOS XE OSPFv2 selection model used here, an explicitly configured router-id takes precedence. Without it, the process selects the numerically highest eligible loopback IPv4 address; if there is no eligible loopback, it uses the highest eligible active interface IPv4 address. A loopback is a software interface, independent of a physical cable.

Suppose R1 has loopbacks 10.255.0.1 and 10.255.0.9, plus an active Ethernet address 192.0.2.1. With no explicit RID, the loopback choice is 10.255.0.9, even though the Ethernet address is numerically higher. Compare the address values, not interface numbers: Loopback100 does not win merely because 100 is larger than 0.

Automatic selection depends on the addresses available when selection occurs. Adding a higher address later is not a reliable way to change an existing identity. Set an explicit, unique RID before forming adjacencies, and inspect the effective ID rather than inferring it from the running configuration.

Configure the identity before the link joins OSPF

These OSPFv2 examples use Cisco IOS/IOS XE router syntax. Interface names depend on the lab image. Start with unused local processes in an isolated lab; the port addresses are already assigned and the interfaces are up. Both ends deliberately use the point-to-point OSPF network type, so no DR/BDR election is needed on this link.

router-id names the router; it does not assign an interface address. ip ospf 1 area 0 enables R1’s interface in process 1 and area 0. Keep the process number consistent within that router’s own configuration.

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:36    10.0.12.2       GigabitEthernet0/1

Read the row from R1’s viewpoint: Neighbor ID names R2, Address is R2’s interface IP and Interface is R1’s local port. FULL/– is the expected steady state for this point-to-point example. R1’s own RID is not the Neighbor ID in that row.

A duplicate RID: fix the identity, not the cable

If R2 was cloned from R1’s configuration, both may claim 1.1.1.1 even though their port addresses differ. Check show ip ospf on both routers and inspect the logs and database. Symptoms vary with the topology; a duplicate does not have one universal neighbour-state signature. Do not diagnose it solely from an empty neighbour table.

Record the current state, choose a unique replacement for R2 and plan for adjacency disruption. A RID change is an operational change, even if the CLI accepts it immediately.

Does a change need a restart?

Older IOS command documentation says an active process can retain its old RID until a restart or reload. Cisco’s IOS XE 17.x router guide documents immediate RID application from 17.13.1a, including with an active adjacency. Product families and supported behaviour differ, so check show version and the guide for that exact image.

Verify release behaviour and the effective RID before deciding whether a restart is needed. After the approved change, check the effective RID, neighbour recovery and routes. If an older lab image still uses the old RID and its documentation requires a restart, perform a scoped process restart during the planned interruption.

Confirm that R1 now lists R2’s new RID at the same interface address, that required neighbours return to Full and that destination and return routes recover. Do not repeatedly clear the process when the effective RID is already correct. A higher RID also does not pre-empt a working DR; the election lesson explains that separate decision.

Try it: prove which number changed

1. Build the two-router link above. Record each local process, effective RID and neighbour Address field.
2. Before starting a fresh, unused process in a separate lab, predict automatic selection from two loopbacks and an Ethernet IP. Check the prediction with show ip ospf.
3. For an approved RID-change exercise, record the software version and expected activation behaviour first. Change only R2’s explicit RID to 2.2.2.22; use a scoped restart only if that image requires it.
4. Verify that R1 sees the new neighbour ID while R2’s link IP remains 10.0.12.2. Restore the intended identity using the same release-aware procedure and verify recovery.

Check your reasoning

References and software scope

Protocol identity: RFC 2328. Cisco references: duplicate router IDs, IOS router-id command behaviour and IOS XE 17.x configuration and RID change note. Examples are authored teaching excerpts; verify the actual image before a lab change.