↓ Skip to main content
KAZULOG.INFO
  1. Network Articles/
  2. OSPF Articles/

OSPF Router ID

Table of Contents

What Is the OSPF Router ID

OSPF exchanges the LSAs generated by each router across the area so that every router holds the same LSDB (topology map) and computes the shortest paths from it (see What Is OSPF for how this works). The router ID is the 32-bit value used to identify “which router generated this LSA” and “which node on the topology map this is”. It is written in the same dotted-decimal notation as an IPv4 address (for example 1.1.1.1), but it is merely an identifier, not an IP address, and the value does not need to be reachable.

The router ID is used throughout OSPF.

UseDescription
Origin of LSAsThe Advertising Router field in the header of every LSA. In a Router-LSA (Type 1) the Link State ID is also the router ID.
Hello packetsThe Router ID field in the OSPF header, and the neighbor list carried in Hellos. Neighbors are identified by this value.
DR/BDR electionWhen priorities are equal, the router with the higher router ID becomes the DR.
Master/slave for LSDB synchronizationIn the ExStart state, the router with the higher router ID becomes the master.
show command outputNeighbor ID in show ospf neighbor, Link ID / ADV Router in show ospf database, and so on.

The router ID must be unique within the OSPF domain. If two routers share the same router ID, contradictory LSAs from the “same” origin circulate, the topology map breaks, and routes can no longer be computed correctly.

The tests in this article use the same linear topology (Cisco IOS XR, XRd) as What Is OSPF to check how R1’s router ID is determined and when it changes. During the tests, Loopback1 (11.11.11.11/32), whose address is higher than Loopback0 (1.1.1.1), is added to R1.

Router ID Selection Order

OSPF on Cisco IOS XR determines the router ID in the following order when the process initializes (from the Cisco IOS XR Routing Configuration Guide - Implementing OSPF).

PriorityHow the router ID is determined
1The router ID previously in use, saved in the checkpointing database (consulted when the process restarts)
2The value explicitly configured with the router-id command under router ospf
3The router ID selected by ITAL (the interface information management function of IOS XR). It is chosen from the IPv4 addresses of loopback interfaces that are up; if there is no loopback, an address of a physical interface is used
4The primary IPv4 address of the first interface on which OSPF is enabled
We recommend configuring the router ID explicitly with the router-id command. If you leave it to automatic selection, which address is chosen depends on the platform (IOS XE and IOS XR differ), on the state of the interfaces, and on the previous value, and the router ID can change unexpectedly when an interface is added or removed or the process is restarted, causing adjacencies to be re-established and routes to be lost. Cisco’s documentation also recommends setting it with the router-id command.

On IOS XE the order is “explicit setting → the highest IPv4 address among loopbacks that are up → the highest address among physical interfaces”, but IOS XR works differently, as shown above. In the test environment for this article (XRd 26.1.1), rebooting the router with both Loopback0 (1.1.1.1) and Loopback1 (11.11.11.11) up selected the lower address, 1.1.1.1. In addition, once a router ID was determined it was saved in the checkpointing database and carried over across OSPF process restarts as long as the value remained valid (as long as the interface it came from stayed up). Both behaviors differ from IOS XE. The configuration commands will be covered in IOS XR OSPF Configuration and IOS XE OSPF Configuration.

When the Router ID Changes

How the router ID changes depends on whether it is configured explicitly.

  • When the router ID is configured or changed explicitly with the router-id command, IOS XR applies the new router ID as soon as the change is committed (no process restart is required).
  • An automatically selected router ID does not change on the spot when the interface it came from is later joined by another (for example, when a loopback with a lower address is added). On IOS XE, restarting the OSPF process with clear ip ospf process re-selects the router ID, but on IOS XR, restarting with clear ospf process does not change it as long as the previous value saved in the checkpointing database is still valid, because that value takes precedence. It is re-selected only when the process restarts while the interface that provided the previous value is down.

In either case, a router whose router ID has changed flushes all the LSAs it generated under the old router ID (setting them to MaxAge so they are deleted) and regenerates its LSAs under the new router ID. Its adjacencies with neighbors also go Down and are re-established, so a router ID change must be planned as work that involves a routing outage.

Verification on Real Devices

Checking the Current Router ID

The first line of show ospf shows the router ID the OSPF process is using. On R1, router-id 1.1.1.1 is configured explicitly.

