Managing a JUNOS Configuration

<!--StartFragment-->

One of my longtime gripes about IOS is that when you type a new statement to the CLI and hit return, the statement immediately becomes active on the router. For someone as mistake-prone as me, this is a big risk. And given that the majority of network problems are due to human error rather than hardware and software failures, it is a risk for everyone.

This can also be a problem when you’re making extensive configuration changes. Having those changes take effect one statement at a time can introduce all sorts of transient conditions.

The Candidate Configuration and Explicit Commits

This leads, in contrast, to one of my favorite JUNOS features: When you make a configuration change, the change does not take effect immediately. Instead, it goes into a candidate configuration file. You can make as many configuration additions, deletions, and changes as you like, and none of them become active on the router until you enter a commit command. That command causes the candidate configuration to become the active configuration.

The candidate configuration and explicit commit help tremendously in reducing the number of simple human errors that plague day-to-day network operations. You can make all your changes, check them as many times as you like during the configuration process, and only commit them when you are ready and are sure the changed configuration looks right.

Rollback

Of course there’s still the chance that after you commit the candidate configuration the result is not what you expected, and you want to get back to an earlier configuration. You can do that in JUNOS because when you do a commit and the candidate configuration becomes the active configuration, the previous configuration is saved to a hard disk on the router.

So if you want to get back to a previous configuration, you can enter the rollback 1 command and the most recently saved configuration becomes the candidate configuration. You can then make that previous configuration active again by entering commit.

JUNOS saves the last 49 configuration files. When you commit a new configuration, the old active configuration is saved as juniper.conf.1. What was juniper.conf.1 becomes juniper.conf.2, what was juniper.conf.2 becomes juniper.conf.3, and so on. So if you want to go back to some config older than the most recently saved one, you can do that. For example if you enter rollback 3, juniper.conf.3 – the configuration that was active before the last three commits – is loaded back into the candidate configuration. 

<!--StartFragment-->

Click here for an illustration of how these commands interact. 

Commit Confirmed

Suppose that despite all your efforts to insure your new configuration is correct before you commit it, something is overlooked and when you commit, you are locked out of the router.

Rather than just a simple commit, you can make the candidate configuration active with a commit confirmed command. With this command, the router waits 10 minutes for a second commit. If it does not receive that confirming command within those 10 minutes, the router automatically does a rollback and commit so that the previous configuration becomes active again.

The commit confirmed command can be such a lifesaver, I recommend forming the habit of using it rather than a simple commit in all cases.

You can change the default time that JUNOS waits for a confirming commit, by the way, to between 1 and 65,535 minutes. If for instance, you want the router to wait only 3 minutes for a confirmation, you can enter commit confirmed 3.

Save and Load

The candidate configuration is also a great feature for making maintenance windows go faster. Say you need to make changes to 10 routers at a 2AM scheduled maintenance. You can make the changes ahead of time in the candidate configuration file, and then save the file under whatever name you want either on the router’s hard drive or to an external server.

When it’s time to perform the maintenance, you can load the saved configuration back to the candidate config and commit it.

For example if you make a pre-maintenance configuration change and want to save it as Juniper3_10August_Change, you enter save Juniper3_10August_Change.

After the save, it’s a good idea to do a rollback 0. This causes a copy of the currently active configuration (juniper.conf.0) to be entered as the candidate configuration, thus avoiding a situation in which someone else might log into the router and commit your changes before the intended time.

Note that if you are at the top of the configuration hierarchy, as indicated by [edit], the entire configuration is saved. If you are at some lower level when you issue the save command, only the part of the configuration at that level is saved. For example, if you are at [edit protocols bgp], only the BGP configuration is saved.

When you are ready to make the configuration changes permanent, you load the saved configuration back to the candidate configuration file with – logically enough—the load command. This command has several options, depending on how you want to use the file you are loading:

·      load override completely replaces the current candidate configuration with the file you are loading. So if you saved a complete configuration, this is the option to use.

·      load merge adds the saved file to the existing candidate configuration. This is useful if you are adding new configuration sections; for example, if you are adding a BGP configuration to the [edit protocols] level, where there was no BGP configuration before.

·      load update compares the candidate configuration and the file you are loading, and only changes the parts of the candidate configuration that are different from the new configuration. You would use this, for example, if there is an existing BGP configuration and the file you are loading changes it in some way.

·      load replace looks for replace: tags that you added to the loaded file, and replaces the parts of the candidate configuration with whatever is specified after the tag. This is useful when you want more control over exactly what is being changed.

After the load operation, you can check the new candidate configuration to insure it shows the changes you want, and then commit it.

There’s an alternative approach to the operation I just described. You can make your changes to the candidate configuration and then use the command commit at, specifying an the hour and minute later on the same day, or specifying some later date, hour, and minute. For example, I could type commit at 2008-09-21 02:30:00 and the commit will not happen until 2:30 AM on September 21, 2008 (assuming that time is in the future, according to the router’s date and time).

Personally I don’t like this command; it leaves too much to automation. I prefer saves and loads, which gives more control of the operation. Your own preferences may differ, however.

There are several other JUNOS CLI features that help reduce operational mistakes, and I’ll cover those in the next post. 

<!--EndFragment-->