You will learn that IS-IS and OSPF have quite a few optional capabilitiesparticularly OSPF. Before two neighbors that have discovered each other can begin exchanging routing information, they must ensure that they understand each other’s capabilities. Otherwise, some of the information exchanged might be misunderstood, or interpreted differently between the two neighbors, resulting in inaccurate or broken routing. Additionally, the neighbors must ensure that they agree on some basic parameters such as that they are on the same IP subnet, that their interface MTUs are the same, how often each neighbor should expect a Hello message from the other, and so on.
To ensure that two IS-IS or OSPF neighbors can reliably exchange routing information, they form an adjacency. An adjacency can be thought of as a negotiated agreement between neighbors that essential subnet parameters match and that the information they exchange will be correctly interpreted. If the two neighbors cannot agree on a defined set of parameters and options, they do not become adjacent and they do not consider each other as valid next hops toward other routers.
After discovering a neighbor, an OSPF router must verify that bidirectional communication is possible with the neighbor, through a mechanism called three-way handshaking. Figure 4.20 expands on the basic example of three-way handshaking . RB has just become active on the subnet shared with RA, and is not yet aware of RA. So, in its first Hello, the neighbor list is empty. RA, having received that first Hello from RB, sends a Hello of its own. Notice that it includes RB’s RID in its neighbor list. RB, when it receives the Hello, not only has discovered RA but sees its RID in the neighbor list and knows that there is two-way communication with RA. In the third Hello shown, RB has added RA’s RID to the neighbor list. When RA receives this Hello, it likewise knows that two-way communication with RB is established.
Figure 4.20. Three-way handshaking verifies two-way communication.
After two-way communication is established, and if the network type connecting the two neighbors is broadcast or nonbroadcast multi-access (NBMA), a designated router and backup designated router election is performed.
Next, the neighbors decide whether an adjacency should be formed between them. If the network type connecting them is point to point, point to multipoint, or a virtual link the routers should form an adjacency. If the network type is broadcast or NBMA, an additional consideration is made: An adjacency is formed only if one of the neighbors is a DR or BDR.
If the two neighbors decide that an adjacency should be formed, they begin synchronizing their link state databases. Only after the databases are synchronized are OSPF neighbors fully adjacent. In OSPF, both the neighbor relationships and the database synchronization are driven by state machines
Throughout the OSPF adjacency formation process, from neighbor discovery to database synchronization, certain parameters must be verified as matching. If any of them do not, the adjacency is not established. Most of these parameters are in the Hello messages, and are checked when a neighbor’s Hello is received. First, the IP header and OSPF headers of the Hello packet are checked for validity. Next, the values in the Hello Interval and Router Dead Interval fields are checked. If these values do not match the values of the receiving interface, no adjacency is formed. On all network types except point-to-point and virtual links, the Network Mask is also checked and must match the mask configured on the interface. On point-to-point networks and virtual links, the Network Mask field is ignored.
In addition to such standard parameters that must match between any two OSPF neighbors, certain optional capabilities, if supported by one neighbor, must be supported by the other neighbor. A router indicates which optional capabilities it supports in the Options field The Options field appears not only in the Hello message header, but also in the headers of Database Description packets and all LSAs. As this varied appearance might indicate, flags in this field are examined at various points during the database synchronization and adjacency process. Some options must match for a neighbor’s Hello packets to be accepted at all, whereas other mismatched options can be ignored or negotiated between the neighbors .
After examining the parameters carried in the Hello message, a decision is made whether to continue attempting to form an adjacency. If the decision is positive, the Hello messages provide input events to the OSPF neighbor state machine and the adjacency process continues.