OSPF Router ID

The router ID is the 32-bit value OSPF uses to identify which router originated an LSA and which node it is on the topology map. It is written like an IPv4 address (1.1.1.1 and so on), but it is only an identifier: nothing has to be reachable at that address.

RFC 2328 defines it as “a 32-bit number assigned to each router running the OSPF protocol. This number uniquely identifies the router within an Autonomous System” (Section 1.2), and only goes as far as saying that “one possible implementation strategy would be to use the smallest IP interface address belonging to the router” (Appendix C.1). How it is chosen is left to the implementation.

The router ID appears throughout OSPF.

Where	Description
The originator of an LSA	The Advertising Router field in every LSA header; in a Router-LSA (type 1) the Link State ID is the router ID as well
Hello packets	The Router ID field in the OSPF header and the neighbour list inside the Hello. Neighbours are identified by this value
DR and BDR election	With equal priorities, the router with the higher router ID becomes the DR (Section 9.4)
Master and slave for LSDB synchronisation	In ExStart, the router with the higher router ID becomes the master
`show` command output	The Neighbor ID of `show ospf neighbor`, the ADV Router of `show ospf database`, and so on

A router ID has to be unique inside the OSPF domain. What happens when it is not is covered in OSPF Behavior When Router IDs Collide.

How IOS XR chooses it

The OSPF process on Cisco IOS XR picks the router ID in this order when it starts and when it is reset. The decision is recorded in show ospf trace events, and the lab below follows those strings.

Order	How it is chosen	String in the trace
1	The router ID used previously	`checking for old rtrid`
2	The value of the `router-id` command under `router ospf`	`checking for rtrid config` then `rtrid for vrf ... set by numeric config`
3	The value picked by ITAL (the global router ID feature of IOS XR), taken from a loopback that is up	`checking ITAL rtrid` then `rtrid set by ITAL`
4	The address of an OSPF-enabled interface	`rtrid for vrf ... set using our intf`

Order 1 was never used in this lab. Even after restarting the node, the trace moves past checking for old rtrid and the ITAL value is taken instead (STEP 2).

Configure the router ID explicitly with the router-id command. Leaving it to be chosen automatically ties it to interface states and to whatever ITAL holds, so adding or removing a loopback, or resetting the process, can change it. When it changes, adjacencies drop and routes go with them.

When it changes

Setting or changing router-id takes effect on commit; the process does not have to be restarted
Removing router-id does not change anything on commit. The value is re-derived at the next start or reset
An automatically chosen value does not change when the interface behind it goes down. It is re-derived at the next reset
The ITAL value stays as it is while the interface it picked remains up

Appendix C.1 of RFC 2328 says a router should flush its self-originated LSAs before changing its router ID, otherwise they persist for up to MaxAge. IOS XR does exactly that (see the capture in STEP 4).

Commands that show the decision

Command	What it shows
`show router-id`	The global router ID ITAL holds and the interface it came from
`show ospf trace events \| include rtrid`	The decision recorded by the OSPF process. Unlike `debug`, it can be read after the fact

Lab verification

Lab setup

Four Cisco IOS XR routers (XRd 26.1.1). R1 is the subject of the test: it has Loopback0 (1.1.1.1) and gains Loopback1 (11.11.11.11) partway through.

Only R4 has no loopback and no router-id, so that order 4 (the address of an OSPF-enabled interface) can be confirmed.

Steps

STEP	Change	Router ID of R1
0	Initial state (`router-id 1.1.1.1` configured)	`1.1.1.1`
1	`router-id` removed, `Loopback1` added	`1.1.1.1`, unchanged
2	The R1 node restarted	`1.1.1.1`
3	`clear ospf 1 process`	`1.1.1.1`
4	`Loopback0` shut down, then `clear ospf 1 process`	`11.11.11.11`
5	`Loopback0` brought back, then `clear ospf 1 process`	`11.11.11.11`, unchanged
6	`clear ospf 1 process` on R4	`11.11.11.11` (this STEP looks at R4)
7	`router-id 1.1.1.1` configured	`1.1.1.1`
8	`Loopback1` removed (final state)	`1.1.1.1`

The configured value wins (STEP 0)

The trace on R1:

STEP 0 R1 show ospf trace events | include rtrid
RP/0/RP0/CPU0:R1#show ospf trace events | include rtrid
Wed Sep 23 07:41:38.979 UTC
31   Sep 23 07:32:37.384  ospf_rtrid_set_configured: new_rtr_id 1.1.1.1
32   Sep 23 07:32:37.384  ospf_rtrid_set_configured: rtrid config by value, op_conf_rtr_id 1.1.1.1 vrfid 60000000
48   Sep 23 07:32:37.570  ospf_rtrid_allocate: checking for old rtrid 0x60000000
49   Sep 23 07:32:37.570  ospf_rtrid_allocate: checking for rtrid config
50   Sep 23 07:32:37.570  ospf_rtrid_allocate: rtrid for vrf 0x60000000 set by numeric config: 1.1.1.1

