VMware ESXi and vSphere Cluster Management

OSPF Neighbor States: From Down to Full Adjacency

Learn the OSPF neighbor-state sequence, packet exchanges, DR and BDR behavior, adjacency requirements, Cisco verification commands, and state-based troubleshooting.

OSPF neighbor states show how two OSPF routers progress from discovering one another to synchronizing their link-state databases. The sequence is one of the most useful troubleshooting indicators in OSPF: the state where a neighbor stops often identifies the part of the process that is failing.

An OSPF neighbor is a router with which OSPF has exchanged Hello packets on an OSPF-enabled link or segment. An OSPF adjacency is a neighbor relationship selected to synchronize link-state databases fully. Every adjacency begins as a neighbor relationship, but not every neighbor becomes fully adjacent.

Why OSPF Uses Neighbor States

Before routers calculate routes, they must discover eligible peers, confirm two-way communication, agree on important parameters, and synchronize the Link-State Database (LSDB). The LSDB is the collection of Link-State Advertisements (LSAs) that describes OSPF topology information for an area.

OSPF state information can be viewed with commands such as show ip ospf neighbor and show ip ospf neighbor detail. A neighbor that remains in a particular state provides a starting point for troubleshooting.

OSPF Neighbor-State Sequence

The usual sequence is Down, Attempt, Init, 2-Way, ExStart, Exchange, Loading, Full. Attempt is a special state for manually configured neighbors on NBMA networks and is not normally seen during neighbor formation on broadcast Ethernet.

Down --Hello--> Init --two-way Hello--> 2-Way --adjacency selected--> ExStart --> Exchange --> Loading --> Full

Attempt: NBMA-only discovery state for a statically configured neighbor

On a shared broadcast or NBMA segment, some neighbors may intentionally remain in 2-Way. DR and BDR operation avoids creating a full adjacency between every possible pair of routers.

OSPF Neighbor States at a Glance

State	What the router has confirmed	Primary packets or actions	Expected next state	Common issue if persistent
Down	No valid recent Hello from the peer	Wait for or send Hello packets	Init	Interface, filtering, passive interface, timers, or authentication
Attempt	A configured NBMA neighbor is being actively contacted	Unicast Hellos to the configured address	Init	Incorrect static neighbor or unreachable NBMA peer
Init	A Hello was received, but it does not list this router ID	Hello exchange is one-way	2-Way	Return-path failure or peer-side configuration problem
2-Way	Each router sees its own router ID in the other's Hello	Two-way Hello communication; DR/BDR decision	ExStart if adjacency is required	Normal for DROther-to-DROther; otherwise eligibility or network-type issue
ExStart	Adjacency negotiation has begun	Master/slave negotiation and initial DD sequence number	Exchange	MTU mismatch, duplicate router ID, or unstable link
Exchange	DBD summaries are being exchanged	Database Description packets containing LSA headers	Loading or Full	MTU, network-type, packet-loss, or identity inconsistency
Loading	Missing or newer LSAs have been identified	LSR, LSU, and LSAck exchange	Full	Loss, filtering, resource pressure, or unstable connectivity
Full	Relevant LSDB contents are synchronized	Normal LSA flooding and SPF operation	Full until failure	Later liveness loss, interface flap, or parameter change

State-by-State Explanation

Down

Down is the initial or inactive state. The router has not received a valid Hello from the peer during the applicable period. If an established neighbor stops sending Hellos, the Dead interval determines how long OSPF waits before declaring that neighbor Down. The Dead interval is the maximum time allowed without receiving a Hello.

Common causes include a down interface, OSPF not enabled on the intended interface, a passive interface, multicast or unicast reachability problems, access-list filtering, authentication mismatch, incompatible Hello or Dead intervals, and incompatible network types.

Attempt

Attempt is associated with NBMA, or nonbroadcast multi-access, networks. Because an NBMA network may not support automatic multicast discovery, a router can have statically configured neighbor addresses and actively send unicast Hellos while trying to establish contact.

Attempt is generally absent on point-to-point and broadcast Ethernet links. Seeing it on a normal Ethernet adjacency usually suggests that the network type or interpretation of the topology should be checked.

Init

In Init, a router has received a Hello from the peer, but its own router ID is not listed in the peer's Hello neighbor field. This indicates one-way Hello communication: traffic is arriving in one direction, but bidirectional confirmation has not occurred.

