One of the favourite features about Junos when it comes to configuration management is the ability to manage configuration on a methodical manner. This is where the COMMIT configuration comes in and takes care of any unnecessary configuration mistakes which could have been made while performing a certain task.
To quote from Juniper’s website
When you commit the current candidate configuration, you can require an explicit confirmation for the commit to become permanent. This is useful if you want to verify that a configuration change works correctly and does not prevent access to the router. If the change prevents access or causes other errors, the router automatically returns to the previous configuration and restores access after the rollback confirmation timeout passes. This feature is called automatic rollback.
This feature will automatically rollback a “Candidate Configuration” unless the commit confirmed command is entered.
You can see are detailed explanation on Juniper’s Website here
Concept Extension
We live in an era where Internetworks are growing exponentially and it is near impossible to replicate a test lab to test out configurations before deploying onto the production network. However, an error in the configuration can cause catastrophic impact to the network. Therefore, to minimize such incident the following concept could be added to Junos. This concept extension takes one step further by giving the engineer more control over the configuration change he/she performing on the equipment.
When the Active Configuration (Running Config) is in place, the Juniper Routing Engine will display the verification commands according to the current config and how it will interact with the Router Control Plane (Fig 2). This is the current concept, and not only on Junos, but this is how all routers and switches behave.
The new concept takes account of the “Commit” feature and rebuilds the verification output according to the candidate configuration. The candidate configuration does take effect until it has been committed.
As you can see below (Fig 3) the user adds the Candidate Configuration to the Juniper Routing Engine as follows.
The user will be able to see how the Router Control Plane will behave once the Candidate Configuration is added into the Active Configuration. By doing so; all verification can be done on the router before finalizing Candidate Configuration to work with the Active Configuration.
For example we will assume that the Juniper Routing Engine running OSPF.
- The user is modifying OSPF network statements into the Candidate Configuration.
- Juniper Routing Engine combines the candidate Configuration with the Active Configuration and builds a Verification Template.
- User goes into the Verification Template and verifies how the network will converge when the new configuration is added.
- If the user is happy with the change, he/she can commit the change which will be installed into the Router Control Plane.
Conclusion
****I am sure this idea will indeed create a lot of bottlenecks when it comes to generating a Verification Template based on the Configurations. The resource available on the router will definitely get affected while creating the Verification Template, along with other facts such as live verification tasks such as QoS etc.
Nevertheless, this concept would be a fool proof verification method for an end user on checking how a Router Control Plane (OSPF Database, BGP Prefix exchange etc) behaves when new configuration is added.
This will give the end user more confident while working on the systems and will tremendously minimize any configurations mistakes. At the moment, there is only one way to find out whether such errors could cause an impact on the network is after the configuration is committed which could result in downtime. Thus having a fool proof method as such will eliminate such downtimes in future.