It goes checking for old rtrid, then checking for rtrid config, and settles on set by numeric config: 1.1.1.1. With a configured value present, ITAL is never consulted.

Here is what ITAL holds anyway:

STEP 0 R1 show router-id
RP/0/RP0/CPU0:R1#show router-id
Wed Sep 23 07:41:23.679 UTC
Router-ID         Interface
      
1.1.1.1           Loopback0       

IPv6 router id is not enabled - Configure IPv6 address on loopback interface

ITAL has picked 1.1.1.1 from Loopback0. Whether OSPF uses that value is a separate matter: a configured value takes precedence.

Removing it does nothing on commit (STEP 1)

router-id was removed and Loopback1 (11.11.11.11) added at the same time.

STEP 1 The configuration committed on R1
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Wed Sep 23 07:43:35.373 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
interface Loopback1
 ipv4 address 11.11.11.11 255.255.255.255
!
router ospf 1
 no router-id 1.1.1.1
 area 0
  interface Loopback1
   passive enable
  !
 !
!
end

STEP 1 R1 show ospf (first lines)
RP/0/RP0/CPU0:R1#show ospf
Wed Sep 23 07:45:20.151 UTC

 Routing Process "ospf 1" with ID 1.1.1.1

The router ID is still 1.1.1.1. The removal takes effect only at the next start or reset.

Restarting the node and the process (STEPs 2 and 3)

The R1 node was restarted (STEP 2) and then clear ospf 1 process was run (STEP 3). The trace follows the same path in both cases.

STEP 2 R1 show ospf trace events | include rtrid (after the node restart)
RP/0/RP0/CPU0:R1#show ospf trace events | include rtrid
Wed Sep 23 07:53:30.908 UTC
82   Sep 23 07:50:21.198  ospf_rtrid_allocate: checking for old rtrid 0x60000000
83   Sep 23 07:50:21.198  ospf_rtrid_allocate: checking for rtrid config
84   Sep 23 07:50:21.198  ospf_rtrid_allocate: checking ITAL rtrid: 1.1.1.1
85   Sep 23 07:50:21.300  ospf_rtrid_allocate: rtrid set by ITAL: 1.1.1.1

The checking for old rtrid line is there but yields nothing; after checking for rtrid config (removed, so nothing there either) it settles on rtrid set by ITAL: 1.1.1.1. Loopback0 and Loopback1 are both up, but ITAL keeps the Loopback0 it picked earlier, so the higher 11.11.11.11 is not used.

A loopback going down forces a new choice (STEPs 4 and 5)

Loopback0 was shut down and the process reset.

STEP 4 R1 show ospf trace events | include rtrid
RP/0/RP0/CPU0:R1#show ospf trace events | include rtrid
Wed Sep 23 08:03:39.107 UTC
 Sep 23 07:50:21.199  ospf_rtrid_allocate: checking for old rtrid 0x60000000
 Sep 23 07:50:21.199  ospf_rtrid_allocate: checking for rtrid config
 Sep 23 07:50:21.199  ospf_rtrid_allocate: checking ITAL rtrid: 1.1.1.1
 Sep 23 07:50:21.301  ospf_rtrid_allocate: rtrid set by ITAL: 1.1.1.1
Sep 23 07:55:33.394  ospf_rtrid_allocate: checking for old rtrid 0x60000000
Sep 23 07:55:33.394  ospf_rtrid_allocate: checking for rtrid config
Sep 23 07:55:33.394  ospf_rtrid_allocate: checking ITAL rtrid: 1.1.1.1
Sep 23 07:55:33.414  ospf_rtrid_allocate: rtrid set by ITAL: 1.1.1.1
Sep 23 07:55:33.414  ospf_soft_reset_up: rtrid: new 1.1.1.1 old 1.1.1.1
Sep 23 08:00:14.099  ospf_rtrid_allocate: checking for old rtrid 0x60000000
Sep 23 08:00:14.099  ospf_rtrid_allocate: checking for rtrid config
Sep 23 08:00:14.099  ospf_rtrid_allocate: checking ITAL rtrid: 11.11.11.11
Sep 23 08:00:14.115  ospf_rtrid_allocate: rtrid set by ITAL: 11.11.11.11
Sep 23 08:00:14.116  ospf_soft_reset_up: rtrid: new 11.11.11.11 old 1.1.1.1
Sep 23 08:00:14.116  ospf_soft_reset_up: rtrid changed, check vlink for reconfig

