I am on mission to prevent people from getting into the habit of making configuration changes in Junos and, when the time comes to activating them, doing a commit check, immediately followed by a commit, if they don’t get any errors.
Absolutely, nothing wrong with it! Just that I feel it is completely unnecessary, and a waste of time.
Let’s take a look at this very simple scenario:
We have a virtual-router named VR1, with a single interface (fe-0/0/0.0), which currently has no configuration.
We configure an IP address under the interface, and immediately activate the new configuration by issuing the commit command (without any options).
If we compare the time stamps of the show system uptime, and the commit complete message, we can determine that it took about 28 seconds for the commit process to be completed, and the address to be activated.
NOTE: I am issuing the show system uptime just to get the starting time, and the commit command right after. The timestamp for the commit is displayed when the commit complete message is shown. Yo can get more accurate numbers with other methods but we really don’t need that here.
Let’s now add a second IP address. This time instead of commit we will do commit check.
It took about 16 seconds for the commit check to be completed.
Because the configuration does not get activated with commit check, we now have to commit for real.
It took about 24 seconds for the commit process to be completed, and the address to be activated.
Thus, it took 40 seconds ( commit check time + commit time), for the interface’s new IP address to become active, from the moment we said that we wanted to activate it.
Here is another example, where we are issuing the commands back to back:
It took about 42 seconds total for the new address to be activated.
What if we make multiple changes, and commit them all at the same time?
63 seconds total for the changes to be applied; significantly longer than it took when we simply added the addresses, and we didn’t made a large amount of changes.
Granted, the examples above are from my old SRX210, running 12.1X44-D35.5, you can see how the time jumped just by adding a few additional changes. Imagine making a large amount of changes. The activation time is roughly 1.5 times what it needs to be, because we are doing commit check and then commit.
A few years ago I was testing a largely scaled configuration on a MX480, with IPSEC, bridge domains, MC-LAG, BGP, GRE tunnels, BFD, VRRP… all x 4000. The config was about 650K lines, and the commit time was no less than 15 minutes. As you can imagine, I did NOT want to add any additional waiting time.
Commit time has been a source of concern for customers with scaled configurations and a need to frequent changes (to provision new customers for example). Juniper has implemented many features to improve commit times, including fast synchronize, delta export, batch commits, persist-groups-inheritance, … Why would we want to add more time to the process?
And I get it! You want to check for mistakes! You want to make sure your configuration is correct.
But it’s OK. commit will give you the exact error message(s) that you would get with commit check , if there is anything wrong with your configuration. And if there is anything wrong with your configuration it will NOT become active even with the commit option. It is not like you would be committing a configuration with errors.
If you compare side by side what happens when you do commit check and what happens when you do commit, you can see how both validate the new configuration. When you run the two commands back to back you are just duplicating these validations for no reason.
If for example, we added an address with a wrong subnet mask to our interface, we will see the same error with both commands.
And again, we don’t need to worry about these incorrect configuration becoming active. If it doesn’t pass the validations the commit process simply fails, and the configuration does not get activated.
You can see below that even with commit, the IP address 172.16.30.2/32 does NOT get added to the routing table.
Then, is commit check useful?
Absolutely!
Maybe you want to validate the changes you are making as you go, without activating them yet.
Maybe you need to wait until a certain time of day before you can actually activate the changes, but you still want to make sure the configuration is correct.
Maybe you want to validate that your router would accept some configuration changes, but you really don’t want to make those changes right now.
The common aspect on these situations is: you do NOT want to activate the changes! You just want to validate the syntax.
When you ARE READY to activate the changes just GO FOR IT!!! COMMIT!!
Recent Comments