JN0-106 Networking Fundamentals Practice Question
You are troubleshooting an OSPF adjacency issue between two Juniper MX series routers, R1 and R2, both running Junos 18.2. They are directly connected via a Gigabit Ethernet link. R1's interface ge-0/0/0 is configured with IP 192.168.1.1/24, and R2's ge-0/0/0 is configured with IP 192.168.1.2/24. Both interfaces are in OSPF area 0.0.0.0. The physical connectivity is confirmed up, and both interfaces are administratively enabled. You have checked that the hello and dead intervals match (hello 10, dead 40), the area IDs are identical, and the subnet masks are /24. No firewall filters are blocking OSPF. The OSPF configuration on R1 includes 'authentication-type md5' and 'authentication-key juniper123' under the interface. On R2, the configuration also includes 'authentication-type md5' but the key is 'juniper321'. Both routers have loopback addresses as router IDs: 1.1.1.1 for R1 and 2.2.2.2 for R2. No explicit OSPF network type is set, so the default is broadcast. Despite these configurations, the OSPF adjacency state on both routers remains in INIT. What is the most likely cause of this issue?
⚠ Common exam trap
The trap here is that candidates often overlook authentication key consistency because they focus on matching hello/dead intervals and area IDs, assuming authentication is correctly configured if the type matches.
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 OSPF authentication keys do not match.
OSPF authentication keys must match exactly for the adjacency to form. R1 uses key 'juniper123' while R2 uses 'juniper321', causing the MD5 digest computed on each Hello packet to differ. Since OSPF authentication is validated per-packet, mismatched keys prevent the routers from moving past the INIT state.
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 interface MTU size is mismatched.
Why it's wrong here
An MTU mismatch on an OSPF interface typically surfaces during the Database Description (DBD) exchange, because the MTU value is carried in DBD packets and a larger packet is dropped or truncated. This manifests as adjacency stagnation in the EXSTART or EXCHANGE state, not INIT. In INIT, the router has received a valid Hello but is still waiting for bidirectional reachability, which is a layer of operation prior to MTU negotiation.
- ✗
The OSPF network type is mismatched.
Why it's wrong here
Both routers in this scenario default to the broadcast OSPF network type on Ethernet interfaces, so there is no network type mismatch to cause the INIT state. A true mismatch (e.g., broadcast on one side and point-to-point on the other) would alter Hello packet fields like the DR/BDR priority and options, preventing proper neighbor discovery or two-way establishment, but that is not the case here. The existing configuration resolves to identical network types.
- ✓
The OSPF authentication keys do not match.
Why this is correct
When MD5 authentication keys differ, each router silently drops the other's Hello packets after the keyed digest fails verification. Because the local router never receives a valid Hello containing its own router ID, the neighbor state cannot advance from INIT to 2-Way. The adjacency therefore remains stuck in INIT, even though the Hello packets arrive at the interface, making this the misconfiguration exactly consistent with the symptoms.
- ✗
The router IDs are not properly configured.
Why it's wrong here
Router IDs are unique and correctly set in this scenario, so they cannot be the cause. OSPF uses router IDs for DR/BDR election, database exchange, and LSA identification, but the INIT state only depends on seeing your own router ID in an unauthenticated neighbor's Hello. Duplicate or missing router IDs tend to create later problems in EXSTART/EXCHANGE or cause LSDB inconsistencies, not a failure to establish two-way adjacency in INIT.
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 →
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.