R1 checking the router ID
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Thu Sep  3 14:29:29.074 UTC
 Routing Process "ospf 1" with ID 1.1.1.1
RP/0/RP0/CPU0:R1#show running-config router ospf
Thu Sep  3 14:29:29.892 UTC
router ospf 1
 router-id 1.1.1.1
 area 0
  interface Loopback0
   passive enable
  !
  interface GigabitEthernet0/0/0/0
  !
  interface GigabitEthernet0/0/0/1
  !
 !
!

Removing the Explicit Setting and Adding Loopback1

Remove the router-id configuration from R1 and, at the same time, add Loopback1 (11.11.11.11/32), whose address is higher than Loopback0 (1.1.1.1). Loopback1 is not enabled for OSPF.

R1 configuration applied
router ospf 1
 no router-id
!
interface Loopback1
 ipv4 address 11.11.11.11 255.255.255.255
!

The router ID immediately after the commit, and the neighbor state as seen from R2, are shown below.

R1 after removing router-id and adding Loopback1
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Thu Sep  3 14:30:25.793 UTC
 Routing Process "ospf 1" with ID 1.1.1.1
RP/0/RP0/CPU0:R1#show running-config router ospf
Thu Sep  3 14:30:26.788 UTC
router ospf 1
 area 0
  interface Loopback0
   passive enable
  !
  interface GigabitEthernet0/0/0/0
  !
  interface GigabitEthernet0/0/0/1
  !
 !
!
RP/0/RP0/CPU0:R1#show ipv4 interface brief
Thu Sep  3 14:30:27.568 UTC

Interface                      IP-Address      Status          Protocol Vrf-Name
Loopback0                      1.1.1.1         Up              Up       default 
Loopback1                      11.11.11.11     Up              Up       default 
MgmtEth0/RP0/CPU0/0            unassigned      Shutdown        Down     default 
GigabitEthernet0/0/0/0         10.1.2.1        Up              Up       default 
GigabitEthernet0/0/0/1         10.1.3.1        Shutdown        Down     default 
GigabitEthernet0/0/0/2         unassigned      Shutdown        Down     default
R2 checking neighbors
RP/0/RP0/CPU0:R2#show ospf neighbor
Thu Sep  3 14:30:35.736 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1         1     FULL/BDR        00:00:35    10.1.2.1        GigabitEthernet0/0/0/0
    Neighbor is up for 00:02:37
3.3.3.3         1     FULL/DR         00:00:30    10.2.3.3        GigabitEthernet0/0/0/1
    Neighbor is up for 00:02:30

Total neighbor count: 2

Even after the explicit setting is removed and a loopback with a higher address is added, the router ID of the running OSPF process stays 1.1.1.1. The Neighbor ID seen from R2 is unchanged, and the adjacency is not affected.

Rebooting the Router

If R1 is rebooted in this state, the OSPF process determines the router ID afresh at startup. With both Loopback0 (1.1.1.1) and Loopback1 (11.11.11.11) up at boot, the address selected was the lower one, Loopback0’s 1.1.1.1.

R1 after reboot
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Fri Sep  4 22:56:55.130 UTC
 Routing Process "ospf 1" with ID 1.1.1.1
RP/0/RP0/CPU0:R1#show ipv4 interface brief
Fri Sep  4 22:56:56.563 UTC

Interface                      IP-Address      Status          Protocol Vrf-Name
Loopback0                      1.1.1.1         Up              Up       default 
Loopback1                      11.11.11.11     Up              Up       default 
MgmtEth0/RP0/CPU0/0            unassigned      Shutdown        Down     default 
GigabitEthernet0/0/0/0         10.1.2.1        Up              Up       default 
GigabitEthernet0/0/0/1         10.1.3.1        Shutdown        Down     default 
GigabitEthernet0/0/0/2         unassigned      Shutdown        Down     default

If the “highest loopback address” were chosen, as on IOS XE, the result would be 11.11.11.11, but that is not what IOS XR does. Because the outcome of automatic selection differs by platform, it should not be relied on.

Restarting the OSPF Process (Both Loopbacks Up)

Restart the OSPF process with clear ospf 1 process. IOS XR shows a confirmation prompt, which is answered with yes.

R1 clear ospf process (both loopbacks up)
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Fri Sep  4 23:34:51.485 UTC
 Routing Process "ospf 1" with ID 1.1.1.1
