This post originally appeared on the Packet Pushers’ Ignition site on March 24, 2020.
In both OSPFv2 (IPv4) and OSPFv3 (IPv6), the router ID (RID) is a 32-bit number assigned to the router. The RID must be unique within the OSPF network, as a RID provides a point of origin for link state advertisements (LSAs). If LSAs from more than one device improperly sharing a RID appear in the OSPF database, the shortest path first (SPF) calculation for the OSPF area will be, at best, wonky.
“Wonky” is a technical term that means broken. 😉 Users experiencing OSPF wonkiness will struggle to reach destinations consistently, as the OSPF database churns itself into a froth constantly recalculating what it thinks is a changing topology, when in fact it’s dealing with duplicate RIDs.
A RID does not have to be a real IP address present on the router. The RID merely needs to be a unique 32-bit value–it’s just a label. OSPF routing domain admins tend to use IP addresses for the RID, because network engineers are familiar with IP addresses. RIDs that match an IP address on the router is logical and perhaps even convenient. But the RID can be any unique value that fits into 32 bits expressed as a dotted quad.
In my experience, assigning an IP address found on the local router to be the RID is the most common approach. So common is this approach that Cisco even supports performing hostname lookups against RIDs, so that you see the hostname of the router in OSPF CLI output instead of the RID.
How Are OSPF RIDs Set?
OSPF RIDs can be set automatically or manually.
Automatic RID Assignment
Cisco IOS assigns the RID with the following preference.
- The largest IP assigned to a loopback interface.
- If no loopback is present, the largest IP of any interface will become the RID.
- If no IPs are assigned to any interface, then OSPF can’t start on that router unless a RID is manually assigned.
OSPF uses the largest IP address configured on the interfaces as its router ID. If the interface associated with this IP address is ever brought down, or if the address is removed, the OSPF process must recalculate a new router ID and resend all its routing information out its interfaces.
If a loopback interface is configured with an IP address, the Cisco IOS software will use this IP address as its router ID, even if other interfaces have larger IP addresses. Because loopback interfaces never go down, greater stability in the routing table is achieved.
Let’s expand on Cisco’s closing point about “greater stability in the routing table is achieved.” The idea is that loopbacks are virtual interfaces that never go down. When an OSPF RID is changed, the entire OSPF process on that device must restarted for the new RID to be reflected. When you restart the OSPF process on a device, that ripples throughout the OSPF domain like a pebble thrown into the water. SPF is recalculated across the domain. This recalculation happens quickly, but some destinations might be briefly unreachable while this happens.
Therefore, if you create a loopback interface and assign an IP address to it, an OSPF process left to select its own RID will choose it. In theory, that loopback interface IP will never change and never go down, making it a stable choice as a RID and reducing the chance that the RID will need to change, requiring an OSPF process restart and subsequent convergence event.
Manual RID Assignment
If automatic RID assignment feels a bit fragile, you’re in good company. Well, you’re in my company. Judge for yourself how good that company is. I’m a fan of manually assigning a RID using the router-id command in the router ospf paragraph of a Cisco IOS device.
However, I will argue against manual assignment for this reason. In the world of network automation, should network engineers be fussing with minutiae like RIDs? The message we get from Kubernetes is that operators ought not care what workloads are named or what IP address blocks are used for behind-the-scenes connectivity. Let that, bounded by some policy guidance, just happen. If we apply that logic to OSPF RIDs, then all we should concern ourselves with is uniqueness of the RID.
In that spirit, I believe that the OSPF automatic RID assignment process of the highest IP of a loopback interface is fine. If you wish to guide this process, guide the automated workflow that assigns a loopback interface, presumably used for device management anyway, to the device as it is provisioned.
What Lab Work Reveals About RID Assignments
In preparing for this article, I spent a good bit of lab time making sense of how Cisco IOS handles OSPF RIDs. Take this information with a grain of salt in that virtual images can act weird (wonky?) at times, but these are my observations.
If the RID is unconfigured, then the OSPF process is first started, IOS will grab whatever RID it grabs according to the algorithm discussed above. Once the OSPF process is using that RID, there’s almost nothing that will change it. For example…
- Adding a loopback with a higher IP and performing a clear ip ospf process will not cause OSPF to select a new RID.
- Deleting the loopback that was used to assign the RID and performing a clear ip ospf process will not cause OSPF to select a new RID.
That is, if you let the OSPF process pick its own RID, it’s going to hang onto that RID until you restart the entire router or blow away the OSPF process via no router ospf and recreate the OSPF config from scratch.
If, however, you decide to manually configure the router with the router-id command in the router ospf paragraph, then clear ip ospf process will cause the new RID to take effect.
Conversely, if you do a no router-id and then clear ip ospf process, OSPF will again select a RID for itself.
These details matter if you are planning to change the OSPF RID and are calculating the potential risk of the change to the business. Verify behavior in your own lab before scheduling a RID change window or pushing out an automated RID change into a production environment.
The behavior of Cisco IOS OSPFv3 varies from OSPFv2 in that clear ip ospf process will cause a new RID to be selected in all circumstances.