Open Shortest Path First (OSPF) is one of the most widely used IGP routing protocols. Implementing OSPF may not be a big deal but it is always a big deal to trouble-shoot OSPF. A network engineer has to take care of many aspects of configuration in order to deal with OSPF troubleshooting. And I know all of you are now very comfortable with OPSF implementation (Thanks to previous articles published here about OSPF).

In this article, we are going to learn how to trouble-shoot and resolve OSPF routing. Before i I start, I want to tell you that I made a GNS3 topology for you, which is configured with IP addresses and hostname so you can get the GNS3 file from the download link posted here and start with described configuration in this article.

In the real environment, our OSPF neighborship often goes down, and we have to check some common possible causes for the breakdown. The most common problems with OSPF neighborship are:

  1. Reachability
  2. Neighbors must be in same area
  3. Neighbors must be using same primary subnet
  4. Authentication must be properly implemented on both neighbors (if configured)
  5. Timers (hello and dead interval) must be same on neighbors
  6. MTU (Maximum Transmission Unit) must be same
  7. Router Id must be unique on neighbors
  8. Area flags (stub, nssa NSSA, etc.) must be same on OSPF neighbors


Fig.1 shows a scenario where OSPF is configured with Process_id 1 and Area 1 between two routers, in New York and Washington.

I already configured IP addresses, so just start the devices in GNS3 and enable OSPF routing with the following commands:

NewYork(config)#router ospf 1
NewYork(config-router)#network 12.1.1.1 0.0.0.0 area 1
NewYork(config-router)#network 1.1.1.1 0.0.0.0 area 1

Washington(config)#router ospf 1
Washington(config-router)#network 12.1.1.2 0.0.0.0 area 1
Washington(config-router)#network 2.2.2.2 0.0.0.0 area 1

After configuring the above commands, you will get following log message for OSPF neighborship formation:

“*Mar 1 00:03:44.511: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0/0 from LOADING to FULL, Loading Done”

Okay, for now your OSPF routing is configured, so it’s time to prove OSPF neighborship conditions, which will make you more confident while resolving OSPF issues in a real environment. So let’s start with the first one,

    1. Reachability:: To check this condition, just shut down the serial interface of any router.
      NewYork(config)#int serial 0/0
      NewYork(config-if)#shutdown

You will get this log message: “*Mar 1 00:37:11.335: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

To get your OSPF neighborship up again, bring up your interface:

NewYork(config)#int s0/0
NewYork(config-if)#no shutdown

    1. Neighbor must be in same area: To check this condition, just advertise the serial interface network under OSPF configuration with any area-id other than 1; for example, just configure Router New York as:
      NewYork(config)#router ospf 1
      NewYork(config-router)#network 12.1.1.1 0.0.0.0 area 2

      After advertising the network in area 2, you will see that your neighborship will goes down. Advertise it in area 1 again to form your neighborship.

      And if you use debug ip OSPF adj , you will get the following log message, which indicates mismatch area-id:

      *Mar 1 02:02:30.151: OSPF: Rcv pkt from 12.1.1.2, Serial0/0, area 0.0.0.0

      mismatch area 0.0.0.1 in the header

      Useful Tshoot commands for area mismatch:

      • show ip ospfOSPF interface interface-id (eg- sh ip ospf int s0/0)
      • show ip protocol
      • debug ip ospf adj
    2. Neighbors must be using same primary subnet: definitely, if your neighbor is in a different subnet, then your OSPF neighborship will definitely not be formed because it will not be reachable at all. I don’t think I need to prove this point, since we already covered this at in the reachability section. If you want, then change the serial interface ip address of Router Washington to 13.1.1.2/30 and then check.
    3. Authentication must be properly configured on both neighbors: You can configure three kinds of authentication with OSPF. The first one is Null (use no authentication, just like description), the second one is plain text authentication, and the third one is the most important and widely used “MD5 Authentication.” You can configure OSPF authentications by using the following commands:

      For Null Authentication,
      NewYork(config)#interface s0/0
      NewYork(config-if)#ip ospf authentication null

      For Plain Text Authentication,
      NewYork(config)#interface s0/0
      NewYork(config-if)#ip ospf authentication /* to enable plain text authentication
      NewYork(config-if)#ip ospf authentication-key cisco123 /* to set password

      For MD5 Authentication,
      NewYork(config)#interface s0/0
      NewYork(config-if)#ip ospf authentication message-digest /* to enable md5 authentication.
      NewYork(config-if)#ip ospf message-digest-key 1 md5 cisco123 /to set password