ITAL picked Loopback1 instead and the router ID changed to 11.11.11.11 (rtrid: new 11.11.11.11 old 1.1.1.1).

STEP 4 R1 show router-id
RP/0/RP0/CPU0:R1#show router-id
Wed Sep 23 08:03:25.306 UTC
Router-ID         Interface
      
11.11.11.11       Loopback1       

IPv6 router id is not enabled - Configure IPv6 address on loopback interface

STEP 4 R1 syslog (the ADJCHG lines)
RP/0/RP0/CPU0:Sep 23 08:00:14.050 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 23 08:00:14.050 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 10.0.14.4 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 23 08:00:54.137 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 10.0.14.4 on GigabitEthernet0/0/0/1 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 
RP/0/RP0/CPU0:Sep 23 08:00:58.714 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 

Both adjacencies went DOWN and came back to FULL about 40 seconds later. Changing the router ID is not a hitless operation.

These are the packets at the moment of the change.

STEP 4 R1 - R2 around the router ID change
2026-09-23 17:00:05.996060    10.0.12.2 → 224.0.0.5    OSPF 114 Hello Packet
2026-09-23 17:00:08.293572    10.0.12.1 → 224.0.0.5    OSPF 122 LS Update
2026-09-23 17:00:08.793062    10.0.12.1 → 224.0.0.5    OSPF 114 Hello Packet
2026-09-23 17:00:10.298774    10.0.12.2 → 224.0.0.5    OSPF 78 LS Acknowledge
2026-09-23 17:00:14.092854    10.0.12.1 → 224.0.0.5    OSPF 122 LS Update
2026-09-23 17:00:14.117425    10.0.12.1 → 224.0.0.5    OSPF 110 Hello Packet
2026-09-23 17:00:15.125878    10.0.12.2 → 224.0.0.5    OSPF 110 Hello Packet

No.5 is R1 withdrawing the Router-LSA of the old router ID 1.1.1.1 by sending it with LS age 3600 (MaxAge).

STEP 4 No.5 LS Update (withdrawing the Router-LSA of the old router ID)
    LS Update Packet
        Number of LSAs: 1
        LSA-type 1 (Router-LSA), len 60
            .000 1110 0001 0000 = LS Age (seconds): 3600
            0... .... .... .... = Do Not Age Flag: 0
            Options: 0x22, (DC) Demand Circuits, (E) External Routing
                0... .... = DN: Not set
                .0.. .... = (O) Opaque: Not set
                ..1. .... = (DC) Demand Circuits: Supported
                ...0 .... = (L) LLS Data block: Not Present
                .... 0... = (N) NSSA: Not supported
                .... .0.. = (MC) Multicast: Not capable
                .... ..1. = (E) External Routing: Capable
                .... ...0 = (MT) Multi-Topology Routing: No
            LS Type: Router-LSA (1)
            Link State ID: 1.1.1.1
            Advertising Router: 1.1.1.1
            Sequence Number: 0x80000004
            Checksum: 0x5c1a
            Length: 60
            Flags: 0x00
                0... .... = (H) Host: No
                ..0. .... = (S) Shortcut-capable ABR: No
                ...0 .... = (N) NSSA translation: No
                .... 0... = (W) Wild-card multicast receiver: No
                .... .0.. = (V) Virtual link endpoint: No
                .... ..0. = (E) AS boundary router: No
                .... ...0 = (B) Area border router: No

Download the pcap of the packet in the tshark output above (No.5 LS Update)

24 milliseconds later, from No.6 onwards, the Hello packets carry the new router ID.

STEP 4 No.6 Hello (the new router ID)
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: Hello Packet (1)
        Packet Length: 44
        Source OSPF Router: 11.11.11.11
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0xd688 [correct]
        Instance ID: Base IPv4 Unicast Instance (0)

Download the pcap of the packet in the tshark output above (No.6 Hello)

The withdrawal comes first and the new identity second, which is what Appendix C.1 of RFC 2328 asks for.

In STEP 5 Loopback0 was brought back and the process reset again, but the router ID stayed at 11.11.11.11: ITAL does not re-pick while the Loopback1 it chose is up.

A router with no loopback (STEP 6)

R4 has neither a loopback nor a router-id.

