In this post, we will outline a simple process for tracking configuration changes to network devices using Ansible. The goal is to provide a simple workflow for tracking, validating and approving network changes using Git as well as setting the stage for validation and testing.

This can be considered part of the Change Management process, and a way to accelerate & enhance this lengthy process by adopting DevOps & CI/CD methodology. Usually, the Change Management process involves many resources (such as Change Management team, Design, Operation, and Governance).

Via automating and enhancing changes to your infrastructure that involves Network, System, Applications, and storage using predefined simple workflow will reduce pre-qualification and approval time for changes that should lead to enhanced Change Cycle.

 

Introduction

Normally in any new configuration change, after drafting Implementation Plan that includes the configuration required for the change across one or multiple devices. Then we normally deploy the required changes during a maintenance window.

In case we are skeptical, and following the best practice we shall try the new configuration in a lab environment; to make sure that there is no syntax error and it achieves the expected results.

The below sample workflow outlines, the proposed enhancement to the lengthy Configuration process discussed earlier and a simpler approach in terms of tracking and approving changes in the network in a more DevOps manner.

 

This workflow performs almost the same steps using relatively different tools and automated approach:

  • We are going to use Git as a change control in order to track the configuration changes that occur.
  • We are going to use NAPALM Ansible module to push the changes to the devices under the change.
  • Using NAPALM will allow us to capture the Candidate configuration of the targeted devices before the change, and push the intended configuration for these devices during the change.
  • We will not commit the changes to the devices, however, we will push the changes and the new Candidate Configuration for the devices to a new Git Branch in order to kick off a validation stage for these changes, thus this step can be carried out in normal working hours, since there is no impact on the network.
  • Once these changes are validated either using peer review or using CI/CD pipeline, we commit the changes into the master branch.
  • In the change window, we push the changes from the master branch to the devices using and commit the configuration.

 

The high-level workflow is outlined in the below diagram.

 

Playbook Workflow

The workflow can be divided into three main parts for better modularity, hierarchy, and control:

  1. Part 1: Creating a new Git Branch
  2. Part 2: Pushing the changes to the devices and retrieving the candidate and configuration differences “Config Diff”.
  3. Part 3: Pushing the new branch to a remote Git Repo.

We have used Ansible Roles in order to segregate the three above tasks/parts, and we have used a single playbook to execute all the roles.

The master playbook is shown below

 

 

 

 

 

 

 

 

We shall run the playbook first time with no commit only specifying the folder which has the changes that need to be pushed

ansible-playbook playbooks/pb_deploy_new_config.yml -l dc1-fw01 --e change_id=ch001

 

The variable change_id point to the folder which has the configuration for the device (dc1-fw01) in this example

 [117] → tree local_changes/
local_changes/
└── ch001
└── dc1-fw01.cfg

 

After this playbook run the new proposed configuration changes is pushed,  then we retrieve the candidate configuration for the device and we push all these changes to a new Git Branch locally as well as to a remote Git Repo.

we keep track of each change we perform by saving the changes that were pushed as well a the config diff that was retrieved from the devices as shown below



 


 


 


 


Using any Git workflow the new changes will be approved via either peer review or a CI/CD pipeline, the changes are merged with the master branch and can now be pushed to the devices in the approved change window


We run the playbook again but now using commit in order to push the changes to the devices.


ansible-playbook playbooks/pb_deploy_new_config.yml -l dc1-fw01 --e change_id=ch001 --e commit=yes








Retrieving the Candidate Configuration from devices


The below snippet outline the tasks in the config_deploy role in order to push the changes to the network device and retrieve both the candidate configuration and config diff that NAPALM provides.




 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


With the above tasks, we capture both the candidate configuration and config diff for the device and we overwrite the current configuration of the device which is saved in the Git Repo with the new Candidate configuration (in order to easily visualize the changes that will happen on the target device).




Conclusion


Using this sample workflow for updating the configuration on the network devices, we can have a complete record of all the changes and the capability to audit the changes as well as using the built-in Git commands in order to revert back the network state in case the changes that were applied are faulty ( using git revert ), thus a network-wide rollback mechanism can be easily added. Further, we gain the following key features


    

  • Syntax Validation on the same exact OS running on the network node.
    • 

  • Collecting Candidate Configuration, which can support us in building more accurate CI/CD pipelines with offline validation tools like Batfish.
    • 

  • providing configuration Diff to articulate the exact effect of the changes that will be applied to the devices.
    • 



 


The complete playbook (with all the roles) can be found in this GitHub Repo.