Why OSPF Neighbors Get Stuck in 2-Way State

OSPF neighbour states confuse a lot of CCNA candidates, and the 2-Way state is one of the most misunderstood. Exam questions exploit this by presenting a 2-Way state and asking whether the network is working correctly.

The short answer: 2-Way between two DROther routers on a broadcast segment is completely normal. Understanding why requires knowing how OSPF builds adjacencies on different network types.

The OSPF Neighbour State Sequence

OSPF moves through a defined sequence of states as two routers establish a relationship:

1. Down — No hellos received yet
2. Attempt — Only on NBMA networks; hellos are sent unicast
3. Init — A hello was received but our own router ID was not in it
4. 2-Way — Our router ID appears in the neighbour's hello; bidirectional communication is confirmed
5. ExStart — Master/slave relationship negotiated; DBD exchange begins
6. Exchange — Database Description packets exchanged
7. Loading — LSR/LSU/LSAck exchanged to fill gaps
8. Full — Databases synchronised; adjacency is complete

The decision of whether to proceed past 2-Way to Full depends on the network type and the router's role.

Why 2-Way Is the End State for DROther Pairs

On a broadcast multi-access network, OSPF elects a Designated Router (DR) and Backup Designated Router (BDR) to reduce the number of adjacencies. All routers form full adjacencies only with the DR and BDR.

This means:

• DROther to DR: reaches Full
• DROther to BDR: reaches Full
• DROther to DROther: stops at 2-Way

The 2-Way state between two DROther routers is intentional. It confirms that hellos are being exchanged and that both routers are aware of each other. They do not synchronise their link-state databases directly — they do that through the DR.

When 2-Way Indicates a Real Problem

The 2-Way state is only a problem if you expect a Full adjacency and do not see one.

Point-to-Point Links — On a serial link or GRE tunnel, there is no DR/BDR election. Both routers should reach Full. If you see 2-Way on a point-to-point link, something is wrong — often a network type mismatch where one side thinks it is broadcast and the other thinks it is point-to-point.

NBMA Networks — On Frame Relay and similar networks, OSPF requires additional configuration. Misconfigured network type or missing static neighbour statements can leave routers stuck at 2-Way.

Router Priority Set to 0 on All Routers — If all routers on a segment have ip ospf priority 0, no DR or BDR can be elected. Routers see each other as DROther but there is no DR to form Full adjacencies with. No Full adjacencies exist on the segment.

Exam Question Pattern

The CCNA exam commonly presents this scenario:

R1 runs show ip ospf neighbor and sees R2 in state 2WAY/DROTHER. R1, R2, R3, and R4 are all connected to the same Ethernet switch. R3 is the DR. R4 is the BDR. What does the 2-Way state between R1 and R2 indicate?

Options typically include "misconfiguration," "timer mismatch," "normal operation," and "adjacency failure."

The correct answer is normal operation. R1 and R2 are both DROthers. They confirm reachability in 2-Way and rely on the DR (R3) to distribute LSAs.

A follow-up trap: the question might ask which command you would use to verify who the DR is. Use show ip ospf interface GigabitEthernet0/0 — this shows the DR and BDR IP addresses for that segment directly.

Changing Who Becomes DR

The DR election is based on:

1. Highest OSPF interface priority (default 1; 0 = cannot become DR)
2. Highest router ID (tiebreaker)

Priority is set with:

R1(config-if)# ip ospf priority 100

Important: the DR election is non-preemptive. Once a DR is elected, it stays DR until it fails or OSPF is reset, even if a router with a higher priority comes online later. Setting a higher priority does not immediately make a router the DR — it takes effect only after the current DR fails.

To force a re-election, use clear ip ospf process on the existing DR.

Summary Table

Practice CCNA OSPF questions with command output scenarios to solidify this before exam day.

The Exam Always Tests This in a Weird Way

The CCNA exam does not just ask you to define 2-Way. It wraps the concept in a topology question and makes the wrong answers look very plausible. Here are three question formats you will actually see and exactly how to think through each one.

Question Scenario 1

Four routers are connected to a common Ethernet segment. R1 has priority 0. R2 has priority 1. R3 has priority 5. R4 has priority 5 and router ID 10.0.0.4, which is higher than R3's router ID 10.0.0.3. A technician runs *show ip ospf neighbor* on R1 and sees R2 in state 2WAY/DROTHER. What does this indicate?

The trap here is that the question sounds like it might be describing a problem with R1 (priority 0) not being able to reach Full state with R2. It is not a problem. R2 and R1 are both DROthers — R2 lost the election to R3 and R4. R1 (priority 0) never entered the election. They are both DROthers so 2-Way is exactly correct.

Correct answer: R1 and R2 are both DROthers; 2-Way state is expected and indicates normal operation.

Question Scenario 2

A new router R5 is added to the same Ethernet segment with priority 200. A week later, a technician notices R5 still shows as 2WAY/DROTHER in the neighbour table of other routers. The current DR is R4. Should R5 have taken over as DR?

This tests the non-preemptive election rule. R5 has the highest priority on the segment. But the DR election already happened when R5 was not present. OSPF does not re-run the election just because a better candidate shows up. R5 will remain a DROther until R4 fails or the OSPF process is cleared.

Correct answer: No. OSPF DR elections are non-preemptive. R5 will only become DR if R4 fails or if the OSPF process is cleared on R4.

Question Scenario 3

A network administrator reports that all five routers on a segment are showing each other in 2WAY/DROTHER state. No router shows any neighbour in FULL state. What is the most likely cause?

