CCNA IP Routing Practice Question
Exhibit
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 0 EXSTART 00:00:31 10.1.12.2 Serial0/0/0
Exhibit: R1 shows an OSPF neighbor stuck in EXSTART with R2 on a serial link. What is the most likely cause?
⚠ Common exam trap
Be aware that MTU mismatches cause EXSTART issues, while other mismatches prevent adjacency formation.
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
✓
An interface MTU mismatch between the routers
When two OSPF routers stay in EXSTART, the first thing to suspect is an MTU mismatch. They can discover each other, but database exchange does not complete because the DBD packets do not agree on interface MTU.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
An OSPF area mismatch
Why it's wrong here
An OSPF area mismatch on the shared link would prevent R2 from even establishing a stable two-way relationship with R1, because the Area ID field in Hello packets would not match the configured area on the interface. The routers would typically become stuck in the INIT or DOWN state, or the Hello packets would be ignored entirely, rather than advancing to the EXSTART state. Since EXSTART is a state reached only after the routers have exchanged Hello packets and formed a neighbor relationship, an area mismatch would block the process earlier in the neighbor state machine.
When this WOULD be correct
In a different question setup where the focus is on OSPF neighbor relationships failing completely, an area mismatch could be presented as a potential cause for neighbors not forming at all. For example, if the question described routers in different OSPF areas trying to establish a neighbor relationship, this option would be correct.
- ✗
A duplicate router ID on R1 and R2
Why it's wrong here
A duplicate Router ID would cause each router to mistakenly interpret the other's Hello as coming from itself, triggering an immediate rejection of the adjacency and potential routing table flapping. While this could cause the neighbor state to oscillate, it would not normally leave the session permanently in EXSTART, as the duplicate ID is typically detected and the adjacency is torn down before the Database Descriptor exchange completes. The fact that R1 and R2 are specifically stuck in EXSTART on a single link points to a packet-level size or delivery issue, not a Router ID conflict.
When this WOULD be correct
If the question were about OSPF neighbor relationships failing to establish due to configuration issues, and it explicitly mentioned that both routers have the same router ID, then option B would be the correct answer. This could occur in a scenario where both routers are configured with identical router IDs, leading to OSPF not forming any adjacency.
- ✓
An interface MTU mismatch between the routers
Why this is correct
When the MTU on the connecting interfaces differs, the routers negotiate Database Descriptor (DBD) packet sizes during the EXSTART/EXCHANGE handshake. R1 may send a DBD packet that exceeds R2's interface MTU, causing R2 to silently drop it, so the adjacency never advances past EXSTART. The router with the larger MTU will repeatedly fail to receive acknowledgment for its DBD, leaving both neighbors stuck in the EXSTART state while the OSPF process waits for a response.
- ✗
A missing default route on R2
Why it's wrong here
A missing default route on R2 is a routing information condition that has no bearing on the OSPF adjacency state machine, which governs only the exchange of Hello, Database Descriptor, and Link-State Request/Update packets. OSPF neighbors form adjacencies regardless of whether a default route exists in the routing table, as adjacency establishment is a prerequisite for exchanging routes in the first place. Therefore, the absence of a default route would not cause R2 to halt at EXSTART with R1.
When this WOULD be correct
In a different scenario, if the question specified that R2 was unable to route packets to R1 due to a lack of a default route, and the context involved troubleshooting routing issues rather than OSPF adjacency, then this option could be correct.
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.
✓An interface MTU mismatch between the routersCorrect answer▾
Why this is correct
When the MTU on the connecting interfaces differs, the routers negotiate Database Descriptor (DBD) packet sizes during the EXSTART/EXCHANGE handshake. R1 may send a DBD packet that exceeds R2's interface MTU, causing R2 to silently drop it, so the adjacency never advances past EXSTART. The router with the larger MTU will repeatedly fail to receive acknowledgment for its DBD, leaving both neighbors stuck in the EXSTART state while the OSPF process waits for a response.
✗An OSPF area mismatchWrong answer — click to see why▾
Why this is wrong here
An OSPF area mismatch prevents routers from forming a full adjacency; they typically remain in the INIT or 2-WAY state, not EXSTART. The EXSTART state indicates that the routers have already exchanged Hello packets and are attempting to negotiate the master/slave relationship, which requires matching area IDs.
★ When this WOULD be the correct answer
In a different question setup where the focus is on OSPF neighbor relationships failing completely, an area mismatch could be presented as a potential cause for neighbors not forming at all. For example, if the question described routers in different OSPF areas trying to establish a neighbor relationship, this option would be correct.
Why candidates choose this
Students often associate OSPF neighbor issues with area mismatches because it is a common configuration error. However, the specific state (EXSTART) points to a different problem, such as MTU mismatch, rather than area mismatch.
✗A duplicate router ID on R1 and R2Wrong answer — click to see why▾
Why this is wrong here
Duplicate router IDs cause OSPF to behave unpredictably, often resulting in flapping adjacencies or multiple neighbors with the same ID, but they do not typically cause a stuck EXSTART state on a single link. The routers would still progress through the states, but the adjacency may be unstable.
★ When this WOULD be the correct answer
If the question were about OSPF neighbor relationships failing to establish due to configuration issues, and it explicitly mentioned that both routers have the same router ID, then option B would be the correct answer. This could occur in a scenario where both routers are configured with identical router IDs, leading to OSPF not forming any adjacency.
Why candidates choose this
Duplicate router ID is a well-known OSPF issue, and test-takers may assume it can cause any neighbor problem. However, the EXSTART state is specifically related to the Database Description (DD) packet exchange, which is not directly affected by duplicate IDs.
✗A missing default route on R2Wrong answer — click to see why▾
Why this is wrong here
A missing default route on R2 does not affect OSPF adjacency formation. OSPF neighbors exchange routing information using multicast Hello and DD packets, which do not require a default route. The adjacency process is independent of the routing table content.
★ When this WOULD be the correct answer
In a different scenario, if the question specified that R2 was unable to route packets to R1 due to a lack of a default route, and the context involved troubleshooting routing issues rather than OSPF adjacency, then this option could be correct.
Why candidates choose this
Students may confuse the need for a default route for general network connectivity with the specific requirements for OSPF neighbor establishment. Since OSPF is a dynamic routing protocol, it does not rely on default routes to form adjacencies.
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
OSPFv3 Single-Area Configuration for IPv6
Key term
OSPF
OSPF is a link-state routing protocol that uses the SPF algorithm to compute the shortest path to each destination within a single autonomous system.
Key term
MTU
MTU (Maximum Transmission Unit) is the largest size of a single data packet that can be sent over a network without needing to be fragmented.
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.