Note: For plain text authentication, key-string (cisco123 in my eg) must be the same on OSPF neighbors but, for MD5 authentication, key-id and key-string must be same (key-id is 1 and key-string is cisco123 in my description)

If OSPF authentication is not properly configured (a mismatch of key-id or key string) then you can debug OSPF adjacency (debug ip ospf adj) and you will get logs for mismatch authentication key, as shown in fig. 2.

Useful Tshoot commands to check OSPF authentication:

      • * show ip OSPF interface interface-id (eg- sh ip ospf int s0/0)
      • * show run interface interface-id (eg – sh run int s0/0)
      • * debug ip ospf adj
    1. OSPF hello and dead intervals must be the same: Timers plays an important role for OSPF neighborship formation. Both hello and dead intervals must match on OSPF neighbors. By default, the hello interval is 10 sec and the dead interval is 40 sec for fast links; for slow links, the hello interval is 30 sec and the dead interval is 120 sec. Fig. 3 displays the output of the “show ip ospf int s0/0” command, where you can check multiple useful configurations.

      To configure OSPF timers:

      NewYork(config)#int s0/0
      NewYork(config-if)#ip ospf hello-interval <1-65535> Seconds
      NewYork(config-if)#ip ospf dead-interval <1-65535> Seconds

Useful Tshoot Commands to show OSPF Timers ::

      • * show ip OSPF interface interface-id (eg- sh ip ospf int s0/0)
      • * show run interface interface-id (eg – sh run int s0/0)
    1. MTU (Maximum Transmission Unit): If the MTU is not the same between OSPF neighbors, then your neighborship can be stuck in exstart state. Fig. 4 shows the result of checking the MTU. And you can change the MTU by using the following commands:

Washington(config)#int s0/0
Washington(config-if)#ip mtu 1490
Washington(config-if)#shut /* MTU takes effect only with reload so reload interface
Washington(config-if)#no shut

Note: You will get a Log message for MTU mismatch like “*Mar 1 01:02:40.955: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0 from EXCHANGE to DOWN, Neighbor Down: Too many retransmissions”

But it is always better to use “ip opsf mtu-ignore” for an interface which is configured with least MTU.

    1. Router-Id must be unique on neighbors: If the OSPF router-id is the same on neighbors, then they will not form an OSPF neighborship and you will get OSPF detected duplicate router-id log message, as follows:

Log Message for same router-id
“*Mar 1 01:15:42.855: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 12.1.1.1 on interface Serial0/0

Useful Tshoot commands to check the OSPF router-id:

      • * show ip ospfOSPF interface interface-id (eg- sh ip ospf int s0/0)
      • * show ip protocol

    1. Area flags (stub, NSSA, etc.) must be the same on OSPF neighbors: if an area is configured as stub or NSSA, then OSPF neighbors must be configured with the same area flag. Fig. 6 shows the output of “show ip protocol” that results when an area is configured as stub.

Note: OSPF network type should the same on neighbors for proper OSPF database exchange.

There are many commands to check OSPF status and configuration, but I personally recommend the following commonly used commands that will help you to troubleshoot most OSPF issues.

For neighbor relationships, local configuration issues, and routing problems you can use the following commands for OSPF troubleshooting.

    1. * show ip ospf neighbors—Displays adjacent neighbors, router ID of neighbors, neighbor state/DR-BDR state, IP addresses/interfaces, and dead time of neighbors.
    2. * show ip ospf interfaces—Displays OSPF interfaces. You can also use “show ip ospf int

      interface-id” for eg. sh ip ospf s0/0, as shown in Fig. 3.

    3. * show ip protocols—You can check OSPF process-id, status, and networks that are being advertised and, most important, you can check the router-id with this command. It also provide information for area types configured (normal, stub, NSSA, etc.)

For missing routes and filtering problems, you can use following commands to resolve OSPF issues:

    1. * show ip ospf database—Displays LSA types per area, advertising router, Link ID (subnet), and age.
    2. * show ip route ospf—Displays OSPF routes that are being received from neighbors and their administrative distances, with cost.

The following debug commands can also useful in troubleshooting OSPF issues:

    1. * debug ip ospf adjacency is used to debug neighbor adjacencies
    2. * debug ip ospf events is used to debug OSPF network events

I always enjoy technology with my work and, day to day. I try to make it easier so everyone can understand it. I personally believe that, without understanding, one cannot be comfortable with technologies.

If you really like this article, then please say thanks to intenseschool.com for providing you with such technologies from the best of technical professionals from all over the world.

References :