STEP 6 R4 show ospf trace events | include rtrid
RP/0/RP0/CPU0:R4#show ospf trace events | include rtrid
Wed Sep 23 08:14:25.302 UTC
 Sep 23 07:33:00.605  ospf_rtrid_allocate: checking for old rtrid 0x60000000
 Sep 23 07:33:00.605  ospf_rtrid_allocate: checking for rtrid config
 Sep 23 07:33:00.796  ospf_rtrid_allocate: rtrid for vrf  0x60000000 set using our intf: 10.0.14.4
Sep 23 08:10:08.413  ospf_rtrid_allocate: checking for old rtrid 0x60000000
Sep 23 08:10:08.413  ospf_rtrid_allocate: checking for rtrid config
Sep 23 08:10:08.508  ospf_rtrid_allocate: rtrid for vrf  0x60000000 set using our intf: 10.0.14.4
Sep 23 08:10:08.508  ospf_soft_reset_up: rtrid: new 10.0.14.4 old 10.0.14.4

set using our intf: 10.0.14.4: the address of an OSPF-enabled interface was used, which is order 4. The value is the same at startup (the upper lines) and after clear ospf 1 process (the lower lines).

A configured value takes effect on commit (STEP 7)

router-id 1.1.1.1 was put back on R1.

STEP 7 The configuration committed on R1
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Wed Sep 23 08:14:40.741 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 router-id 1.1.1.1
!
end

STEP 7 R1 show ospf trace events | include rtrid
RP/0/RP0/CPU0:R1#show ospf trace events | include rtrid
Wed Sep 23 08:17:17.799 UTC
 Sep 23 07:50:21.199  ospf_rtrid_allocate: checking for old rtrid 0x60000000
 Sep 23 07:50:21.199  ospf_rtrid_allocate: checking for rtrid config
 Sep 23 07:50:21.199  ospf_rtrid_allocate: checking ITAL rtrid: 1.1.1.1
 Sep 23 07:50:21.301  ospf_rtrid_allocate: rtrid set by ITAL: 1.1.1.1
Sep 23 07:55:33.394  ospf_rtrid_allocate: checking for old rtrid 0x60000000
Sep 23 07:55:33.394  ospf_rtrid_allocate: checking for rtrid config
Sep 23 07:55:33.394  ospf_rtrid_allocate: checking ITAL rtrid: 1.1.1.1
Sep 23 07:55:33.414  ospf_rtrid_allocate: rtrid set by ITAL: 1.1.1.1
Sep 23 07:55:33.414  ospf_soft_reset_up: rtrid: new 1.1.1.1 old 1.1.1.1
Sep 23 08:00:14.099  ospf_rtrid_allocate: checking for old rtrid 0x60000000
Sep 23 08:00:14.099  ospf_rtrid_allocate: checking for rtrid config
Sep 23 08:00:14.099  ospf_rtrid_allocate: checking ITAL rtrid: 11.11.11.11
Sep 23 08:00:14.115  ospf_rtrid_allocate: rtrid set by ITAL: 11.11.11.11
Sep 23 08:00:14.116  ospf_soft_reset_up: rtrid: new 11.11.11.11 old 1.1.1.1
Sep 23 08:00:14.116  ospf_soft_reset_up: rtrid changed, check vlink for reconfig
Sep 23 08:05:38.698  ospf_rtrid_allocate: checking for old rtrid 0x60000000
Sep 23 08:05:38.698  ospf_rtrid_allocate: checking for rtrid config
Sep 23 08:05:38.698  ospf_rtrid_allocate: checking ITAL rtrid: 11.11.11.11
Sep 23 08:05:38.716  ospf_rtrid_allocate: rtrid set by ITAL: 11.11.11.11
Sep 23 08:05:38.716  ospf_soft_reset_up: rtrid: new 11.11.11.11 old 11.11.11.11
Sep 23 08:14:39.925  ospf_rtrid_set_configured: new_rtr_id 1.1.1.1
Sep 23 08:14:39.925  ospf_rtrid_set_configured: rtrid config by value, op_conf_rtr_id 1.1.1.1 vrfid 60000000
Sep 23 08:14:39.934  ospf_rtrid_allocate: checking for old rtrid 0x60000000
Sep 23 08:14:39.934  ospf_rtrid_allocate: checking for rtrid config
Sep 23 08:14:39.934  ospf_rtrid_allocate: rtrid for vrf 0x60000000 set by numeric config: 1.1.1.1
Sep 23 08:14:39.937  ospf_soft_reset_up: rtrid: new 1.1.1.1 old 11.11.11.11
Sep 23 08:14:39.937  ospf_soft_reset_up: rtrid changed, check vlink for reconfig

It went back to 1.1.1.1 without resetting the process. Only setting or changing the value takes effect on commit.

