CCNA online course

OSPF Neighbor States Explained

Learn every OSPF neighbor state from Down to Full, understand DR and BDR behavior, and troubleshoot adjacency problems using Cisco IOS verification commands.

OSPF, or Open Shortest Path First, is a link-state interior gateway protocol. It builds a view of network topology by exchanging link-state advertisements, or LSAs, with other OSPF routers. Before routers can exchange this information reliably, they must discover one another and agree on important operating parameters.

This lesson explains the OSPF neighbor state machine: Down, Init, 2-Way, ExStart, Exchange, Loading, and Full. It also explains why a neighbor can legitimately remain in 2-Way on a broadcast LAN and provides a state-driven troubleshooting workflow for Cisco IOS and IOS XE.

Why OSPF Routers Form Neighbor Relationships

An OSPF neighbor is a router from which valid OSPF Hello packets are received on an OSPF-enabled segment. Neighbor discovery prevents a router from exchanging topology information with an unknown or incompatible device.

A Hello packet is used for neighbor discovery, keepalives, parameter checks, and DR/BDR election. The Hello interval is the time between transmitted Hellos. The dead interval is the maximum time a router waits without receiving a Hello before declaring the neighbor unavailable.

Receiving a Hello creates neighbor awareness, but it does not automatically mean that the routers have synchronized their link-state databases. A neighbor relationship is the broader relationship created through Hello communication. An adjacency is a relationship that progresses through database synchronization, normally reaching Full state.

Each Hello includes information such as the sender's router ID, area, timers, authentication information, network type, and the router IDs of neighbors already known on the segment. A router can use this information to confirm that communication is bidirectional and that the two routers are compatible.

OSPF Neighbor State Machine

OSPF progresses through a defined state machine. The state is maintained independently for each neighbor, so one neighbor can be Full while another on the same interface is still in Exchange or remains in 2-Way. The exact progression also depends on the interface network type.

1. Down: No valid Hello has been received within the dead interval.
2. Init: A Hello has been received, but it does not list the local router ID.
3. 2-Way: Both routers see one another in their Hello packets.
4. ExStart: The routers negotiate master and slave roles and initial database-description sequence numbers.
5. Exchange: Database Description packets summarize the routers' link-state databases.
6. Loading: Link-State Requests and Link-State Updates obtain missing or newer LSAs.
7. Full: The link-state databases are synchronized.

Down State

Down means that no valid Hello has been received from the neighbor within the dead interval. A newly configured neighbor begins in Down before the first acceptable Hello arrives. An established neighbor can also return to Down when Hellos stop arriving for the duration of the dead timer.

Common causes include an administratively down or failed interface, incorrect IP addressing, OSPF not enabled on the interface, a passive interface, an incorrect area, and blocked OSPF multicast traffic. OSPF uses protocol-specific multicast on many network types, so an ACL, switch feature, firewall, or other filtering device can prevent Hello delivery.

Init State

In Init, a router has received a Hello from a neighbor, but the received Hello does not contain the local router's ID in its neighbor list. This is evidence that the local router can hear the neighbor, while the neighbor may not be receiving or accepting the local router's Hellos.

This one-way communication prevents normal adjacency formation. Investigate unidirectional Layer 2 faults, blocked return traffic, multicast filtering, ACLs, asymmetric reachability, and interface errors. Capturing or debugging Hellos in a controlled environment can confirm whether each direction is working.

2-Way State

2-Way confirms bidirectional Hello communication. Each router ID appears in the other router's Hello neighbor list. At this point, the routers know one another and have verified enough information to decide whether a full database adjacency is needed.

On broadcast and non-broadcast multiaccess networks, OSPF elects a Designated Router (DR) and a Backup Designated Router (BDR). The DR reduces the number of required adjacencies and originates the network LSA for the segment. The BDR is prepared to take over DR duties.

A router that is neither DR nor BDR is a DROther. DROther routers normally form Full adjacencies with the DR and BDR, but remain in 2-Way with one another. Therefore, 2-Way is healthy and expected between two DROthers on a broadcast LAN.

2-Way indicates an incomplete adjacency only when the network type and router roles require the two routers to synchronize databases. For example, two expected peers on a point-to-point link should normally continue from 2-Way to ExStart and eventually Full.

ExStart State

During ExStart, the routers negotiate which one is the master and which one is the slave for Database Description packet sequencing. The router with the higher router ID normally becomes master. The routers also negotiate initial database-description sequence numbers.

The OSPF router ID is a unique 32-bit identifier used to identify routers, including during master/slave negotiation. Duplicate router IDs can produce confusing neighbor behavior and prevent stable adjacency formation.

