OSPF Adjacencies Tshoot

Problem: OSPF Neighbor List is Empty

This is the most common problem in OSPF neighbor relationships. The most common causes
are related to either misconfiguration or lack of configuration. If the neighbor list is empty, it will
not even proceed to form OSPF neighbor relationships.

Most common possible causes for this problem are:

• OSPF not enabled on the interface

• Layer 1/2 is down
• Interface defined as Passive
o When interface is defined as passive, it suppresses OSPF Hellos. This means that
OSPF does not send or receive any Hellos on such interfaces. Therefore, no adjacency
is formed.
• An ACL blocking Hellos on both sides
• Subnet mask mismatched
o OSPF performs the subnet number and mask check on all media except point-to-
point and virtual links as specified. The network mask gets advertised in the Hello
packet.
o In the case of unnumbered point-to-point links and virtual links, the network mask
field contains 0.0.0.0.
o If the subnet mask is different across the Ethernet link, OSPF will not form a neighbor
relationship on that link.
• Hello/Dead interval mismatched
• Authentication Type (plain vs MD5) mismatched
o OSPF uses two types of authentication, plain-text (Type 1) and MD5 (Type 2). Type
0 is called null authentication.
o If the plain-text authentication type is enabled on one side, the other side must also have
plain-text authentication.
o OSPF will not form an adjacency unless both sides agree on the same authentication
type.
• Authentication key mismatched
• Area ID mismatched
o OSPF sends area information in the Hello packets. The area information is a part of the
OSPF protocol header.

o If both sides do not agree that they are members of a common area, no OSPF
adjacency will be formed.

• Stub/transit/NSSA area options mismatched

o If one neighbor is configured as a stub area router and another neighbor is not, there will
be no adjacency formed because the stub area flags do not match.
• OSPF adjacency with Secondary IP address
o OSPF utilizes the primary IP address as the source of all Hello packets sent on that
interface. Neighbor relationships will not form based on secondary IP addressing.
o
Problem: OSPF Neighbor Stuck in INIT

When a router receives an OSPF Hello from a neighbor, it sends the Hello packet by including
that neighbor’s router ID in the Hello packet. If it doesn’t include the neighbor’s router ID, the
neighbor will be stuck in INIT. This is an indication of a problem.

The first packet that a router receives will cause the router to go into INIT state. At this point, it is
not a problem, but if the router stays in this state for a long time, it’s an indication of a
problem. It means that the neighbor router is not seeing Hellos sent by this router—that’s why it
is not including the router ID of the router in its Hello packet.

Most common possible causes for this problem are:

• ACL on one side blocking OSPF hellos

• Authentication is enabled on only one side
• Hellos getting lost on one side at Layer 2
ACL Blocking OSPF Hellos
ACL Blocking OSPF Hellos
OSPF sends Hello packets to the multicast address of 224.0.0.5. If an access list is configured
that doesn’t explicitly permit this address, it will be denied. The Hellos cannot get through the
access list and the neighbor is stuck in INIT state. The stuck in INIT problem occurs only if one
side is blocking OSPF Hellos. If both sides are blocking OSPF Hellos, the output of show ip
ospf neighbor returns an empty list.

Authentication Enabled on One Side

When authentication is used, it must be enabled on both sides; otherwise, one side will show
the neighbor stuck in the INIT state. The router that has authentication enabled will reject all the
nonauthenticated packets, and the adjacency will show stuck in INIT. Hellos from the
nonauthenticating router will be dropped.
Hellos Getting Lost on One Side at Layer 2

This situation happens when there is a problem on the Layer 2 media.

When R1 sends the Hello, R2 never receives it. Because R2 never saw Hellos from R1, the
neighbor list of R2 will be empty. However, R1 sees the Hellos from R2, which does not list R1
as a valid neighbor; so, R1 declares this neighbor in the INIT state.

R1 keeps sending OSPF Hellos but never receives any Hellos from R2. This means that R2’s
Hellos are getting lost in the middle because the debug shows that R2 is sending as well as
receiving OSPF Hellos.

The debug is done on both sides, and it is clear that both sides are sending Hellos but R1
Hellos never get across. Most likely, the Frame Relay cloud or other Layer 2 medium is
dropping this multicast packet. This also can be verified by using a sniffer on the wire.

Problem: OSPF Neighbor Stuck in 2-WAY

It is normal in broadcast media to have a 2-WAY state because not every router becomes
adjacent on broadcast media. Every router enters into FULL state with the DR and the BDR.

Example: There are only two routers on Ethernet; both are configured with priority 0. Priority 0
means that this router will not take part in DR/BDR election process. This configuration is useful
when there are “low-end” routers on the segment and the desire is not to make those low-end
routers DRs. For this purpose, you should configure priority 0.

By default, the priority is set to 1. A router with the highest priority on a segment wins a DR
election. If all priorities are kept to the default, the router with the highest router ID becomes
the DR. If all the routers on an Ethernet segment are configured with priority 0, no routers on the
segment will be in FULL state with any other router. This creates problems. At least one router
on the segment must have a priority that is not set to 0.

Solution: Remove the priority 0 on at least one router so that router becomes a DR and forms
a FULL adjacency.

Problem: OSPF Neighbor Stuck in EXSTART/EXCHANGE