RP/0/RP0/CPU0:R1#clear ospf 1 process
Fri Sep  4 23:34:54.865 UTC
Reset OSPF process 1? [no]: yes
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Fri Sep  4 23:36:16.613 UTC
 Routing Process "ospf 1" with ID 1.1.1.1

The router ID remains 1.1.1.1 even after the process restart. This is because the previous value saved in the checkpointing database was carried over; the adjacency goes Down once and is re-established with the same router ID.

R1 neighbor change log
RP/0/RP0/CPU0:R1#show logging | include OSPF
Fri Sep  4 23:36:17.551 UTC
RP/0/RP0/CPU0:Sep  4 23:25:16.454 UTC: ospf[1035]: %ROUTING-OSPF-5-HA_NOTICE_START : Starting OSPF 
RP/0/RP0/CPU0:Sep  4 23:25:19.744 UTC: ospf[1035]: %ROUTING-OSPF-6-HA_INFO : Process 1: OSPF process initialization complete 
RP/0/RP0/CPU0:Sep  4 23:25:20.045 UTC: ospf[1035]: %ROUTING-OSPF-5-HA_NOTICE : Process 1: Signaled PROC_AVAILABLE 
RP/0/RP0/CPU0:Sep  4 23:26:20.057 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:Sep  4 23:34:54.977 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from FULL to DOWN, Neighbor Down: interface down or detached, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:Sep  4 23:35:03.393 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000

Shutting Down Loopback0 and Restarting the Process

Shut down Loopback0, the source of the router ID, and then restart the process once more. Shutting the interface down alone does not change the router ID; after the restart it changed to 11.11.11.11, the address of Loopback1, which is still up.

R1 Loopback0 shutdown → clear ospf process
RP/0/RP0/CPU0:R1#show ipv4 interface brief
Fri Sep  4 23:37:47.169 UTC

Interface                      IP-Address      Status          Protocol Vrf-Name
Loopback0                      1.1.1.1         Shutdown        Down     default 
Loopback1                      11.11.11.11     Up              Up       default 
MgmtEth0/RP0/CPU0/0            10.100.22.1     Up              Up       Mgmt    
GigabitEthernet0/0/0/0         10.1.2.1        Up              Up       default 
GigabitEthernet0/0/0/1         10.1.3.1        Shutdown        Down     default 
GigabitEthernet0/0/0/2         unassigned      Shutdown        Down     Mgmt    
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Fri Sep  4 23:37:47.487 UTC
 Routing Process "ospf 1" with ID 1.1.1.1
RP/0/RP0/CPU0:R1#clear ospf 1 process
Fri Sep  4 23:37:48.370 UTC
Reset OSPF process 1? [no]: yes
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Fri Sep  4 23:37:48.604 UTC
 Routing Process "ospf 1" with ID 11.11.11.11

On the R2 side, the neighbor relationship with R1 went Down with the reason “Neighbor router id change”, and immediately afterwards the re-establishment of the adjacency began with R1 as a new neighbor with router ID 11.11.11.11. The Router-LSA with the old router ID 1.1.1.1 has been flushed from the LSDB and is gone.

R2 right after the router ID change
RP/0/RP0/CPU0:R2#show logging | include ADJCHG
Fri Sep  4 23:38:22.864 UTC
RP/0/RP0/CPU0:Sep  4 23:26:20.060 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0/0/0 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:Sep  4 23:26:25.810 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0/0/1 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:Sep  4 23:35:03.396 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0/0/0 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:Sep  4 23:37:48.566 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0/0/0 in area 0 from FULL to DOWN, Neighbor Down: Neighbor router id change, vrf default vrfid 0x60000000
RP/0/RP0/CPU0:R2#show ospf neighbor
Fri Sep  4 23:38:21.135 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface
11.11.11.11     1     EXSTART/BDR     00:00:34    10.1.2.1        GigabitEthernet0/0/0/0
    Neighbor is up for 00:00:23
3.3.3.3         1     FULL/DR         00:00:39    10.2.3.3        GigabitEthernet0/0/0/1
    Neighbor is up for 00:12:26

Total neighbor count: 2
RP/0/RP0/CPU0:R2#show ospf database
Fri Sep  4 23:38:22.003 UTC


            OSPF Router with ID (2.2.2.2) (Process ID 1)

		Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         34          0x80000007 0x006062 3
