Bart is a networking expert who spent the majority of his career in the ISP and Enterprise industry, gaining experiences in areas such as Routing & Switching, Linux and programming, while also establishing himself as a respected CCIE. You can find him on LinkedIn and Twitter.
My first steps in network automation using Python
You never start with multiple tools at the same time. Usually, there’s a simple task that you want to automate and you start looking for what is out there already. Years ago, I worked for a company with more than 150 different locations. The business required a regular overview of all unused ports at each location. I googled some solutions and soon enough I had built my own script in Python. The result was an Excel file that listed all the switches with their ports and their status, the mac addresses and vendor identifier along with the IP address. The next time the request came in, it took only one minute to run it, instead of a couple of days.
One tool = many tools!
Although I was happy with my network automation solution, I immediately knew that I had passed a point of no return. On the outside it is just one script, though underneath multiple dependencies exist; the system it runs on, the python version, libraries and potentially specific versions. Soon enough I made more scripts to automate other tasks, which meant even more tools, scripts, and dependencies. While writing these you keep wondering, isn’t there something out there? I read about all the good stuff out there: Ansible, Puppet, Netmiko, NAPALM, Nornir, Saltstack, NetBOX, the list goes on. But one tool = many tools! You have to make it work for your situation and adjust it to the desired flow.
The solutions we wrote became more advanced; not only retrieval of information from the network but also deployment in the network. Developing and maintaining the scripts took up a large part of my time.
The number of tools meant a lot of challenges:
- Lack of overview - there is only one person who had an overview of all the tools, what if I leave the company?
- Usage knowledge - training and documentation required
- Knowledge - more than one person should be able to maintain the code
- Onboarding - everyone has to be trained on how and when to use the different tools
- Integration - how to re-use information between tools, how to prevent duplicate solutions and databases, where is the single source of truth?
- Error handling
- Risk - what if we can't solve a specific problem; since we’re network engineers, not programmers.
- Security - can the usage of the scripts and dependencies be a security risk?
- Time - usually things like this start as side projects. Did the manager improve the time spent on this? Who is doing your 'other' work?
- Writing and debugging code properly takes a lot of time
- How to scale?
A platform to integrate all tools
Here’s what I learned: the biggest challenge is not the tools, but the integrations between them. I recommend thinking about a system or platform that can integrate all your point solutions. This inevitably means you need:
- Knowledge about programming
- Knowledge about networking
- Knowledge about building or selecting the right platform to support the integration
But it goes further than that; you need to think about where to keep your data (single source of truth), documentation, error handling, version management, security, and ways to educate your team.
As I see it, you have basically three options:
- Do it yourself, which is perfectly okay. I’ve seen companies run their network automation with lots of different tools working together for their specific environment. If the business grows, your team needs to grow. Are they network or software engineers? Dealing with legacy can take up a decent amount of time as well.
- Choose an application that is specifically made for network automation that forces you to work a certain way. This is also a good solution for some companies since it gives you focus and standardization. However, what to do with your existing solutions, and what about exceptions?
- Choose a platform where the two worlds of dev and ops come together. So you can still run your scripts and the platform takes care of all non-functional things. Such as logging, version control role-based access, approvals, and system management features. The advantage of this approach is that it gives you enough flexibility while also driving standardization.
So where did I go? After my first automation adventures, I felt I shouldn’t reinvent the wheel. I saw the market developing and was well aware that network automation was here to stay. I asked myself: How can I help as many people as possible with their network automation challenges? That’s when I decided to join NetYCE; a company that enables network engineers to focus on what they do best: work on the network while taking most of the automation work out of their hands.
