Home Network Layer OSPF Version 2 Troubleshooting OSPF Neighbor Adjacency Problems on Cisco IOS

Troubleshooting OSPF Neighbor Adjacency Problems on Cisco IOS

In this post, you will learn techniques and Cisco IOS commands related to troubleshooting OSPF neighbor adjacency issues. First, I will explain how OSPF nodes form full neighbor relationships and the different states they go through before reaching the Full neighbor state.

Then, I will describe how to troubleshoot OSPF neighbor adjacencies and the different reasons that may cause a neighbor to become down or not reach the Full state.

In addition, I will summarize the Cisco IOS commands used in the troubleshooting process and explain the reasons that cause OSPF neighbor relationships to fail and cause a neighbor to be stuck in a particular state and not reach the Full state.

Upon the completion of this guide, you will be able to answer the following questions:

  • How do I troubleshoot an OSPF neighbor that is down?
  • What must match for two routers to form an OSPF adjacency?
  • How does OSPF establish neighbor relationships?
  • What are the possible causes of OSPF neighbor problems?
  • How does OSPF maintain adjacencies?

In this tutorial, I will be using the following diagram. The routing domain includes three OSPF areas: 0, 15, and 16, which is a stub area. The OSPF router ID values of routers R1, R2, R3, R4, R5, R6, and R7 are 1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4, 5.5.5.5, 6.6.6.6, and 7.7.7.7, respectively.

Besides, we enable OSPF adjacency debugging using the debug ip ospf adj command on all routers in order to display error messages related to OSPF adjacency issues on the network.

You can click the links below to download the initial router configurations.

Router 1 Router 2 Router 3
Router 4 Router 5 Router 6
Router 7

Note: Troubleshooting OSPF route advertisement is beyond the scope of this guide.

Let’s get started.

Table of Contents

Toggle

What Are The Main Conditions for Routers to Form Full OSPF Neighbor Relationships and How an OSPF Adjacency Gets Established?

OSPF neighbor relationship refers to the connection established between two OSPF-enabled devices or routers over a shared network link.

The aim of a full OSPF neighbor relationship is to exchange routing information and ensure that each device has a necessary and up-to-date view of the network topology in order to make routing decisions according to the autonomous system’s routing policy.

An OSPF neighbor relationship is negotiated between a pair of OSPF nodes as if they were connected by a point-to-point link, regardless of whether the current media is multi-access or not. OSPF neighbor relationships cannot be negotiated by more than two routers together.

When an OSPF neighbor relationship reaches the Full state, it is called a full neighbor relationship or an OSPF adjacency.

An OSPF neighbor relationship is established through the exchange of OSPF hello packets, which allows the devices to discover each other and agree on several parameters such as the hello and the dead intervals.

The factors that influence and enable two routers to successfully establish a full OSPF neighbor relationship, other than that both routers should have unique OSPF router IDs and not be DROther nodes, are:

  • Interfaces connecting the routers are in the up/up state.
  • OSPF is enabled on both neighboring interfaces. This can be done using the network command or the ip ospf area command.
  • Both routers have a bidirectional connection, meaning they can receive OSPF packets from each other.
  • Both routers are on the same subnet.
  • The MTU is the same on both neighboring interfaces.
  • The routers use the same hello and dead intervals.
  • OSPF authentication is configured correctly.
  • Neither adjacent interface is passive.
  • Both neighboring interfaces are in the same area.
  • The area type is the same on both routers. OSPF areas can be divided into three types: normal, stub, and NSSA.

Here are some useful guides to learning more about OSPF stub areas:

What Are The OSPF Neighbor Adjacency States in OSPF?

Two OSPF neighbors go through several OSPF neighbor states before reaching the Full state; thus creating an OSPF adjacency, a full OSPF neighbor relationship. These neighbor states are Down, Init, Attempt, 2-Way, ExStart, Exchange, and Loading.

Let’s explain each of these states.

Down: The initial state of each discovered OSPF neighbor whether or not hello packets have been received from it.

When no hellos have been received from an actual OSPF neighbor within the dead interval, the neighbor is placed in the DOWN state and removed from the neighbor table. Note that routers may send hello packets to OSPF routers that are listed as DOWN.

Attempt: On Non-Broadcast Multi-access (NBMA) networks, routers place any manually configured OSPF neighbor in this state immediately after it is originally placed in the DOWN state.

When an OSPF neighbor is in this state, that means no Hello packet has been received from it, but the neighbor continues to receive Hello packets. Finally, the Attempt state applies only to OSPF nodes in (NBMA) networks.

Init: When a router receives a Hello packet that does not contain its own OSPF router ID from an OSPF node, it places that node in the Init neighbor state. For example, if router R1 gets an OSPF Hello packet from R2 that does not include its OSPF router ID, then R1 would put R2 in the Init state.

2-Way: In this state, a bi-directional connection has been established between the two neighbors. This means that each router includes the other neighbor’s router ID in the hello packets sent to it.

In broadcast and NBMA networks, the designated router and the backup designated router are elected from the neighbors in the 2-way or higher. Moreover, DROther routers do not build OSPF adjacencies with each other and get stuck at the 2-Way state. However, they form full OSPF neighbor relationships with the designated router (DR) and the backup designated router (BDR).

On a point-to-point or point-to-multipoint link, each OSPF-enabled router tries to form an OSPF adjacency with each OSPF neighbor on that link.

ExStart: In this state, the two routers that are not both DROthers and have already reached the 2-way state determine the initial DD sequence number and decide which one should be the master in order to start sending DBD packets first.

Exchange: In the exchange state, OSPF routers exchange database descriptor (DBD) packets containing only LSA headers to describe their complete LSDBs. In addition, LS requests can be transmitted in this state to obtain more recent LSAs.

Loading: In the loading state, LS requests and LS updates are sent to retrieve and share specific LSAs depending on the contents of the DBD packets. In addition, all LS update packets are acknowledged.

Full: In this state, the neighbors’ LSDBs are fully synchronized, and the OSPF neighbors’ data is added to the router and network LSAs generated by the neighbors.

Troubleshooting OSPF Neighbor Adjacency Issues: What Would Prevent Two Routers From Forming an OSPF Adjacency?