3.3.3.3         3.3.3.3         717         0x80000003 0x0004d3 2

		Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.2.3.3        3.3.3.3         717         0x80000001 0x0046c1

Once the adjacency has been re-established, R2 shows the neighbor 11.11.11.11 in the Full state, and the Router-LSA with the new router ID is registered in the LSDB.

R2 after the adjacency is re-established
RP/0/RP0/CPU0:R2#show ospf neighbor
Fri Sep  4 23:39:45.835 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface
11.11.11.11     1     FULL/BDR        00:00:35    10.1.2.1        GigabitEthernet0/0/0/0
    Neighbor is up for 00:01:48
3.3.3.3         1     FULL/DR         00:00:32    10.2.3.3        GigabitEthernet0/0/0/1
    Neighbor is up for 00:13:51

Total neighbor count: 2
RP/0/RP0/CPU0:R2#show ospf database
Fri Sep  4 23:39:46.678 UTC


            OSPF Router with ID (2.2.2.2) (Process ID 1)

		Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         78          0x80000008 0x00d4dc 3
3.3.3.3         3.3.3.3         802         0x80000003 0x0004d3 2
11.11.11.11     11.11.11.11     79          0x80000002 0x00b903 1

		Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.2.2        2.2.2.2         78          0x80000001 0x0017d7
10.2.3.3        3.3.3.3         802         0x80000001 0x0046c1

Bringing Loopback0 Back and Restarting the Process

Bring Loopback0 back with no shutdown and restart the process once more with both loopbacks up. This time the router ID stays 11.11.11.11 and does not return to Loopback0’s 1.1.1.1.

R1 Loopback0 no shutdown → clear ospf process
RP/0/RP0/CPU0:R1#show ipv4 interface brief
Fri Sep  4 23:40:16.154 UTC

Interface                      IP-Address      Status          Protocol Vrf-Name
Loopback0                      1.1.1.1         Up              Up       default 
Loopback1                      11.11.11.11     Up              Up       default 
MgmtEth0/RP0/CPU0/0            10.100.22.1     Up              Up       Mgmt    
GigabitEthernet0/0/0/0         10.1.2.1        Up              Up       default 
GigabitEthernet0/0/0/1         10.1.3.1        Shutdown        Down     default 
GigabitEthernet0/0/0/2         unassigned      Shutdown        Down     Mgmt    
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Fri Sep  4 23:40:16.416 UTC
 Routing Process "ospf 1" with ID 11.11.11.11
RP/0/RP0/CPU0:R1#clear ospf 1 process
Fri Sep  4 23:40:17.273 UTC
Reset OSPF process 1? [no]: yes
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Fri Sep  4 23:40:17.468 UTC
 Routing Process "ospf 1" with ID 11.11.11.11

When the router ID was 1.1.1.1 before the restart it stayed 1.1.1.1 afterwards, and when it was 11.11.11.11 it stayed 11.11.11.11. This is the behavior in which the previous router ID saved in the checkpointing database takes top priority: an automatically selected router ID is carried over across process restarts as long as the interface it came from is up. It is re-selected only when the process starts while that interface is down.

Configuring router-id Explicitly

With the router ID at 11.11.11.11, configure router-id 1.1.1.1 explicitly.

R1 configuration applied
router ospf 1
 router-id 1.1.1.1
!

Immediately after the commit (23:40:50) the router ID changed to 1.1.1.1, the adjacency went Down, and re-establishment with the new router ID began. No process restart is required.

R1 right after configuring router-id
RP/0/RP0/CPU0:R1#show ospf | include Routing Process
Fri Sep  4 23:41:05.490 UTC
 Routing Process "ospf 1" with ID 1.1.1.1
RP/0/RP0/CPU0:R1#show logging | include ADJCHG
Fri Sep  4 23:41:06.303 UTC
RP/0/RP0/CPU0:Sep  4 23:40:50.974 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from FULL to DOWN, Neighbor Down: interface down or detached, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:R1#show ospf neighbor
Fri Sep  4 23:41:06.453 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2         1     2WAY/DROTHER    00:00:38    10.1.2.2        GigabitEthernet0/0/0/0
    Neighbor is up for 00:00:06