A common ExStart failure is an MTU mismatch. The interface MTU is the largest Layer 3 packet that can be sent without fragmentation on that interface. If directly connected OSPF interfaces advertise incompatible MTUs, DBD packets may not be accepted, leaving the neighbor in ExStart or causing repeated resets.

Exchange State

In Exchange, routers send Database Description, or DBD, packets. A DBD contains summaries of LSAs in the sender's link-state database, rather than the complete LSA contents.

Each router compares the summaries with its own LSDB. It identifies LSAs that are missing locally or that have newer information on the neighbor. Those LSAs are requested in the Loading state.

Exchange problems can result from MTU incompatibility, packet loss, unstable links, inconsistent network types, duplicate router IDs, or failed master/slave negotiation. Repeated transitions between ExStart and Exchange are especially useful evidence that DBD packets are not being accepted or completed.

Loading State

In Loading, a router requests missing or newer LSAs with Link-State Request (LSR) packets. The neighbor supplies the requested information in Link-State Update (LSU) packets. Link-State Acknowledgment (LSAck) packets provide reliable confirmation of LSA delivery.

After all required LSAs have been received and acknowledged, the link-state databases are synchronized and the neighbor reaches Full. A neighbor that remains in Loading may have LSA delivery problems, inconsistent authentication, packet filtering, unstable connectivity, or recurring interface resets.

Full State

Full means the routers have synchronized their link-state databases for that adjacency. Each router can use the shared LSDB to calculate routes with the Shortest Path First algorithm.

Point-to-point peers normally reach Full with one another. On a broadcast segment, the DR and BDR normally reach Full with the other OSPF routers. Two DROthers normally remain 2-Way with each other.

Full does not guarantee end-to-end IP reachability. Routes can still be missing because of incorrect network advertisements, area design, filtering, summarization, route selection, an incomplete LSDB elsewhere, or a data-plane problem. Verify the routing table and forwarding path separately.

Expected States by Network Type and Role

Adjacency Prerequisites and Compatibility Checks

Before investigating advanced database synchronization, verify the basic parameters that must match or be compatible:

• Area ID: Both interfaces must belong to the same OSPF area on the shared segment.
• IP subnet and Layer 2 reachability: The interfaces must be correctly addressed and able to exchange traffic on the shared segment.
• Hello interval: The Hello timers must match.
• Dead interval: The dead timers must match.
• Authentication: Authentication type, key, and credentials must be compatible.
• Area type: The routers must agree on area behavior, such as normal, stub, or other supported area configurations.
• Router ID: Every OSPF router in the routing domain must have a unique router ID.
• OSPF process enablement: OSPF must be enabled on the correct interface. A passive interface advertises its connected network but does not send or receive Hellos.
• Network type: The configured network type must be appropriate and compatible with the segment and the neighbor.
• MTU: Directly connected interfaces should use compatible Layer 3 MTU values.

Cisco IOS and IOS XE Verification

Start with the neighbor table. It identifies the neighbor router ID, current state, interface, priority, and often the DR or BDR relationship.

show ip ospf neighbor
show ip ospf neighbor detail

Inspect the OSPF-enabled interface for area, timers, network type, priority, state, and designated-router information.

show ip ospf interface
show ip ospf interface brief
show ip ospf interface <interface>

Verify the underlying interface, OSPF process, and configuration:

show ip interface brief
show interfaces <interface>
show running-config interface <interface>
show ip protocols

Baseline OSPF Interface Configuration

OSPF can be enabled with a network statement or directly under an interface. The following commands show common Cisco IOS and IOS XE forms:

router ospf <process-id>
 router-id <router-id>
 network <network-address> <wildcard-mask> area <area-id>

interface <interface>
 ip ospf <process-id> area <area-id>

Interface-specific parameters can be inspected or configured with commands such as:

interface <interface>
 ip ospf hello-interval <seconds>
 ip ospf dead-interval <seconds>
 ip ospf network point-to-point
 ip mtu <bytes>

Use Configure OSPF for a broader configuration review. For LSAs and the LSDB, see Link-State Advertisement (LSA).

State-Driven Troubleshooting Workflow

