JN0-106 Networking Fundamentals Practice Question
A network engineer is troubleshooting OSPF adjacencies between two Juniper routers. The routers are directly connected and have matching OSPF configurations except for the router IDs. Router A has router-id 10.0.0.1, Router B has router-id 10.0.0.2. The adjacency remains in the EXSTART state. What is the most likely cause?
⚠ Common exam trap
Many candidates assume mismatched hello/dead intervals are the cause of any adjacency problem, but those issues manifest earlier (at the 2-Way state), while EXSTART specifically points to MTU or DBD packet exchange problems.
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 MTU on the interface is mismatched.
The EXSTART state indicates that the routers have progressed past the 2-Way state and are attempting to exchange Database Description (DBD) packets. A common cause for getting stuck in EXSTART is an MTU mismatch, because OSPF uses the interface MTU to determine the maximum size of DBD packets. If Router A's MTU is larger than Router B's, Router B will drop the oversized DBD packet and the adjacency will remain in EXSTART.
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 MTU on the interface is mismatched.
Why this is correct
An MTU mismatch is a classic cause of OSPF adjacency being stuck in the EXSTART state. During the Database Description (DD) packet exchange, OSPF embeds the interface MTU in the DD header. If one interface has a larger MTU and sends a DD packet that exceeds the neighbor's MTU, the receiving router will drop the packet. Since the neighbor never receives the DD packet, the routers cannot complete the master/slave negotiation, and the adjacency remains permanently in EXSTART rather than progressing to FULL.
- ✗
The router IDs are not the same.
Why it's wrong here
Router IDs are 32-bit identifiers that must be unique within the OSPF routing domain. If two routers have different router IDs, that is the normal and expected condition; adjacency formation does not require router IDs to match. In fact, matching router IDs would create an error, because each router would see the other's packets as coming from itself and reject them. Therefore, the router IDs not being the same is not a fault; it is a prerequisite for a valid OSPF neighbor relationship to exist.
- ✗
The area ID is not configured.
Why it's wrong here
If the area ID were not configured, the interface would not be enabled for OSPF at all, and you would not see any neighbor entry or adjacency state. In this scenario, the adjacency reaching EXSTART means OSPF is operationally up on both ends and the routers have already exchanged Hello packets. A mismatch in area IDs would prevent the routers from even becoming neighbors, typically leaving the state at DOWN or INIT, not EXSTART. The stem indicates the configurations match in this regard, so an unconfigured or mismatched area ID is not the cause.
- ✗
The hello and dead intervals are mismatched.
Why it's wrong here
Mismatched hello and dead intervals produce failures much earlier in the OSPF neighbor discovery process. Routers only accept Hello packets that carry matching values for these timers; if they differ, the Hello packets are ignored, and the neighbor state never progresses past DOWN or INIT. EXSTART represents a far later stage, after the routers have already exchanged Hello packets and reached the 2-Way state, which proves that the hello/dead intervals were successfully matched and accepted. Thus, this option cannot explain an adjacency stuck specifically in EXSTART.
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
About these practice questions
Courseiva writes every JN0-106 question from scratch — 156 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 →
Same concept, more angles
1 more way this is tested on JN0-106
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Refer to the exhibit. The OSPF neighbor adjacency repeatedly goes up and down on R1. What is a likely cause?
hard- A.The physical link is flapping
- ✓ B.MTU mismatch between the two routers
- C.OSPF authentication is misconfigured
- D.The routers are in different OSPF areas
Why B: An MTU mismatch between OSPF neighbors can cause the adjacency to flap because OSPF includes the interface MTU in the Database Description (DBD) packets. If the MTU values do not match, the receiving router will reject the DBD packet, preventing the exchange of LSAs and causing the neighbor state to reset. This is a common cause of repeated up/down OSPF adjacencies even when the physical link is stable.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This JN0-106 practice question is part of Courseiva's free Juniper Networks 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 JN0-106 exam.