3.2 Configuration Model

JNCIA-Junos Juniper Networks Certified Associate

Track your progress as you read

Finished sections get a check mark.

1 Introduction & JNCIA-Junos Exam Overview

1.1 JNCIA-Junos Exam Facts 1.2 Juniper Certification Track 1.3 Exam Blueprint & Study Strategy

2 Networking & Junos OS Fundamentals

2.1 Networking Fundamentals 2.2 Junos OS Architecture 2.3 Transit Traffic & Packet Flow

3 User Interfaces & Configuration Basics

3.1 Junos CLI & J-Web 3.2 Configuration Model 3.3 Initial Configuration & Interfaces

4 Operational Monitoring & Maintenance

4.1 Monitoring with Operational Commands 4.2 Logging & Traceoptions 4.3 Device Maintenance

5 Routing Fundamentals

5.1 Routing & Forwarding Tables 5.2 Static & Default Routing 5.3 Route Preference & Dynamic Routing Overview

6 Routing Policy, Firewall Filters & Final Review

6.1 Routing Policy 6.2 Stateless Firewall Filters 6.3 High-Yield Review & Test Strategy

3.2 Configuration Model

Key Takeaways Explain This Topic AI

Junos uses a candidate configuration that you edit freely and an active (running) configuration that only changes when you commit .

Configuration is a structured hierarchy edited with set , delete , edit , top , up , and inspected with show and compare .

commit confirmed automatically rolls back after a timer unless you confirm, commit check validates without applying, and commit at schedules a future commit.

Junos keeps up to 50 previous configurations; rollback 0 discards candidate edits and rollback 1 returns to the prior active configuration (you still must commit a rollback).

A rescue configuration is a known-good config you save deliberately and restore with rollback rescue , while load factory-default returns to the shipped baseline.

Last updated: May 2026

Why This Topic Matters

The Junos commit model is what separates Junos from many other network operating systems, and Configuration Basics is the single largest JNCIA-Junos objective area (about one-fifth of the exam). Candidates lose points by assuming a set command takes effect immediately - it does not. Expect scenario questions that hinge on the difference between candidate and active configuration, and on which recovery command to use.

Candidate vs. Active Configuration

Junos maintains two distinct configurations:

Configuration Description

Candidate configuration A working copy you edit freely with set and delete . Changes here do not affect device behavior yet.

Active configuration The configuration the device is actually running. It only changes when you successfully commit .

When you enter configuration mode, Junos copies the active configuration into the candidate. You modify the candidate, review it, then commit to copy it back into the active role and apply it. If you log out without committing, the candidate edits remain pending for shared-config users or are discarded in private mode - so the rule to remember is: nothing happens until you commit.

Loading diagram... Junos Candidate / Commit / Rollback Flow

The Configuration Hierarchy

Junos configuration is a structured tree, not a flat list of lines. The top of the tree is [edit] . Beneath it are stanzas such as system , interfaces , protocols , routing-options , and policy-options , each of which contains sub-levels.

You can display the configuration in two formats. The default hierarchical (curly-brace) format shows the tree; the set format shows the equivalent flat commands. [edit]

• user@host# show system
• host-name router1;
• services {
• ssh;
• }

• [edit]
• user@host# show system | display set
• set system host-name router1
• set system services ssh
• Core Editing Commands

• Command What it does
• set path value Creates or sets a configuration statement
• delete path Removes a statement or an entire subtree
• edit path Moves your editing context down into a hierarchy level
• up / top Moves up one level / jumps to [edit]
• show Displays the candidate configuration at the current level
• rename / copy Renames or duplicates a configuration element
• annotate Adds a comment to a statement
• Using edit changes the [edit ...] banner so you can issue shorter relative commands: [edit]
• user@host# edit interfaces ge-0/0/0 unit 0

• [edit interfaces ge-0/0/0 unit 0]
• user@host# set family inet address 192.0.2.1/30

• [edit interfaces ge-0/0/0 unit 0]
• user@host# top

Reviewing Changes Before Commit

Before committing, compare the candidate against the active configuration. This is one of the most exam-relevant habits. [edit]

• user@host# show | compare
• [edit system]
• + host-name router1;
• [edit interfaces ge-0/0/0 unit 0 family inet]
• address 10.0.0.1/30;
• + address 192.0.2.1/30;

Lines beginning with + are additions in the candidate; lines beginning with - are removals relative to the active configuration. This shows exactly what a commit would change.

Commit and Its Variants

The commit command validates the candidate, and if it passes, copies it into the active role and applies it. Junos checks syntax and many semantic constraints during commit; a failed check leaves the active configuration untouched.

• Command Behavior
• commit Validate and apply the candidate immediately
• commit check Validate only; report errors but do not apply

commit confirmed minutes Apply now, but auto-roll back unless you run commit again within the timer (default 10 minutes)

• commit at time Schedule the commit for a future date/time
• commit comment "text" Apply and attach a log comment to this commit
• commit and-quit Apply and immediately return to operational mode
• commit synchronize Apply on both routing engines in a dual-RE system

commit confirmed is critical for remote work: if a change cuts off your own management connection, the device automatically reverts after the timer, so you can reconnect. To keep the change permanently, run a plain commit before the timer expires. [edit]

• user@host# commit confirmed 5
• commit confirmed will be automatically rolled back in 5 minutes unless confirmed
• commit complete

• [edit]
• user@host# commit
• commit complete

Rollback, Rescue, and Factory Default

Junos automatically archives previous configurations and provides several recovery paths. Knowing which one to choose is heavily tested.

Configuration Rollback

Junos stores the current active configuration plus up to 49 previous versions (so rollback 0 through rollback 49 , 50 total). Rollback loads an archived configuration into the candidate - you still must commit for it to become active.

• Command Result
• rollback 0 Discard all uncommitted candidate edits (reload the current active config)
• rollback 1 Load the configuration that was active before the last commit
• rollback 1..49 Load any older archived configuration
• show system commit List the commit history with timestamps and users

A common exam point: rollback 0 is the standard way to abandon edits you do not want, and after any rollback you must commit to apply it.

Rescue Configuration

A rescue configuration is a known-good configuration that an administrator deliberately saves as a safety net. It is not automatic. user@host> request system configuration rescue save

• [edit]
• user@host# rollback rescue
• load complete
• user@host# commit

Use request system configuration rescue save (operational mode) to capture the current active config as the rescue copy, and rollback rescue (configuration mode) to restore it. request system configuration rescue delete removes it.

Factory-Default Configuration

load factory-default replaces the candidate with the minimal configuration the device shipped with. Because the factory default has no root authentication, Junos requires you to set a root password before you can commit. [edit]

• user@host# load factory-default
• user@host# set system root-authentication plain-text-password

New password:

user@host# commit

• Recovery option When to use it
• rollback 0 Throw away current uncommitted edits
• rollback 1 Undo the most recent committed change
• rollback rescue Restore the admin-saved known-good baseline
• load factory-default Wipe the device back to shipped state