Troubleshooting OSPF

  • Article

If an OSPF environment is properly configured, OSPF routers learn all the least cost routes from adjacent OSPF routers after convergence. The exact list of routes added by OSPF to the IP routing table depends, among other factors, on whether or not areas are configured to summarize their routes, whether or not stub areas or totally stubby areas are being used, and whether or not ASBRs and route filtering is being used.

Most OSPF problems are related to the formation of adjacencies, either physical or logical (through virtual links). If adjacencies cannot form, the LSDBs cannot be synchronized and the OSPF routes will not accurately reflect the topology of the internetwork. Other OSPF problems are related to the lack of routes or existence of improper routes in the IP routing table.

Adjacency Is Not Forming

  • Before proceeding, verify that the two neighboring routers should form an adjacency. If the two routers are the only routers on the network, an adjacency should form. If there are more than two routers on the network, adjacencies only form with the DR and BDR. If the two routers have already formed adjacencies with the DR and the BDR, they will not form adjacencies with each other. In this case, their neighbor should appear as 2-way under neighbor state.

  • Ping the neighboring router to ensure basic IP and network connectivity. Use the tracert command to trace the route to the neighboring router. There should not be any routers between the neighboring routers.

  • Use OSPF logging to log errors and warnings to record information about why the adjacency is not forming. To obtain additional information about OSPF processes, enable tracing for the OSPF component. For more information about tracing, see "Routing and Remote Access Service" in this book.

  • Verify that the areas are enabled for authentication and the OSPF interfaces are using the same password. Windows 2000 OSPF routers have authentication enabled by default and the default password is "12345678". Change the authentication to match all neighboring OSPF routers on the same network. The password can vary per network.

  • Verify that the routers are configured for the same Hello Interval and Dead Interval. By default the Hello Interval is 10 seconds and the Dead Interval is 40 seconds.

  • Verify that the routers agree as to whether the area to which the common network belongs is a stub area or not.

  • Verify that the interfaces of the neighboring routers are configured with the same Area ID.

  • If the routers are on a Non-Broadcast Multiple Access (NBMA) network such as X.25 or Frame Relay and the connection to the NBMA network appears as a single adapter (rather than separate adapters for each virtual circuit), their neighbors must be manually configured using the unicast IP address of the neighbor or neighbors to which the link state information needs to be sent. Also verify that Router Priorities are configured so that one router can become the DR for the network.

  • On broadcast networks (Ethernet, Token Ring, FDDI) or NBMA networks (X.25, Frame Relay), verify that all routers do not have a Router Priority of 0. At least one router must have a Router Priority of 1 or greater so that it can become the DR for the network.

  • Verify that IP packet filtering is not preventing the receiving (through input filters) or sending (through output filters) of OSPF messages on the router interfaces enabled for OSPF. OSPF uses the IP protocol number 89.

  • Verify that TCP/IP packet filtering is not preventing the receiving of OSPF messages on the interfaces enabled for OSPF.

  • Verify that the virtual link neighbor routers are configured for the same password, Hello Interval, and Dead Interval.

  • For each router, verify that the virtual link neighbor's Router ID is correctly configured.

  • Verify that both virtual link neighbors are configured for the correct transit area ID.

  • For large internetworks with substantial round-trip delays across the transit area, verify that the re-transmit interval is long enough.

Lack of OSPF Routes or Existence of Improper OSPF Routes

  • If you are not receiving summarized OSPF routes for an area, verify that all the ABRs for the area are configured with the proper {Destination, Network Mask} pairs summarizing that area's routes.

  • If you are receiving both individual and summarized OSPF routes for an area, verify that all the ABRs for the area are configured with the proper {Destination, Network Mask} pairs summarizing that area's routes.

  • If you are not receiving external routes from the ASBR, verify that the source and route filtering configured on the ASBR is not too restrictive, preventing proper routes from being propagated to the OSPF AS. External source and route filtering is configured on the External Routing tab on the properties of the OSPF routing protocol in the Routing and Remote Access snap-in.

  • Verify that all ABRs are either physically connected to the backbone or logically connected to the backbone using a virtual link. There should not be backdoor routers—routers connecting two areas without going through the backbone.