OSPF Neighbor Discovery and Adjacency Formation

Learn how OSPF routers discover neighbors with Hello packets, progress through neighbor states, elect DR and BDR routers, synchronize LSDBs, and troubleshoot incomplete adjacencies.

What OSPF Neighbor Discovery Accomplishes

OSPF (Open Shortest Path First) is a link-state interior gateway protocol. Before routers can exchange topology information, they must identify compatible OSPF peers on a shared network segment.

An OSPF neighbor is a router detected through Hello packet exchange. An adjacency is a neighbor relationship that has completed the required link-state database synchronization. Every adjacency is a neighbor relationship, but not every neighbor becomes fully adjacent.

Neighbor discovery verifies items such as the area, timers, authentication, network type, and router IDs. Once compatible routers become adjacent, they exchange link-state advertisements (LSAs). Each router uses the received LSAs to build its link-state database (LSDB), then runs the SPF algorithm to calculate routes.

OSPF Hello Protocol

A Hello packet discovers neighbors, confirms that a neighbor is still reachable, and validates important configuration parameters. OSPF sends Hellos periodically on an OSPF-enabled interface.

IPv4 OSPF uses 224.0.0.5, the AllSPFRouters multicast address, for traffic sent to all OSPF routers.
IPv4 OSPF uses 224.0.0.6, the AllDRouters multicast address, for traffic sent to the DR and BDR.
The Hello interval is how often a router sends a Hello.
The dead interval is the maximum time a router waits without receiving a Hello before declaring the neighbor unavailable.

An outgoing Hello includes the sending router's parameters and a list of router IDs from which it has received Hellos. When Router A sees its own router ID listed in Router B's Hello, Router A knows that communication is bidirectional. This recognition drives the relationship to the 2-Way state.

Hello and dead timers

Neighboring interfaces must use compatible Hello and dead intervals. A common Cisco IOS default on broadcast and point-to-point networks is a 10-second Hello interval and a 40-second dead interval. Other network types commonly use different defaults, so verify the actual interface settings rather than assuming them.

A missed Hello does not immediately remove a neighbor. The neighbor is declared down only after the dead interval expires. Packet loss, a failed interface, congestion, or a timer mismatch can therefore produce neighbor flaps or a Down state.

Neighbor Compatibility Requirements

Receiving a Hello is not enough to form an adjacency. The routers must agree on the values that define how the OSPF relationship operates.

Setting	Must match or be compatible	Where to verify	Typical symptom when incorrect
Area ID	Both interfaces on the common segment must belong to the same OSPF area.	`show ip ospf interface`	No neighbor or a neighbor that does not progress normally.
Hello and dead intervals	Hello frequency and dead timer must match.	`show ip ospf interface`	Hellos are rejected or the neighbor does not establish.
Authentication	Authentication type and credentials must match when enabled.	Interface configuration and OSPF logs	Authentication failure and no usable adjacency.
Network type	The interfaces must use compatible OSPF network behavior.	`show ip ospf interface`	Unexpected DR behavior, missing multicast discovery, or incomplete adjacency.
IPv4 subnet and mask	Interfaces on a shared multiaccess segment must have compatible addressing and mask expectations.	`show ip interface brief` and interface configuration	Hellos may not be accepted or the segment may be treated incorrectly.
Router ID	Every OSPF router in the routing domain needs a unique router ID.	`show ip ospf`	Incorrect identity, unstable operation, or duplicate-router-ID messages.
Area type and flags	Stub-related options and other area-type settings must be compatible.	`show ip ospf` and area configuration	Neighbor rejection or failure to progress toward Full.
Interface MTU	MTU should match on both ends of an adjacency.	`show interfaces`	Initial discovery may work, but the neighbor often stalls in ExStart or Exchange.

A network type is the OSPF interface behavior model. It determines discovery method, common timer defaults, whether a DR and BDR are elected, and how neighbors are expected to form adjacencies.

OSPF Router ID Selection

The router ID is a unique 32-bit OSPF identifier displayed in IPv4 address notation. It does not have to be an address reachable through the routing table, but it must be unique within the OSPF routing domain.

Cisco IOS selects the router ID in this order:

A manually configured OSPF router ID.
The highest IPv4 address on an up loopback interface.
The highest IPv4 address on an active physical interface, if no loopback address exists.

