I don’t know if you’re like me, but I seem to always mix up the neighbor relationship requirements of OSPF and EIGRP if I haven’t been recently studying the topic. I’d like to do a quick review so that we both have a new frame of reference and something we can quickly come back to if need be. Let’s begin!
The first step on the path to a device becoming a participating member of the Link State Database and Shortest Path Tree is to become neighbors with the adjacent OSPF speaking devices on the network. Whether or not they become adjacent is another story, for this post we’ll focus on the neighborship. To start this process hello packets are sent out of all OSPF enabled interfaces. Bi-directional communication with a neighbor is realized when the router sees itself listed in a received hello packet. RFC 2328 indicates the following parameters must be evaluated prior to packets being accepted at the IP level. I’ve included only the checks necessary for becoming a neighbor. Assuming the IP checksum is correct the packet must be destined for either the ip address of the receiving interface or the ALLSPFrouters or ALLDRouters multicast addresses, 224.0.0.5 and 224.0.0.6 respectively. The IP protocol must be OSPF (89) and the version field must specify protocol version 2. The area ID must be verified and is expected to match the area ID of the receiving interface otherwise the packet is discarded. There are a few additional properties of the interface that must be considered so let’s take a closer look at the interface data structure.
There are many elements of the (ospf) interface configuration that are relevant to the ospf neighborship and adjacency process however I will highlight a few of the parameters that must match or have an expected value in order to become a neighbor.
- First the IP address and mask must be consistent with the network on the datalink
- The Area ID indicates what area the attached network belongs to and must match on the receiving interface as indicated before.
- The HelloInterval and RouterDeadInterval must be common between all routers attached to a common network.
- If the AuType (authentication) is not set to zero or null, then the authentication key must match.
I mentioned earlier that I often confuse the requirements of OSPF and EIGRP, and that mainly surrounds number three in the above list. The hello and hold timers in do not have to match for two routers to become an EIGRP neighbor, while in OSPF they are required to be the same. While they don’t have to be the same in EIGRP it is considered best practice to make them consistent. One last thing I’ll mention here that isn’t a requirement for establishing the initial neighbor relationship but is an important factor in the data plane functioning properly is the router-id. These two values must be unique between two routers otherwise the LSDB will have entries from two different sources with the same router-id and there will be many issues with the data plane. This is a little easier to catch if the two routers are adjacent but if they are not it may not be immediately evident that you’re headed for trouble.
The good thing is, for testing OSPF you can pretty much enable it on two routers that share a datalink and the default values will be enough for you to become neighbors and adjacent! Just make sure you match the area-id and you’re good to go. When you’re enabling OSPF you must supply a process id which does not need to match with your neighboring routers process id.
Well i hope you enjoyed this short article on OSPF neighbors, feel free to leave a question or comment below!
~EPerk