Design notes

Configure the router ID explicitly. An automatic value depends on the state ITAL is in and changes when loopbacks come and go or the process is reset; when it changes, adjacencies drop and routes go with them
On a router with no loopback, an interface address becomes the router ID. Move that interface and the value changes
Once a value has been chosen automatically, restoring the original interface does not restore it. Configure it explicitly if it has to come back

Configurations and show outputs

In each STEP the following files were collected from all four routers, one file per router. The configuration used in the lab is the ..._run.txt file (the final state is the one of the last STEP).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show route ospf` and the `show ospf` set (`interface` / `neighbor` / `database` / `database router` / `database network` / `database router self-originate` / `statistics interface` / `routes`), `show router-id` / `show ipv4 interface brief` / `show configuration commit list`
`..._log.txt`	`show logging` limited to that STEP
`..._run.txt`	`show running-config` at that STEP (= the configuration of that STEP)
`..._trace.txt`	`show ospf trace events \| include rtrid` (how the router ID was decided) plus `show ospf trace events` / `errors`
`..._ping.txt`	`ping` (50 packets) and `traceroute` between the Loopback0 addresses of R1 and R3
`..._clear.txt`	The counters cleared before the `ping` of that STEP
`..._commit.cfg`	The configuration committed in that STEP (`show configuration commit changes last 1`)
`..._reset.txt`	The record of `clear ospf 1 process` (STEPs 3 to 6)

There is no commit.cfg for STEPs and routers whose configuration did not change. The final state matches the initial one, without Loopback1.

STEP 0: Initial state (router-id configured on R1)

Router	show output	syslog	running-config	trace	ping	clear	commit / reset
R1	show	log	run	trace	ping	clear	—
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	ping	clear	—
R4	show	log	run	trace	—	clear	—

STEP 1: router-id removed and Loopback1 added on R1

Router	show output	syslog	running-config	trace	ping	clear	commit / reset
R1	show	log	run	trace	ping	clear	commit
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	ping	clear	—
R4	show	log	run	trace	—	clear	—

STEP 2: The R1 node restarted

Router	show output	syslog	running-config	trace	ping	clear	commit / reset
R1	show	log	run	trace	ping	clear	—
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	ping	clear	—
R4	show	log	run	trace	—	clear	—

STEP 3: clear ospf 1 process on R1

Router	show output	syslog	running-config	trace	ping	clear	commit / reset
R1	show	log	run	trace	ping	clear	reset
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	ping	clear	—
R4	show	log	run	trace	—	clear	—

STEP 4: Loopback0 shut down, then clear ospf 1 process

Router	show output	syslog	running-config	trace	ping	clear	commit / reset
R1	show	log	run	trace	ping	clear	commit / reset
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	ping	clear	—
R4	show	log	run	trace	—	clear	—

STEP 5: Loopback0 brought back, then clear ospf 1 process

Router	show output	syslog	running-config	trace	ping	clear	commit / reset
R1	show	log	run	trace	ping	clear	commit / reset
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	ping	clear	—
R4	show	log	run	trace	—	clear	—

STEP 6: clear ospf 1 process on R4

Router	show output	syslog	running-config	trace	ping	clear	commit / reset
R1	show	log	run	trace	ping	clear	—
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	ping	clear	—
R4	show	log	run	trace	—	clear	reset

STEP 7: router-id 1.1.1.1 configured on R1

Router	show output	syslog	running-config	trace	ping	clear	commit / reset
R1	show	log	run	trace	ping	clear	commit
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	ping	clear	—
R4	show	log	run	trace	—	clear	—

STEP 8: Loopback1 removed (final state)

Router	show output	syslog	running-config	trace	ping	clear	commit / reset
R1	show	log	run	trace	ping	clear	commit
R2	show	log	run	trace	—	clear	—
R3	show	log	run	trace	ping	clear	—
R4	show	log	run	trace	—	clear	—

Packets were captured per STEP on the R1 - R2 link. There is no capture for STEP 2: restarting the R1 node detached the capture from the link.

STEP	R1-R2	STEP	R1-R2
0	pcap	5	pcap
1	pcap	6	pcap
2	—	7	pcap
3	pcap	8	pcap
4	pcap	—	—

References

Source	Sections referred to
RFC 2328 OSPF Version 2	Section 1.2 (the definition of the router ID), Section 9.4 (DR election), Appendix C.1 (how a router ID may be chosen, and flushing LSAs before changing it)
Lab	Four Cisco IOS XR routers (XRd 26.1.1). The selection was followed in the decisions recorded by `show ospf trace events`