Content

| 5.7 |  | Troubleshooting OSPF |
| 5.7.1 |  | Mismatched parameters |

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.