Configuration management with Juniper Junos
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.
root@dc-firewall> configure
root@dc-firewall# exit
root@dc-firewall>
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:
root@dc-firewall> file list /config
/config:
juniper.conf.1.gz
juniper.conf.2.gz
juniper.conf.3.gz
juniper.conf.4.gz
juniper.conf.5.gz
juniper.conf.gz
juniper.conf.md5*
license-status.db
rescue.conf.gz
usage.db
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/ 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!
root@dc-firewall# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes
unless confirmed
commit complete
root@dc-firewall# commit
commit complete
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:
root@dc-firewall# commit at "reboot"
or
root@dc-firewall# commit at "2014-04-13 19:00:00"
If you don’t use the “commit confirmed” command, you can use the “rollback” command to revert commited changes.
root@dc-firewall# rollback ?
Possible completions:
<[Enter]> Execute this command
0 2014-04-13 10:35:44 GMT+1 by user via cli
1 2014-04-09 23:28:46 GMT+1 by user via cli
2 2014-03-08 16:58:32 GMT+1 by user via cli
rescue 2014-04-13 16:59:44 GMT+1 by user via cli
| Pipe through a command
root@dc-firewall# rollback 2
load complete
root@dc-firewall# commit
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.
root@dc-firewall# set system archival configuration transfer-interval interval 15
or
root@dc-firewall# set system archival configuration transfer-on-commit
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.
set system archival configuration archive-sites "ftp://ftp@192.168.200.65/data/configs/dc-firewall" password "ftp"
set system archival configuration archive-sites "scp://patrick@192.168.200.69/data/dc-firewall" password "Passw0rd"
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.