After reading the first two parts of the OSPF series, you should have a good understanding of the OSPF protocol, enough to know how it works and how you can configure its features which are necessary for the CCNA exam.

The next step will be to get familiar with OSPF troubleshooting methods and the commands that will be the most helpful to find the problem which is presented to you.

CCNA Training – Resources (Intense)

This is useful not only for any CCNA exam candidate, but also in any situation where you will have to manage a network where OSPF is used as interior gateway protocol.

Everything is nice and good when you have network connectivity and routing tables look as you expect. But what happens when users start to complain that they cannot access various destinations?

Let’s suppose that you are the administrator of a network with this topology:

Host1 — R1 — R2 — R3 — Host2

Host1 then tells you that they cannot reach Host2.

What do you do? You start by investigating the routing table of R1 and checking if the Host2 route is present there. If it’s there, then the problem is on the segment between Host1 and R1. Otherwise, you jump on R2 and check the existence of the Host2 route.

Let’s suppose that the Host2 route is there, which obviously means there’s a problem between R1 and R2.

What problems can cause the Host2 route to be missing from the R1 table?

  1. R1 is not running the routing protocol on the interface towards R2.
  2. R1 is running the routing protocol on the interface towards R2, but the adjacency between them to exchange routes is not formed.
  3. The adjacency is formed, but the Host2 route is not sent by R2.
  4. The Host2 route is sent by R2, but is not installed in R1 routing table.

All these represent generic steps to be taken when you troubleshoot a routing protocol.

Although it’s not always possible because you might not be in control of all devices, the first step you should take would be to examine the configuration of the devices. Check the routing protocol configuration and the interface’s IP addresses to make sure that you’re running the routing problems on the intended interfaces. Often, a small typo in the ‘network’ statement can lead to a lot of time wasted on troubleshooting and can be fixed quickly by comparing the configuration.

However, knowing the appropriate ‘show’ and ‘debug’ commands specific for each routing protocol will also help you find the problem and fix it.

This article focuses on how to troubleshoot the OSPF protocol using ‘show’ and ‘debug’ commands. To make things more interesting, we’re not allowed to view the configuration of the routing protocols, unless it’s for verification.

Right after OSPF has been enabled on a particular interface, the router will start to discover neighbours and form neighbour relationships with each router with whom it shares a common subnet.

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).

We will use a topology with five routers as shown below to show how we can check if neighbour relationship requirements are met by using ‘show’ and ‘debug’ commands.

The routers should have been configured based on how the topology looks like: R1 and R2 are internal routers to Area 1, R3 is ABR, R4 and R5 are backbone routers. Additionally, the OSPF neighbour relationship is secured by using MD5 authentication with the key ‘cisco’ and each router has a loopback interface using this schema addressing: Rx=x.x.x.x/32. For instance, R1 has a loopback interface configured with the IP address 1.1.1.1/32.

At the end of the troubleshooting scenario, each router will have all the loopback interfaces of the other routers in the routing table.

Let’s start with R1 and check the OSPF routes from the routing table:

So, we don’t have any OSPF routes. The next step will be to check the OSPF adjacencies:

Now we know why we don’t have any OSPF routes. This is because we don’t have any OSPF adjacency formed with R2. Though we have one out of two, it is in EXCHANGE state, not in FULL state.

When you see a neighbour relationship which is in EXCHANGE state, then the most probable cause is the IP MTU mismatch between the two OSPF routers.

One way of verifying this is to with the debug command: debug ip ospf adj.

Here is the output:

The last message from the debug log says that neighbour 2.2.2.2 (which is R2) has a larger MTU. Let’s check R1 Serial0/0 and R2 Serial0/0 interfaces configuration:

As we suspected, the MTU is different on R1 and R2. By default, the MTU is 1500, so let’s remove the MTU configuration from R1 Serial0/0:

As you can see, OSPF is now up between R1 S0/0 and R2 S0/0. But we have another interface over which OSPF is configured. This is Serial0/1 and the Neighbours count shows 0:

When we initially checked the state of the OSPF neighbours, we saw only one neighbour in EXCHANGE state. This means that the information present in the hello packet to pass the neighbour relationship requirement was agreed by the remote router. This is not the case with the OSPF neighbour relationship over Serial0/1, because it didn’t appear in ‘show ip ospf neighbor’ output.

Therefore, something in the hello packet makes the OSPF adjacency not to come up.

‘show ip ospf interface’ should give us more information about the OSPF parameters that are configured on an interface.

Let’s analyze the output from both R1 and R2:

Both interfaces are configured in the same subnet and in the same area. Each router has a different Router ID. The two lines below let us check the configured hello and dead intervals.