Investigate unidirectional Layer 1 or Layer 2 connectivity, a peer-side OSPF or interface problem, incorrect addressing, and filtering of return traffic. Inspecting Hello packets can confirm whether the local router ID is missing.

2-Way

In 2-Way, each router has seen its own router ID in the other router's Hello. This confirms bidirectional communication.

On broadcast and NBMA multiaccess networks, OSPF uses a Designated Router (DR) and Backup Designated Router (BDR) to reduce the number of full adjacencies and simplify flooding. A DROther is a router that is neither the DR nor the BDR.

Two DROther routers commonly remain in 2-Way with each other by design. They form Full adjacencies with the DR and BDR. Point-to-point neighbors normally continue from 2-Way toward Full because there is no multiaccess DR/BDR restriction.

ExStart

In ExStart, routers begin database synchronization. They negotiate master and slave roles for Database Description packet exchange and select an initial DD sequence number. The master controls the sequence used to coordinate the exchange.

A persistent ExStart condition is especially associated with an MTU mismatch. Also check duplicate router IDs, incompatible interface behavior or network types, unstable links, and packet handling problems.

Exchange

In Exchange, routers send Database Description (DBD or DD) packets. A DBD packet summarizes LSDB contents by carrying LSA headers; it does not normally carry the complete LSAs.

Each router compares the received LSA headers with its local LSDB to identify missing or outdated topology information. The complete information is requested and delivered later with LSR and LSU packets.

Loading

In Loading, a router sends Link-State Request (LSR) packets for missing or newer LSAs. The neighbor returns the requested information in Link-State Update (LSU) packets. Link-State Acknowledgment (LSAck) packets provide reliable confirmation that LSAs were received.

Loading completes when all needed LSAs have been received, processed, and acknowledged as appropriate. Persistent Loading can result from packet loss, filtering, corrupted or unstable links, congestion, high CPU use, or insufficient memory.

Full

Full means the relevant LSDBs are synchronized and the neighbor relationship is a completed adjacency. The routers can participate in normal LSA flooding and use the synchronized topology information for SPF route calculation.

Full does not mean every router on a shared network must be fully adjacent to every other router. For example, two DROther routers normally remain 2-Way with one another while each reaches Full with the DR and BDR.

OSPF Packet Types and State Relationships

Packet type	Purpose	Primary neighbor states	Contents or key fields
Hello	Discovery, liveness, parameter checking, and two-way confirmation	Down, Attempt, Init, 2-Way	Router ID, area, timers, options, priority, DR/BDR information, and neighbor IDs
Database Description	Summarizes LSDB contents during database exchange	ExStart, Exchange	LSA headers, DD sequence number, and master/slave control flags
Link-State Request	Requests a missing or newer LSA	Loading	Identifiers for specific LSAs needed by the requesting router
Link-State Update	Delivers topology information	Loading and normal flooding	One or more complete LSAs
Link-State Acknowledgment	Confirms reliable receipt of LSAs	Loading and normal flooding	LSA headers identifying received LSAs

DBD packets advertise LSA headers. LSAs are the actual topology information maintained in the LSDB, and LSUs carry one or more complete LSAs.

Adjacency Eligibility by Network Type

Network type	Neighbor pair or role relationship	Expected stable state	Reason
Point-to-point	Both peers	Full	No DR/BDR election; the direct peer is normally fully adjacent
Broadcast	DR to BDR	Full	Both central flooding roles must synchronize
Broadcast	DR to DROther	Full	DROther synchronizes with the DR
Broadcast	BDR to DROther	Full	DROther synchronizes with the BDR
Broadcast	DROther to DROther	2-Way	Full adjacency is not required between non-DR/non-BDR routers
NBMA	Configured peers	Full when eligible; Attempt during discovery	Static unicast neighbor configuration may be required, with DR/BDR behavior still relevant
Point-to-multipoint	Each reachable peer	Normally Full	Each peer is treated as a point-to-point relationship; no DR/BDR is normally used
Point-to-multipoint nonbroadcast	Each statically defined peer	Normally Full after Attempt or discovery	Unicast neighbor configuration may be needed because automatic broadcast discovery is unavailable

