How to Read show ip ospf neighbor Output in CCNA Questions

The show ip ospf neighbor command is one of the most commonly tested verification commands on the CCNA exam. Questions either give you the output directly and ask what it proves, or describe a scenario and ask which command would confirm the neighbour relationship.

This guide breaks down every column, explains the states you will see, and covers the traps that make candidates choose wrong answers.

What the Output Looks Like

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2          1   FULL/DR         00:00:36    192.168.1.2     GigabitEthernet0/0
10.0.0.3          1   FULL/BDR        00:00:31    192.168.1.3     GigabitEthernet0/0
10.0.0.4          0   FULL/  -        00:00:38    192.168.1.4     GigabitEthernet0/0

Column by Column

Neighbor ID — This is the OSPF router ID of the neighbour, not its interface IP address. The router ID is typically the highest loopback IP or the highest active interface IP if no loopback exists. Exam questions sometimes ask which address appears here — it is the router ID, not the address in the Address column.

Pri — The OSPF interface priority. Used in DR/BDR election. A priority of 0 means the router cannot become DR or BDR. The default is 1. You change it with ip ospf priority on the interface.

State — The most important column. This tells you the OSPF relationship state and the role of the neighbour.

• FULL/DR — The neighbour is the Designated Router and the adjacency is fully formed.
• FULL/BDR — The neighbour is the Backup Designated Router and the adjacency is fully formed.
• FULL/ - — The neighbour is a DROther. On point-to-point links, you also see FULL/ - because there is no DR election.
• 2WAY/ - — DROther to DROther relationship. This is normal and expected on broadcast networks.
• EXSTART, EXCHANGE, LOADING — Transitional states. If a neighbour is stuck here, there is usually an MTU mismatch.

Dead Time — Counts down from the dead interval (default 40 seconds on broadcast networks). If it reaches zero, the neighbour is declared dead. Mismatched hello/dead timers prevent adjacency formation.

Address — The IP address of the neighbour's interface that is directly connected to this router. This is the next-hop address used to reach the neighbour.

Interface — The local interface through which the neighbour is reachable.

The Exam Traps

Trap 1: Confusing Neighbour ID with Interface Address

A question might show you the output and ask "What is the IP address of R2's GigabitEthernet0/0?" The Neighbor ID column shows the router ID — that is usually a loopback address. The Address column shows the interface IP. Candidates who do not read carefully pick the wrong column.

Trap 2: Treating 2WAY as a Problem

On a broadcast multi-access network like Ethernet, DROther routers only form full adjacencies with the DR and BDR. Two DROther routers will show each other as 2WAY/ - in the neighbour table. This is correct and expected behaviour. The exam sometimes presents this as a scenario and asks whether there is a problem — the answer is no.

Trap 3: FULL/ - on Point-to-Point

On a point-to-point serial link or a tunnel, there is no DR/BDR election. Both routers reach FULL state and the role shows as a dash. This is not an error state.

Trap 4: Which Command Confirms the DR?

show ip ospf neighbor shows neighbour state and roles. show ip ospf interface shows your own router's interface role and gives the DR and BDR IP addresses directly on the segment. If the question asks which command shows the DR IP address, show ip ospf interface is the more direct answer.

What Causes a Neighbour to Not Appear

If a router does not appear in show ip ospf neighbor at all, common causes include:

• Mismatched area numbers
• Mismatched hello or dead timers
• Mismatched network types (broadcast vs point-to-point)
• Authentication mismatch
• The network command not matching the interface IP
• The interface is passive (passive-interface)

If the neighbour appears but is stuck in EXSTART or EXCHANGE, check for an MTU mismatch.

Practice Question

A candidate runs show ip ospf neighbor on R1 and sees R2 listed with State 2WAY/ -. R1 is running OSPF on a broadcast segment with four routers. Which of the following is true?

A) R2 and R1 have an incomplete adjacency due to a timer mismatch
B) R2 is the DR and R1 is a DROther
C) R2 is a DROther and the state is expected
D) OSPF is not converged on this segment

The correct answer is C. On a multi-access broadcast network, DROther routers form full adjacencies only with the DR and BDR. Two DROther routers showing each other as 2WAY is normal.

Practice more CCNA routing and switching questions to get comfortable reading command output under exam conditions.

Running This Command on Exam Day — A Worked Scenario

Let's take a more complex topology: five routers (R1 through R5) all connected to the same Ethernet switch. R3 has been configured with *ip ospf priority 200* on its interface, and R5 has priority 0. Everyone else is at the default of 1.

You run *show ip ospf neighbor* on R1 and see this:

**` R1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface 10.0.0.3 1 FULL/DR 00:00:37 192.168.1.3 Gi0/0 10.0.0.4 1 FULL/BDR 00:00:39 192.168.1.4 Gi0/0 10.0.0.2 1 2WAY/DROTHER 00:00:34 192.168.1.2 Gi0/0 10.0.0.5 0 2WAY/DROTHER 00:00:33 192.168.1.5 Gi0/0 **`