Total neighbor count: 1
R2 neighbor change log
RP/0/RP0/CPU0:R2#show logging | include ADJCHG
Fri Sep  4 23:41:16.692 UTC
RP/0/RP0/CPU0:Sep  4 23:40:51.052 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 11.11.11.11 on GigabitEthernet0/0/0/0 in area 0 from FULL to DOWN, Neighbor Down: Neighbor router id change, vrf default vrfid 0x60000000

Duplicate Router IDs

With R1’s router ID at 1.1.1.1, configure the same router-id 1.1.1.1 on the adjacent router R2 to see what happens when router IDs are duplicated.

R2 configuration applied (duplicate)
router ospf 1
 router-id 1.1.1.1
!

Both R1 and R2 record %ROUTING-OSPF-3-DUP_RTRID, indicating that a Hello with their own router ID was received from the peer’s interface address, every time a Hello arrives (about every 20 seconds). R2 brings its adjacencies with R1 and R3 Down because of its router ID change and re-establishes the one with R3 as 1.1.1.1, but it cannot form an adjacency with R1.

R1 duplicate detection log
RP/0/RP0/CPU0:R1#show logging | include DUP_RTRID
Fri Sep  4 23:45:19.656 UTC
RP/0/RP0/CPU0:Sep  4 23:42:55.723 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.2 on interface GigabitEthernet0/0/0/0 
RP/0/RP0/CPU0:Sep  4 23:43:15.094 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.2 on interface GigabitEthernet0/0/0/0 
RP/0/RP0/CPU0:Sep  4 23:43:34.307 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.2 on interface GigabitEthernet0/0/0/0 
RP/0/RP0/CPU0:Sep  4 23:43:53.395 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.2 on interface GigabitEthernet0/0/0/0 
RP/0/RP0/CPU0:Sep  4 23:44:12.804 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.2 on interface GigabitEthernet0/0/0/0 
RP/0/RP0/CPU0:Sep  4 23:44:31.583 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.2 on interface GigabitEthernet0/0/0/0 
RP/0/RP0/CPU0:Sep  4 23:44:50.124 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.2 on interface GigabitEthernet0/0/0/0 
RP/0/RP0/CPU0:Sep  4 23:45:08.828 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.2 on interface GigabitEthernet0/0/0/0
R2 after the duplicate setting
RP/0/RP0/CPU0:R2#show ospf | include Routing Process
Fri Sep  4 23:43:35.241 UTC
 Routing Process "ospf 1" with ID 1.1.1.1
RP/0/RP0/CPU0:R2#show logging | include OSPF
Fri Sep  4 23:43:36.227 UTC
RP/0/RP0/CPU0:Sep  4 23:41:33.331 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0/0/0 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:Sep  4 23:42:55.645 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0/0/0 in area 0 from FULL to DOWN, Neighbor Down: interface down or detached, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:Sep  4 23:42:55.646 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0/0/1 in area 0 from FULL to DOWN, Neighbor Down: interface down or detached, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:Sep  4 23:43:02.626 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.1 on interface GigabitEthernet0/0/0/0 
RP/0/RP0/CPU0:Sep  4 23:43:20.716 UTC: ospf[1035]: %ROUTING-OSPF-3-DUP_RTRID : OSPF detected duplicate router-id 1.1.1.1 from 10.1.2.1 on interface GigabitEthernet0/0/0/0
RP/0/RP0/CPU0:R2#show ospf neighbor
Fri Sep  4 23:43:36.621 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3         1     EXSTART/DR      00:00:39    10.2.3.3        GigabitEthernet0/0/0/1
    Neighbor is up for 00:00:32

Total neighbor count: 1

On the R1 side, the Hellos from R2 are treated as R1’s own and R2 is not recognized as a neighbor, so the adjacency with R2 disappears once the Dead timer expires. As a result, all routes learned through OSPF were lost.

R1 after the Dead timer expired
RP/0/RP0/CPU0:R1#show logging | include ADJCHG
Fri Sep  4 23:46:41.431 UTC
RP/0/RP0/CPU0:Sep  4 23:43:35.649 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from FULL to DOWN, Neighbor Down: dead timer expired, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:R1#show ospf neighbor
Fri Sep  4 23:45:17.458 UTC
RP/0/RP0/CPU0:R1#show ospf database
Fri Sep  4 23:45:18.492 UTC


            OSPF Router with ID (1.1.1.1) (Process ID 1)

		Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         103         0x80000003 0x0057ae 2
