Configuration management with Juniper Junos

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

One strength of Juniper Junos is the config file management. The concept of different configurations is nothing special. For example Cisco uses two configuration files to reflect the current configuration in the RAM (running configuration), and the configuration used on startup (startup configuration). HP is doing the same on their networking gear. If you are new to Juniper Junos, the concept of an active configuration and a candidate config, which holds the current changes but isn’t active, maybe confuses you.

The basics

Junos knows two command mods: The operational mode and the confguration mode. The operational mode is used for managing and monitoring your Junos device. You can switch from the operational mode to the configuration mode. The configuration mode allows you to configure your device.

As you can see, the prompt changes when entering or leaving the configuration mode. When you change from the operational mode into the configuration mode, the latest configuration file is used to create a candidate configuration. The latest configuration is stored in the filesystem and reflects the active configuration in the memory. The candidate configuration is used to store the changes that were made in the configuration mode. But changes to the candidate configuration doesn’t take effect immediately. You have to commit the changes at the end of the configuration process. During the commit, the configuration is checked for syntax errors and if it’s fine, the commited configuration gets the new active configuration. This configuration is stored in the filesystem and the older files get rolled.The filesystem contains more then the latest config. You can check this by using the file command in the operational mode:

The rescue.conf.gz contains the rescure configuration, the juniper.conf.gz contains the latest configuration and the juniper.conf.#.gz contain the last configurations, which can be used for a configuration rollback. I have tried to illustrate in a graphic:

juniper_commit_process

Juniper/ www.juniper.com

Advanced operations

Junos is designed to handle configuration as a process. This explains why the active configuration isn’t changed immediately. The syntax check upon commit gives you more safety in regard to syntax or configuration errors. We all know this situation: We connect to a network device by Telnet or SSH, we enter a command and the session disconnects. This can also happen to you when you use Junos. After the commit, the candidate configuration gets active and your session goes down. But hey, there’s a solution!

If you commit a change with the “commit confirmed” command, you have to enter a second commit to save the configuration. Otherwise your changes will be rolled back after 10 minutes. So the worst case is, that you make a change, you lose your connection but after 10 minutes the failed change is rolled backup automatically. You can also specify the point of time, at which a candidate configuration should be commited:

 or

 If you don’t use the “commit confirmed” command, you can use the “rollback” command to revert commited changes.

The “rollback”  command copies an archived config to a candidate configuration, which can be commited.

Another often faced problem are missing configuration backups. Junos provides a way to automate the backup of configuration files. The configuration can be backuped after an interval or after a commit.

or

The interval is given in minutes and has to be set between 15 and 2880 minutes. In both cases you need to add an archive site, meaning a place where the files has to be uploaded. You can add multiple achive sites, in this case I have entered a FTP and a SCP destination.

The password in the configuration file is saved encrypted . :) Depending on what you have chosen, the configuration will be uploaded after the interval or after a commit.

Follow me

Patrick Terlisten

vcloudnine.de is the personal blog of Patrick Terlisten. Patrick has a strong focus on virtualization & cloud solutions, but also storage, networking, and IT infrastructure in general. He is a fan of Lean Management and agile methods, and practices continuous improvement whereever it is possible.

Feel free to follow him on Twitter and/ or leave a comment.
Patrick Terlisten
Follow me

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept!