I often see people on forums saying, “We want to do network automation, but we don’t know where to start.” In my opinion wanting to start is the best place. Pick up something and play around with it in the lab. That’s the best way to get started. However, if you are working in a decent sized environment and you have convinced the managers to get behind you it becomes a whole new ball game once it moves from just you doing automation to your entire team is doing automation. Where does your company get started when you decide to take the leap? Let’s look at standardization, your source of truth, and your automation platform. Getting these will be your company’s starting point.
First let’s look at standardization. In order to automate something, there have to be standards: if everything in your network is a snow flake (no two alike) your gonna have a bad time. Your automation programs will need to know what they are looking for and your gear must operate in a predictable manner; as such you’ll need standards. You can even have multiple standards but every standard you have means more work keeping them all up to date. For example, you have some old gear in your network that doesn’t support the standard password/SNMP key/named ACLs/etc you use on your newer gear. Do you build multiple standards, or do you deal with something that every peace of gear supports? Honestly that’s up to you, maybe you have government requirements for complexity of the passwords or something along those lines. So, you may be required to have to have those multiple standards. Personally, I would rather deal with one standards file for those three issues than with six files, or with lots of logic in my 1 standards file. When dealing with complex stuff I like the KISS method (Keep It Simple Stupid). An example of a part of a standards file would be:
Interface vlan 10
ip address <vlan_10_ip> <vlan_10_snm>
With this every VLAN 10 in the network will look the same. Your automation platform will be filling this template out and will pull the IP and subnet mask from the source of truth and build the configuration for each device. Speaking of which, let’s try and figure out what that source of truth will be.
Your source of truth is: when you want your automation to know something about the network, where should that program look? You don’t want the source of truth to be the network itself as that would be circular logic. Let’s say R1’s loopback IP address is 192.168.0.1 how do you know that is correct? Is it correct because it exists? Wouldn’t it be better to have somewhere to check that this is correct such as the IPAM (IP address manager)? Along those same lines what happens if R1 goes down? Should your automation be dependent on everything in the network being up? That sounds like a bad idea. In the example above for VLAN 10, your source of truth would be your IPAM. Your script should know by the configuration on the IPAM that router X has subnet Y, and the program knows to give VLAN 10 the last IP address in that subnet. You don’t have to try and find one all powerful program to be your single source of truth, you’ll more than likely have lots of sources of truth which are functionally in use, even if people are not aware of them. The important thing is that these sources of truth are reliable, and you’ll be building your network based on them. If these sources of truth have bad data, such as a mistyped IP address, your network will suffer.
If your networking department is any size at all you’ll need an automation platform such as Ansible, Salt, or Puppet. Each of these are configuration management tools which are commonly used in the industry. Personally, I would recommend Ansible, as it’s one of the more heavily used, and there has already been a lot of development done for it. There is no need to reinvent the wheel, when solving the same basic problems such as connecting to a device and sending commands from a template. Also it’s the only one I have used the most, so expect some bias in the rest of the article.
The automation platform is what will be making the actual changes to the network and keeping it up to date according to your source of truth and templates. On this topic, I have heard a lot of people advocating for using pure python to configure network devices, instead of using a pre-built tool like Ansible. There are situations when I would go this route and build a Python program to take care of something I could have done with Ansible instead.
For example, if you are a 1 person show and the rest of the company hasn’t picked up this whole “automation” thing, especially in a large company it can take months or more to get a Linux server to run Ansible on, and longer still to get it permitted though the firewalls if it needs special rights to be able to access secure networks, such as the management networks for your network gear. With Python all you really need is a laptop and often you’ll be able to VPN in so the laptop can reach those management networks skipping straight to the automation. Python also deals with snowflakes in your network much better than your standard frameworks, such as Ansible. Personally, I love Python, I enjoy writing it, and get a sense of pride when I write something amazing. That being said, Python can lack scalability to the extreme. When learning Python it will probably take at least a month or two before you get usable code. In contrast, Ansible after a week or two of learning and most people can do a fair amount of stuff with way more safety built into the process. The engineers don’t need to know all the python that lives below the surface. There is also a huge list of pre-built modules in the platforms that will do most things you would want to do, where with to python where you have the bottle neck of there being one or two guys who can do python that will have to write stuff those modules already do. With some flavors of Ansible you can even have it schedule tasks such as “Go out every night at midnight and make sure the SNMP ACLs are up to date.” This framework will be the hugely important to your network, make sure you know it very well!! If I were you, I would get some training. Personally, I work for Network to Code so I am a little bias on where you should get your training. Some alternatives are Kirk Byers has an Ansible class and I liked his other classes well enough. Udemny.com has some Ansible courses for networking, udemy.com often has good courses and always cheap ones. Note I can’t speak for any of these class’s quality. I know INE has a course, but I wasn’t a big fan the class when I took it, but that was quite some time ago. So, if you already have an all access pass it might be worth a look since it would be free.
As a side note for the managers out there, be sure you put a plan in place to make your automation engineers want to stay where they are. Right now, “Enterprises are already spending over $12 billion on IT automation in 2018. And by 2025, spending will reach nearly $232 billion.” https://www.qubitnet.com/networking-solution/network-automation/ You can bet that head hunters will be coming for your network automation people in droves. If you don’t have a plan to keep them you will probably lose them, and yes, I told my boss that about four months before I I got a better offer somewhere else and quit. Make sure multiple people have these skills for this reason.