3.3.3.3         3.3.3.3         1134        0x80000003 0x0004d3 2

		Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.2.3.3        3.3.3.3         1134        0x80000001 0x0046c1
RP/0/RP0/CPU0:R1#show route ospf
Fri Sep  4 23:45:19.459 UTC

% No matching routes found

Restoring R2’s router-id to 2.2.2.2 re-establishes the adjacency with R1 and the routes come back.

R1 after R2 router ID is restored
RP/0/RP0/CPU0:R1#show logging | include ADJCHG
Fri Sep  4 23:46:41.431 UTC
RP/0/RP0/CPU0:Sep  4 23:45:44.011 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0/0/0 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:R1#show ospf neighbor
Fri Sep  4 23:46:40.285 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2         1     FULL/BDR        00:00:33    10.1.2.2        GigabitEthernet0/0/0/0
    Neighbor is up for 00:00:57

Total neighbor count: 1
RP/0/RP0/CPU0:R1#show route ospf
Fri Sep  4 23:46:41.190 UTC

O    2.2.2.2/32 [110/2] via 10.1.2.2, 00:00:57, GigabitEthernet0/0/0/0
O    3.3.3.3/32 [110/3] via 10.1.2.2, 00:00:20, GigabitEthernet0/0/0/0
O    10.2.3.0/24 [110/2] via 10.1.2.2, 00:00:20, GigabitEthernet0/0/0/0

Packet Capture

Below is a capture on the R1–R2 link covering the steps from “Restarting the OSPF Process (Both Loopbacks Up)” through “Configuring router-id Explicitly” (ospf-router-id-change.pcap). Of the 169 packets, the main OSPF packets involved in the router ID changes are excerpted. The Router ID column is the Router ID field of the OSPF header.

No.TimeSourceDestinationRouter IDInfo
21.16610.1.2.1224.0.0.51.1.1.1Hello Packet
410.17110.1.2.1224.0.0.51.1.1.1Hello Packet
511.40110.1.2.1224.0.0.51.1.1.1LS Update
611.48410.1.2.1224.0.0.51.1.1.1Hello Packet
919.79610.1.2.110.1.2.21.1.1.1DB Description
1719.81710.1.2.110.1.2.21.1.1.1LS Update
1919.84910.1.2.1224.0.0.51.1.1.1LS Update
2121.10010.1.2.1224.0.0.51.1.1.1Hello Packet
54172.86610.1.2.1224.0.0.51.1.1.1LS Update
60184.93110.1.2.1224.0.0.51.1.1.1LS Update
61184.98810.1.2.1224.0.0.511.11.11.11Hello Packet
65194.33910.1.2.210.1.2.12.2.2.2DB Description
78224.98910.1.2.110.1.2.211.11.11.11DB Description
83225.00110.1.2.110.1.2.211.11.11.11LS Update
87225.03910.1.2.1224.0.0.511.11.11.11LS Update
92232.02410.1.2.1224.0.0.511.11.11.11Hello Packet
109313.96810.1.2.1224.0.0.511.11.11.11LS Update
115333.81310.1.2.1224.0.0.511.11.11.11LS Update
118334.47210.1.2.110.1.2.211.11.11.11DB Description
127334.56610.1.2.1224.0.0.511.11.11.11LS Update
138367.46610.1.2.1224.0.0.511.11.11.11LS Update
139367.47410.1.2.1224.0.0.51.1.1.1Hello Packet
143376.68510.1.2.210.1.2.12.2.2.2DB Description
158407.47510.1.2.110.1.2.21.1.1.1DB Description
166409.75210.1.2.110.1.2.21.1.1.1LS Update
168409.80510.1.2.1224.0.0.51.1.1.1LS Update
  • No.5 (process restart): R1 floods its own Router-LSA with LS Age 3600 (MaxAge), telling the other routers to remove it from their LSDBs. In No.9–21 that follow, the adjacency is re-established with the same router ID 1.1.1.1.
  • No.54: Because Loopback0 was shut down, R1 updates its Router-LSA (Sequence Number 0x80000003) and floods it.
  • No.60–61 (process restart with Loopback0 shut down): Right after flushing the Router-LSA of the old router ID 1.1.1.1 with MaxAge, a Hello whose Router ID field has changed to 11.11.11.11 is sent. From No.65 R2 starts sending DBDs, but R1 only responds to the DBD exchange from No.78, after its Wait timer (40 seconds) expires, and in No.83 it sends the Router-LSA of the new router ID 11.11.11.11 (Sequence Number 0x80000001).
  • No.109: The Router-LSA update caused by bringing Loopback0 back. In No.115 (the third process restart) the 11.11.11.11 LSA is flushed again, but in the re-establishment from No.118 onward the router ID is still 11.11.11.11.
  • No.138–139 (explicit router-id 1.1.1.1): At the moment of the commit, the Router-LSA of 11.11.11.11 is flushed, and from the next Hello the Router ID is back to 1.1.1.1. From No.158 the adjacency is re-established as 1.1.1.1, and in No.166 the new Router-LSA (Sequence Number 0x80000001) is sent.

