From hand crafting to mass production
In the beginning we created configs by hand. Lovingly tuned and refined them until they were doing exactly "the right thing"...
In the beginning we created configs by hand. Lovingly tuned and refined them until they were doing exactly "the right thing". When something changed, we once again tuned and refined the configs.
Stop it! No, really. Stop making individual changes to routers and switches.
In our quest to automate we must be willing to let go of the careful configuration and TLC we paid each device. We must transition these devices from our pets (each with a name) to livestock (just a number).
From experience, this process will take time and you will iterate over the steps several times.
Step 1 - Templates
Take your network configuration and make templates from it. There is a balance on how much to break up a configuration. Having a single template for each device is, in most cases, not granular enough. While having a template for every interface is to granular. What parts are the same across all devices? Start there. I found a good place to start was the MOTD/BANNER of the devices. This was something that was (should be) consistent on all devices that, if I messed up, wouldn't impact the operation of the device. Worst case, if everything else went to hell, I would have to SSH into every device and copy and paste a fixed banner. Or, more appropriately, I would fix my template and deployment playbook (Ansible term) and try again.
Now, every changes should be tracked in a versioning system. This way as the templates change you can track the changes and identify if/when problems were introduced.
I ended up breaking my templates up into areas of operation. VLAN creation, AAA, NTP, Spanning Tree, L3 interfaces, L2 interfaces, QoS, NAC, etc. By doing this I found that some parts of my templates would be revalent across categories of devices. NAC was really only applied to the access layer switches, while NTP, AAA, was applied to all devices.
Step 2 - Update processes and Involve the Team
Update the processes you use to deploy changes to incorporate the new tools. While it is easy to think that, if you see the benefits of automation, then all your team member also see the benefits. They don't... yet! While you are taking this journey, involve your other team members. Invite them to participate in maintenances you have where you'll be using your new templates and tools to push out configuration changes. Help them get started on using the tools, templates and process to deploy changes. If you are using automation and the others on your team are not, then you'll be constantly stepping on each others toes.
Step 3 - Refine and repeat
You will not get everything perfect the first, second, or tenth time. Refine your processes. Refine you templates. Repeat. Software changes. Hardware changes. Business changes. You will be making updates and changes to the templates to accommodate the various changes. Here are some refinements you should look at making.
Change "hard coded" values in templates to variables. e.g Instead of having the DNS servers in the template directly, place them into a variable and add that variable to the template. The better you get at this the closer you will come to a Network as code state.
Practice DRY (Don't Repeat Yourself) principles. When you find yourself building configurations that are the same over and over, this is a prime candidate to consolidate those operations into one file. And then just call that file (perhaps with some variables?!) from within the unique portions of the configuration.
Currently, I find an ideal situation is where I can define the specifics of a site, the IP addresses, VLANs, device names, etc. in a single configuration file and then have that site "built" by the automation tools from the configuration.
Next...
In the next article I'll explore moving from automation to intent.