1. Identify the exact state: Run show ip ospf neighbor and note the neighbor router ID, interface, state, priority, and DR/BDR role.
2. Verify Layer 1 and Layer 2: Confirm that both interfaces are administratively and operationally up. Check cabling, VLANs, switch ports, errors, and link stability.
3. Verify IP connectivity: Confirm correct addresses and subnet masks on the shared segment. Test reachability as appropriate for the network type.
4. Confirm Hello exchange: Check that OSPF is enabled on both interfaces, neither required interface is passive, and multicast or configured unicast neighbor traffic is not filtered.
5. Compare OSPF parameters: Check area ID, Hello and dead intervals, authentication, area type, network type, router IDs, and MTU.
6. Investigate database synchronization: If the neighbor reaches ExStart, Exchange, or Loading, focus on DBD and LSA delivery, packet loss, MTU, authentication, and interface stability.
7. Verify routing separately: After Full is reached, inspect the LSDB and routing table. A Full neighbor is necessary but not sufficient for correct end-to-end forwarding.

OSPF Adjacency Parameter Compatibility

Practical Examples

Point-to-Point Link Reaches Full

Two routers connected by a point-to-point transit link should normally progress from Down to Init, 2-Way, ExStart, Exchange, Loading, and Full. After convergence, each router should report the other router in Full state on the transit interface.

show ip ospf neighbor

If the relationship stops at 2-Way on this type of link, verify the configured network type, timers, area, authentication, MTU, router IDs, and bidirectional packet flow.

Broadcast LAN Shows Healthy 2-Way Relationships

Consider an Ethernet segment with four OSPF routers. One becomes the DR, one becomes the BDR, and the remaining two become DROthers. Each DROther should normally show Full with the DR and BDR, but 2-Way with the other DROther.

This is a design feature that reduces the number of full adjacencies on a multiaccess network. Do not treat every 2-Way entry as a fault; first determine the network type and the roles shown in the neighbor output.

Hello and Dead Timer Mismatch

If two routers on the same segment use different Hello or dead intervals, they do not form the expected adjacency. Inspect the OSPF interface output on both routers, configure matching values, and then verify that the neighbor progresses through the state machine.

show ip ospf interface <interface>

interface <interface>
 ip ospf hello-interval <seconds>
 ip ospf dead-interval <seconds>

MTU Mismatch in ExStart or Exchange

Configure unequal interface MTUs on directly connected OSPF routers and the neighbor may remain in ExStart or Exchange. Compare the interface MTU values, make them compatible, and verify that the relationship reaches Full.

show interfaces <interface>
show ip ospf interface <interface>

interface <interface>
 ip mtu <bytes>

One-Way Communication Remains at Init

If one router receives Hellos but the return Hellos are absent or blocked, the receiving router remains in Init because its router ID is not listed in the neighbor's Hello. Restore bidirectional Layer 2 or multicast communication, then verify that the relationship reaches 2-Way or Full as appropriate.

Controlled Debugging and Process Reset

Debugging can reveal Hello reception, adjacency transitions, and negotiation failures, but it should be used cautiously. Debug output can consume CPU and generate extensive terminal output. Use it in a lab or controlled maintenance window, preferably with logging and rate awareness.

debug ip ospf hello
debug ip ospf adj
undebug all

clear ip ospf process resets the OSPF process. This disrupts all OSPF neighbor relationships and routing while adjacencies reform, so use it only in a lab or during an approved maintenance window after less disruptive checks have been completed.

clear ip ospf process

Exam-Relevant Notes

• Init means a Hello was received, but the local router ID was not found in the neighbor's Hello neighbor list.
• 2-Way means bidirectional Hello communication exists; it does not always mean that the LSDB is synchronized.
• Two DROthers on a broadcast network normally remain 2-Way with one another.
• ExStart is where master/slave roles and initial DBD sequence numbers are negotiated.
• MTU mismatches commonly stop adjacency progression in ExStart or Exchange.
• Loading uses LSR and LSU packets to obtain missing LSAs; LSAck confirms reliable delivery.
• Full indicates synchronized databases, not guaranteed end-to-end reachability.
• The OSPF process ID is locally significant on Cisco devices, while the router ID must be unique within the OSPF routing domain.

Summary

OSPF uses Hello packets to discover and maintain neighbors, then advances compatible neighbors through database synchronization states. Down and Init primarily point to missing or one-way Hello communication. 2-Way confirms bidirectional awareness and can be the correct final state between DROthers on a broadcast network. ExStart and Exchange involve DBD negotiation and database summaries, while Loading retrieves missing LSAs. Full means the adjacency databases are synchronized.

When troubleshooting, begin with the observed state and check from the bottom up: interface and Layer 2 health, IP connectivity, Hello exchange, OSPF parameters, and finally DBD and LSA synchronization. For related protocol foundations, review the OSI Reference Model and OSPF Route Summarization.