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 AssignmentCisco IOS assigns the RID with the following preference.
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 AssignmentIf 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 AssignmentsIn 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. OSPFv2If 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…
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. OSPFv3The 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. |