DR and BDR election reduces the number of required full adjacencies on multiaccess networks. Interface priority influences election; a priority of zero prevents a router from becoming DR or BDR.

Requirements for Neighbor Formation

Area: Interfaces must use compatible area assignments. In an overall multi-area design, the backbone area is Area 0 and provides the required inter-area connectivity.
Timers: Hello and Dead intervals must match on the link.
Authentication: Authentication type and credentials must match.
Area options: Area type settings and options, including stub-related flags where applicable, must be compatible.
Network type: The interfaces need compatible network-type behavior. A mismatch can affect discovery, DR/BDR operation, and adjacency formation.
MTU: Compatible interface MTU behavior is required for successful DBD negotiation and exchange.
Identity: Router IDs must be unique within the OSPF routing domain.
Addressing and reachability: Interfaces need valid, reachable addressing and operational Layer 1, Layer 2, and Layer 3 connectivity.

Normal Point-to-Point Example

Consider two routers connected by a point-to-point link. Both interfaces are operational, OSPF is enabled in the same area, Hello and Dead intervals match, authentication matches, MTUs match, and router IDs are unique.

The expected progression on each router is:

Down -> Init -> 2-Way -> ExStart -> Exchange -> Loading -> Full

The final neighbor state should be Full on both routers. Hellos establish discovery and liveness, DBD packets compare LSDB summaries, and LSR, LSU, and LSAck packets complete synchronization.

Broadcast Ethernet with a DR and BDR

On a shared Ethernet VLAN with four routers, one router can be elected DR, one BDR, and the remaining two DROther routers. Each DROther forms Full adjacencies with the DR and BDR. The two DROther routers display 2-Way with each other, which is expected behavior rather than a failure.

DR       <==== Full ====> BDR
DR       <==== Full ====> DROther-1
BDR      <==== Full ====> DROther-1
DR       <==== Full ====> DROther-2
BDR      <==== Full ====> DROther-2
DROther-1 <---- 2-Way ---> DROther-2

Example: Neighbor Stuck in Init

Suppose Router A receives Hellos from Router B, but Router B's Hello does not list Router A's router ID. Router A remains in Init because it cannot confirm bidirectional communication.

Inspect the received Hello or neighbor details, then check the return path, interface errors, switch behavior, access lists, and whether OSPF is correctly enabled on Router B. After both routers receive and list each other's router IDs, the relationship should move to 2-Way and then continue if a Full adjacency is required.

Example: ExStart Caused by MTU Mismatch

If one adjacent interface has an MTU of 1500 bytes and the other has an MTU of 1400 bytes, Hello exchange may succeed while DBD negotiation fails. The neighbor can remain in ExStart or repeatedly reset between ExStart and Exchange.

Compare the interface MTUs, correct the mismatch according to the design, and verify that the neighbor progresses to Full. Ignoring MTU problems may allow discovery while preventing database exchange.

Example: NBMA Attempt State

On an NBMA topology, configure the peer's address as a static OSPF neighbor when automatic multicast discovery is unavailable. The router sends unicast Hellos to that configured address. Attempt is therefore an expected intermediate state while the router tries to discover the peer; it is not a normal stage for broadcast Ethernet neighbor formation.

Cisco IOS and IOS XE Verification

Begin with non-disruptive show commands. These commands reveal state, identity, timers, roles, interface settings, and resulting routes:

show ip ospf neighbor
show ip ospf neighbor detail
show ip ospf interface
show ip ospf interface brief
show ip ospf
show ip route ospf
show running-config | section router ospf
show running-config interface <interface-id>
show ip interface <interface-id>
show interfaces <interface-id>

Useful fields include neighbor state, neighbor address, local and remote router IDs, priority, dead timer, and DR/BDR role.

Basic Interface Configuration

router ospf <process-id>
 router-id <router-id>
!
interface <interface-id>
 ip ospf <process-id> area <area-id>
 ip ospf hello-interval <seconds>
 ip ospf dead-interval <seconds>
 ip ospf authentication message-digest
 ip ospf message-digest-key <key-id> md5 <key>

Network Type, Priority, and NBMA Examples

interface <interface-id>
 ip ospf network point-to-point
 ip ospf network broadcast
 ip ospf network non-broadcast
 ip ospf priority <0-255>
!
router ospf <process-id>
 neighbor <neighbor-ip-address>

