JN0-106 Junos Configuration Basics Practice Question
Scenario: Your company has a Juniper MX Series router at a branch office running Junos 18.4. The device has been in production for two years with a stable configuration. Yesterday, a senior engineer made several changes to the OSPF configuration to optimize routing for a new link. They committed the changes and left for the day. This morning, the branch office experiences intermittent connectivity, and the OSPF neighbor relationships are flapping. You suspect the recent OSPF changes caused the issue. You have remote console access to the router. The goal is to restore network stability as quickly as possible while preserving the ability to re-apply the changes after troubleshooting. Which course of action should you take?
⚠ Common exam trap
Watch out — candidates often choose Option A (deactivate OSPF) thinking it is a quick fix, but they overlook that deactivating the entire protocol causes a complete routing disruption, whereas 'rollback' with 'commit confirmed' is the precise, safe, and reversible method Junos provides for this exact scenario.
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
✓
Use 'rollback 1' to revert to the configuration before the changes, then 'commit confirmed 10' to verify stability.
'rollback 1' reverts the active configuration to the previous committed version (before the problematic OSPF changes), and 'commit confirmed 10' applies that rollback with a 10-minute confirmation timer. If connectivity stabilizes, the rollback becomes permanent; if not, the router automatically reverts to the previous configuration, ensuring no prolonged outage. This approach restores stability quickly while preserving the ability to later re-apply and test the OSPF changes in a controlled manner.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use 'deactivate protocols ospf' to disable OSPF entirely and then manually re-enable pieces.
Why it's wrong here
Deactivating the entire [edit protocols ospf] hierarchy disables all OSPF adjacencies and routes at once, not just the problematic changes. You would then have to manually re-enable each piece, including areas, interfaces, and authentication, without knowing exactly what the prior stable configuration contained. This approach both prolongs the routing outage and introduces a high risk of configuration drift or a syntax error, so it is not a quick or safe recovery.
- ✗
Immediately delete the OSPF configuration sections that were changed and re-add the original settings manually.
Why it's wrong here
Deleting and re-adding the OSPF sections manually means you are reconstructing the original configuration by hand in the candidate configuration. Since the changed portion is already loaded in the candidate, you would have to type out every original statement from memory or a separate backup, which is slow and prone to omissions or typos. Junos already provides a robust rollback mechanism, so manual editing is an unnecessary risk that extends the outage and offers no benefit over a proper rollback.
- ✓
Use 'rollback 1' to revert to the configuration before the changes, then 'commit confirmed 10' to verify stability.
Why this is correct
This is the correct approach because rollback 1 reverts the candidate configuration to the last committed configuration prior to the current one, which is exactly the stable state you want. Issuing commit confirmed 10 activates that configuration for 10 minutes; if nothing else is done, the system automatically rolls back to the previous config, ensuring connectivity is restored without a permanent lock-in. You can later issue commit (or commit confirmed again) to make the change permanent once you have verified OSPF stability.
- ✗
Perform a 'load factory-default' and 'commit' to reset the device to base settings, then reconfigure from backup.
Why it's wrong here
Loading factory-default is a drastic operation that erases the entire Junos configuration, including system settings, interfaces, routing instances, and security policies, not just the OSPF portion. After that, you would need a complete backup to restore the router to its original state, and even with a backup, it is much slower than a targeted rollback and risks losing other untracked changes. This is meant for initial provisioning or complete reinitialization, not for fixing a single protocol misconfiguration, so it causes far longer downtime than necessary.
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
This JN0-106 question is part of Courseiva's 156-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.