By James Hanback
You can pick your Open Shortest Path First (OSPF) router. You can pick your OSPF router ID. And if you don’t pick your router ID, the routing protocol will attempt to do it for you.
As anyone who has spent some time studying for a CCNA certification can tell you, how an OSPF router selects a router ID and what the router ID is used for is important knowledge to have when taking a Cisco certification exam that covers OSPF. Both OSPF and OSPF version 3 (OSPFv3), which is OSPF for IP version 6 (IPv6) networks, use router IDs to uniquely identify each router on the network. OSPF also uses the highest router ID among OSPF routers in a given area to determine which router is elected the designated router (DR) and backup designated router (BDR) on multiaccess networks if the routers have equal OSPF priority values.
So we’ve established that OSPF router IDs are important, but what are they exactly and how does one go about assigning them? If you were to issue the show ip ospf command on a Cisco router that is configured with the OSPF routing protocol, you might see output similar to the following:
Router1#show ip ospf
Routing Process "ospf 1" with ID 192.168.51.50
<output omitted>
The output above indicates that OSPF process 1 is running on Router1 and using a router ID of 192.168.51.50. The first thing you might notice about the router ID is that it looks quite similar to an IP address. That’s because, like IP addresses, router IDs are 32-bit values that are typically represented in dotted-decimal notation. More, the actual IP addresses that are configured on either the logical or the physical interfaces of an OSPF router can be used by the router to configure the router ID if one has not been configured manually.
Let’s say you’re a control freak (we all know them) and you want to exert your mighty influence over every possible nuance of your network configuration, including the OSPF router IDs. Alas, the lazy bum who administered your company’s OSPF configuration before you chose to knit everything together with what appears to be a wholly random IP addressing scheme, rife with wasteful subnetting and no regard as to which of the OSPF routers becomes the DR or the BDR. Also, the previous admin did not configure loopback interfaces! (I know, I know. Deep breath. Reign in that eye tic.) You see, when a router ID is not manually configured, it is determined by using the following method:
- the highest IPv4 address assigned to a loopback interface
- if no loopback interfaces are configured, the highest IPv4 address assigned to a physical interface
The above rules apply even if you are configuring an IPv6 network and using OSPFv3 as the routing protocol. An OSPFv3 router that is not configured with IPv4 addresses requires the manual assignment of a 32-bit router ID.
As a result of a previous admin’s slothfulness and poor IPv4 addressing scheme, the router IDs on your company’s OSPF routers have been assigned to be whatever the highest IP address on each router’s physical interface is. This could be problematic because, once elected, the DR becomes responsible for the conservation of network resources by being the sole generator of link-state advertisements (LSAs), those little pieces of data OSPF routers use to learn the topology of a given area. If the DR fails, the BDR takes over for the DR. Thus you can use the router ID on a multiaccess network to influence which OSPF router gets the essential chore of being the town crier. If the selection of the DR is left up to a router ID generated from a poor IP addressing scheme, you might be saddled with a DR that is a potential drag on network performance because it doesn’t have the resources to be the most efficient and responsible provider of the LSAs. Also, physical interfaces can come up slow or not at all on reboots, which creates the potential for an OSPF router to reboot with a different router ID than the one that it was configured with when it went down.
So what’s a Type A admin to do?
You might think that your first step should be to modify the IP addressing scheme so that it is less wasteful and so that the router you want to be the DR is configured with the highest IP address. However, any network admin worth his or her weight in copper wiring will tell you that’s a potential nest of snakes. Depending on the size and complexity of the established network, you might end up with a Lortab prescription as a result of all the severe headaches you’ll get from banging your head against the corner of your desk.
Unlike physical interfaces, loopback interfaces are always in the up state. Therefore, a simpler way to fix the problem would be to configure loopback interfaces on the OSPF routers and then assign each of those loopback interfaces an IP address that has meaning. For example, if there were 10 routers in OSPF Area 1, you could configure the router that you want to become the DR with a loopback interface that has an IP address of 10.10.1.10/32, which is to say an IP address of 10.10.1.10 on a single-host network (if you don’t understand subnetting, here’s a good tutorial). The router you want to become the BDR could be configured with a loopback interface that is assigned an IP address of 10.10.1.9/32, and so on until the last router is configured with a loopback interface that has an IP address of 10.10.1.1/32. This addressing scheme has simple logic: it’s a private addressing scheme and it establishes an easily recognizable router ID convention. The third octet (1) represents OSPF Area 1 and the final octet (10, 9, 8, 7, 6, 5, 4, 3, 2, or 1) represents the router number in that area. On your own network, you would naturally want to ensure that whatever single-host IP addressing scheme you chose for the loopback interfaces did not overlap with any other IP networks configured on the router (or elsewhere in the topology). You could then configure each router in the OSPF area to advertise its loopback IP address so that you can connect to the router from other locations on the network by using the loopback IP address. Similar to configuring a loopback interface on a single-host subnet, you should configure OSPF to advertise the single IP address that is assigned to the loopback interface, not the entire classful network to which the IP address might belong
This scenario solves several problems: it enables you to control which routers are elected the DR and the BDR, it provides some stability for OSPF because loopback interfaces are always in the up state, and it organizes network management in a logical fashion. Because you can now communicate with each router by using its 10.10.1.x IP address, it’s going to be easy for you as an admin to remember (and document) that this particular router is number 10 in Area 1, that one is number 9 in Area 1, and that little one over there in the corner of your office you just can’t bear to part with is number 1 in Area 1. Otherwise, you must remember that this one is 192.168.51.50, that one is 172.16.14.30, and so on. Another benefit of this solution is that you’ve lessened the danger that a given router will change IDs on you when a physical interface is slow to come up or doesn’t come up at all for some reason on a reboot. As long as a loopback interface is configured with an IP address, OSPF will use the highest loopback IP address as the router ID and ignore the IP addresses that are assigned to the physical interfaces.
However, there is the possibility that another admin could create an additional loopback interface on a router and assign it an IPv4 address that is higher than the one you assigned in your easy-to-recall scheme. For example, imagine that you configured the Loopback 1 interface on Router10 to use the IP address of 10.10.1.10/32. If the Loopback 1 interface is the only loopback interface on the router, you have little to worry about in terms of router ID variance. But if another admin comes along, creates a Loopback 2 interface, and assigns it the higher IP address of 10.10.2.1/32, the beautiful and logical addressing scheme you devised above remains intact, but if Router10 were to need a reboot, its router ID would no longer match its documented counterpart. If that admin similarly configures the other routers, it could additionally influence the election of the DR and the BDR.
Thus, the ultimate way to fix the router ID so that it always matches the network documentation and always influences the DR and BDR election in the same way is to manually configure it. If the router ID is manually configured, OSPF will not attempt to create a router ID by using the IP addresses that are configured on the router. You can manually configure a router ID by issuing the router-id ip-address command in router configuration mode, where ip-address is the 32-bit value that you want OSPF to use as the router ID. The value of ip-address does not necessarily need to be an IP address that is configured on a router interface; it simply needs to be a 32-bit dotted-decimal value. But since you’ve already devised that beautiful, logical addressing scheme using loopback interfaces, why not manually assign those same addresses as the router IDs? That way, the scheme you used remains intact even if another admin adds a loopback interface with a higher IP address. And you won’t go to jail for slicing anyone up with the broken shards of glass from the framed CCNA certificate that you flung against the wall in frustration. But you’re not really that guy, are you?
Of course you’re not.
Because now you know how to gracefully fix problems that are caused by inattention to OSPF router IDs.
Are you studying for the CCNA or CCNP exams? Download the NetSim demo and see how we can help you get certified.
Learn more about NetSim Network Simulator.
Photo: Paulo Henrique Rodrigues