Intro

Short blog post, as many of you, will just want to fiddle with the playbook(s) itself.

GitHub repo link: https://github.com/netdevdan/Network-Backups-VCS-Git

Many orgs rely on plain text backups, which are “versioned” by directory structure or simply creating a new file with the date added to the latter end of the file name. I wanted a clean way to reduce that structure to 1 backup (the most recent) but have the previous versions available under git/ version control (VCS).

Many configuration backup tools simply run commands over ssh and capture the output. This can be resource-intensive and time-consuming. As well as costing the organisation, depending on what product you’re using.

Note: This will require NETCONF to be enabled on your Juniper devices.

What are the advantages of this?

What was created?

An Ansible playbook to pull the committed (active) configuration from Juniper devices defined in a host file (NetBox is the next goal) and save it to a local directory. With that config in place, if any changes are detected under git control, it will add/ commit/ push it to your git repo (via an additional playbook).

These playbooks can then be scheduled to run at specific times via CRON, using Ansible Tower’s schedule or even on the Juniper device itself. We could create a commit script in Python on the Juniper device to call the playbook on the remote server, capturing its latest configuration change and pushing changes to the VCS.

What do I need to do to test your script?

• In the hosts file, amend the host IP addresses and your username/ password for accessing your devices.

  • Not recommended to statically set your username/ password in the hosts file unless in a lab scenario, which I am. Otherwise; use an SSH key or Ansible Vault.

• Ensure your current working directory is under git control.

• Amend the git_control.yml file with your git username and repo as well as changing the paths to the configuration backup directory.

• Enable NETCONF on your devices

  • set system service netconf ssh

• Ensure you have the correct Junos pip and Ansible galaxy packages installed.

  • pip3 install junos-eznz

  • pip3 install jxmlease

  • pip3 install ansible

  • ansible-galaxy install Juniper.junos

Playbook(s) in action.

I’m using VScode, working in a development VM in my lab environment using EVEng.

Scenario

The simple layout of devices, nothing complex, just shows the basics of config management.

• 3 vSRX devices, no config changes made prior.

• Creation of username on one device, change of hostname on another, and “accidental” deletion of interface config causing layer 3 to drop between 2 sites. - Will be running the playbooks between commits manually, but in a real-world scenario, you may have Junos run a commit script to call the remote playbook on the control server.

The EVE-ng lab layout below shows the management connections from the FXP interface to a Cisco vIOS switch and feeds into my “management” network.

Lab layout - Ignore the 2 devices on the right that are turned off.

Run the backup playbook and Git playbook; no changes detected.

Note: This is normal if errors come up while running the Git playbook*. It will error if no changes have been made. It's simply git complaining about “no changes to commit, so we’re not committing”.*

Ansible playbook running and complete.

Make some configuration changes.

Quick config change on a vSRX

Rerun the backup and git playbooks.

Bit of a difference in output when a configuration change has been made.

We can see above that there were changes at the end of the task. 3 files had changed, which would match up with what we had just done. These changes have now been committed to our remote repo.

Let's check out GitHub.

We can see here that the changes have been committed. But we can dig a little further into what's been changed.

Comparing configuration commits.

At this time, we probably have our monitoring solutions flagging that the Bridgend site has gone down. We can check via Git what changes were made.

We can see the config differences between the previous and current versions.

We can see here that the most recent change via Junos was made by “admin” at 12:39. We can see the shift in hostname and “accidental” deletion of our interface connecting to Edinburgh.

Final words

There are a million different ways of doing this; as mentioned earlier, commit scripts on the devices, CRON (which wouldn’t be as effective), and multiple other forms of scripting your backups.

This was simply an exercise to get my hands dirty around configuration backups and VCS.

Please let me know if you have any questions or suggestions about what could make this work better or changes to the code! Still, very early into this, I feel like these posts remind me of where I was in the coming years and maybe act as a point of reference.