Expanding the LS Update in No.60 shows that it is a Router-LSA whose LS Age has been set to 3600 seconds (MaxAge). A router that receives it removes this LSA from its LSDB.

No.60 LS Update (flushing the Router-LSA of the old router ID 1.1.1.1)
Open Shortest Path First
    OSPF Header
        Message Type: LS Update (4)
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
    LS Update Packet
        Number of LSAs: 1
        LSA-type 1 (Router-LSA), len 36
            .000 1110 0001 0000 = LS Age (seconds): 3600
            LS Type: Router-LSA (1)
            Link State ID: 1.1.1.1
            Advertising Router: 1.1.1.1
            Sequence Number: 0x80000003
            Number of Links: 1
            Type: Transit  ID: 10.1.2.2        Data: 10.1.2.1        Metric: 1

In the Hello of No.61 immediately afterwards, the Router ID field of the OSPF header is 11.11.11.11, and the DR/BDR fields have also been reset to 0.0.0.0. From the moment R2 receives this Hello, it starts treating the sender as a new neighbor distinct from 1.1.1.1.

No.61 Hello (new router ID 11.11.11.11)
Open Shortest Path First
    OSPF Header
        Message Type: Hello Packet (1)
        Source OSPF Router: 11.11.11.11
        Area ID: 0.0.0.0 (Backbone)
    OSPF Hello Packet
        Network Mask: 255.255.255.0
        Hello Interval [sec]: 10
        Router Priority: 1
        Router Dead Interval [sec]: 40
        Designated Router: 0.0.0.0
        Backup Designated Router: 0.0.0.0

Router ID Design

As confirmed in the tests in this article, an automatically selected router ID varies with the platform and the state of the router. The following practices are recommended for operation.

  • Always configure the router ID explicitly with the router-id command. If left to automatic selection, the address chosen differs by platform (the highest loopback address on IOS XE, the lowest on IOS XR) and can change unexpectedly when interfaces are added or the router restarts.
  • Use the address of Loopback0 as the value. Unlike physical interfaces, a loopback does not go down, and keeping the management address and the router ID the same makes it easy to identify the router from show output.
  • Keep it unique within the OSPF domain. A duplicate is logged as %ROUTING-OSPF-3-DUP_RTRID, the adjacency cannot be formed, and routes are lost.
  • Because a router ID change involves re-establishing adjacencies and regenerating LSAs, do it within a maintenance window. Note that on IOS XR a change to the explicit setting takes effect as soon as it is committed.

Verification Config

The running-config of each router at the end of the tests, and the output of show ospf (router ID), show ospf neighbor, show ospf database, and show route ospf. Loopback1 remains on R1. The vrf Mgmt on MgmtEth0/RP0/CPU0/0 is for management access to the test lab and has nothing to do with OSPF.

Download R1 config (r1_ospf-router-id.cfg)

Download R2 config (r2_ospf-router-id.cfg)

Download R3 config (r3_ospf-router-id.cfg)

Download R1 show output (r1_ospf-router-id_show.txt)

Download R2 show output (r2_ospf-router-id_show.txt)

Download R3 show output (r3_ospf-router-id_show.txt)

Download ospf-router-id-change.pcap

References

RFCTitleSummary
RFC 2328OSPF Version 2Definition of the router ID (Section 1.2, C.1).
DocumentSummary
Routing Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 7.10.x - Implementing OSPFThe router ID selection order on IOS XR (checkpointing database → router-id command → ITAL → interface address) and the recommendation to configure it with the router-id command.

Related Articles