For two OSPF neighbors to exchange and synchronize their LS databases, they should reach the Full neighbor state. If the neighbors have trouble getting to that neighbor state, this may be the consequence of one of the following reasons:

  • Interface down.
  • OSPF is not enabled on the interface.
  • Mismatched subnets or the OSPF adjacency is negotiated using the current OSPF node’s primary IP address with the neighbor’s secondary IP address.
  • Mismatched MTU values.
  • Mismatched Hello and Dead timers.
  • Mismatched network types.
  • Both OSPF nodes are negotiating an OSPF adjacency over a non-broadcast link using unicast Hellos, and at least one of them is not manually defined using the neighbor command.
  • Misconfigured OSPF authentication.
  • Routers cannot elect a designated router.
  • At least one of the interfaces connecting the routers is passive.
  • Area number mismatch.
  • Mismatched area type
  • An ACL is blocking OSPF Hello packets.
  • Duplicate OSPF router IDs.

Now, let’s explain each of them and look at the ways to solve these OSPF neighbor issues.

Interface Down

A router interface can be down because of a bad cable, the use of the shutdown command, a non-working switch port connected to a neighbor’s interface or both adjacent interfaces, and Layer 2 protocol problems such as a failed PPP authentication.

You can use the show interfaces and show ip interface commands to determine whether a particular interface is down and whether it has Layer 1 or Layer 2 problems.

First, we check to see if the interface is up, and then we check the interface’s Layer 2 status to verify that the underlying Layer 2 protocol is up.

R10# show interfaces serial 1/0
Serial1/0 is up, line protocol is up 
  Hardware is M4T
  Internet address is 10.0.120.10/24
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, crc 16, loopback not set

omitted output

The second line is the previous example includes the string “Serial1/0 is up”, meaning the interface has no issues at Layer 1; otherwise, the interface has physical problems, or it was disabled using the shutdown command, and in this case, Cisco IOS will display the text “line protocol is down”, as shown in the next show interfaces command output.

The string “line protocol is up” indicates that the interface’s Layer 2 protocol is working, meaning there are no issues at Layer 1.

In this example, the show interfaces command output tells that the interface is working, but the underlying Layer 2 protocol is failing.

R1# show interfaces serial 1/0
Serial1/0 is up, line protocol is down
  Hardware is M4T
  Internet address is 10.0.12.1/24

omitted output

To solve this issue, use necessary Cisco IOS commands so that the failed interface becomes in the up/up state depending on the cause of the problem. For example, issue the shutdown command if the interface was administratively shut down.

Let’s diagnose OSPF on the link between R1 and R2. The show ip ospf interface outputs below indicate that the interfaces connecting R1 and R2 are well configured according to the criteria discussed above, except that we cannot tell if an ACL is blocking OSPF Hellos, there is an MTU mismatch, or area type mismatch.

Besides, R1’s GigabitEthernet 0/2 interface is administratively down. Therefore, that interface might be the reason why routers R1 and R2 cannot establish an OSPF adjacency.

Router R1

R1# show ip ospf interface gigabitEthernet 0/2
GigabitEthernet0/2 is administratively down, line protocol is down
Internet Address 10.0.12.1/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State DOWN, Priority 1
No designated router on this network
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40

Router R2

R2# show ip ospf interface gigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up 
Internet Address 10.0.12.2/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 2.2.2.2, Interface address 10.0.12.2
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

omitted output

In this example, we enable the R1’s GigabitEthernet 0/2 interface by issuing the no shutdown command.

R1(config)# interface gigabitEthernet 0/2
R1(config-if)# no shutdown

The show ip ospf neighbor command output states that R1 and R2 are now able to form a full OSPF neighbor relationship.

R1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:38 10.0.12.2 GigabitEthernet0/2

OSPF is Not Enabled on The Interface

This problem can be caused by misconfigured network or ip ospf commands. As a result, hello packets are not sent over the correct interfaces, or router interfaces are associated with the wrong areas; thus the router is unable to discover neighbors and form OSPF adjacencies over those interfaces.

To verify that an interface is participating in OSPF and is associated with the correct area, use the show ip ospf interface command or the show ip ospf interface brief command in enable mode.

These examples indicate that OSPF is not enabled on R2’s GigabitEthernet 0/7 interface, connected to R7, while R7’s GigabitEthernet 0/2 interface is advertised into area 0 as mentioned in the network diagram. Therefore, R2 and R7 cannot form an OSPF adjacency.

R2# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi0/3 1 0 10.0.23.2/24 1 DR 0/0
Gi0/1 1 0 10.0.12.2/24 1 DR 1/1

R7# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi0/1 1 0 10.0.17.7/24 1 DR 0/0
Gi0/5 1 0 10.0.57.7/24 1 DR 0/0
Gi0/4 1 0 10.0.47.7/24 1 DR 0/0
Gi0/3 1 0 10.0.37.7/24 1 DR 0/1
Gi0/2 1 0 10.0.27.7/24 1 DR 0/0

Since the GigabitEthernet 0/7 interface does not appear in the show ip ospf interface brief command, the ip ospf area command is not applied to the interface and there is no network statement that matches that interface.

In fact, this example illustrates that there is no network command that matches interface GigabitEthernet 0/7 in R2’s OSPF configuration. The show ip protocols command lists all network statements under the Routing for Networks section.

R2# show ip protocols

omitted output

Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 2.2.2.2
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.0.12.2 0.0.0.0 area 0
10.0.23.2 0.0.0.0 area 0
Routing Information Sources:
Gateway Distance Last Update
7.7.7.7 110 03:54:28
1.1.1.1 110 04:28:58
Distance: (default is 110)

To solve this issue, we can either use the ip ospf area command or the network command to place the interface in question in area 0 under OSPF instance 1. This example adds R2’s GigabitEthernet 0/7 to area 0.

R2(config)# interface gigabitEthernet 0/7
R2(config-if)# ip ospf 1 area 0

The show ip ospf neigbor command output states that the issue has been fixed, and the routers are reaching the Full neighbor state.

R7# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 1 INIT/DROTHER 00:00:34 10.0.37.3 GigabitEthernet0/3
2.2.2.2 1 FULL/BDR 00:00:31 10.0.27.2 GigabitEthernet0/2

Finally, remember that if OSPF is configured on a router interface using both the network command and the ip ospf area command, the ip ospf area command wins. Therefore, you may need to use the show ip ospf interface command to verify the current area of the interface, rather than relying on the show ip protocols command.

Mismatched Subnets or The OSPF Adjacency is Negotiated Using The Current OSPF Node’s Primary IP Address with The Neighbor’s Secondary IP Address

When the neighbors’ interfaces are in different subnets, debugging OSPF adjacencies would generate the following message.

*Jan 31 22:12:40.396: OSPF-1 ADJ Gi0/3: Rcv pkt from 10.0.123.3, area 0.0.0.0 : src not on the same network

