Cisco routing:OSPF Neighbor relationship establishment

As a link state routing protocol, OSPF establishes and maintains neighbor relationships in order to exchange routing updates with other routers. The neighbor relationship table is called an adjacency database in OSPF. Provided that OSPF is configured correctly, OSPF forms neighbor relationships only with the routers directly connected to it. The routers that it forms a neighbor relationship with must be in the same area as the interface with which it is using to form a neighbor relationship. An interface can only belong to a single area.

When OSPF adjacency is formed, a router goes through several state changes before it becomes fully adjacent with its neighbor.
OSPF neighbor relationship problems can be of any type. Sometimes, the neighbor list is empty (that is, an OSPF neighbor might not even see the Hellos from each other). Sometimes, the problem is that the neighbor is stuck in a specific state. If the state is something other than FULL for a long period of time, this indicates a problem.

OSPF neighbor relationship problems can be of any of these types:

Neighbor in down State

A neighbor that is discovered dynamically through reception of HELLO packets can fall back to a down state if it is being deleted, for example when OSPF does not receive HELLO packets from the neighbor for period of time longer than the Dead timer interval. Therefore, the down state is transient for such neighbors; they will either advance to higher states or be completely deleted from the table of known neighbors. This is known as being “forgotten”.

Usually, neighbors that are seen in the down state were manually configured with the neighbor command. Manually configured neighbors are always present in the OSPF neighbor table. If OSPF has never received HELLO packet from the manually configured neighbor, or if no HELLO packets were heard from the neighbor during the previous Dead timer interval, then the manually configured neighbor will be listed as down.

Note: The neighbor command can only be configured for directly attached neighbors on these types of networks:

Non-Broadcast MultiAccess (NBMA) networks-Interfaces configured with the ip ospf network non-broadcast command.
Non-Broadcast Point-to-Multipoint networks-Interfaces configured with the ip ospf network point-to-multipoint non-broadcast command.

If you see a neighbor in the down state, verify that the neighbor router is up, is running, and is properly configured for OSPF on this interface. Test connectivity between routers with the ping and traceroute commands. Check the OSPF neighbor table on the neighboring router with the show ip ospf neighbor command, and perform the same configuration verification actions listed in the No State Revealed section.

Neighbor in init State

The init state indicates that a router sees HELLO packets from the neighbor, but two-way communication has not been established. A Cisco router includes the Router IDs of all neighbors in the init (or higher) state in the Neighbor field of its HELLO packets. For two-way communication to be established with a neighbor, a router also must see its own Router ID in the Neighbor field of the neighbor’s HELLO packets. For a more detailed example and explanation, refer to Why Does the show ip ospf neighbor Command Reveal Neighbors in the Init State?

Neighbor in 2-way State

The 2-way state indicates that the router has seen its own Router ID in the Neighbor field of the neighbor’s HELLO packet. Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also a cause a transition to 2-way state. The OSPF neighbor 2-way state is not a cause for concern. For an explanation of the 2-way state, refer to Why Does the show ip ospf neighbor Command Reveal Neighbors Stuck in 2-Way State?

Neighbor in exstart or exchange State

OSPF neighbors that are in exstart or exchange state are trying to exchange DBD packets. The router and its neighbor form a master and slave relationship. The adjacency should continue past this state. If it does not, there is a problem with the DBD exchange, such as a maximum transmission unit (MTU) mismatch or the receipt of an unexpected DBD sequence number. For more information, refer to Why Are OSPF Neighbors Stuck in Exstart/Exchange State?

Neighbor in loading State

In the loading state, routers send link-state request packets. During the adjacency, if a router receives an outdated or missing link-state advertisement (LSA), it requests that LSA by sending a link-state request packet. Neighbors that do not transition beyond this state are most likely exchanging corrupted LSAs. This problem is usually accompanied by a %OSPF-4-BADLSA console message. Because this problem is not common, Contact Cisco for assistance.
Typical Reasons for OSPF Neighbor Problems

This table lists reasons why OSPF neighbors have problems forming an adjacency and lists some of the commands you can use to verify the problem. TAC Case Collection can also help diagnose problems.

Popularity: 28% [?]