A manually configured ID or a stable loopback address is preferred because physical interfaces can fail or change. After changing a router ID, reset or restart the OSPF process so the new ID takes effect. Use this carefully in production because the process reset temporarily removes OSPF routes and adjacencies.

router ospf 1
 router-id 1.1.1.1

OSPF Neighbor States

OSPF uses neighbor states to describe discovery and synchronization progress. The exact transition can vary slightly with network type, but the normal point-to-point sequence is Down, Init, 2-Way, ExStart, Exchange, Loading, and Full.

State	What the router knows	Packets or events involved	Expected next state	Common troubleshooting interpretation
Down	No valid Hello has been received within the expected period.	Hello transmission, timer expiration, or interface activation.	Init when a valid Hello arrives.	Check Layer 1/2, addressing, OSPF activation, multicast, and timers.
Init	A Hello from the neighbor was received, but the local router ID is not in that neighbor's Hello list.	One-way Hello communication.	2-Way after bidirectional recognition.	Often indicates return traffic, multicast, VLAN, filtering, or compatibility trouble.
2-Way	Both routers recognize one another.	Hellos contain each other's router IDs.	ExStart for routers that should become adjacent; remains 2-Way for DROTHER-to-DROTHER.	Normal on many multiaccess links; unexpected if a Full adjacency is required.
ExStart	The routers are preparing database synchronization and selecting roles.	Initial Database Description negotiation; master/slave selection uses router ID.	Exchange.	MTU mismatch and unstable links are common causes of a stall.
Exchange	The routers are comparing LSDB summaries.	Database Description (DBD or DD) packets list LSA headers.	Loading or Full if no LSAs are missing.	Investigate MTU, packet loss, and database-description exchange.
Loading	The routers know which LSAs are missing or outdated.	LSRs request LSAs; LSUs provide them; LSAcks confirm receipt.	Full after requested LSAs are received and acknowledged.	Look for packet loss, filtering, unstable links, or an LSDB synchronization problem.
Full	The required LSDB portions are synchronized.	LSA updates and acknowledgments maintain synchronization.	Remains Full until a failure or configuration change.	Normal for routers that should form an adjacency.

Adjacency Formation and LSDB Synchronization

Discovery: Interfaces send Hello packets and identify compatible neighbors.
Bidirectional recognition: Each router sees its own router ID in the other's Hello and reaches 2-Way.
ExStart: The routers negotiate the database exchange. The router with the higher router ID becomes the master; the other becomes the slave. The master controls the sequence of Database Description packets.
Exchange: DBD packets summarize the LSAs known by each router. They carry LSA headers rather than the complete LSA contents.
Loading: A router sends an LSR (Link-State Request) for missing or newer LSAs. The neighbor sends the requested information in an LSU (Link-State Update), which can contain one or more LSAs. An LSAck (Link-State Acknowledgment) confirms LSA receipt.
Full: Required LSAs have been exchanged and the databases are synchronized. The router can use the LSDB as input to SPF route calculation.

Packet type	Purpose	Neighbor-state phase	Key result
Hello	Discover, maintain, and validate neighbors.	Down through 2-Way and during normal operation.	Compatible, bidirectional neighbor relationship.
Database Description (DBD/DD)	Summarize LSDB contents with LSA headers.	ExStart and Exchange.	Routers identify missing or newer LSAs.
Link-State Request (LSR)	Request a specific missing or newer LSA.	Loading.	Neighbor knows which topology information is needed.
Link-State Update (LSU)	Deliver one or more LSAs.	Loading and ongoing operation.	Requested or changed topology information is received.
Link-State Acknowledgment (LSAck)	Acknowledge received LSAs.	Loading and ongoing reliable flooding.	LSA delivery is confirmed.

OSPF Network Types and Adjacency Behavior