You can use the show ip interface command, the show ip ospf interface command, or the show running-config interface interface_type interface_number command to check the IP configuration of OSPF neighbors connected to the same data link.

If their interfaces are in different subnets, the routers cannot build up an OSPF adjacency. For example, R2 and R3’s adjacent interfaces are in different subnets as shown in these examples.

Router R2

R2# show ip interface gigabitEthernet 0/3
GigabitEthernet0/3 is up, line protocol is up
Internet address is 10.0.23.2/24
Broadcast address is 255.255.255.255
Address determined by setup command

omitted output

Router R3

R3# show ip ospf interface gigabitEthernet 0/2
GigabitEthernet0/2 is up, line protocol is up
Internet Address 10.0.123.3/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State WAITING, Priority 1


omitted output

To solve this issue, we set the IP address of R3’s GigabitEthernet 0/2 interface to 10.0.23.3/24 according to the network diagram. Additionally, we need to check that the interface is still advertised into OSPF; if it does not, we have to add it to the right OSPF instance and area using either the ip ospf area command or the network command.

R3(config)# interface gigabitEthernet 0/2
R3(config-if)# ip address 10.0.23.3 255.255.255.0

This example indicates that the GigabitEthernet 0/2 interface is no longer advertised into OSPF.

R3# show ip ospf interface gigabitEthernet 0/2
%OSPF: OSPF not enabled on GigabitEthernet0/2
R3#

We apply the ip ospf area command to R3’s GigabitEthernet 0/2 interface to fix this problem.

R3(config)# interface gigabitEthernet 0/2
R3(config-if)# ip ospf 1 area 0

The OSFP adjacency debugging command generates the Syslog message above when the OSPF adjacency is negotiated using the current OSPF node’s primary IP address with the neighbor’s secondary IP address.

Routers R1 and R2, in the following network diagram, illustrate this issue. Both neighboring interfaces, have IP addresses in the same subnet, but IP address 10.0.12.1/24 is configured as a primary address on R1’s GigabitEthernet 0/2 interface while IP address 10.0.12.2/24 is configured as a secondary IP address on R2’s GigabitEthernet 0/1 interface.

Since the primary IP address of R2’s GigabitEthernet 0/1 is 10.0.2.2/24, R1 and R2 use IP addresses 10.0.12.1/24 and 10.0.12.2/24, respectively, as source addresses of their Hello packets in order to establish an OSPF neighbor relationship. Consequently, they will fail because booth IP addresses are in different subnets.

Mismatched MTU Values

Router interfaces participating in an OSPF adjacency should have the same MTU in order to allow their routers to form a full OSPF neighbor relationship. When the interfaces, connecting two OSPF neighbors, have different MTU values, the OSPF nodes reach the 2-Way state.

However, they would get stuck in the ExStart, Exchange, or Loading state. In this example, R18’s neighbors 20.20.20.20 and 60.60.60.60 are getting stuck in the Exchange and ExStart states, respectively.

R18# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
20.20.20.20           0   EXCHANGE/  -    00:00:38    10.0.120.20       Serial1/0
60.60.60.60           0   EXSTART/  -     00:00:39    10.0.160.60       Serial1/1

To check the MTU set on an interface, use the show interfaces command or the show ip interface command in enable mode.

These examples state that R3 and R4’s interfaces in subnet 10.0.34.0/24 are configured with different MTU values. R3’s Gigabtethernet 0/4 uses the default MTU value, 1500 bytes, while the MTU is set to 1000 bytes on R4’s Gigabtethermet 0/3 interface.

Router R3

R3# show ip interface gigabitEthernet 0/4
GigabitEthernet0/4 is up, line protocol is up
Internet address is 10.0.34.3/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes

omitted output

Router R4

R4# show interfaces gigabitEthernet 0/3
GigabitEthernet0/3 is up, line protocol is up
Hardware is iGbE, address is 5000.0004.0003 (bia 5000.0004.0003)
Internet address is 10.0.34.4/24
MTU 1000 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

omitted output

Consequently, routers R3 and R4 cannot form an OSPF adjacency. Additionally, the debug ip ospf adj command would display these error messages.

Router R3

*Jan 31 23:19:53.743: OSPF-1 ADJ Gi0/4: Nbr 4.4.4.4 has smaller interface MTU

Router R4

*Jan 31 23:22:05.091: OSPF-1 ADJ Gi0/3: Nbr 3.3.3.3 has larger interface MTU

Additionally, the show ip ospf interface brief command output indicates that R3 detects one OSPF neighbor over the G0/4 interface but it does not form a full neighbor relationship with it.

Besides, if you look at the last entry, you will notice string “0/1” in column “Nbrs F/C”, which means 0 OSPF adjacencies and 1 OSPF neighbor associated with the Gigabtethernet0/4 interface.

R3# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Gi0/2 1 0 10.0.23.3/24 1 BDR 1/1
Gi0/7 1 0 10.0.37.3/24 1 DR 0/0
Gi0/4 1 0 10.0.34.3/24 1 DR 0/1

To fix this problem, we can change the MTU configured on one of the neighboring interfaces using the mtu command, or issue the ip ospf mtu-ignore command on the adjacent interface with the smaller MTU in order to avoid comparing the MTU during the establishment of their OSPF adjacency.

Moreover, both commands must be entered in interface configuration mode.

This example sets the MTU of R3’s GigabitEthernet 0/4 interface to 1000 bytes to match the one used by R4.

R3(config)# interface gigabitEthernet 0/4
R3(config-if)# mtu 1000

Mismatched Hello and Dead Timers

Hello and Dead intervals have to match between two routers in order to become OSPF neighbors in a particular common subnet.

If those timer values do not match, the routers cannot create an OSPF neighbor relationship, or each router gets moved to the down state if they were OSPF neighbors.

The output of the debug ip ospf hello command states that the hello and dead timers do not match between R4 and R5.

R5# debug ip ospf hello
OSPF hello debugging is on
R5#
*Jan 31 23:49:12.831: OSPF-1 HELLO Gi0/4: Rcv hello from 4.4.4.4 area 0 10.0.45.4
*Jan 31 23:49:12.831: OSPF-1 HELLO Gi0/4: Mismatched hello parameters from 10.0.45.4
*Jan 31 23:49:12.832: OSPF-1 HELLO Gi0/4: Dead R 44 C 888, Hello R 10 C 222 Mask R 255.255.255.0 C 255.255.255.0
*Jan 31 23:49:13.572: OSPF-1 HELLO Gi0/6: Send hello to 224.0.0.5 area 0 from 10.0.56.5
*Jan 31 23:49:14.555: OSPF-1 HELLO Gi0/0: Send hello to 224.0.0.5 area 0 from 10.0.0.5
*Jan 31 23:49:16.052: OSPF-1 HELLO Gi0/7: Send hello to 224.0.0.5 area 0 from 10.0.57.5

