Daniel Dib wrote a nice article describing the history of the loopback interface¹, triggering an inevitable mention of the role of a loopback interface in OSPF and related flood of ancient memories on my end.

Before going into the details, let’s get one fact straight: an OSPF router ID was always (at least from the days of OSPFv1 described in RFC 1133) just a 32-bit identifier, not an IPv4 address². Straight from the RFC 1133:

Router ID a 32-bit number that uniquely identifies this router in the AS. One possible implementation strategy would be to use the smallest IP interface address belonging to the router.

Someone within Cisco focused too much on the latter part of the above paragraph, resulting in decades-long insistence on OSPF router ID being an interface IPv4 address³. That slant persisted as the informal OSPF lore spread across other vendors⁴.

However, compared to what we have to deal with today, the initial implementation attempts were particularly “interesting”⁵. Here’s how I remember Cisco’s slow realization of the gap between theory and practice⁶:

1. Initially, Cisco would pick the highest IP address of any interface configured on the box as the router ID.
2. Even worse, they would change the router ID if that interface went down, resulting in a temporary loss of a router node for no good reason.
3. Losing a transit router just because an interface flapped eventually bothered enough customers to trigger a change in the router ID selection algorithm. They figured out that using a loopback interface IPv4 address as a router ID makes for more stable networks, so the above rule #1 was changed into ’the highest loopback IPv4 address, or the highest IPv4 address if the device has no loopbacks'
4. Years later⁷, we got the router-id command.

5. Sometime during that journey, they got to a point where a loss of an interface no longer triggered a change in the router ID. Even changing the interface IP address that was used as the router ID no longer changes the router ID (you have to clear the OSPF process to change it). Mission Accomplished.

However, based on the my experience writing OSPF-in-VRFs netlab configuration templates for numerous devices, Cisco IOS is the only device that still treats OSPF router ID as something special⁸.

All other devices are perfectly happy to start multiple OSPF processes with the same router ID⁹; Cisco IOS (and IOS/XE) refuses to do that, rejects duplicate statically-configured router-id¹⁰, and uses the above algorithm to pick a different OSPF router ID for every VRF OSPF process. Even worse, if you configure two OSPFv3 routing processes (without static router IDs) but have a single IPv4 address on the device, one of them won’t start.