Network type	Discovery method	Default Hello/Dead behavior	DR/BDR election	Expected adjacency pattern	Typical deployment
Broadcast	Multicast, including 224.0.0.5 and 224.0.0.6.	Common Cisco default: 10/40 seconds.	Yes.	DROTHER routers are 2-Way with one another and Full with DR/BDR.	Ethernet multiaccess LAN.
Point-to-point	Multicast.	Common Cisco default: 10/40 seconds.	No.	The two routers normally form a Full adjacency.	Dedicated routed link, including a two-router Ethernet link.
Point-to-multipoint	Multicast to reachable neighbors.	Common Cisco default: 30/120 seconds.	No.	Each reachable neighbor normally forms a direct adjacency.	Hub-and-spoke connectivity represented as multiple point-to-point relationships.
Nonbroadcast multiaccess (NBMA)	Neighbors are manually configured; multicast is not assumed.	Common Cisco default: 30/120 seconds.	Yes.	Adjacency behavior includes DR/BDR considerations and manually defined peers.	Older NBMA WAN technologies.
Point-to-multipoint nonbroadcast	Neighbors are manually configured because multicast is unavailable.	Common Cisco default: 30/120 seconds.	No.	Direct adjacencies to configured neighbors.	Nonbroadcast hub-and-spoke environments.

On a two-router Ethernet link, using the point-to-point network type avoids an unnecessary DR/BDR election and normally produces a direct Full adjacency. On a shared Ethernet LAN, the broadcast type supports multicast discovery and uses DR/BDR roles to control the number of adjacencies.

DR and BDR Election

A broadcast or NBMA segment can contain many routers. If every router formed a full adjacency with every other router, the number of relationships and update exchanges would grow rapidly. The designated router (DR) acts as a central adjacency point, and the backup designated router (BDR) is ready to assume the DR role if the DR fails.

Election order is based first on the highest OSPF interface priority and then, for ties, the highest router ID. An interface with priority 0 is ineligible to become either DR or BDR, although the router can still form adjacencies as a DROTHER.

OSPF elections are generally nonpreemptive. After a DR has been established, a newly arriving router with a higher priority does not normally replace it. In a lab, resetting neighbor relationships or restarting the process may be necessary to demonstrate a new election. Avoid unnecessary resets in production.

On a broadcast segment, each DROTHER becomes Full with the DR and BDR. DROTHER-to-DROTHER relationships normally remain 2-Way. The DR and BDR use 224.0.0.6 for traffic directed to them, while all OSPF routers listen on 224.0.0.5.

interface GigabitEthernet0/0
 ip ospf priority 100

interface GigabitEthernet0/1
 ip ospf priority 0

Practical Cisco IOS Examples

Two routers on a point-to-point Ethernet link

Assume two routers use 10.0.12.1/30 and 10.0.12.2/30. Enable OSPF in area 0 and identify the link as point-to-point.

router ospf 1
 router-id 1.1.1.1
 network 10.0.12.0 0.0.0.3 area 0

interface GigabitEthernet0/0
 ip address 10.0.12.1 255.255.255.252
 ip ospf 1 area 0
 ip ospf network point-to-point

Configure the second router with a unique router ID and the other address. After compatible Hellos and database synchronization, show ip ospf neighbor should show the neighbor in Full. No DR or BDR election is expected on this OSPF point-to-point network type.

Three routers on a shared Ethernet LAN

Leave the interfaces as the broadcast network type. Set priorities when a particular router should be preferred.

interface GigabitEthernet0/0
 ip ospf 1 area 0
 ip ospf priority 100

The highest eligible priority normally wins DR, and the next eligible router becomes BDR. If priorities tie, router IDs break the tie. On a segment with two DROTHER routers, their relationship with one another should be 2-Way, while their relationships with the DR and BDR should be Full.

Timer mismatch example

interface GigabitEthernet0/0
 ip ospf hello-interval 10
 ip ospf dead-interval 40

Apply matching values on both ends. If one router uses different values, neighbor discovery may fail or the relationship may not establish normally. After correcting the settings, allow the adjacency to reform or reset the relationship if needed.

Authentication mismatch example

interface GigabitEthernet0/0
 ip ospf authentication
 ip ospf authentication-key cisco

Authentication type and credentials must match on both interfaces. Different passwords or authentication settings cause Hellos to fail validation. Inspect logs or appropriate OSPF diagnostics, correct both sides, and verify that the neighbor recovers.

MTU mismatch example

If neighboring interfaces have different maximum transmission unit values, Hellos may succeed because initial discovery packets are small. The adjacency can then stall in ExStart or Exchange when Database Description packets are negotiated. Correct the interface MTU values. An MTU-ignore setting can sometimes bypass the check, but it should not be used as the first fix because the underlying packet-size mismatch remains.