omitted output

The string “Dead R 44 C 888, Hello R 10 C 222” means the routers are using different Dead and Hello intervals. The remote interface (letter R), connected to R4, has Hello and Dead timers of 10 and 44, respectively, while the Hello and Dead timers of the current router’s interface (letter C), connected to R5, are 222 and 888.

To verify the Hello and Dead intervals, you can use the show ip ospf interface command. If those timers were set manually, the show running-config interface interface_type interface_number command would help get their values.

These examples illustrate that R4 and R5 are using different OSPF timers in subnet 10.0.45.0/24.

Router R4

R4# show ip ospf interface gigabitEthernet 0/5
GigabitEthernet0/5 is up, line protocol is up
Internet Address 10.0.45.4/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 4.4.4.4, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 4.4.4.4, Interface address 10.0.45.4
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 44, Wait 44, Retransmit 5


omitted output

Router R5

R5# show ip ospf interface gigabitEthernet 0/4
GigabitEthernet0/4 is up, line protocol is up
Internet Address 10.0.45.5/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 5.5.5.5, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 5.5.5.5, Interface address 10.0.45.5
No backup designated router on this network
Timer intervals configured, Hello 222, Dead 888, Wait 888, Retransmit 5

omitted output

As a result, R4 and R5 cannot establish an OSPF adjacency. To solve this issue, we can set the Hello and Dead intervals of R5’s G0/4 interface to 10 and 44 seconds, respectively.

R5(config)# interface gigabitEthernet 0/4
R5(config-if)# ip ospf hello-interval 10
R5(config-if)# ip ospf dead-interval 44

Changing the current OSPF network type of both R4’s G0/5 and R5’s G0/4 interfaces to a specific value solves this problem. In fact, this would work because when you change the OSPF network type of an interface, the Hello and Dead timers are reset to the default values associated with the new OSPF network type.

Mismatched OSPF Network Types

Two OSPF nodes can form an OSPF adjacency over a particular network link regardless of the network type configured on each neighbor interface, however, the Hello and Dead timers set on those interfaces should match. Otherwise, the OSPF neighbor relationship fails.

OSPF adjacencies may not be formed because of incompatible OSPF network types. In fact, network types with mismatched Hello and Dead timers would prevent establishing OSPF neighbor relationships.

For example, If you configure one neighbor interface with the point-to-point or broadcast type and the other interface with a network type that does not support Layer 2 broadcasts, the routers would not build up an OSPF neighbor relationship over those interfaces because they would have different OSPF timers, as illustrated in this table.

OSPF Network Type Hello Interval Dead Interval
Broadcast 10 40
Point-to-point 10 40
Non-broadcast 30 120
Point-to-multipoint 30 120
Point-to-multipoint non-broadcast 30 120

To verify the current OSPF network type on an OSPF-enabled interface, issue the show ip ospf interface command in enable mode.

These examples indicate that the network type of R5’s GigabitEthernet 0/6 interface is broadcast, while the network type of R6’s GigabitEthernet 0/5 interface is point-to-multipoint. OSPF Hello and Dead intervals do not match on both adjacent interfaces; thus the routers cannot build up an OSPF neighbor relationship.

Router R5

R5# show ip ospf interface gigabitEthernet 0/6
GigabitEthernet0/6 is up, line protocol is up
Internet Address 10.0.56.5/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 5.5.5.5, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 5.5.5.5, Interface address 10.0.56.5
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

omitted output

Router R6

R6# show ip ospf interface gigabitEthernet 0/5
GigabitEthernet0/5 is up, line protocol is up
Internet Address 10.0.56.6/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 6.6.6.6, Network Type POINT_TO_MULTIPOINT, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5


omitted output

To solve this problem, we can configure the same network type on both interfaces or change the OSPF hello and dead timers to match. In this example, we choose the first option and set the OSPF network type of R6’s GigabitEthernet 0/5 interface to broadcast.

R6(config)# interface gigabitEthernet 0/5
R6(config-if)# ip ospf network broadcast

Misconfigured OSPF Authentication

OSPFv2 allows you to implement three types of authentication:

  • Null: means no authentication.
  • Plain text: the authentication password is sent as clear text. Any device on the current medium, capturing OSPF traffic, can read the plain text password.
  • MD5/SHA-HMAC: the password hash is exchanged instead of the real password.

You can configure OSPF authentication on a per-area basis or on a per-interface basis; however, in both cases, you have to configure the password at the interface level.

If OSPF authentication fails on a network link, it prevents the neighbors from creating OSPF adjacencies on that link. Authentication may fail because of one of the following reasons:

  • Mismatched passwords.
  • Mismatched authentication types.
  • One end of the data link is not enabling authentication.

The show ip ospf command allows you to know OSPF areas on which authentication is enabled.

R6# show ip ospf 
 Routing Process "ospf 1" with ID 6.6.6.6
 Start time: 00:00:17.776, Time elapsed: 00:07:30.532
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Supports NSSA (compatible with RFC 3101)
 Event-log enabled, Maximum number of events: 1000, Mode: cyclic
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF disabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
 Reference bandwidth unit is 100 mbps
    Area 16
        Number of interfaces in this area is 1
	Area has simple password authentication
	SPF algorithm last executed 00:05:50.016 ago
	SPF algorithm executed 3 times
	Area ranges are
	Number of LSA 4. Checksum Sum 0x01B617
	Number of opaque link LSA 0. Checksum Sum 0x000000
	Number of DCbitless LSA 0
	Number of indication LSA 0
	Number of DoNotAge LSA 0
	Flood list length 0

If authentication is to be enabled, it must be configured properly for two routers to form an OSPF adjacency. You can check these guides to learn more about:

To verify whether OSPF authentication is enabled on an interface, issue the show ip ospf interface command in enable mode.

These examples state that OSPF authentication is enabled on R7’s GigabitEthernet 0/5 interface, but it isn’t on R5’s GigabitEthernet 0/7 interface.

Router R5

R5# show ip ospf interface gigabitEthernet 0/7
GigabitEthernet0/7 is up, line protocol is up
Internet Address 10.0.57.5/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 5.5.5.5, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 5.5.5.5, Interface address 10.0.57.5
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:04
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/4/5, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)

Router R7

