Troubleshooting OSPF

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Troubleshooting OSPF

What problem are you having?

  • OSPF adjacency is not forming.

  • A virtual link is not forming.

  • Lack of OSPF routes or existence of improper OSPF routes.

OSPF adjacency is not forming.

Cause:  OSPF is not enabled on the interface.

Solution:  Verify that OSPF is enabled on the interface on the network segment where an adjacency should form. By default, when you add an interface to the OSPF routing protocol, OSPF is disabled for the interface and must be manually enabled.

See also:  Verify that OSPF is enabled

Cause:  Adjacency should not form.

Solution:  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 designated router (DR) and backup designated router (BDR). If the two routers have already formed adjacencies with the DR and the BDR, they cannot form adjacencies with each other. In this case, the neighbor should appear as 2-way under Neighbor State (in the Neighbors dialog box from IP Routing\General).

See also:  View routing tables

Cause:  No IP connectivity to a neighboring router.

Solution:  Ping the neighboring router to ensure basic IP and network connectivity. You can use the tracert command to trace the route to the neighboring router. There should not be any routers between the neighboring routers.

See also:  Using the ping command; Using the tracert command

Cause:  Adjacency cannot form because of mismatched OSPF configuration.

Solution:  Use OSPF logging to log errors and warnings to record information on why the adjacency is not forming.

See also:  Using event logging

Cause:  Mismatched authentication setting or mismatched passwords.

Solution:  Verify that the areas are enabled for authentication and the OSPF interfaces are using the same password. Servers running Routing and Remote Access configured to act as OSPF routers have authentication enabled by default and the default password is 12345678. You need to change the authentication to match all neighboring OSPF routers on the same network. The password can vary per network.

See also:  Create an OSPF area; Set a password on an OSPF interface

Cause:  The neighboring routers are not configured for the same hello or dead interval.

Solution:  Verify that the neighboring routers are configured for the same hello and dead intervals. By default the hello interval is 10 seconds and the dead interval is 40 seconds.

See also:  Configure the hello and dead intervals

Cause:  Mismatched stub area configuration on neighboring routers.

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

See also:  Create an OSPF area

Cause:  Neighboring routers have mismatched Area IDs.

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

See also:  Create an OSPF area

Cause:  Non-Broadcast Multiple Access (NBMA) interfaces are not configured with OSPF neighbors.

Solution:  If the routers are on a NBMA network such as X.25 or Frame Relay that operate in single interface mode, their neighbors must be manually configured by using the unicast IP address of the neighbor or neighbors to which the OSPF packets need to be sent.

See also:  Add an OSPF neighbor; OSPF design considerations

Cause:  All router interfaces are set to a router priority of 0.

Solution:  On broadcast networks (Ethernet, token ring, FDDI) or NBMA networks (X.25 and Frame Relay operating in single interface mode), 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.

See also:  Configure an OSPF interface

Cause:  IP packet filtering is preventing the receiving (through input filters) or sending (through output filters) of OSPF traffic.

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

See also:  Manage Packet Filters

Cause:  TCP/IP filtering is preventing the receiving of OSPF traffic.

Solution:  Verify that TCP/IP filtering on the router interfaces is not preventing the receiving of OSPF traffic. OSPF traffic uses IP protocol number 89.

See also:  Configure TCP/IP to use TCP/IP filtering

Cause:  Mismatched configuration of password, hello interval, or dead interval.

Solution:  Verify that the virtual link neighbor routers are configured for the same password, hello interval, and dead interval.

See also:  Add a virtual interface

Cause:  The router ID of the virtual link neighbor is configured incorrectly.

Solution:  For each router, verify that the router ID of the virtual link neighbor is correctly configured. The router ID is found on the General tab on the properties of the OSPF routing protocol.

See also:  Add a virtual interface

Cause:  Virtual link neighbors are configured for the incorrect transit area ID.

Solution:  Verify that both virtual link neighbors are configured for the same correct transit area ID.

See also:  Add a virtual interface

Cause:  The retransmit interval is not long enough.

Solution:  For large internetworks with substantial round-trip delays across the transit area, verify that the retransmit interval is long enough.

See also:  Add a virtual interface

Lack of OSPF routes or existence of improper OSPF routes.

Cause:  Not receiving summarized routes.

Solution:  If you are not receiving summarized OSPF routes for an area, verify that the area border routers (ABRs) for the area are configured with the proper {Destination, Network mask} pairs summarizing that area's routes.

See also:  Configure ranges for an OSPF area

Cause:  You are receiving both individual and summarized OSPF routes for an area.

Solution:  Verify that all the ABRs for the area are configured with the proper {Destination, Network mask} pairs summarizing that area's routes.

See also:  Configure ranges for an OSPF area

Cause:  You are not receiving external routes from the autonomous system boundary router (ASBR).

Solution:  Verify that the source and route filtering that is configured on the ASBR is not too restrictive, preventing proper routes from being propagated to the OSPF autonomous system. External source and route filtering is configured on the External Routing tab on the properties of the OSPF routing protocol.

See also:  Configure an ASBR

Cause:  All ABRs are not connected to the backbone.

Solution:  Verify that all ABRs are either physically connected to the backbone or logically connected to the backbone by using a virtual link. There should not be backdoor routers, which are routers that connect two areas without going through the backbone.

Notes

  • This feature is not available on the Itanium-based versions of the Windows operating systems.

  • This content is not available in this preliminary release.

  • For more information, see "Unicast IP Routing" at the Microsoft Windows Resource Kits Web site.