Verification and Troubleshooting Workflow

Check Layer 1 and Layer 2: Confirm interfaces are up, the correct VLAN or switch segment is used, and the two routers can communicate on the expected network.
Check IPv4 addressing: Verify addresses, subnet masks, and the intended common segment.
Check OSPF activation: Confirm OSPF is enabled on both interfaces and that the interfaces are assigned to the same area.
Compare Hello parameters: Check Hello and dead intervals, authentication type and credentials, network type, and area flags.
Check router IDs: Confirm that each router ID is unique and that a recently changed ID was applied by restarting or resetting the OSPF process when appropriate.
Check MTU: Compare interface MTUs when the neighbor reaches ExStart or Exchange but does not progress.
Check DR/BDR expectations: Determine whether 2-Way is normal for the network type and router roles.
Check results: Review the neighbor table, OSPF interface settings, OSPF process information, routing table, and logs.

show ip ospf neighbor
show ip ospf neighbor detail
show ip ospf interface brief
show ip ospf interface GigabitEthernet0/0
show ip ospf
show ip protocols
show ip route ospf

Observed state	Normal or abnormal condition	Likely causes	Verification actions	Corrective actions
No neighbor	Abnormal when both routers should communicate.	Interface down, wrong segment, OSPF disabled, area/timer/authentication mismatch, incompatible network type, or unavailable multicast.	Check interfaces, addressing, OSPF interface output, timers, authentication, and switching.	Restore connectivity and make OSPF parameters compatible.
Init	Usually abnormal.	One-way Hello communication; the local router ID is absent from the remote Hello list.	Check return traffic, multicast handling, VLANs, ACLs, and Hello details.	Fix Layer 2 or filtering problems and correct incompatible settings.
2-Way	Normal between DROTHER routers on broadcast or NBMA networks; abnormal if a direct Full adjacency is required.	Expected DR behavior, wrong network type, or DR/BDR issue.	Identify DR, BDR, router roles, and interface network type.	Decide whether 2-Way is expected; correct network type or election configuration if not.
ExStart	Abnormal if it persists.	MTU mismatch, unstable link, or database-description negotiation problem.	Compare MTUs and review detailed neighbor output and adjacency messages.	Correct MTU or link/configuration problems, then reset the adjacency if necessary.
Exchange	Abnormal if it persists.	MTU mismatch, packet loss, or DBD exchange failure.	Compare MTUs, inspect logs, and check link stability.	Correct the mismatch and re-form the adjacency.
Loading	Abnormal if it persists.	Requested LSAs are not being delivered or acknowledged.	Inspect LSR/LSU behavior, packet delivery, logs, and link quality.	Remove filtering or transport problems and stabilize the link.
Repeated flaps	Abnormal.	Physical failures, dead timer expiration, CPU congestion, changing interface state, or duplicate router ID.	Correlate logs with interface errors, timer events, and router-ID messages.	Repair the link, address congestion, stabilize configuration, and ensure unique IDs.

Debugging carefully

debug ip ospf adj
debug ip ospf hello
clear ip ospf process

Use debugging and process clearing cautiously. Debug output can consume CPU and storage, and clearing the OSPF process disrupts production routing while adjacencies and routes are rebuilt. Prefer show commands first, and use these tools in a controlled lab or approved maintenance window.

Key Exam Notes

A neighbor is discovered through Hellos; an adjacency has synchronized the required LSDB information.
Seeing a router ID in the neighbor's Hello list indicates bidirectional recognition and supports the 2-Way state.
Full means synchronized link-state databases for routers that are expected to become adjacent.
Higher router ID selects the ExStart master when other selection details do not decide the result.
Interface priority 0 prevents DR and BDR election on that interface.
DR elections are generally nonpreemptive.
2-Way between DROTHER routers on a broadcast segment is usually correct, not a failure.
MTU mismatches commonly allow discovery but block progress in ExStart or Exchange.
After changing a router ID, restart or reset the OSPF process for the new ID to take effect.

For related configuration practice, see Configure OSPF. Review Link-State Advertisement (LSA) for the information carried during synchronization, and revisit the OSI Reference Model when separating physical, switching, and routing-layer causes.