R7# show ip ospf interface gigabitEthernet 0/5
GigabitEthernet0/5 is up, line protocol is up
Internet Address 10.0.57.7/24, Area 0, Attached via Network Statement
Process ID 1, Router ID 7.7.7.7, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 7.7.7.7, Interface address 10.0.57.7
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:09
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/5/5, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Cryptographic authentication enabled
Youngest key id is 12

Consequently, R5 and R7 cannot establish an OSPF adjacency since R5’s interface does not use authentication, while R7 does.

We can solve this issue by configuring authentication on R5’s GigabitEthernet 0/7 interface according to the output of the show running-config interface GigabitEthernet 0/5 command below.

R7# show running-config interface gigabitEthernet 0/5
Building configuration...

Current configuration : 194 bytes
!
interface GigabitEthernet0/5
ip address 10.0.57.7 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 12 md5 CISCO
duplex auto
speed auto
media-type rj45
end

Finally, note that if you configure an OSPF authentication method on all interfaces in a specific area without using the area authentication command, the show ip ospf command would indicate that the area has no authentication.

Thus, this Cisco IOS command is not always enough to check OSPF authentication, and you would need to the show ip ospf interface command also, as illustrated in this example.

R7# show ip ospf


omitted output


Reference bandwidth unit is 100 mbps
Area BACKBONE(0)
Number of interfaces in this area is 5
Area has no authentication
SPF algorithm last executed 01:46:21.808 ago
SPF algorithm executed 54 times
Area ranges are
Number of LSA 20. Checksum Sum 0x08EC14
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

Even though OSPF MD5 authentication is enabled on R7’s GigabitEthernet0/5 interface, advertised in area 0, the show ip ospf command still tells that area 0 has no authentication.

Routers Cannot Elect a Designated Router

This is a rare case, but it could happen mistakenly. For example, if the OSPF priority in a subnet is set to 0 on all router interfaces connected to that subnet, the OSPF nodes would not elect a DR and all routers become DROthers; thus no OSPF neighbor relationship can be built on the subnet.

These examples show that R4, R5, and R6 are getting stuck at the 2-Way neighbor state, and they cannot select a DR in subnet 10.0.0.0/24.

Router R4

R4# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
7.7.7.7 1 FULL/BDR 00:00:33 10.0.47.7 GigabitEthernet0/7
5.5.5.5 1 FULL/DR 00:00:40 10.0.45.5 GigabitEthernet0/5
3.3.3.3 1 FULL/BDR 00:00:33 10.0.34.3 GigabitEthernet0/3
5.5.5.5 0 2WAY/DROTHER 00:00:37 10.0.0.5 GigabitEthernet0/0
6.6.6.6 0 2WAY/DROTHER 00:00:37 10.0.0.6 GigabitEthernet0/0

Router R5

R5# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
6.6.6.6 1 FULL/BDR 00:00:38 10.0.56.6 GigabitEthernet0/6
4.4.4.4 1 FULL/BDR 00:00:40 10.0.45.4 GigabitEthernet0/4
4.4.4.4 0 2WAY/DROTHER 00:00:38 10.0.0.4 GigabitEthernet0/0
6.6.6.6 0 2WAY/DROTHER 00:00:37 10.0.0.6 GigabitEthernet0/0

Router R6

R6# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
5.5.5.5 1 FULL/DR 00:00:36 10.0.56.5 GigabitEthernet0/5
4.4.4.4 0 2WAY/DROTHER 00:00:30 10.0.0.4 GigabitEthernet0/0
5.5.5.5 0 2WAY/DROTHER 00:00:39 10.0.0.5 GigabitEthernet0/0

The value next to the neighbor router ID refers to the priority of the corresponding neighbor. Based on the show ip ospf neighbor outputs above state that the OSPF priority of each OSPF interface in subnet 10.0.0.0/24 is set to 0.

Therefore, all routers are getting stuck in the 2-Way neighbor state. In fact, they are not participating in the OSPF DR/BDR election process because the OSPF priority of their GigabitEthernet 0/0 is 0, as shown above.

To fix this issue, it is enough the increase the OSPF priority of one of the routers, the one we want to be the DR. But, it would be better if we change the current OSPF priority of all routers in order to elect a DR and also a BDR.

In these examples, we set the OSPF priority of R4, R5, and R6’s interfaces in subnet 10.0.0.0/24 to 10.

Router R4

R4(config)# interface gigabitEthernet 0/0
R4(config-if)# ip ospf priority 10

Router R5

R5(config)# interface gigabitEthernet 0/0
R5(config-if)# ip ospf priority 10

Router R6

R6(config)# interface gigabitEthernet 0/0
R6(config-if)# ip ospf priority 10

The output of the show ip ospf neighbor command indicates that routers R4, R5, and R6 could elect a DR and a BDR on subnet 10.0.0.0/24.

R4# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
7.7.7.7 1 FULL/DR 00:00:39 10.0.47.7 GigabitEthernet0/7
5.5.5.5 1 FULL/DR 00:00:35 10.0.45.5 GigabitEthernet0/5
3.3.3.3 1 FULL/DR 00:00:39 10.0.34.3 GigabitEthernet0/3
5.5.5.5 10 FULL/BDR 00:00:35 10.0.0.5 GigabitEthernet0/0
6.6.6.6 10 FULL/DR 00:00:35 10.0.0.6 GigabitEthernet0/0

At Least One of The Interfaces Connecting The Routers is a Passive Interface

When we want to stop OSPF from sending, receiving, and processing Hello packets over an interface not connected to a neighbor and at the same time keep advertising its corresponding subnet, we need to convert that interface to an OSPF passive interface by issuing the passive-interface interface_type interface_number command in router configuration mode.

The following example disables Hello packets on Loopback interfaces 0 and 1.

R10(config)# router ospf 1
R10(config-router)# passive-interface loopback 0
R10(config-router)# passive-interface loopback 1

In this example, we use the show ip protocols command to display the current list of OSPF passive interfaces on router R7.

R7# show ip protocols


omitted output


Routing for Networks:
10.0.17.7 0.0.0.0 area 0
10.0.27.7 0.0.0.0 area 0
10.0.37.7 0.0.0.0 area 0
10.0.47.7 0.0.0.0 area 0
10.0.57.7 0.0.0.0 area 0
Passive Interface(s):
GigabitEthernet0/1
Routing Information Sources:
Gateway Distance Last Update
6.6.6.6 110 00:16:53
5.5.5.5 110 00:18:04
4.4.4.4 110 00:17:49
3.3.3.3 110 00:22:28
1.1.1.1 110 05:44:20
2.2.2.2 110 05:44:20
Distance: (default is 110)

