For OSPF to form and maintain neighbor adjacencies, several parameters must
match. OSPF neighbors exchange Hello packets periodically to form neighbor
relationships. If specific parameters do not match, the neighbor adjacency will
not be formed and the routers will not exchange OSPF updates.

Most
mismatch issues can be seen using the debug ip ospf adj
command.
Hello/Dead Interval Mismatch
The output of R2
debug ip ospf adj, when the neighbor Hello interval does
not match with Router R2, is shown in Figure
.
R refers to "Received" and C refers to
"Configured". Figure
shows the
configuration of routers R1 and R2. R2 has the default Hello interval of 10
seconds, whereas R1 has been configured with the Hello interval of 15 seconds.
Both the Hello and the Dead intervals must match for routers to form an
adjacency.
Figure
shows the
corrected configuration of R1. Figure
displays the
output of the show ip ospf neighbor command. This shows
that after configuring the same Hello interval, OSPF forms an adjacency.
Mismatched Authentication Type
The output of R2 debug ip
ospf adj
indicates that
the R2 neighbor is configured for MD5 authentication and that R2 is configured
for plain-text authentication. In Figure
, the
configurations of routers R1 and R2 show that both are using different
authentication methods.
To fix this problem, both routers must be
configured to use the same type of authentication, which can be verified using
the show ip ospf neighbor command.

 |
NOTE:
Besides the authentication type, the authentication key must also
match. Beginning with Cisco IOS 12.0.8, RFC 2328 is now supported, which allows
authentication to be configured on a per-interface basis. Prior to this
release, authentication was only supported on a per-area basis.
|
Mismatch Area ID
OSPF sends area information in Hello
packets. If both sides do not agree that both routers are members of a common
area, no OSPF adjacency will be formed. The area information is part of the
OSPF protocol header.
The output of debug ip ospf
adj on R1, as shown in Figure
, indicates that
R1 is receiving an OSPF packet from R2 and that the OSPF header has area
0.0.0.1. Looking at the configurations on both routers, shown in Figure
proves that the two routers are configured for different areas.
The solution to this problem is to configure the same area across this
common link. To solve this problem, change the area of router R1 to area 1.
Using the show ip ospf neighbor command will verify that
the routers have formed a neighbor relationship.

Mismatched Stub/Transit/NSSA Area Options
When OSPF exchanges
Hello packets with a neighbor, one of the things that it exchanges is an
optional capability represented by 8 bits. One of the option fields is for the
E bit, which is the OSPF stub flag. When the E bit is set to 0, the area with
which the route is associated is a stub area, and no external LSAs are allowed
in this area.
If the E bit does not match on both sides, an adjacency will not be formed.
This is called an optional capabilities mismatch.
The output of
debug ip ospf adj on R1
indicates a
stub/transit bit mismatch. Figure
verifies the
configuration mismatch.
The solution would be to configure the routers
with the appropriate stub commands. A configuration change on R1 that fixes the
problem is shown in Figure
. Router R1 is
now also a part of the stub area. Using the show ip ospf
neighbor command will verify that the routers have formed a neighbor
relationship.
