This article will allow you to troubleshoot OSPF problems in a network where multi-area OSPF is configured. Before you go and start troubleshooting for any problems as to why the network is not working as expected, I suggest you read this article from the Intense School website: CCNA Prep: Troubleshooting OSPF.

This tutorial will deal with most of the problems described in the above mentioned article, so reading the article will show you or remind you of OSPF troubleshooting techniques.

I have created two Packet Tracer files:

  • ospf-troubleshooting-init.pkt – this is the starting point when you have a broken network. You will have to use your skills to have all OSPF adjacencies up and routes exchanged between the routers.
  • ospf-troubleshooting-final-working.pkt – this will show you the answers and how the routers should have been configured. You will have text boxes showing what is needed to be done in all the points of the network where misconfiguration was placed on purpose.

The goals of this tutorial are:

  • all possible OSPF adjacencies must be in FULL state.
  • reachability between all four PCs. Just issuing a ping from PC1 towards PC2, PC3 and PC4 and receiving a reply should be enough as a confirmation that you successfully solved all the problems.

Regarding the topology, on every subnet where a PC is connected, the router’s interface has an IP address whose last octet is .1 and last octet of the PC’s IP address is .100. The default gateway of the PC is the router’s IP address.

For instance, on the subnet with PC4: PC1 has the IP address of and R1’s interface IP address is

Each router has a loopback address in the form of x.x.x.x/32, where x is the router number. For instance, the loopback address of R6 is as you can also see on the diagram.

Each subnet between the routers is written on the topology and every router is using as the last octet its router number. The third octet of the subnet is in the form of <lowest_router_number_on_the subnet><highest_router_number_on_the subnet >. For instance, for the subnet between R1 and R5, R1 has and R5 has Another example for the subnet between R4 and R6, R4 has and R6 has


  • a. Any password that you might need to set must be cisco.
  • b. In case you would have to choose between MD5 and clear test authentication (mismatch of the authentication type), you must choose MD5.
  • c. In case the hello and dead interval timers are not matching, use the default values.
  • d. You are not allowed to check the configuration (no show running-config commands).
  • e. You can troubleshoot both ends of a link. For instance, if you are asked to have all OSPF neighbours of R5 in FULL state, you can troubleshoot any of R1, R2, R3 or R6.
  • Task 1 requirements
  • a. All OSPF adjacencies on R5 are in FULL state

    Task 1 verification:

  • a. You should have an identical output as the below one:

    R5#show ip ospf neighbor

    Neighbor ID     Pri State              Dead Time     Address        Interface               0 FULL/ –           00:00:33     Serial0/0/0                 0 FULL/ –           00:00:33      Serial0/1/0               0 FULL/ –           00:00:31     Serial0/1/1               1 FULL/BDR     00:00:35     FastEthernet0/1

Task 1 hints:

  1. Make sure that the routers on a link are in the same subnet
  2. Make sure that the hello and dead interval timers match
  3. Make sure that the authentication passes (if configured)

Task 2 requirements

  • All OSPF adjacencies on R6 are in FULL state

    Task 2 verification:

  • You should have an identical output as the below one:

    R6#show ip ospf neighbor

    Neighbor ID   Pri State            Dead Time   Address       Interface             1 FULL/BDR    00:00:35    FastEthernet0/1             0 FULL/ –          00:00:35    Serial0/1/0               0 FULL/ –          00:00:35     Serial0/1/1             0 FULL/ –          00:00:35    Serial0/0/0

Task 2 hints:

  1. Make sure that the routers on a link are in the same area
  2. Make sure that all interfaces over with OSPF should run are up
  3. Make sure that the stub flag is identical (in case any area is configured as stub, make it normal area)
  4. Make sure that the authentication passes (if configured)

The tasks presented above and which you are going to troubleshoot are the most common configuration errors that can be found in the production networks.

This is just a reiteration of what is needed. For OSPF to build a neighbour relationship, a few requirements have to be met:

  1. Routers must be in the same subnet
  2. Hello and dead timers must match
  3. Router IDs must be unique
  4. Routers must be in the same area
  5. Stub flag must be identical
  6. IP MTU must be identical
  7. Must pass neighbour authentication (if configured)