R7’s GigabitEthernet 0/1 is passive, thus R1 and R7 cannot form an OSPF adjacency. To fix this problem, apply the no passive-interface command to that interface, as shown in this example.

R7(config)# router ospf 1
R7(config-router)# no passive-interface gigabitEthernet 0/1

Area Number Mismatch

“Area Number Mismatch” is an error that occurs when the neighboring OSPF interfaces on the same network link are configured with different area numbers. This would prevent the routers from establishing an OSPF adjacency.

To resolve this issue, both routers’ neighboring interfaces must be configured with the same area number.

The check the OSPF area of an interface, you can use the show ip ospf interface interface_type interface_number command or the show ip ospf interface brief command.

However, it would be a tedious task to diagnose this type of error using those Cisco IOS commands. In fact, you can use the debug ip ospf adj command to detect area number mismatches fast. In this case, Cisco IOS shows an error message.

The following example states that there is an area number mismatch between routers R1 and R6. R1’s GigabitEthernet 0/6 is in area 16, while R6’s GigabitEthernet 0/1 is in area 160. Therefore, they would not build up an OSPF adjacency.

*Feb 1 04:39:21.788: OSPF-1 ADJ Gi0/6: Rcv pkt from 10.0.16.6, area 0.0.0.16, mismatched area 0.0.0.160 in the header

To fix this issue, we use the ip ospf area command in order to place R6’s GigabitEthernet0/1 interface in area 16 according to the network diagram, as shown in this example.

R6(config)# interface gigabitEthernet 0/1
R6(config-if)# ip ospf 1 area 16

Note that you cannot rely on the network command to solve this problem. If the interface’s area is set with the ip ospf area command, the network command cannot change the current area because the ip ospf area command overrides the network command.

Mismatched Area Type

OSPF supports three types of areas: normal, stub, and NSSA. For two OSPF nodes to establish a neighbor relationship, the adjacent interfaces must use the same type of area.

The fast way to check an area type mismatch is to issue the debug ip ospf hello command. This example indicates that there is an area type mismatch between routers R1 and R5.

R1# debug ip ospf hello
OSPF hello debugging is on
R1#
*Feb 1 04:58:12.743: OSPF-1 HELLO Gi0/2: Rcv hello from 2.2.2.2 area 0 10.0.12.2
*Feb 1 04:58:14.965: OSPF-1 HELLO Gi0/6: Rcv hello from 6.6.6.6 area 16 10.0.16.6
*Feb 1 04:58:15.177: OSPF-1 HELLO Gi0/5: Rcv hello from 5.5.5.5 area 15 10.0.15.5
*Feb 1 04:58:15.178: OSPF-1 HELLO Gi0/5: Hello from 10.0.15.5 with mismatched Stub/Transit area option bit
*Feb 1 04:58:16.705: OSPF-1 HELLO Gi0/2: Send hello to 224.0.0.5 area 0 from 10.0.12.1

Note that you can check the number of normal, stub, and NSSA areas that the current router is connected to by using the show ip protocols command, as shown in this example.

R1# show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "application"
Sending updates every 0 seconds
Invalid after 0 seconds, hold down 0, flushed after 0
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Maximum path: 32
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 4)

Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 1.1.1.1
It is an area border router
Number of areas in this router is 3. 2 normal 1 stub 0 nssa


omitted output

Additionally, to display stub areas use the show ip ospf command, as illustrated in this example.

R1# show ip ospf

omitted output

Area 15
Number of interfaces in this area is 1
It is a stub area
Generates stub default route with cost 1
Area has no authentication
SPF algorithm last executed 19:04:32.024 ago
SPF algorithm executed 3 times
Area ranges are
Number of LSA 14. Checksum Sum 0x05678D
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 16
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 01:29:08.726 ago
SPF algorithm executed 3 times
Area ranges are
Number of LSA 27. Checksum Sum 0x10D822
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

Area 15 is configured as an OSPF stub area on R1, while it is configured as a normal area on R5, as you can notice in this example.

R5# show ip ospf | begin Area 15
Area 15
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 01:52:51.373 ago
SPF algorithm executed 2 times
Area ranges are
Number of LSA 13. Checksum Sum 0x064661
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

To fix this problem, we can configure area 15 as either a stub area or a normal area.

An ACL is Blocking OSPF Hello packets

If an ACL blocks inbound OSPF packets to a router interface, the router fails to establish OSPF neighbor relationships over that interface. A standard/extended ACL cannot filter OSPF traffic locally originated by the router. Consequently, only inbound ACLs can lead to OSPF problems.

To verify the ACLs being applied to a given interface, issue the show ip interface command in enable mode. In addition, to display the configuration of an ACL, issue the show ip access-list command in enable mode.

This example states that R3 is appearing in R7’s OSPF neighbor list with the Init state. This means R7 is receiving Hello packets from R3 but they don’t include R7’s OSPF router ID.

R7# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DR 00:00:34 10.0.17.1 GigabitEthernet0/1
4.4.4.4 1 FULL/BDR 00:00:38 10.0.47.4 GigabitEthernet0/4
3.3.3.3 1 INIT/DROTHER 00:00:36 10.0.37.3 GigabitEthernet0/3
2.2.2.2 1 FULL/BDR 00:00:35 10.0.27.2 GigabitEthernet0/2

The following show ip ospf neighbor command output indicates that R3 did not discover R7 yet. That may be due to the fact that R3 does not receive Hello packets from R7 or may be caused by another reason.

R3# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:35 10.0.23.2 GigabitEthernet0/2
4.4.4.4 1 FULL/BDR 00:00:36 10.0.34.4 GigabitEthernet0/4

In fact, the debug ip ospf hello command output confirms that R3 is not receiving OSPF hello packets from R7.