This is the all-priority-0 trap. If every router has *ip ospf priority 0*, no router can be elected DR or BDR. Without a DR, no router can advance past 2-Way because Full adjacency requires going through the DR. The entire segment is stuck.

Correct answer: All routers on the segment have OSPF priority set to 0, preventing DR/BDR election. At least one router must have a non-zero priority.

Priority 0 — The Sneaky All-DROther Trap

This scenario deserves its own detailed explanation because it is subtle and the exam exploits it well.

When OSPF starts on a broadcast segment, routers hold a DR election. Normally, one router wins DR, one wins BDR, and everyone else is DROther. The DROthers form Full adjacencies with DR and BDR, and 2-Way with each other.

Now set all routers to priority 0. The election runs. No router is eligible. No DR is elected. No BDR is elected. Every router declares itself a DROther.

Here is the problem: DROthers advance to Full only with the DR and BDR. If there is no DR or BDR, there is no one to advance to Full with. Every router on the segment stays at 2-Way with every other router.

On the surface, this looks like the normal DROther-to-DROther 2-Way state. But in this case, it applies to every pair of routers on the segment, not just the DROther pairs. Nobody has a Full adjacency. Nobody has a synchronised link-state database. OSPF appears to be "running" (hellos exchange, neighbours form) but routing is completely broken.

How to spot this in the output:

**` R1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface 10.0.0.2 0 2WAY/DROTHER 00:00:38 192.168.1.2 Gi0/0 10.0.0.3 0 2WAY/DROTHER 00:00:35 192.168.1.3 Gi0/0 10.0.0.4 0 2WAY/DROTHER 00:00:40 192.168.1.4 Gi0/0 **`

Every neighbour has priority 0. No FULL state exists. The fix is changing at least one router's priority to a non-zero value and running *clear ip ospf process* to force a new election.

Watching the State Machine Live

You almost never need *debug ip ospf adj* in production — the output is overwhelming and it consumes CPU on the router. But on an exam scenario where they show you debug output and ask what it means, knowing how to read it is worth marks.

Here is what you see when two routers form a neighbour relationship from scratch:

**` R1# *May 19 10:00:01.123: OSPF-1 ADJ Gi0/0: 2WAY with 10.0.0.2, state 2WAY *May 19 10:00:01.124: OSPF-1 ADJ Gi0/0: Neighbor change Event, state EXSTART *May 19 10:00:01.125: OSPF-1 ADJ Gi0/0: DR/BDR election *May 19 10:00:01.126: OSPF-1 ADJ Gi0/0: Elect BDR 10.0.0.2 *May 19 10:00:01.127: OSPF-1 ADJ Gi0/0: Elect DR 10.0.0.2 *May 19 10:00:01.130: OSPF-1 ADJ Gi0/0: Send DBD to 10.0.0.2 seq 0x1F28 opt 0x52 flag 0x7 len 32 *May 19 10:00:01.200: OSPF-1 ADJ Gi0/0: Rcv DBD from 10.0.0.2 seq 0x232B opt 0x52 flag 0x7 len 32 state EXSTART *May 19 10:00:01.201: OSPF-1 ADJ Gi0/0: NBR Negotiation Done. We are the SLAVE May 19 10:00:01.210: OSPF-1 ADJ Gi0/0: Exchange Done May 19 10:00:01.300: OSPF-1 ADJ Gi0/0: Neighbor 10.0.0.2 is FULL **`

Line by line:

• 2WAY with 10.0.0.2 — Bidirectional communication confirmed. Both routers see each other's hello.
• state EXSTART — Decision made to advance to Full. Master/slave negotiation about to begin.
• DR/BDR election — Roles being assigned based on priority and router ID.
• Send DBD / Rcv DBD — Database Description packets being exchanged. This is where MTU mismatches cause problems — if these packets are too big, they get dropped here.
• NBR Negotiation Done. We are the SLAVE — The router with the lower router ID becomes slave. The master controls DBD sequence numbers.
• Exchange Done — Both sides have sent their full list of LSA headers.
• Neighbor 10.0.0.2 is FULL — Databases synchronised. Adjacency complete.

If you see the debug stop at EXSTART and loop on "Send DBD" with no "Rcv DBD" response, you are looking at an MTU mismatch. If it gets to Exchange and then drops back, there is usually a database inconsistency or a flapping link.

What clear ip ospf process Actually Does

This command is the nuclear option for OSPF and the exam tests whether you understand its implications.

**` R1# clear ip ospf process Reset ALL OSPF processes? [no]: yes **`

What happens the moment you confirm:

1. All OSPF neighbour adjacencies drop to Down state immediately.
2. All OSPF routes are withdrawn from the routing table.
3. Any traffic relying on OSPF-learned routes is dropped during reconvergence.
4. OSPF restarts from scratch: hellos go out, neighbour relationships rebuild, LSAs are exchanged.
5. Full convergence takes 30–60 seconds on a typical network.

This means there is a traffic blackout during reconvergence. In a production environment, you do not run this carelessly. On an exam question, the answer "clear ip ospf process forces a new DR/BDR election" is correct — but the follow-up answer "traffic is unaffected during this process" is wrong.

The exam also distinguishes *clear ip ospf process* from *clear ip ospf counters*. The counters command only resets statistical counters (packets sent, received, errors) — it does not affect neighbour relationships or routing table entries. If a question asks what you would do to reset OSPF statistics without dropping adjacencies, the answer is *clear ip ospf counters*.

Practice Question Sets

The best way to lock in OSPF neighbour states is working through real exam questions with immediate feedback. Pick a session size that fits your schedule: