Even Jeff Doyle tells me that I should do a little blogging with OSPF. What’s a networker to do with that kind of backing? 😉 And a few others expressed some interest as well – in understanding LSAs better, in multi-area designs, in deciphering some of the show commands, and in some of the oddball cases.
When prepping for a Cisco exam that covers OSPF – which is several of them – you need be ready to notice whether a pair of routers that share the same layer 2 network (same VLAN, same FR PVC, same pt-pt link…) can become neighbors. Once the two routers are neighbors, they can exchange LSAs (or not), depending on other factors. But as the learning theorists would say, becoming neighbors is necessary but not sufficient for routers to use OSPF to learn routes.
The problem is that if you know how to learn how to configure OSPF correctly, you avoid the issues that prevent OSPF neighborships. But for Cisco exams, you need to be ready to analyze existing config problems in some questions. There are items that must match between two routers, and just as important, items that appear to impact neighborship but do not.
So, if you haven’t looked at my last post, and want to give it a shot before looking at the list of things that prevent OSPF neighborship, then go here now. When you’re ready, go to page 2 of today’s post for the list and the explanation of that part of my last post.
For the rest of today’s post, I’m going to give the generic rules about what must be true to become neighbors, as well as the rules about choosing OSPF RIDs. So…here’s a list of what must be true for OSPF neighborship:
- OSPF must be enabled on the interfaces on each router that are connected to the same layer 2 network (w/ the network command).
- The neighboring primary IP addresses and masks must be in the same subnet.
- Authentication must pass
- Interfaces must be in the same area
- Areas must have the same area type (stubby, NSSA, etc)
- Must NOT have duplicate RIDs
- OSPF Hello and Dead timers must match on the two routers
Additionally, there are a couple of items that appear to be an issue, but are not. In particular:
- The OSPF process ID (on the router ospf command) do not have to match.
- Must use the same reference bandwidth (ip ospf reference-bandwidth command)
So, here’s what matters to the discussion I started in the previous post. First, there’s no authentication, and the Hello/Dead timers are all defaulted, so those items do not matter. Each router has a network command that enables OSPF on the Fa0/0 interfaces on each router, and in each case, those network commands list “area 0”, so all three routers’ Fa0/0 interface has been assigned to area 0. There’s no config related to OSPF area types, so that shouldn’t be a problem. That leaves us to think about whether the primary IP addresses are on the same subnet, and the check for the RIDs.
First, for the Router IDs. OSPF Router IDs are set based on the following:
1) The router-id subcommand,
2) The numerically highest IP address of any up/up loopback interface
3) The numerically highest IP address of any up/up non-loopback interface
For the above, the choice is made when the OSPF process is initialized.
That’s enough to answer the “which routers become neighbors” and “which routers use which RIDs” questions I posed in the previous post. I’ll give you a few days, and then post the conclusions on this part of the question. Then I’ll hit some more on the LSA types.