Just one second, R1 has a hello of 10 seconds and a dead interval of 40 seconds (the default) while R2 has a hello of 5 seconds and a dead interval of 20 seconds.

As said in the beginning, hello and dead intervals must match.

Let’s configure the default values on R2 and see if the OSPF adjacency comes up:

Right just after we changed the configuration, the OSPF adjacency between R1 and R2 over Serial0/1 came up.

Let’s check if R2 Loopback0 IP address (2.2.2.2) is present in the R1 routing table:

Another way to identify the mismatched hello timers is to enable OSPF hello debug using the command ‘debug ip ospf hello’. Below is the output when there was a mismatch of hello timers:

‘R’means received, and in this case R1 received a dead interval timer of 20 seconds, while ‘C’ means configured, which in this case R1 was configured with a dead interval of 40 seconds.

Let’s check the routing table of R2:

R2 has only one OSPF route, the Loopback interface of R1. By checking the neighbours’ status, we see that OSPF is down between R2 and R3.

As we don’t see the R3 at all in the neighbour list, let’s enable ‘debug ip ospf hello’ and see if there is any mismatch in the hello packets:

Nothing obvious here. Let’s go further and enable ‘debug ip ospf adj’ and check the output:

We found the problem. It seems that the authentication requirement wasn’t met.

As you should know:

  1. Type 0 is no authentication.
  2. Type 1 is clear text authentication.
  3. Type 2 is MD5 authentication.

In this particular case, it seems that R3 (10.10.23.3) was configured with clear text authentication instead of MD5 authentication.

One way to check the authentication configured on an interface is using the ‘show ip ospf interface’command.

On R1, we have configured MD5 (message digest) authentication:

But on R3, we have configured clear text (simple text) authentication:

Let’s fix the configuration error from R3 and see if OSPF comes up between R2 and R3:

Now that we fixed the authentication problem between R2 and R3, we can see that OSPF adjacency came up and we should have more OSPF routes in the routing table of R2:

If you take a look at the topology, you’ll see that we have five routers in the network. Analyzing the routing table of R2 regarding the OSPF routes, we notice that the R4 Loopback interface IP address (4.4.4.4/32) is missing.

Let’s check the routing table of R2 one more time:

What just happened? It seems that the R4 Loopback is present now, but the R5 Loopback IP address (5.5.5.5/32) is missing.

One more time:

Now the R5 Loopback is present, but not the R4 Loopback. As you can see, there is a constant flapping of the two networks.

For both 4.4.4.4/32 and 5.5.5.5/32, the next-hop IP address is R3 (10.10.23.3). Therefore, we need to check the OSPF operation and routing table on R3:

We see the same behaviour here: we cannot have both 4.4.4.4/32 and 5.5.5.5/32 routes in the routing table at the same time.

Usually, in an OSPF domain, when you are not doing any redistribution and you see this sort of route flapping in the routing table, you should make sure that Router ID uniqueness is met.

Let’s check the R3 OSPF neighbours:

R3 should have 5.5.5.5 as neighbours over two interfaces: Serial2/0 and FastEthernet1/0, therefore 2 neighbours with Router IDs of 5.5.5.5.

On interface Serial2/0, the IP address of the router with Router ID 5.5.5.5 should be 10.10.35.5 and on interface FastEthernet1/0, the IP address of the router with Router ID 5.5.5.5 should be 10.10.0.5.

But we have another router with Router ID 5.5.5.5 with the IP address 10.10.0.4, which is R4.

Let’s check the Router ID of both R4 and R5:

As you can see, both of them have the same Router ID: 5.5.5.5 which leads to the problem of route flapping. Because both of them have the same Router ID, an OSPF adjacency cannot be formed between the two of them:

Let’s check the OSPF configuration on R4 and modify it:

All problems have been fixed now and in the routing table of R1, we should see all the Loopback interfaces of all the routers in the network:

We have seen various situations where the neighbour relationship requirements were not met. Let’s review all OSPF requirements and how you can check them using ‘show’ and ‘debug’ commands:

  1. Routers must be in the same subnet.
  • show interfaces, debug ip ospf hello
  1. Hello and dead timers must match.
  • show ip ospf interface, debug ip ospf hello
  1. Router IDs must be unique.
  • show ip ospf, show ip ospf interface
  1. Routers must be in the same area.
  • show ip ospf interface, debug ip ospf adj
  1. Stub flag must be identical.
  • show ip ospf, debug ip ospf hello
  1. IP MTU must be identical.
  • show interfaces, debug ip ospf adj
  1. Must pass neighbour authentication (if configured).
  • show ip ospf interface, debug ip ospf adj