R3# debug ip ospf hello
OSPF hello debugging is on
R3#
*Feb 1 06:55:09.555: OSPF-1 HELLO Gi0/4: Send hello to 224.0.0.5 area 0 from 10.0.34.3
*Feb 1 06:55:12.312: OSPF-1 HELLO Gi0/7: Send hello to 224.0.0.5 area 0 from 10.0.37.3
*Feb 1 06:55:13.952: OSPF-1 HELLO Gi0/4: Rcv hello from 4.4.4.4 area 0 10.0.34.4
*Feb 1 06:55:15.932: OSPF-1 HELLO Gi0/2: Send hello to 224.0.0.5 area 0 from 10.0.23.3
*Feb 1 06:55:17.569: OSPF-1 HELLO Gi0/2: Rcv hello from 2.2.2.2 area 0 10.0.23.2
*Feb 1 06:55:18.567: OSPF-1 HELLO Gi0/4: Send hello to 224.0.0.5 area 0 from 10.0.34.3
*Feb 1 06:55:21.686: OSPF-1 HELLO Gi0/7: Send hello to 224.0.0.5 area 0 from 10.0.37.3
*Feb 1 06:55:23.128: OSPF-1 HELLO Gi0/4: Rcv hello from 4.4.4.4 area 0 10.0.34.4
*Feb 1 06:55:24.943: OSPF-1 HELLO Gi0/2: Send hello to 224.0.0.5 area 0 from 10.0.23.3
*Feb 1 06:55:27.242: OSPF-1 HELLO Gi0/2: Rcv hello from 2.2.2.2 area 0 10.0.23.2
*Feb 1 06:55:28.286: OSPF-1 HELLO Gi0/4: Send hello to 224.0.0.5 area 0 from 10.0.34.3
*Feb 1 06:55:30.853: OSPF-1 HELLO Gi0/7: Send hello to 224.0.0.5 area 0 from 10.0.37.3
*Feb 1 06:55:32.650: OSPF-1 HELLO Gi0/4: Rcv hello from 4.4.4.4 area 0 10.0.34.4
*Feb 1 06:55:34.487: OSPF-1 HELLO Gi0/2: Send hello to 224.0.0.5 area 0 from 10.0.23.3
*Feb 1 06:55:36.797: OSPF-1 HELLO Gi0/2: Rcv hello from 2.2.2.2 area 0 10.0.23.2
*Feb 1 06:55:37.882: OSPF-1 HELLO Gi0/4: Send hello to 224.0.0.5 area 0 from 10.0.34.3

omitted output

The show ip interface command idicates that ACL 100 is applied inbound to R3’s GigabitEthernet 0/7 interface.

R3# show ip interface gigabitEthernet 0/7
GigabitEthernet0/7 is up, line protocol is up
Internet address is 10.0.37.3/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.5 224.0.0.6
Outgoing access list is not set
Inbound access list is 100

omitted output

This example states that ACL 100 is blocking OSPF traffic received on R3’s GigabitEthernet 0/7 interface, thus that would not let R3 and R7 form an adjacency.

R3# show ip access-lists 100
Extended IP access list 100
10 deny ospf any any (7503 matches)
20 permit ip any any

To solve this problem, we remove the first entry from ACL 100, as you can see in this example.

R3(config)# ip access-list extended 100
R3(config-ext-nacl)# no deny ospf any any

Duplicate OSPF Router IDs

OSPF adjacencies cannot be formed between routers with duplicate router IDs. In this case, Cisco IOS generates the following error message.

*May 6 02:40:08.651: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 11.11.11.11 from 10.0.161.11 on interface Serial1/1

To resolve this problem, modify the OSPF router ID of the router that is causing the problem using the router-id command in router configuration mode, and then restart the current OSPF instance by issuing the clear ip ospf ospf_id process command, where ospf_id is the ID of the OSPF instance to restart.

Troubleshooting OSPF Neighbor Adjacencies Based on The Neighbor State: How Would You Troubleshoot an OSPF Adjacency Stuck in The Attempt, Init, 2-Way, ExStart, Exchange, or Loading State?

OSPF neighbor relationship problems can occur for several reasons, preventing neighbors from reaching the Full neighbor state. In this case, one or both of the OSPF neighbors may not be installed in the OSPF neighbor list of each other, or they may be stuck in the Attempt, Init, 2-Way, ExStart, Exchange, or Loading neighbor state.

In this section, I discuss the issues related to establishing OSPF adjacency between two OSFP nodes and how to troubleshoot them depending on the current state of the OSPF neighbor.

Why OSPF Neighbor Does Not Appear in The Neighbor List?

If a particular OSPF node is not in the OSPF neighbor list, it means that there are no established neighbor relationship with that adjacent router. This can be due to various reasons, including network misconfigurations, firewall blocks, mismatched OSPF configurations, or network connectivity issues.

To resolve this issue, it is recommended to check OSPF settings, verify network connectivity, and ensure that there are no traffic restrictions in place.

The most common possible causes of this problem are as follows:

  • Interface down due to Layer 1 or Layer 2 issues.
  • OSPF is not enabled on the interface.
  • Mismatched subnets.
  • An OSPF adjacency is negotiated using the current OSPF node’s primary IP address with the neighbor’s secondary IP address.
  • Mismatched Hello and Dead timers.
  • Both OSPF nodes are negotiating an OSPF adjacency over a non-broadcast link, and at least one of them is not manually defined using the neighbor command.
  • Misconfigured OSPF authentication type or key.
  • At least one of the interfaces connecting the routers is passive.
  • Area number mismatch.
  • Mismatched area type
  • An ACL is blocking OSPF Hello packets.
  • Duplicate OSPF router IDs

Why is OSPF Stuck in The Attempt State, and What Could Be The Reason for OSPF Neighbors Being Stuck In The Attempt State?

The Attempt state happens when a router dispatches a unicast hello packet to a manually added OSPF neighbor but it has not yet gotten a hello packet from that neighbor.

On NBMA networks, it is the initial state in which a neighbor is placed, and then it goes through the Init state, the ExStart site, and so on until it reaches the Full state if things are running normally. Otherwise, if a neighbor gets stuck in the Attempt state, it tells you that there is a problem that needs to be resolved.

An OSPF neighbor can get stuck in the Attempt state on NMBA (non-broadcast multiaccess) networks only. This issue is not valid for broadcast and point-to-point links. In this case, the current OSFP node is sending Hello packets to a manually configured neighbor in order to negotiate an OSPF neighbor relationship, but it does not receive any responses from it.

Here is what can cause an OSPF neighbor to be stuck in the Attempt state:

  • The NBMA link is not configured properly so that OSPF nodes send and receive unicast IP packets from each other without a need to be routed. For example, a missing or bad mapping between IP address and DLCI in a Frame Relay network.
  • Misconfigured neighbor IP address.

Why is OSPF Stuck in The Init State, and What Could Be The Reason for OSPF Neighbors Being Stuck In The Init State?

The Init state is triggered when an OSPF node receives a Hello packet from a neighbor, but the packet’s originating neighbor does not include the OSPF router ID of the receiving neighbor in the Hello packet.