Use only the network-type and neighbor settings appropriate for the actual topology. Changing a network type can alter DR/BDR behavior and adjacency expectations.

State-Based Troubleshooting Workflow

Check interface status and Layer 2 and Layer 3 reachability. Confirm the link is operational, addressing is correct, and interface errors or flaps are absent.
Verify OSPF is enabled on the intended interface and that the interface is not passive when an adjacency is expected.
Check show ip ospf neighbor for state, router ID, priority, dead timer, address, and DR/BDR role.
Compare area, Hello interval, Dead interval, authentication, area options, network type, MTU, and router IDs on both routers.
Check multicast or required unicast reachability and inspect access lists, firewalls, or other packet filters.
Use debug only after the preceding checks and only in a lab or controlled maintenance context.

Observed state	Likely interpretation	Likely causes	Checks and corrective actions
Down	No valid recent Hello	Interface down, OSPF disabled, passive interface, filtering, authentication, timers, or network type	Restore the interface and bidirectional Hello exchange; compare settings
Attempt	NBMA router is trying a configured peer	Wrong static neighbor address, unreachable peer, or unsuitable network type	Verify unicast reachability and neighbor configuration
Init	Hello arrives but local router ID is absent from the peer's Hello	One-way connectivity, peer OSPF issue, interface fault, or return filtering	Inspect Hellos and fix the return path or peer configuration
2-Way when Full is expected	Bidirectional communication exists, but adjacency was not selected	DROther-to-DROther relationship, DR/BDR role, network-type mismatch, or eligibility issue	Accept 2-Way when intentional; otherwise verify roles, priority, and network type
ExStart or Exchange	DBD negotiation or summary exchange is failing	MTU mismatch, duplicate router ID, incompatible network type, packet loss, or unstable link	Compare MTUs and IDs first; then inspect link health and packet handling
Loading	Outstanding LSA requests remain	Loss or filtering of LSR, LSU, or LSAck packets, resource pressure, or unstable connectivity	Check errors, congestion, CPU, memory, filtering, and reliable LSA exchange

Controlled Debugging

Debugging can generate substantial output and CPU load. Do not use it as the first troubleshooting step; prefer a lab or controlled maintenance window.

debug ip ospf adj
debug ip ospf hello
undebug all

Common Failure Patterns

Neighbor Remains Down

Verify both interfaces are operational and have compatible connectivity. Confirm OSPF activation, area assignment, passive-interface settings, multicast or unicast reachability, authentication, timers, network type, and filtering. The goal is valid bidirectional Hello exchange.

Neighbor Remains Init

Confirm that received Hellos do not contain the local router ID. Investigate one-way communication, peer configuration, interface faults, and filtering of return traffic.

Neighbor Is 2-Way

First determine whether both routers are DROthers on a broadcast or NBMA segment. If so, 2-Way is normal. If Full is expected, validate DR/BDR roles, network type, adjacency eligibility, and interface configuration.

Neighbor Repeatedly Resets at ExStart or Exchange

Compare MTU values first. Then check duplicate router IDs, link stability, network-type compatibility, and whether protocol packets are being altered or dropped.

Neighbor Remains Loading

Check for loss or filtering of LSR, LSU, and acknowledgment traffic. Review interface errors, congestion, CPU or memory pressure, and unstable connectivity until outstanding requests are cleared.

Adjacency Forms but Later Drops

Compare Hello and Dead timers and check intermittent Layer 1 or Layer 2 faults, packet loss, interface flaps, CPU saturation, and authentication changes.

Exam-Relevant Notes

Init means a Hello was received, but the local router ID was not seen in the peer's Hello.
2-Way means bidirectional Hello communication is confirmed, not necessarily that LSDB synchronization is complete.
ExStart negotiates master/slave roles and the initial DD sequence number.
DBD packets carry LSA headers and summaries; LSUs carry complete LSAs.
LSRs request missing or newer LSAs, and LSAcks acknowledge received LSAs.
Two DROther routers on a broadcast segment normally remain 2-Way.
Attempt is primarily associated with statically configured NBMA neighbors.
MTU mismatch is a classic cause of ExStart or Exchange problems.
Full indicates synchronized relevant LSDBs, not a full mesh of every shared-segment neighbor.

For a concise reference to this progression, return to OSPF neighbor states.