CCNA IP Routing Practice Question
A network engineer configures OSPF on R1 and R2 over a point-to-point link. The interfaces are in the same OSPF area, with matching hello and dead timers, and are on the same IP subnet. However, the command show ip ospf neighbor on both routers shows no neighbors. A firewall sits between R1 and R2. What should the technician do next?
⚠ Common exam trap
Cisco often tests the distinction between issues that prevent neighbor formation entirely (like multicast filtering, ACLs blocking protocol 89, or duplicate router IDs) versus issues that cause neighbor states to stall or flap (like MTU mismatch), leading candidates to overthink parameters that are already correctly configured.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Check the firewall rules to verify that multicast address 224.0.0.5 is not being blocked.
OSPF uses multicast address 224.0.0.5 (AllSPFRouters) to send hello packets and establish neighbor adjacencies. A firewall blocking this multicast address would prevent R1 and R2 from receiving each other's hello packets, resulting in no neighbors appearing in the show ip ospf neighbor output. Since all other OSPF parameters (area, timers, subnet) are correctly configured, the firewall is the most likely cause.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Check the firewall rules to verify that multicast address 224.0.0.5 is not being blocked.
Why this is correct
Checking the firewall rules is the correct first step because OSPF on an Ethernet link sends its hello packets to the multicast group 224.0.0.5 (AllSPFRouters). If a stateful firewall between R1 and R2 drops multicast traffic, the hello packets never reach the neighbor, so the OSPF neighbor table remains empty even though IP connectivity may exist. Unicast OSPF packets, such as database descriptors, might be permitted, but the initial neighbor discovery process requires these multicast hellos to establish the neighbor relationship. Thus, verifying that 224.0.0.5 is permitted is essential before moving to router-ID or MTU checks.
- ✗
Verify that the OSPF router IDs on R1 and R2 are unique.
Why it's wrong here
While duplicate router IDs can cause issues in OSPF, they would not prevent the initial hello exchange or the appearance of a neighbor in the neighbor table (even if adjacency fails). The neighbor would still be seen, possibly cycling states. This step is too deep given the complete absence of neighbors.
- ✗
Check the OSPF network type on the connecting interfaces.
Why it's wrong here
Checking the OSPF network type is irrelevant here because the firewall is the explicit cause of neighbour adjacency failure; OSPF network type affects neighbour discovery only on multi-access segments (e.g., requiring a Designated Router on broadcast or non-broadcast links), whereas a point-to-point link with matching timers and subnet would form adjacency automatically if Layer 3 connectivity existed. This option is tempting because mismatched network types (e.g., broadcast vs. point-to-point) commonly prevent neighbour formation on Ethernet links, but that scenario assumes no firewall blocking OSPF multicast or unicast packets.
- ✗
Verify that the MTU on the connecting interfaces matches.
Why it's wrong here
MTU mismatch usually causes neighbors to get stuck in the EXSTART/EXCHANGE state because DBD packets cannot be fully exchanged. The routers would still discover each other via hellos and appear in the neighbor table. Therefore, checking MTU does not address why hellos are not showing up at all.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.
✓Check the firewall rules to verify that multicast address 224.0.0.5 is not being blocked.Correct answer▾
Why this is correct
Checking the firewall rules is the correct first step because OSPF on an Ethernet link sends its hello packets to the multicast group 224.0.0.5 (AllSPFRouters). If a stateful firewall between R1 and R2 drops multicast traffic, the hello packets never reach the neighbor, so the OSPF neighbor table remains empty even though IP connectivity may exist. Unicast OSPF packets, such as database descriptors, might be permitted, but the initial neighbor discovery process requires these multicast hellos to establish the neighbor relationship. Thus, verifying that 224.0.0.5 is permitted is essential before moving to router-ID or MTU checks.
✗Verify that the OSPF router IDs on R1 and R2 are unique.Wrong answer — click to see why▾
Why this is wrong here
Router ID duplication does not explain a completely empty neighbor table; neighbors would still be detected via hellos.
✗Check the OSPF network type on the connecting interfaces.Wrong answer — click to see why▾
Why this is wrong here
Network type mismatch would likely still result in hellos being received and a neighbor entry appearing, just not advancing to full adjacency. The complete absence of neighbors points to a transport issue.
✗Verify that the MTU on the connecting interfaces matches.Wrong answer — click to see why▾
Why this is wrong here
Candidates often remember MTU mismatch as a frequent OSPF problem, but it manifests after neighbor discovery, not as a complete lack of neighbors.
Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
Quick reference
Routing Protocol Comparison
| Protocol | Metric | Max Hops | Algorithm | Type |
|---|---|---|---|---|
| RIP v2 | Hop count | 15 | Bellman-Ford | Distance vector |
| OSPF | Cost (bandwidth) | Unlimited | Dijkstra (SPF) | Link state |
| EIGRP | Composite metric | Unlimited | DUAL | Hybrid |
| IS-IS | Cost | Unlimited | Dijkstra | Link state |
| BGP | Policy / attributes | Unlimited | Path vector | Path vector |
RIP's 15-hop limit makes it unsuitable for large networks. OSPF and EIGRP dominate modern enterprise deployments.
Go deeper
Related to this question
Learn chapter
Exam Trap: OSPF Common Mistakes
Key term
OSPF
OSPF is a link-state routing protocol used to find the best path for data packets to travel across IP networks, like a smart GPS that recalculates routes when traffic changes.
Key term
OSPF neighbor
An OSPF neighbor is another router that has been directly discovered through OSPF Hello packets and is willing to exchange routing information to build a network topology map.
About these practice questions
One of 1,450 original 200-301 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-301 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-301 exam.