Automation revitalized the way we think about configuration management, and it is relevant to our entire customer base. So, let’s explore the wide variety of ways companies manage their configurations. We won’t cover everyone, because there is as much variety in how people use automation to manage their networks as there are networks. Our customer’s networks are not made with cookie cutters, rather they are original creations. And the ways they manage them are covered with the signatures of all the people who designed and operated them throughout the years.
SHOW ME THE CONFIGURATION
Should we have a lively debate on how we like to view our configurations? Or how we store them? Which is better, JSON or XML? I could be mistaken but friendships may have been lost due to this debate. Many customers save Junos OS configurations in text, display set, JSON, and/or XML. Sometimes the same people save their configurations in different formats depending on how they will be using them in the future. As one of my favorite Juniper Educational Services people used to say, “Life is full of choices.” I prefer to store entire configurations using XML (reasons include hierarchy and manual manipulation with lowest error rate) but utilize display set for lab testing with partial configurations. Please don’t judge me. Hopefully, we can all agree to disagree.
VIDEO 1– Junos OS CLI - MULTIPLE WAYS TO DISPLAY
REGULAR BACK UPS
How often do you back up configurations? Do you keep all those configurations and for how long? How often should you verify that their configurations are what they expect? And how do you go about this? Should you look at the commit history? Monitor the device for a change and check the unexpected ones? Or do you poll at a regular interval (4 hours, daily, etc) and also monitor for a commit? In my team’s lab, I currently backup before maintenance. I am thinking of starting a weekly backup on Friday nights where I delete the older configuration if it matches the new configuration. Let me know what you think.
Note: Lab is different from production, please do not use my methods here to run your production environment.
VIDEO 2 – ANSIBLE – CONFIGURATIONS BACKUPS
WHERE TO STORE
We are seeing an increase in configurations being stored in the cloud. Many customers are automating the pull from the device and pushing into a Git repository. There are many interesting things that can be done from here. Testing your configurations with changes in a virtual topology is one of Juniper’s exciting concepts we have made a reality.
WHAT IS TRUE?
The next religious debate is where to look for the truth. Do you keep a repository of configurations or do you check the network? An increasing number of customers are using the mentality of the network as the database. Instead of running analytics on the backed up configurations they are polling a live network. Why do they care about analyzing configurations? One example would be verification of the current configuration before pushing a new configuration onto the network that is dependent on a previous configuration. A second example could be standardization of certain configurations like NTP or TACACS servers. As soon as I had auditing capabilities provided by JSNAPy (see video below), I stopped analyzing backed up configurations. Consider me on the side of the network as the database.
VIDEO 3 – JSNAPy – AUDITING THE NTP CONFIGURATIONS
PUSH A CONFIG
Now we have a live network where there may have been configuration changes during the day… or not. Either way, we need the final outcome to be that the set of configurations expected on the devices, should be on the devices. Do we check each device for a delta and push the expected configuration if we do not see it? Or do we not care and just push the expected configuration on the devices, change/no change be damned? People are doing it either way. So if a tech support guy made changes during the day, we don’t care, his/her changes will be gone during the nightly check or push. Even Ansible (checks) and SaltStack (pushes) treat this scenario differently. This is a religious debate. Personally, the thought of looking at a commit history on the Junos OS with nightly pushes makes me cringe. I understand why companies do this but I vote check and push, if needed.
VIDEO 4 – PYEZ - MULTIPLE OPTIONS
IT’S COMPLICATED
So what does this all mean? I am not trying to confuse you, I promise. There are so many choices and there is not always a best practice since different customers have different needs on their different networks. Our goal here was to show you that you can choose different tools to do similar work. If you have some flexibility, you may use the tools (Ansible, SaltStack, Puppet, or Chef) where Juniper developers used our best practices to write code. If you know exactly what you want and these tools vary too much, please use Junos PyEZ or whatever programming language you want to use with NETCONF. Configuration management is one tiny piece of the puzzle, and it is a good way to start. Therefore, whether one utilizes the deployment tools or writes code from scratch, Juniper has multiple solutions using different ideologies and methods of configuration management. Learning and thinking through this one example of automation can open up one’s thoughts and ideas as to where their ideology lies.
ADDITIONAL LINKS
Infrastructure as Code Video
PyEZ Examples
Commit Time Enhancements