Work through what this tells you:

R3 is the DR. It won the election because priority 200 beats everyone else's priority 1. Its router ID is 10.0.0.3, but its interface IP on the segment is 192.168.1.3 — notice those are different numbers. The Neighbor ID column is the router ID (usually a loopback); the Address column is the interface IP you actually see on the wire.

R4 won the BDR election. Four routers had priority 1. The tiebreaker was router ID, and 10.0.0.4 is higher than 10.0.0.2. So R4 beat R2 for BDR.

R2 is a DROther showing 2WAY. Normal. R1 and R2 both lost the BDR election. They confirm reachability with each other in 2-Way and rely on R3 to distribute LSAs.

R5 has priority 0 — it shows 2WAY/DROTHER. The priority 0 means it can never become DR or BDR, but it still forms adjacency (2-Way) with other DROthers and Full adjacencies with the DR and BDR. What the output does NOT show you is R1's relationship with R3 and R4 — you are looking at R1's perspective, and R3 and R4 show as FULL because R1 (a DROther) is fully adjacent to the DR and BDR.

Now here is the question the exam loves: "R5 has priority 0. Which statement is true?"

Wrong answer A: "R5 cannot form an OSPF adjacency on this segment." False. Priority 0 only means it cannot become DR or BDR. It still participates in OSPF.

Wrong answer B: "R5 will be the DR because it has a unique priority value." This is backwards thinking. Priority 0 is the lowest possible — it disqualifies from DR/BDR election.

Correct answer: R5 will form 2-Way adjacency with DROthers and Full adjacency with the DR and BDR, but will never become DR or BDR.

Things That Break Before show ip ospf neighbor Even Shows Output

If *show ip ospf neighbor* returns an empty table, the question shifts to why no neighbour relationship formed at all. There are three failure modes the exam tests specifically:

MTU Mismatch — The Sneaky One

An MTU mismatch is different from most OSPF problems because hellos still exchange and you see the neighbour in the table — but stuck in EXSTART or EXCHANGE state, never reaching Full. This is the failure mode that trips people who have memorised "MTU mismatch = no neighbour" and pick answers accordingly.

The actual behaviour: OSPF hellos use small packets and get through fine. The problem starts during Database Description (DBD) exchange, which uses larger packets. If R1 has MTU 1500 and R2 has MTU 1476 (common on some WAN circuits), R2's DBD packets are slightly too big for R1's interface and get dropped. The routers see each other but can never synchronise databases. You see them stuck at EXSTART.

Verify with *show interfaces GigabitEthernet0/0* — look for the MTU line. Fix with *ip ospf mtu-ignore* on the interface if you cannot change the actual MTU.

Passive Interface

*passive-interface GigabitEthernet0/0* prevents OSPF from sending hellos out that interface. The network is still included in OSPF advertisements, but no neighbours can form on it. This is intentional on stub interfaces (loopbacks, interfaces facing only end hosts) and a misconfiguration if applied to inter-router links.

If a router's interface shows up in *show ip ospf interface* as "passive," that is why no neighbours appear.

ACL Blocking Multicast

OSPF hellos go to 224.0.0.5 (all OSPF routers) and 224.0.0.6 (DR/BDR only). An extended ACL applied inbound on an interface that denies protocol 89 or that denies traffic to 224.0.0.0/8 will silently kill OSPF. The interface looks physically up, IP connectivity may appear fine, but no OSPF hellos get in.

Always check *show ip interface GigabitEthernet0/0* for inbound access lists if OSPF won't form and the interface is clearly up.

The Timer Trap — When Neighbours Show Up but Won't Stay

Here is a failure mode that does show an entry in the table, at least briefly: hello/dead timer mismatch.

OSPF routers exchange hello/dead timers in their hello packets. If they do not match, they cannot become neighbours. On broadcast networks the defaults are hello 10 seconds, dead 40 seconds. On non-broadcast (NBMA) networks the defaults are hello 30 seconds, dead 120 seconds. Change the network type or manually modify timers without keeping both sides in sync and you get this:

**` R1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface 10.0.0.2 1 INIT/DROTHER 00:00:12 192.168.1.2 Gi0/0 **`

That INIT state means R1 received a hello from R2, but R1's router ID was not in R2's hello. This typically indicates mismatched timers — the routers are not treating each other as valid neighbours and are stuck in the Init state.

The fix is ensuring timers match:

**` R1(config-if)# ip ospf hello-interval 10 R1(config-if)# ip ospf dead-interval 40 **`

Apply identically on both sides. There is no automatic negotiation of timers — they must match manually.

Quick Reference: States That Always Mean a Problem

Not every non-Full state is a problem. Here is an unambiguous breakdown:

If you ever see EXSTART in an exam question, the answer is almost certainly MTU mismatch. It appears in far more exam questions than any other stuck-state scenario.

Practice Question Sets

The best way to lock in show ip ospf neighbor is working through real exam questions with immediate feedback. Pick a session size that fits your schedule: