CCNA Network Services and Security Practice Question
Exhibit
R1 Gi0/0: ip address 10.10.12.1 255.255.255.252 ip ospf 10 area 0 ip mtu 1500 R2 Gi0/0: ip address 10.10.12.2 255.255.255.252 ip ospf 10 area 0 ip mtu 1400 Both interfaces are up/up. show ip ospf neighbor on both routers: Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 EXSTART 00:00:31 10.10.12.2 Gi0/0
R1 and R2 should form an OSPF adjacency on their shared GigabitEthernet link, but they remain stuck in EXSTART. What is the most likely cause?
⚠ Common exam trap
A common exam trap is selecting area mismatch or passive-interface as the cause of OSPF adjacency stuck in ExStart. While area mismatch prevents neighbor formation entirely, and passive-interface stops hello packets, these issues cause earlier failures, not ExStart stalls. The ExStart state specifically involves negotiating database description packets, which requires matching MTU values. Candidates often overlook MTU mismatches because neighbors appear in the topology, misleading them to suspect other configuration errors. Understanding that MTU mismatch allows neighbor discovery but blocks database synchronization is key to avoiding this trap.
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
✓
The interface MTU values do not match.
The MTU values do not match. OSPF neighbors can discover each other and even move through earlier states, but an MTU mismatch commonly leaves them stuck in EXSTART or EXCHANGE because the routers do not agree on database description packet sizing. Area mismatch, network mismatch, and passive-interface issues usually prevent a much earlier stage of adjacency formation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The routers are using different OSPF areas.
Why it's wrong here
For OSPF to form an adjacency, the two routers must agree on the area ID configured on the shared link. Since both r1 and r2 are explicitly in area 0, their area IDs match, so an area mismatch is not the cause. An area mismatch would cause hello packets to be rejected, preventing the neighbor state from even being established, not becoming stuck in EXSTART.
When this WOULD be correct
In a different scenario where the question specifies that both routers are in the same OSPF area but are unable to establish adjacency, this option would be correct if the routers were configured to use different OSPF area IDs, preventing adjacency formation.
- ✓
The interface MTU values do not match.
Why this is correct
A mismatch in interface MTU is the classic cause of OSPF neighbors becoming stuck in EXSTART or EXCHANGE. During the Database Description (DBD) packet exchange, each router includes its MTU in the DBD header; if the receiving router sees a larger MTU than its own, it drops the packet, so the neighbor state never progresses past EXSTART. This correctly explains why the adjacency fails to reach FULL.
- ✗
One side is configured as passive-interface.
Why it's wrong here
Configuring passive-interface on an OSPF-enabled interface stops both outgoing and incoming hello packets on that interface, which would prevent any OSPF neighbor relationship from forming at all. In this scenario, the neighbors have progressed to EXSTART/EXCHANGE, which proves hello packets are being exchanged successfully. Therefore, a passive-interface configuration cannot be the reason for the adjacency being stuck.
When this WOULD be correct
In a different scenario, if the question stated that OSPF adjacency was not forming at all and one router was configured with a passive-interface command on the shared link, then this option would be correct as it would directly prevent OSPF from establishing a neighbor relationship.
- ✗
The subnet mask on the link is incorrect.
Why it's wrong here
Both interfaces belong to the same /30 subnet, as indicated by their addresses, so the subnet masks effectively match on the link. OSPF verifies the subnet mask in the hello packet; a mismatch would cause the received hello to be ignored, and the neighbor state would remain down. Because the two routers are already exchanging DBD packets, the mask is consistent and cannot be the issue.
When this WOULD be correct
In a different scenario, if the question were about OSPF failing to establish an adjacency due to incorrect IP addressing, including a mismatched subnet mask, this option would be correct. For example, if R1 and R2 were on different subnets, OSPF would not form an adjacency.
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.
✓The interface MTU values do not match.Correct answer▾
Why this is correct
A mismatch in interface MTU is the classic cause of OSPF neighbors becoming stuck in EXSTART or EXCHANGE. During the Database Description (DBD) packet exchange, each router includes its MTU in the DBD header; if the receiving router sees a larger MTU than its own, it drops the packet, so the neighbor state never progresses past EXSTART. This correctly explains why the adjacency fails to reach FULL.
✗The routers are using different OSPF areas.Wrong answer — click to see why▾
Why this is wrong here
This option is incorrect because OSPF adjacencies can still form between routers in different areas, as long as they are not directly connected. The EXSTART state issue is more likely related to mismatched MTU settings rather than area configuration.
★ When this WOULD be the correct answer
In a different scenario where the question specifies that both routers are in the same OSPF area but are unable to establish adjacency, this option would be correct if the routers were configured to use different OSPF area IDs, preventing adjacency formation.
Why candidates choose this
Candidates may choose this option due to a common misconception that OSPF requires routers to be in the same area for adjacency, leading them to overlook other factors like MTU mismatches that can cause EXSTART issues.
✗One side is configured as passive-interface.Wrong answer — click to see why▾
Why this is wrong here
This option is wrong because configuring one side as passive-interface prevents OSPF from forming an adjacency, but the question specifies that R1 and R2 are stuck in EXSTART, which indicates they are attempting to establish adjacency.
★ When this WOULD be the correct answer
In a different scenario, if the question stated that OSPF adjacency was not forming at all and one router was configured with a passive-interface command on the shared link, then this option would be correct as it would directly prevent OSPF from establishing a neighbor relationship.
Why candidates choose this
Candidates might choose this option because they recall that passive-interface settings can disrupt OSPF adjacencies, leading them to mistakenly assume it applies in this situation without considering the specific EXSTART state.
✗The subnet mask on the link is incorrect.Wrong answer — click to see why▾
Why this is wrong here
The subnet mask on the link being incorrect would typically lead to connectivity issues or routing problems, but it would not specifically cause OSPF to be stuck in EXSTART. OSPF can still establish a neighbor relationship if the subnet mask is mismatched, as long as the routers can reach each other.
★ When this WOULD be the correct answer
In a different scenario, if the question were about OSPF failing to establish an adjacency due to incorrect IP addressing, including a mismatched subnet mask, this option would be correct. For example, if R1 and R2 were on different subnets, OSPF would not form an adjacency.
Why candidates choose this
Candidates may choose this option because they associate subnet mask issues with general connectivity problems, leading them to believe it could affect OSPF adjacency formation.
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
Diagnosing DNS Record Issues — A, AAAA, CNAME, MX, NS, and PTR Records
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
Packet
A packet is a small unit of data that is sent over a network, containing both the actual data and control information for delivery.
About these practice questions
Courseiva writes every 200-301 question from scratch — 1,389 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.