Imagine your OSPF neighbors are like distant coworkers who never pick up the phone. When OSPF neighbors won't form, your network can't converge, routes go missing, and traffic blackholes appear. This chapter covers exam objective 3.4 (Troubleshoot OSPF neighbor issues) and is critical for both the CCNA 200-301 exam and real-world network troubleshooting. Mastering these diagnostic steps will save you hours of frustration when routers refuse to say hello.
Jump to a section
Imagine two apartment buildings next to each other, each with a receptionist at the front desk. The receptionists need to coordinate to ensure packages are delivered correctly between buildings. They use an intercom system. For the intercom to work, several things must align: both receptionists must speak the same language (OSPF version), they must press the same intercom button (OSPF process ID is irrelevant, but they must agree on area ID), they must be on the same floor (IP subnet), and their intercom handsets must be set to the same channel (authentication, hello/dead timers). The receptionist in Building A sends a 'hello' message every 10 seconds, expecting a reply within 40 seconds. If Building B's receptionist is on a coffee break (interface down) or speaks a different language (area mismatch), the hello is ignored. Even if they speak the same language, if one receptionist uses a different intercom channel (authentication key mismatch), the message is garbled. The receptionists also need to know each other's extension numbers (router IDs) and must not have a restraining order (ACL blocking OSPF). Once the intercom works, they can exchange package delivery lists (LSAs). In OSPF, the neighbor state machine progresses from Down to Full, mirroring the receptionists moving from 'no contact' to 'regular coordination'. If any step fails – wrong floor, wrong language, wrong channel – the state stalls at INIT, 2-WAY, or EXSTART/EXCHANGE, never reaching FULL. The CCNA exam loves to ask why a neighbor is stuck at a particular state, and the answer is almost always a mismatch in one of these parameters.
What is OSPF Neighbor Formation and Why Does It Fail?
OSPF (Open Shortest Path First) is a link-state routing protocol that builds a topology map by exchanging link-state advertisements (LSAs) between neighbors. Before any LSA exchange can happen, two routers must become OSPF neighbors. This process is governed by the OSPF neighbor state machine, which has eight states: Down, Attempt (NBMA only), Init, 2-Way, ExStart, Exchange, Loading, and Full.
Neighbor formation fails when the routers cannot agree on the parameters required to establish a bidirectional communication channel. The CCNA 200-301 exam tests your ability to identify why a neighbor is stuck at a particular state and how to fix it. The most common causes are:
Layer 1/2 issues (interface down, duplex mismatch)
IP subnet mismatch
OSPF area mismatch
OSPF network type mismatch (broadcast vs. point-to-point)
Authentication mismatch
MTU mismatch (especially in ExStart/Exchange)
Passive interface configuration
Access control lists (ACLs) blocking OSPF traffic (224.0.0.5 and 224.0.0.6)
Router ID conflict (same RID on two routers in the same OSPF domain)
The OSPF Hello Protocol and Neighbor States
OSPF uses Hello packets to discover and maintain neighbors. Hello packets are sent every 10 seconds by default on broadcast and point-to-point networks, and every 30 seconds on NBMA networks. The Dead interval is four times the Hello interval (40 seconds on broadcast networks). These timers must match between neighbors.
Hello packets contain:
Router ID (RID)
Area ID
Authentication data (if configured)
Network mask
Hello and Dead intervals
Options (capabilities)
List of neighbors seen (for 2-Way state)
When a router receives a Hello packet, it checks these fields. If any mismatch is found, the Hello is ignored and the neighbor state never progresses beyond Init.
Neighbor State Machine – Key States for Troubleshooting
Down: No Hello received. Possible causes: interface down, ACL blocking, passive interface, or remote router not configured for OSPF.
Init: Hello received, but the router's own RID is not in the neighbor list of the received Hello. This means the remote router hasn't seen our Hello yet. Causes: one-way communication (e.g., ACL blocking only one direction).
2-Way: Bidirectional communication established. On broadcast networks, this is the state where DR/BDR election occurs. If both routers are DROTHER, they remain in 2-Way and do not form a full adjacency. This is normal for non-DR/BDR routers.
ExStart: Routers negotiate the master/slave relationship and initial sequence number. Stuck here often indicates an MTU mismatch – the interface MTU must match for the Database Description (DBD) packets to be accepted.
Exchange: Routers exchange DBD packets (LSAs headers). Stuck here can be due to MTU mismatch or OSPF packet corruption.
Loading: Routers request missing LSAs. Stuck here is rare but can happen if LSAs are corrupted or if there is a QoS policy dropping OSPF packets.
Full: Full adjacency. All LSAs exchanged and synchronized.
Verification Commands
The primary command for troubleshooting OSPF neighbor issues is:
show ip ospf neighborExample output:
Neighbor ID Pri State Dead Time Address Interface
10.0.0.1 1 FULL/DR 00:00:35 10.1.1.1 GigabitEthernet0/0
10.0.0.2 1 2-WAY/DROTHER 00:00:38 10.1.1.2 GigabitEthernet0/0If a neighbor is missing, check:
show ip ospf interfaceThis shows the OSPF configuration on each interface, including network type, timers, area, and neighbor count.
For deeper debugging:
debug ip ospf adjThis shows real-time adjacency events, including why a neighbor is failing. Example output:
OSPF: Send hello to 224.0.0.5 via GigabitEthernet0/0
OSPF: Rcv hello from 10.0.0.2 area 0 from 10.1.1.2 GigabitEthernet0/0
OSPF: Mismatched area ID in hello packet from 10.1.1.2Common Mismatches and How to Identify Them
Area ID mismatch: The area ID must match on both ends. Use show ip ospf interface to verify.
Subnet mask mismatch: The IP subnet mask in the Hello packet must match. Use show ip interface to check.
Network type mismatch: For example, one side is broadcast and the other is point-to-point. This can cause the neighbor to become stuck in ExStart. Verify with show ip ospf interface.
Authentication mismatch: OSPF supports simple password (type 1) and MD5 (type 3) authentication. The authentication key and type must match. Use show ip ospf interface to see if authentication is configured.
Passive interface: A passive interface does not send Hellos, so no neighbor can form. Check with show ip ospf interface – if the interface is passive, it will show "Passive" in the output.
ACL blocking: OSPF uses multicast addresses 224.0.0.5 (all OSPF routers) and 224.0.0.6 (all DR/BDR). ACLs that deny these addresses will block neighbor formation. Check with show access-lists.
MTU mismatch: Both interfaces must have the same MTU. Use show ip interface to check. A common cause is a serial interface with an MTU of 1500 vs. an Ethernet interface with an MTU of 1500 (usually OK), but if one is set to 1400, DBD packets will be dropped.
Router ID conflict: Two routers with the same RID in the same OSPF domain will cause instability. The RID is typically the highest loopback IP, or the highest physical IP. Use show ip ospf to see the RID.
Troubleshooting Flowchart
Check if the interface is up/up with show ip interface brief.
Verify OSPF is enabled on the correct interfaces with show ip ospf interface.
Check show ip ospf neighbor – is the neighbor listed? If not, check for passive interface or ACL.
If neighbor is in Init, check for one-way communication (ACL or firewall).
If neighbor is in ExStart, check MTU mismatch.
If neighbor is in Exchange or Loading, check for packet corruption or QoS drops.
If neighbor is in Full but routes are missing, check LSA filtering or area types (stub, NSSA).
Remember: The exam will often present a scenario where a neighbor is stuck at a specific state. You need to know which parameters are checked at each state. For example, a neighbor stuck at ExStart almost always points to an MTU mismatch.
Verify Layer 1 and Layer 2
Start with the basics. Use `show ip interface brief` to confirm the interface is up/up. If the interface is down/down, check cables, power, or administrative shutdown. If it's up/down, look for a Layer 1 issue like a bad cable or duplex mismatch. On Ethernet, use `show interfaces` to check duplex and speed – a mismatch can cause packet loss, preventing OSPF Hellos from being received. If the interface is not up, fix it first before proceeding. This step eliminates the most common cause of missing neighbors.
Verify OSPF Configuration on Interface
Use `show ip ospf interface` to confirm OSPF is enabled on the interface. Look for the line "Internet Address" and the area ID. If the interface is not listed, OSPF is not configured on it – check the `network` statement under `router ospf`. Also verify the interface is not passive. The output will show "Passive" if it is. If the interface is passive, no Hellos are sent, so no neighbor can form. Use `passive-interface default` or `no passive-interface` to fix.
Check OSPF Neighbor Table
Run `show ip ospf neighbor` to see if the neighbor is present and in what state. If no neighbor is listed, the issue is likely at the Hello stage. If the neighbor is in Init, it means our router received a Hello but the remote router hasn't received ours – check for ACLs blocking outbound Hellos or a one-way firewall rule. If the neighbor is in 2-Way, that's normal for non-DR/BDR routers on broadcast networks – they don't form a full adjacency. If stuck in ExStart, suspect MTU mismatch. If stuck in Exchange, check for packet corruption or QoS drops.
Verify Hello and Dead Timer Match
Use `show ip ospf interface [interface]` to see the Hello and Dead timers. They must match on both ends. The default is 10 and 40 seconds on broadcast and point-to-point networks. If they differ, the routers will never become neighbors because the Hello interval is included in the Hello packet and compared. To change timers, use `ip ospf hello-interval` and `ip ospf dead-interval` under interface configuration. A mismatch will keep the neighbor in Init state indefinitely.
Check for Area and Subnet Mismatch
Use `show ip ospf interface` to verify the area ID. Both routers must be in the same area for the link. Also check the IP subnet mask with `show ip interface`. The OSPF Hello packet includes the network mask, and if it doesn't match, the router discards the Hello. For example, if one side has a /24 and the other a /25, they won't form an adjacency. Correct the mask or area as needed. This is a common exam trap.
Verify Authentication Settings
If authentication is configured, it must match on both ends. Use `show ip ospf interface` to see if authentication is enabled. If it is, check the key and type. Use `show key chain` if using key chains. Authentication can be simple (type 1) or MD5 (type 3). A mismatch will cause the neighbor to stay in Init because the Hello packet is rejected. To debug, use `debug ip ospf adj` and look for "Authentication mismatch" messages. Remove or correct authentication to fix.
Check for ACLs and MTU Issues
ACLs can block OSPF multicast traffic. Check with `show access-lists` and look for denies on 224.0.0.5 or 224.0.0.6. Also check `show ip interface` for any inbound/outbound ACLs. For MTU, use `show ip interface` to see the MTU on both ends. They must match. A mismatch often causes the neighbor to get stuck in ExStart because DBD packets are too large. To fix, set the MTU to the same value on both interfaces using `mtu` command. This is a classic exam scenario.
In a typical enterprise network, OSPF is used as an interior gateway protocol (IGP) to provide fast convergence and loop-free routing. Real-world troubleshooting often involves multiple sites, WAN links, and complex topologies. Here are three common scenarios:
Scenario 1: Site-to-Site VPN with OSPF
A company has two sites connected via a VPN tunnel over the internet. The tunnel interfaces (e.g., Tunnel0) are configured with OSPF. The neighbor fails to form. The engineer checks show ip ospf neighbor and sees nothing. Using show ip ospf interface Tunnel0, they notice the interface is passive. The issue: the passive-interface default command was applied globally, making all interfaces passive. The fix: no passive-interface Tunnel0. After that, the neighbor forms in a few seconds. This is a common mistake when using passive-interface default without selectively enabling interfaces.
Scenario 2: MPLS L3VPN Backbone
In a service provider network, PE routers run OSPF with CE routers. The CE router is stuck in ExStart. The engineer checks show ip interface and finds that the PE router has an MTU of 1500, but the CE router has an MTU of 1400 (due to a misconfiguration). The DBD packets are fragmented and dropped. The fix: set the MTU to 1500 on both sides. In production, MTU mismatches are common when different hardware or IOS versions are used, or when QoS policies change the MTU.
Scenario 3: Data Center Leaf-Spine with OSPF
A data center uses OSPF between leaf and spine switches. The neighbor is stuck in Init. The engineer runs debug ip ospf adj and sees "Mismatched area ID". One leaf was configured for area 0, but the spine was configured for area 1. This happened because the network statement used a wildcard mask that included more interfaces than intended. The fix: correct the area ID or the network statement. In production, area mismatches are a leading cause of OSPF issues, especially when multiple areas are used.
Misconfiguration Consequences: When OSPF neighbors don't form, the network may have routing blackholes, suboptimal routing, or complete loss of connectivity. In a production environment, this can cause outages that affect thousands of users. Always follow a systematic troubleshooting approach to minimize downtime.
The CCNA 200-301 exam tests OSPF neighbor troubleshooting under objective 3.4 (Troubleshoot OSPF neighbor issues). Expect scenario-based questions where you are given a show ip ospf neighbor output and asked why the neighbor is stuck at a particular state. The exam may also present a debug ip ospf adj output and ask you to identify the mismatch.
Most Common Wrong Answers and Why Candidates Choose Them:
1. "The OSPF process IDs don't match" – Candidates think process IDs must match, but they are locally significant and can differ. The exam tests this trick.
2. "The router IDs are the same" – While a RID conflict can cause issues, it's not the most common cause for a stuck neighbor. Candidates often blame RID first, but the real issue is usually a mismatch in timers, area, or subnet.
3. "The interface is passive" – This is a correct cause, but candidates sometimes overlook the fact that a passive interface prevents Hellos from being sent, so the neighbor won't even appear in show ip ospf neighbor. If a neighbor is listed in Init, passive interface is not the issue.
4. "The ACL is blocking OSPF" – Again, this is a valid cause, but candidates need to check if the ACL denies 224.0.0.5/6. A common trap is an ACL that permits OSPF but has an implicit deny at the end.
Specific Values and Commands: Know that Hello timer default is 10 seconds on broadcast and point-to-point, Dead timer is 40 seconds. On NBMA, Hello is 30 seconds, Dead is 120 seconds. The show ip ospf neighbor command shows the state (FULL, 2-WAY, etc.) and the dead time countdown. The show ip ospf interface command shows the network type, timers, area, and whether the interface is passive.
Decision Rule for Scenario Questions: If the neighbor is not listed at all, check Layer 1/2, passive interface, or ACL. If the neighbor is in Init, check for one-way communication (ACL or firewall). If the neighbor is in ExStart, check MTU. If the neighbor is in Exchange or Loading, check for packet corruption or QoS. If the neighbor is in 2-Way on a broadcast network, it's normal for non-DR/BDR routers. Use this decision tree to eliminate wrong answers quickly.
OSPF neighbor states: Down, Attempt, Init, 2-Way, ExStart, Exchange, Loading, Full.
Hello timer default: 10 seconds on broadcast/point-to-point; Dead timer default: 40 seconds.
Neighbor stuck in ExStart almost always indicates MTU mismatch.
Neighbor stuck in Init indicates one-way communication (ACL, firewall, or passive interface).
Process ID is locally significant and does not need to match between neighbors.
Use `show ip ospf neighbor` to check neighbor state; use `debug ip ospf adj` to see real-time adjacency events.
Common mismatches: area ID, subnet mask, authentication, network type (broadcast vs. point-to-point).
These come up on the exam all the time. Here's how to tell them apart.
OSPF Neighbor States
States: Down, Attempt, Init, 2-Way, ExStart, Exchange, Loading, Full
Hello timer: 10 sec (broadcast), 30 sec (NBMA)
Dead timer: 40 sec (broadcast), 120 sec (NBMA)
Neighbor stuck in ExStart often due to MTU mismatch
Uses multicast 224.0.0.5 and 224.0.0.6
EIGRP Neighbor States
States: Down, Init, Received, Restart, Up
Hello timer: 5 sec (default for most interfaces)
Hold timer: 15 sec (3x Hello)
Neighbor stuck in Init often due to ACL or authentication mismatch
Uses multicast 224.0.0.10
Mistake
OSPF neighbor formation requires matching process IDs.
Correct
The OSPF process ID is locally significant and can differ between routers. Neighbors only need to match area ID, timers, authentication, subnet, and network type.
Candidates confuse process ID with area ID because both are numbers configured under router ospf.
Mistake
A neighbor stuck in 2-Way state is always a problem.
Correct
On broadcast multiaccess networks, non-DR/BDR routers remain in 2-Way state and do not form a full adjacency. This is normal and expected.
Candidates think the goal is always FULL, but 2-Way is a valid final state for DROTHERs.
Mistake
If the router IDs are the same, the neighbor will form but routes won't be exchanged.
Correct
A router ID conflict prevents neighbor formation entirely because the router ID is used as the source identifier in Hello packets. The neighbor state will not progress beyond Init.
Candidates think OSPF can handle duplicate RIDs, but it cannot – it causes adjacency failure.
Mistake
Passive interface prevents the router from receiving Hellos.
Correct
A passive interface does not send Hellos, but it can still receive them. However, without sending Hellos, the remote router will never see this router's RID in its neighbor list, so the state will remain Init (one-way).
Candidates think passive stops all OSPF traffic, but it only stops sending Hellos.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The ExStart state is where routers negotiate the master/slave relationship and the initial sequence number for DBD exchange. If the neighbor is stuck here, the most common cause is an MTU mismatch. The DBD packets are sent without fragmentation, so if the interface MTU is different on the two routers, the packet may be dropped. Use `show ip interface` on both routers to compare MTU values. If they differ, configure the same MTU on both interfaces using the `mtu` command. Another possible cause is a network type mismatch (e.g., one side is broadcast and the other is point-to-point), which also affects DBD packet format. Check with `show ip ospf interface` and ensure the network type matches. On the exam, always suspect MTU first when you see ExStart.
Yes, absolutely. The OSPF process ID is locally significant and only identifies the OSPF process on the local router. It is not included in Hello packets, so it does not affect neighbor formation. Two routers can have different process IDs and still become full neighbors. This is a common exam trick – candidates often think process IDs must match, but they don't. The parameters that must match include area ID, timers, authentication, subnet mask, and network type.
When a neighbor is in Init state, it means the router has received a Hello packet from that neighbor, but the neighbor has not yet seen this router's Hello (i.e., the router's RID is not in the neighbor's Hello packet). This indicates one-way communication. Possible causes: an ACL blocking outbound Hellos on this router, a firewall that allows inbound but not outbound OSPF traffic, or the remote router has a passive interface. To troubleshoot, check for ACLs on the interface, verify the interface is not passive, and ensure there is no firewall in between. Use `debug ip ospf adj` to see if Hellos are being sent and received.
On a broadcast multiaccess network (e.g., Ethernet), only the Designated Router (DR) and Backup Designated Router (BDR) form full adjacencies with all other routers. Routers that are not DR or BDR (DROTHERs) remain in 2-Way state with each other. This is normal and expected. The 2-Way state indicates bidirectional communication, but full adjacency is only needed for DR/BDR. If you want all routers to form full adjacencies, change the network type to point-to-point using `ip ospf network point-to-point` on the interface. However, on the exam, a neighbor in 2-Way is usually not a problem unless the router is expected to be DR/BDR.
Use `show ip ospf interface` to see if authentication is enabled. If it is, the output will show the authentication type (simple or MD5). Then check the key using `show key chain` if using key chains, or verify the password in the running config. To confirm authentication is the problem, use `debug ip ospf adj` – you will see messages like "Mismatched authentication key" or "Authentication mismatch". Ensure both routers have the same authentication type and key. If one router has authentication and the other doesn't, the neighbor will not form. Remove authentication from both sides or configure it consistently.
A passive interface stops the router from sending OSPF Hello packets out that interface, but it still listens for Hellos from others. This means the router will not initiate neighbor relationships, but it can respond to Hellos if it receives them? Actually, if the interface is passive, the router will still process received Hellos and could potentially form a neighbor? No – with a passive interface, the router does not send Hellos, so the remote router will never see this router's RID in its neighbor list, and the state will remain Init (one-way). An ACL can block Hellos in one or both directions. If the ACL blocks inbound Hellos, the router never receives them, so no neighbor appears. If it blocks outbound Hellos, the remote router never receives them, leading to Init state. Both can cause neighbor issues, but passive interface is easier to identify via `show ip ospf interface`.
OSPF uses multicast to reduce processing load on non-OSPF routers. 224.0.0.5 (AllSPFRouters) is used for Hellos and LSAs sent to all OSPF routers. 224.0.0.6 (AllDRouters) is used for LSAs sent only to the DR and BDR on broadcast networks. This allows non-DR routers to avoid processing every LSA. When troubleshooting, ensure ACLs permit these multicast addresses. Also, some switches need IGMP snooping configured to forward these multicasts properly. On point-to-point links, OSPF often uses unicast instead of multicast.
You've just covered Troubleshoot: OSPF Neighbor Won't Form — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?