For example, if router A receives a Hello packet from router B that does not include router A’s OSPF router ID in that OSPF packet, router A adds router B to its OSPF neighbor list and places it in the Init state. If router B persists in the Init state for a while, it is likely that something is prohibiting router B from successfully receiving Hellos from router A.

Here is what can cause an OSPF neighbor to be stuck in the Init state:

  • Hello packets cannot reach one of the neighbors because of a Layer 2 issue, regardless of whether they are sent as unicast or multicast IP packets.
  • A Frame-relay mapping between IP address and DLCI, on only one of the OSPF neighbors, is configured without the broadcast keyword.
  • OSPF authentication is active on only one neighboring interface.
  • An access control list is configured on one neighboring interface that is blocking the corresponding router from obtaining OSPF Hello packets received on that interface.

Why is OSPF Stuck in The 2-Way State, and What Could Be The Reason for OSPF Neighbors Being Stuck In The 2-Way State?

The 2-Way state is a particular condition that two OSPF nodes reach when they have exchanged Hello packets with each other, and they discover their own OSPF RIDs in the Hello packets they receive. The 2-way state is the neighbor state in which DROther routers on a broadcast and NBMA network get stuck.

Two neighboring routers can be either both in the 2-Way state or not. This would only happen on networks where the DR/BDR election must occur. What can cause two OSPF neighbors to be stuck in the 2-Way state would be that all neighbor interfaces connected to the network link have an OSPF priority of 0.

Why is OSPF Stuck in The ExStart State, and What Could Be The Reason for OSPF Neighbors Being Stuck In The ExStart State?

The ExStart state is a specific state in which two OSPF neighbors choose, based on their router IDs, which one will become the master and send their OSPF routing data first. The router with the larger OSPF router ID acts as the master, while the other one acts as the slave.

In a multi-access network where the DR/BDR election should occur, the DR and BDR must be chosen first before OSPF neighbor relationships on the network can reach that state. Additionally, each selection of a master and a slave is made on a neighbor-by-neighbor basis. Therefore, the DR and BDR are not expected to become masters in the OSPF adjacencies they are establishing.

Here is what can cause an OSPF neighbor to be stuck in the Exstart state:
• Mismatched MTU.
• Duplicate router IDs.
• Inconvenient large MTU size, configured on the neighboring interfaces, that is not supported by one of the Layer 2 devices interconnecting the two OSPF neighbors.

This happens, when Layer 2 frames carrying DBD packets are sent with a particular MTU, and one device on the Layer 2 path between the OSPF neighbors cannot accept those frames because they are quite big; thus they won’t reach their destination and the source OSPF node get stuck in the ExStart state.

• Wrong IP address and DLCI mapping, on one side or both sides of the current media, that does not allow unicast communication between the neighboring routers. Unlike Hello packets that may get sent as multicast IP packets, DBD packets are sent to the unicast IP address of the current OSPF neighbor.

Therefore, two neighboring routers can discover each other through Hello packets, but if they fail to connect using their unicast IP addresses, they won’t exchange DBD packets; thus, they get stuck in the ExStart state.

  • Access control list blocking unicast OSPF packets between the OSPF neighbors.

Why is OSPF Stuck in The Exchange State, and What Could Be The Reason for OSPF Neighbors Being Stuck In The Exchange State?

In the Exchange state, OSPF routers send database descriptor (DBD) packets, which include LSA headers only, in order to reveal their entire LSDBs to each other. Each OSPF neighbor verifies received DBD packets from the other neighbor in order to determine the missing LSAs in its LSDB. Moreover, LS requests may get sent, in this state, to get more recent LSAs.

Here is what can cause an OSPF neighbor to be stuck in the Exchange state:

• Mismatched MTU.
• Duplicate router IDs.
• Inconvenient large MTU size, configured on the neighboring interfaces, that is not supported by one of the Layer 2 devices interconnecting the two OSPF neighbors.

This happens, when Layer 2 frames carrying DBD packets are sent with a particular MTU, and one device on the Layer 2 path between the OSPF neighbors cannot accept those frames because they are quite big; thus they won’t reach their destination and the source OSPF node get stuck in the ExStart state.

• Wrong IP address and DLCI mapping, on one side or both sides of the current media, that does not allow unicast communication between the neighboring routers. Unlike Hello packets that may get sent as multicast IP packets, DBD packets are sent to the unicast IP address of the current OSPF neighbor.

Therefore, two neighboring routers can discover each other through Hello packets, but if they fail to connect using their unicast IP addresses, they won’t exchange DBD packets; thus, they get stuck in the ExStart state.

  • Access control list blocking unicast OSPF packets between the OSPF neighbors.

Why is OSPF Stuck in The Loading State, and What Could Be The Reason for OSPF Neighbors Being Stuck In The Loading State?

In the Loading state, LS requests and LS updates get sent in order to obtain and share particular LSAs based on the content of the DBD packets received from the other neighbor. Also, all LS update packets must get acknowledged. A router gets stuck in this state when it sends an LS request but it does not get a response because the response does reach the current router or the neighbor does not send one.

Here is what can cause two OSPF neighbors to be stuck in the Loading state:

• There is an MTU mismatch that the OSPF neighbors cannot detect it. In this case, LS requests and LS updates sent over the neighbor interface with the larger MTU won’t get received by the neighboring interface with the smaller MTU, and thus both routers get stuck in the Loading state.
• Corrupted, damaged, or invalid LS request packet. OSPF packets can be corrupted by a software bug, a Layer 2 device in the path between the OSPF neighbors, or a bad interface on one of the neighbors.

Cisco IOS Commands Needed to Troubleshooting OSPF Neighbor Adjacency Problems

Here is a summary of the Cisco IOS commands we can use to diagnose and fix OSPF neighbor issues.

  • debug ip ospf adj
  • debug ip ospf hello
  • show interfaces
  • show ip interface
  • show ip protocols
  • show ip ospf
  • show ip ospf interface
  • show ip ospf interface brief
  • show ip access-lists
  • show key chain
  • show running-config
  • show running-config interface

Related Lessons to Troubleshooting OSPF Neighbor Adjacency

Conclusion

I hope this blog post helps you learn something.
Now I’d like to turn it over to you:
What did you like about this tutorial?
Or maybe you have an excellent idea that you think I need to add.
Either way, let me know by leaving a comment below right now.

Mohamed Ouamer
Mohamed Ouamer is a computer science teacher and a self-published author. He taught networking technologies and programming for more than fifteen years. While he loves to share knowledge and write, Mohamed's best passions include spending time with his family, visiting his parents, and learning new things.
Linkedin

Share

Exit mobile version