Junos configuration basics — the very foundation of how you tell a Juniper device what to do. If you cannot structure a configuration, save changes without breaking the network, and undo mistakes cleanly, you will fail the JNCIA-JUNOS exam before you even start. This chapter gives you the mental model that every Junos admin uses from day one.
Jump to a section
A simple way to picture Junos Configuration Basics
5 is the number of pages in a standard restaurant menu at a busy international hotel. Each page covers a different category: starters, mains, sides, desserts, and drinks. When you sit down, you don't order by shouting across the room. You make your selections, write them down, and then hand the completed order slip to the chef. Only then does the kitchen start cooking. If you decide to change your mind after submitting, you must write a new slip and hand it in again. The chef never starts cooking until the whole slip is complete and submitted.
Junos uses the same approach. The configuration hierarchy is that menu. Every possible setting lives on a specific page — interfaces under 'interfaces', routing protocols under 'protocols', security under 'security'. You never guess where something goes. The order slip is the candidate configuration. You edit it locally, on your device, without affecting the running network at all. Only when you type 'commit' — hand in the slip — does the chef switch to cooking your new order. If you make a mistake, you roll back to a previous order slip (the commit rollback feature). The hierarchy ensures every setting has one and only one home, so you never leave something in the wrong category.
Junos devices run the Junos operating system. Everything you want the device to do — from assigning IP addresses to routing traffic to blocking attacks — is controlled by its configuration. The configuration is not a random list of commands. It is a strict, organised hierarchy, like a filing cabinet with labelled drawers and folders.
Think of the hierarchy as a tree. At the top level, you have broad categories: interfaces, protocols, security, system. Under each category, you drill into specific settings. For example, to set an IP address on a port, you navigate to interfaces -> ge-0/0/0 -> unit 0 -> family inet -> address 192.168.1.1/24. Every leaf of the tree has a unique path. Junos calls this path the 'configuration hierarchy'. You edit using 'set' commands that mirror that tree. You never guess syntax because the path is always the same.
Why does Junos use a hierarchy? Before modern network operating systems, many vendors used flat configurations. You typed one command after another, and the order mattered desperately. If you moved one line before another, the device might ignore it. Junos hierarchies eliminate order dependency. The location of a setting in the tree determines its effect, not the sequence you typed it. This is a huge relief for beginners — you can add settings in any order, and the device will apply them correctly at commit time.
The second pillar is the commit model. Junos separates 'candidate configuration' from 'active configuration'. The candidate is your scratchpad. You make changes inside it, and the device continues running with the old active configuration unchanged. Nothing breaks while you edit. When you are satisfied, you run the 'commit' command. Junos checks the candidate for errors, then instantly replaces the active configuration with the candidate. If the validation fails, the candidate is rejected, and the active config stays untouched. This is called 'confirm' commits, 'rollback' commits, and 'commit check'.
Configuration management in Junos includes several powerful features:
Rollback: Junos stores the last 50 committed configurations. You can revert to any of them with 'rollback X' where X is a number (0 is the most recent). This saves you when you break something and need to go back to a known working state.
Commit script: Advanced users can run scripts that modify the candidate before commit. For beginners, just know it exists — it is not on the JNCIA exam.
Rescue configuration: You can save a known-good configuration as 'rescue'. If the device ever boots without a valid config, it loads the rescue config automatically.
Previously, network devices had no such safety net. You changed one line, and either the change took effect immediately or the device rebooted. There was no 'try before you buy'. Junos changed that with its transactional model. The concept is borrowed from database management: changes are atomic (all or nothing). Either the entire commit succeeds, or nothing changes. This prevents half-applied configurations that cause strange, hard-to-diagnose bugs.
For the JNCIA exam, you must know:
The hierarchy starts with top-level statements: system, interfaces, protocols, security, policy-options, routing-options, etc.
Every configuration statement lives under exactly one top-level category.
The 'set' command builds configuration statements. Example: 'set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/24'.
The 'show configuration' command displays the current candidate configuration. 'show configuration | display set' shows it in 'set' format.
The 'commit' command activates the candidate. 'commit check' validates without activating.
The 'rollback' command discards changes back to a previous commit. Number 0 is the last commit, 1 is the one before that, up to 49.
The hierarchy is not optional. It is the only way Junos accepts configuration. You cannot just type 'ip address 10.0.0.1' and expect it to work. You must navigate the tree. This forces discipline, but it also makes configurations predictable and easy to read. Anyone who knows the hierarchy can look at a Junos configuration and immediately understand where to find interface settings, routing protocols, or firewall rules.
Enter Configuration Mode
You log into a Junos device and type 'configure' at the operational prompt ('>'). The prompt changes to '#' to show you are now editing the candidate configuration. No live changes occur yet — you are just preparing edits.
Edit the Candidate Configuration
Use 'set' commands to add or modify statements in the hierarchy. For example, 'set system host-name my-router' sets the device name. You can also use 'delete' to remove statements. All edits accumulate in the candidate, separate from the active config.
Validate with Commit Check
Run 'commit check' to have Junos scan the candidate configuration for syntax errors, missing references, and logical conflicts. If validation fails, you get clear error messages. You fix them and repeat until checks pass. This step is optional but highly recommended before applying changes.
Activate with Commit
Type 'commit' to apply the candidate configuration to the active configuration. Junos atomically replaces the active config with the candidate. If the commit succeeds, the device starts using the new settings immediately. If there is an error during commit, the active config remains unchanged, and the candidate is rejected.
Verify the Active Configuration
After commit, exit configuration mode by typing 'exit' or 'quit'. Use 'show configuration' at the operational prompt to view the active configuration. You can also use 'show interface terse' or other show commands to confirm specific settings are working as expected.
Roll Back if Needed
If the new configuration causes issues, re-enter configuration mode and type 'rollback 0' to load the previous commit into the candidate. Then commit again to revert the device to the old configuration. You can also use 'rollback 1' for older versions, up to 49 steps back.
An IT professional, let us call her Priya, works for a mid-sized e-commerce company. The company has just bought a Juniper SRX firewall to protect its internal network. Priya must configure a new subnet for the marketing department. She has never touched a Juniper device before, but she studied JNCIA materials.
Step one: Priya connects to the device via SSH and logs in. She enters 'configure' mode. The prompt changes from '>' to '#' — she is now in the configuration hierarchy. She is editing the candidate configuration. The device is still running its old settings, so the marketing team’s internet keeps working while she works.
Step two: Priya wants to create a new interface, say ge-0/0/5, for the marketing subnet. She knows the hierarchy: interfaces -> ge-0/0/5 -> unit 0 -> family inet -> address 192.168.50.1/24. She types the exact 'set' command. Junos accepts it silently. No error, no warning — but also no effect on active traffic yet.
Step three: Before committing, Priya runs 'commit check'. Junos validates her change. It checks that the address is valid, that the interface exists, that there are no conflicts. If she had typed 192.168.50.300/24, commit check would reject it with a clear error. She fixes it and re-checks.
Step four: Priya commits. The device applies her change. Now the marketing team can use the new subnet. But she also realises she forgot to add a security policy. She quickly adds a policy in the candidate, then commits again. The entire process is safe because each commit is atomic.
Step five: A week later, the marketing team says the new subnet is not routing properly. Priya suspects her commit broke something. She uses 'show system commit' to see the list of committed changes, then 'rollback 1' to undo the last commit. The device reverts to the previous configuration. The network is back to normal in seconds. She then investigates more carefully.
In a busy enterprise, IT pros use these Junos features daily:
Commit confirmed: When making risky changes, they add 'commit confirmed 10'. If they do not confirm within 10 minutes, Junos automatically rolls back the change. This prevents being locked out by a bad configuration.
Rollback: Quickly reverting to a known working state when an upgrade or change goes wrong.
Rescue configuration: Setting up a minimal working config so that if the device loses its config (for example, after a factory reset), it can at least come online with management access.
Archive: Storing past configurations on a remote server for compliance and troubleshooting.
Without these tools, Priya would be debugging blind. With them, she can experiment, roll back mistakes, and maintain high uptime.
The JNCIA-JUNOS exam tests your understanding of the Junos configuration model in several direct ways. You will see multiple-choice and multiple-answer questions. Some question types to expect:
'What command enters configuration mode?' Answer: 'configure'. Traps: 'edit', 'config', 'set' — these are not the command. 'configure' is the exact keyword.
'What is the difference between candidate and active configuration?' Answer: Candidate is the scratchpad; active is what the device runs. Traps: saying candidate is the backup, or active is what you edit.
'How many previous commits can you roll back to?' Answer: 50. Traps: 49, 10, unlimited. Memorise 50.
'Which command validates a configuration without applying it?' Answer: 'commit check'. Traps: 'commit validate', 'check config', 'pre-commit'. Only 'commit check' is correct.
'Given a set command, which part is the hierarchy path?' They will show a long command and ask you to identify the statement. Practise reading paths.
Trap patterns to watch for:
They will ask about 'commit confirm' timeout. The default is 10 minutes. They may list other values like 5, 15, 30. Know it is 10.
They will give you a scenario where a change is made but not committed, then ask if it affects traffic. The answer is always no.
They will ask about rollback numbers: 0 is the most recent committed config. Traps: 1 is the most recent. No, 0 is. Remember 0 is now.
They will test if you know that 'set' commands are additive. If you set the same value twice, the last one wins. There is no 'unset' required, but 'delete' removes a statement.
They may present a configuration snippet and ask which top-level hierarchy it belongs to. For example, 'ip-options' under 'protocols'. Memorise the top-level hierarchies: system, interfaces, protocols, security, policy-options, routing-options, forwarding-options, firewall, snmp, etc.
Key definitions to memorise:
Hierarchy: The tree structure of configuration statements.
Candidate configuration: The configuration you are editing in 'configure' mode.
Active configuration: The configuration currently running on the device.
Commit: The action that makes candidate configuration become active.
Rollback: Reverting to a previously committed configuration.
Rescue configuration: A special configuration that loads automatically if the device boots without a valid config.
Exam questions love to combine the hierarchy and commit model. For instance, they might ask: 'You are in configuration mode and have made changes. You want to discard all changes since the last commit. What do you do?' Answer: 'rollback 0'. They expect you to know that rollback 0 reverts to the most recent commit, discarding the candidate.
Also expect scenario-based questions where a junior admin breaks connectivity and needs to undo. They will test whether you choose 'rollback', 'revert', 'undo commit', or 'delete'. Only rollback is correct.
Finally, remember that Junos is case-sensitive. 'Interfaces' and 'interfaces' are different. The hierarchy uses lowercase. Watch out for capital letters in exam options — they may trap you with 'Interfaces' (capital I) as a distractor.
The Junos configuration is a strict hierarchy, so every setting has exactly one valid location — never guess, always follow the tree.
Changes are always made to a candidate configuration first, never directly to the active configuration, to prevent accidental network disruption.
The 'commit' command is the only way to make candidate changes active — without it, nothing happens on the live network.
Junos stores the last 50 committed configurations, and you can revert to any of them using the 'rollback' command with the appropriate number.
'commit check' validates your candidate configuration for errors without applying it, allowing you to catch mistakes before causing outages.
A rescue configuration is a special saved config that loads automatically if the device cannot find a valid startup configuration, ensuring basic management access survives.
The 'set' command is additive — if you set the same leaf twice, the last value overrides the first, but the hierarchy path must match exactly.
Configuration mode is entered with the 'configure' command, and the prompt changes from '>' to '#' to indicate you are editing the candidate.
These come up on the exam all the time. Here's how to tell them apart.
Candidate Configuration
Editable scratchpad where you make changes before they affect the network.
Exists only in memory until committed; not saved to non-volatile storage.
Can be discarded entirely with 'rollback 0' without affecting live traffic.
Active Configuration
The configuration currently used by the device for routing, switching, and security.
Saved to non-volatile storage and survives reboots.
Cannot be edited directly; changes go through the candidate first.
Commit Check
Validates syntax and semantics of the candidate without applying it.
Returns error messages if validation fails; candidate remains unchanged.
No impact on active configuration or network traffic.
Commit
Validates and then applies the candidate to the active configuration.
If validation fails, active config remains unchanged; candidate is rejected.
Causes a momentary interruption in traffic for some changes (e.g., interface modifications).
Rollback 0
Replaces the entire candidate with the most recently committed configuration.
Discards all uncommitted changes in one action.
Does not affect the active configuration until you commit afterwards.
Delete
Removes a specific statement or hierarchy from the candidate.
Leaves other parts of the candidate untouched.
Also does not affect active configuration until commit.
Rescue Configuration
A special configuration saved with the 'request system configuration rescue save' command.
Loaded automatically if the device boots without a valid configuration.
Typically minimal (just management access) to allow recovery.
Normal Committed Configuration
The configuration saved by normal 'commit' operations.
Loaded during normal boot process; overridden if rescue is needed.
Can be complex with full services and policies.
Mistake
Once I type a 'set' command, the change takes effect immediately.
Correct
The change only takes effect after you run the 'commit' command. Until then, it sits in the candidate configuration and does nothing to live traffic.
Most consumer devices apply changes instantly, so beginners expect the same. They forget the commit step entirely and wonder why nothing changed.
Mistake
The 'rollback 0' command undoes the most recent commit and keeps the candidate as it was before.
Correct
'rollback 0' replaces the candidate configuration with the most recently committed configuration, discarding any uncommitted changes in the candidate.
The name 'rollback' sounds like 'undo' — but it actually loads a previous commit into the candidate, not the active. Beginners think it directly undoes the live config.
Mistake
You can only have one level of hierarchy under the top-level categories.
Correct
The hierarchy goes many levels deep. For example, 'interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24' has five levels. Junos supports deep nesting.
The tree structure is not obvious from a few examples. Beginners see 'interfaces' and think it is flat, but each interface can have many sub-options.
Mistake
If you delete a line from the configuration, the device automatically reverts to the factory default for that setting.
Correct
Deleting a line removes the explicit statement. The device then uses its default behaviour, which may be nothing (no address on an interface) or a platform-specific default. It does not automatically restore a prior non-factory value.
People confuse 'delete' with 'rollback'. They think deleting a line is like hitting undo on a document, but it just empties that leaf. The rest of the config stays as committed.
Mistake
The 'commit confirm' command confirms a change permanently.
Correct
'commit confirm' temporarily applies the change, but if you do not run a normal 'commit' within the timeout (default 10 minutes), Junos automatically rolls back to the previous active configuration.
The word 'confirm' implies finality. Beginners think it locks in the change, but it is actually a safety mechanism for risky changes — it is the opposite of permanent.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Type 'exit' or 'quit' at the '#' prompt. Junos will ask if you want to discard uncommitted changes. Answer 'yes', and you return to operational mode with no candidate changes applied.
'commit check' validates the candidate configuration for errors without applying it. 'commit' both validates and applies the candidate, making it the active configuration.
Yes, if you have committed fewer than 50 times since then. Use 'show system commit' to see the history, then 'rollback' with the number corresponding to that commit (0 is most recent, 1 is previous, etc.).
If you have no out-of-band access, you could lose connectivity. Use 'commit confirmed 10' before risky changes. It auto-rolls back after 10 minutes unless you confirm with a normal 'commit', giving you time to reconnect.
Yes. 'Interfaces' with a capital 'I' is not the same as 'interfaces' with lowercase. Junos hierarchy uses all lowercase by convention. Typing incorrect case causes an error.
While in configuration mode, type 'show' or 'show configuration'. This displays the candidate configuration in a tree format. Use 'show | display set' to see it as a list of 'set' commands.
'delete' removes a specific statement from the candidate. 'rollback' replaces the entire candidate with a previously committed configuration. Use 'delete' for targeted removals, 'rollback' to undo multiple changes at once.
You've finished Junos Configuration Basics. Continue through the JNCIA-JUNOS study guide to build a complete picture of the exam.
Done with this chapter?