In this state, the router elects a master and a slave and the initial sequence number. The
whole database also is exchanged during this state. If a neighbor is stuck in
EXSTART/EXCHANGE for a long time, it is an indication of a problem.

Most common possible causes:

• Mismatched interface MTU

• Duplicate router IDs on neighbors
• Inability to ping across with more than certain MTU size
• Broken unicast connectivity due to ACLs or NAT translating the unicast

• Mismatched interface MTU

The interface MTU of both sides of an OSPF neighbor relationship must match; otherwise, the
neighbor relationship will not form.

Duplicate RIDs on Neighbors

When OSPF sends a DBD packet to elect a master and a slave, the router with the highest
router ID becomes the master. This happens in the EXSTART process. If there is any problem
with election, the router will be stuck in the EXSTART/EXCHANGE state.

If a neighbor router has the same router ID as the local router, no neighbor relationship will
form. The router ID must be unique within the entire internetwork.

Issue: R2 is sending a DBD packet with a flag of 7, saying, “I am the master.” R2 also receives
a DBD from R1 saying, “I am the master.” R2 compares R1’s router ID and sees that it is not
higher than its own, so it sends the DBD packet to R1 saying, “I am the master.” So, both
routers keep fighting for the master status and the router gets stuck in the EXSTART state.

Note: Cisco IOS Software Release 12.0 and later provide a warning message, OSPF-3-
DUP_RTRID, that warns if there is a duplicate router ID.

Can't ping across with more than certain MTU Size

When OSPF begins forming an adjacency with its neighbor, it goes through several states.

• In EXSTART state, OSPF determines which will be the master and which will be
the slave.
• After the routers decided this, they start exchanging the LSA header in the form of DBD
packets. If the database is huge, OSPF uses the interface MTU and tries to send as
much data as possible up to the limit of the interface MTU.
• If there is a problem with Layer 2 accepting large packets that are within the interface
MTU range, the OSPF adjacency will be stuck in the EXCHANGE state.

Is the neighbor reachable through ping with a large MTU size? Neighbor must be able to
accept the largest MTU size packet it can handle; otherwise, it’s a Layer 2.

The debug shows that R2 keeps retransmitting the DBD packets every 5 seconds, which is a
default, and is not receiving any reply. Also note that the length of this packet is 1274 and the
flag value is 3; this means that R2 is a master.

When R1 pings R2 with an MTU equal to or greater than 1200, the ping never reaches the other
side. This indicates a problem at Layer 2. R1 can ping R2 when using a 100-byte datagram, but
the ping starts failing when the datagram size is greater than 1200 bytes.

Solution

One way to narrow this problem is to connect the two devices directly instead of going through
switches and so forth, to see whether the problem is with the Layer 2 devices or with the router
itself. If connecting routers back to back doesn’t fix the problem, there is a possibility of bad
hardware. Most times, it turns out to be a problem in the middle.

Unicast Connectivity is Broken

When OSPF routers begin exchanging database information with each other, they send a
unicast packet to each other in EXSTART/EXCHANGE state. This happens only if the network
type is not a point-to-point link. In cases of a point-to-point link, OSPF sends all multicast
packets. If unicast connectivity is broken, OSPF neighbor remains in EXSTART state.

Possible issues:

• ACL blocking unicast

o If an access list is configured on a router, make sure that it’s not blocking the unicast
packet.
• NAT translating the unicast
o If NAT is misconfigured, it will start translating the unicast packet coming toward it, which
will break the unicast connectivity.

Example: When R2 sends a unicast packet to R1, R1 tries to translate that packet and R2
never receives the ping reply. The main thing to watch for is the access list in NAT. If the access
list is permitting everything, this problem will occur.

To solve this problem, change access list and permit only those IP address that require
translation.

Problem: OSPF Neighbor Stuck in Loading

When a neighbor is stuck in the LOADING state, the local router has sent a link-state
request packet (LSR) to the neighbor requesting an outdated or missing LSA and is waiting for
an update from its neighbor. If a neighbor doesn’t reply or a neighbors’ reply never reaches the
local router, the router will be stuck in the LOADING state.

Most common possible causes:

• Mismatched MTU
• Corrupted link-state request packet

LSR Packet is Corrupted

When a link-state request packet is corrupted, the neighbor discards the packet and the local
router never receives the response from the neighbor. This causes the OSPF neighbor to be
stuck in the LOADING state.

Link-state request packets usually become corrupted because of the following reasons:

• A device between the neighbors, such as a switch, is corrupting the packet.

 • The sending router’s packet is invalid. In this case, either the sending router’s interface
is bad or the error is caused by a software bug.
• The receiving router is calculating the wrong checksum. In this case, either the
receiving router’s interface is bad or the error is caused by a software bug. This is the
least likely cause of this error message.

Solution

Most of the time, this problem is fixed by replacing hardware. This could be a simple bad port on
the switch or a bad interface card on the sending/receiving router.

Hello, my name is Rakesh, and I’m a Senior Network Engineer based in Bangalore, India. As I
continue to advance my job in technology, I enjoy spending a lot of time understanding new
technologies. I developed this posts to assist and share all of the knowledge I’ve obtained as a
holder of certifications and a high level of understanding in Cloud, routing, automation,
security, and more. I hope you find success in your profession in IT while reading through my
posts

Happy learning

Thanks
Rakesh