By James Hanback
Time for a pop quiz. You have less than one second. Shout out the first term that pops in your head when you examine the following string of characters:
192.168.51.50
Time’s up. It’s an Open Shortest Path First (OSPF) area ID. Specifically, it’s equivalent to the OSPF area ID decimal value of 3232248626.
Were you right? No? Did everyone around you leap out of their seats or cautiously back away from you when you shouted IP ADDRESS at the top of your voice? If you guessed that 192.168.51.50 is an IP address, I suppose I can give you credit (that credit might not be enough to calm the jangled nerves of your family or co-workers if you were inconsiderate enough to literally shout out your answer, though).
You are correct that 192.168.51.50 is a representation of a 32-bit value in dotted decimal format, which is the format we network administrator types have most come to know and love as an IP address. In this case, the dotted decimal value of 192.168.51.50 precisely resembles an IP version 4 (IPv4) address that falls within the range of Class C addresses that is reserved for use on private networks.
However, an IP address is not an OSPF area ID. Nor is an OSPF area ID an IP address. Each of those 32-bit address spaces serves an entirely different purpose. IP addresses are used to enable devices to communicate with one another at Layer 3, or the Network layer, of the Open Systems Interconnection (OSI) model. OSPF areas, on the other hand, are used as a means of logically grouping OSPF routers and segregating those groups within an autonomous system (AS). An area ID identifies the specific group, or area, to which a network or interface belongs. Therefore, OSPF uses area IDs to organize a topology and to determine the neighbor routers to which it should send the packets that build the link-state database (LSDB). The LSDB is stored on each router within the area and is essentially a snapshot of the topology within that area.
“Wait just a minute here,” you might be saying. “I’ve been studying for my CCNA certification and configuring all my practice OSPF network areas by using decimal values. I’ve configured the OSPF network command with area 0 so many times that it’s practically punctuation. Have I been doing it wrong?”
Absolutely not.
It’s perfectly normal for a budding network administrator like you to not only want to configure an OSPF area ID as a decimal value, but to actually do so. In fact, Cisco IOS enables you to configure an area ID as either a decimal value in the range from 0 through 4294967295 or as a dotted decimal value in the range from 0.0.0.0 through 255.255.255.255. Unlike IP addresses, the values of 0.0.0.0 and 255.255.255.255 are perfectly valid values for an OSPF area ID. You can begin the process of proving it to yourself by using the help system on a Cisco router, as shown in the following output:
RouterA(config-router)#network 198.51.100.0 0.0.0.255 area ?
<0-4294967295> OSPF area ID as a decimal value
A.B.C.D OSPF area ID in IP address format
I know. I know. Cisco’s help refers to the dotted decimal format as the IP address format. That’s because the dotted decimal format makes most people think IP address, as was most likely proven by your own answer to my pop quiz. However, it is important to separate the two address spaces in your mind. The dotted decimal OSPF area ID has nothing to do with the IP addresses that you’ve assigned to interfaces, nor has it anything to do with the IP networks that are being advertised within the area.
The last value in the decimal range of possible area IDs, 4294967295, might at first glance appear to be a bizarre or random way to end a range of values. Somehow it just doesn’t feel as satisfying as, say, a range from 0 through 1024, or 4096, or 32768, or 65535. However, if you convert that decimal value to its 32-bit binary equivalent, you get exactly 32 bits, or 11111111111111111111111111111111. If you separate all those bits into octets, you get 11111111.11111111.11111111.11111111. Convert that quartet of octets into dotted decimal format and you get (surprise!) 255.255.255.255, which is the last possible value in the 32-bit dotted decimal range.
Similarly (and perhaps obviously), the decimal area ID value of 0 is equivalent to the dotted decimal area ID value of 0.0.0.0, which is also known as the OSPF backbone area. Therefore, the decimal area ID you configure on an OSPF router is actually equivalent to the dotted decimal value that OSPF sends in packets across the wire. As far as OSPF is concerned, it doesn’t matter if one end of a link is configured with a decimal area ID and the other end is configured with the equivalent dotted decimal area ID. OSPF sees both formats as the same value and will establish an adjacency between neighboring routers even if the area ID is 0 on one end and 0.0.0.0 on the other.
In practice, however, it might look a little strange to configure one end of the link with Area 0 and the other end with Area 0.0.0.0 because Cisco IOS both stores and displays the area ID in the format that you configure, not the area ID calculated from the area ID format you configure. For example, the following output is from RouterA, which is configured to use Area 0, and the neighboring RouterB, which is configured to use Area 0.0.0.0:
RouterA#show ip ospf interface
FastEthernet0/0 is up, line protocol is up
Internet Address 198.51.100.50/24, Area 0
Process ID 100, Router ID 198.51.100.50, Network Type BROADCAST, Cost: 1
<output omitted>
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 198.51.100.51 (Designated Router)
Suppress hello for 0 neighbor(s)
RouterB#show ip ospf interface
FastEthernet0/0 is up, line protocol is up
Internet Address 198.51.100.51/24, Area 0.0.0.0
Process ID 100, Router ID 198.51.100.51, Network Type BROADCAST, Cost: 1
<output omitted>
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 198.51.100.50 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
You can see from the output that RouterA displays the area ID as 0 because it has been configured to use the decimal value of 0. RouterB, on the other hand, displays the area ID as 0.0.0.0 because it has been configured to use the dotted decimal value of 0.0.0.0. Even so, the two routers have successfully established an adjacency.
If you’ve spent any amount of time creating configuration standards in order to make a simpler task of troubleshooting and scaling your organization’s network, your internal standards violation sensor might be making your eyelid twitch right about now. It’s all well and good that OSPF Area 0 is the same as OSPF Area 0.0.0.0, but what if you’re trying to quickly troubleshoot an adjacency issue when RouterA is configured to use Area 3232248626 and RouterB is configured to use Area 192.168.51.50? Unless you have the maddest of in-your-head math skills, you might not be certain that the area IDs match at first glance. The show ip ospf interface command doesn’t display anything weird about the other values that are required to establish an adjacency (we’re looking at you, Hello timer interval and Dead timer interval). So why doesn’t Cisco IOS just pick a standard format in which to display area IDs regardless of the way you’ve configured them? You don’t have time to do all that math just so you can determine if the routers are operating within the same area!
The alternative to tearing your hair out, of course, is to use an IP address to decimal calculator like the Decimal IP Calculator tab that is included with the Boson IP Subnet Calculator. Or you could just establish a configuration standard and stick to it. Or maybe just find a way to frighten away any other OSPF admins who try to muscle in on your standard. Sometimes the only way to enforce a standard is to configure it yourself. All of which is to say that a mix of decimal and dotted decimal area IDs could be disheartening for those of us who appreciate the times when technology can make standardization easy.
However, if you use packet debugging output to monitor OSPF packets as they are received over the wire, it might be comforting to know that OSPF packet debug output is one place in which the area ID will always be displayed in dotted decimal format even if it was configured in decimal format on the sending router. So even if RouterA is configured to use Area 3232248626 and RouterB is configured to use Area 192.168.51.50, the output from the debug ip ospf packet command on each router will always display the Area ID, or aid, value as 192.168.51.50, as shown in the following output:
RouterA#show running-config | begin router ospf
router ospf 100
log-adjacency-changes
network 198.51.100.0 0.0.0.255 area 3232248626
RouterB#show running-config | begin router ospf
router ospf 100
log-adjacency-changes
network 198.51.100.0 0.0.0.255 area 192.168.51.50
RouterA#debug ip ospf packet
OSPF packet debugging is on
*Nov 14 09:28:07.367: OSPF: rcv. v:2 t:1 l:48 rid:198.51.100.51
aid:192.168.51.50 chk:5EA6 aut:0 auk: from FastEthernet0/0
RouterB#debug ip ospf packet
OSPF packet debugging is on
*Nov 14 09:28:12.367: OSPF: rcv. v:2 t:1 l:48 rid:198.51.100.50
aid:192.168.51.50 chk:5EA6 aut:0 auk: from FastEthernet0/0
The above does not apply to the debug ip ospf hello command or the debug ip ospf events command, which always display the area ID in the format in which it is configured. Nor does it apply to the debug ip ospf adj command, which is typically issued before an adjacency is established in order to watch the process.
If you’ve been paying attention, you might notice a couple of other 32-bit dotted decimal values in the output of the debug ip ospf packet command. It is therefore time for a new pop quiz! What are those values? They have to be IP addresses this time, right? Because they’re in the range of IP addresses that RouterA and RouterB are configured to advertise in the sample output?
Alas, you are wrong again.
The value of 198.51.100.50 in the debugging output is RouterA’s OSPF router ID in dotted decimal format. The value of 198.51.100.51 in the debugging output is RouterB’s OSPF router ID in dotted decimal format. However, you can be even more forgiven for assuming IP address as the answer this time. Router IDs are different from OSPF area IDs not only in purpose, but also in that the 32-bit dotted decimal values they use can actually be derived from the IP address configuration on a router.
But that’s a whole different bundle of bits.
