Tips For Network Engineers Willing to Transit to Network Automation

Hello my friend,

quite often we are getting questions from various folks on LinkedIn or via private consultations about how start with network automation and, more importantly, whether to start with network automation at all. With this blogpost we’ll try to answer the most popular question.

1
2
3
4
5
No part of this blogpost could be reproduced, stored in a 

retrieval system, or transmitted in any form or by any 

means, electronic, mechanical or photocopying, recording, 

or otherwise, for commercial purposes without the 

prior permission of the author.

What to Do If You Already Want to Start?

The answer is simple: don’t wait. The amount of things you need to learn in order to succeed is huge and growing daily with new tools and platforms released. However, the good news is that we we provide you everything you need to start successfully in the role:

We offer the following training programs for you:

• Zero-to-Hero Network Automation Training
• High-scale automation with Nornir
• Ansible Automation Orchestration with Ansble Tower / AWX
• Expert-level training: Closed-loop Automation and Next-generation Monitoring

During these trainings you will learn the following topics:

• Success and failure strategies to build the automation tools.
• Principles of software developments and the most useful and convenient tools.
• Data encoding (free-text, XML, JSON, YAML, Protobuf).
• Model-driven network automation with YANG, NETCONF, RESTCONF, GNMI.
• Full configuration templating with Jinja2 based on the source of truth (NetBox).
• Best programming languages (Python, Bash) for developing automation
• The most rock-solid and functional tools for configuration management (Ansible) and Python-based automation frameworks (Nornir).
• Network automation infrastructure (Linux, Linux networking, KVM, Docker).
• Orchestration of automation workflows with AWX and its integration with NetBox, GitHub, as well as custom execution environments for better scalability.
• Collection network data via SNMP and streaming telemetry with Prometheus
• Building API gateways with Python leveraging Fast API
• Integration of alerting with Slack and your own APIs
• … and many more

Moreover, we put all mentions technologies in the context of real use cases, which our team has solved and are solving in various projects in the service providers, enterprise and data centre networks and systems across the Europe and USA. That gives you opportunity to ask questions to understand the solutions in-depts and have discussions about your own projects. And on top of that, each technology is provided with online demos and labs to master your skills thoroughly. Such a mixture creates a unique learning environment, which all students value so much. Join us and unleash your potential.

Start your automation training today.

If You Are Not Yet Sure What Is Network Automation

The network automation is area of engineering, which has just recently emerged in the past few years and is being actively developed today. The truth is that there is no formal definition of what network automation is, pretty much like there is not a clear definition for a “network engineer” these days as today pretty much everything has a network or is connected to a network. Therefore, let’s start with …

Scope Of Network Automation

What is included in the network automation? Or, to rephrase the question, what exactly Network Automation aims to automate besides the obvious but very broad “network”? There are a few quite precise use cases.

Configuration Automation

For many companies and engineers this is a starting point into network automation. In a nutshell, configuration automation is development and usage of network automation tools (see below) to manage the configuration of network devices. The configuration automation could as simple as using ad-hoc Ansible commands to modify the description of interfaces on multiple devices or as complicated as properly developed Python or Go tools or specifically packaged workflows to run on the workflow managers. What is important to keep in mind all the time for these and other automation you develop: what are you willing to achieve? And be as precise as you can. The good approach here is to use the user stories:

• As a network engineer I want to have automation to provision L3 VPN for customers across my backhaul network running Nokia SR OS so that I can provision such service via API providing a tine amount of vendor-independent data to reduce time for provisioning by 80%.

In such a user story you put clear goal and start specifying what exactly you want and why. Keeping the user stories focused and precise significantly helps during development and may influence the choice of tools

Reporting Automation

Another gateway to automation, which many company uses is reporting and documentation automation. On the one hand, the bigger the company is, the more various reports it needs: for accounting purposes, for extending support contracts, renewing the installed base, etc. On the other hand, when network engineers conduct various standard duties, they may want to quickly grab some network wide report (e.g, which SW version are run on the particular network devices platform). Both these use cases are solvable with network automation by writing some reporting tools, which are either ad-hoc or on a scheduled basis collect and report the relevant information.

Troubleshooting Automation

When the network services are down, it is race against the time to fix it ASAP and each (nano-) second counts. Therefore, the quicker the network services are fixed, the better it is for the company. There are few possible use cases here, where network automation could help:

• As with the reporting automation, it may be useful to retrieve the information about the particular network stack (e.g, your IGP or BGP, MPLS, PIM, etc) and compare it against the baseline to identify how the network is broken.
• Deployment of the network health check probes, which monitors the status of the end-to-end user experience and can automatically report to you how it does look like.
• Automated network reconfiguration (via closed-loop automation), where the convergence of the aforementioned network protocols are unachievable or not desirable for various reasons.

There could be further scenarios on top to what is already mentioned here, but they will be related to one of the categories, at least partially.

These and other use case are covered in our Zero-to-Hero Network Automation Training and other programs.

More advanced use cases

With adoption of the basic use cases, the company and individuals become more savvy with network automation tools and technologies on the one hand and, on the other hand, their confidence in network automation grows. When both characteristics are high enough, companies may start thinking in implementing fully automated provisioning by removing humans from the process.

We can help you with that.

Approaches To Network Automation

Ok, let’s say you have figured out your use list of the use cases, which will be beneficial for your environment and now you are thinking where to start. At the current moment, there are two major approaches (in each category), how the network automation is conducted.

Category To Network Device: CLI-driven Automation

All the network engineers we know start their career from configuring network devices with CLI. Regardless of the vendor, whether this is Cisco with range of their OS (IOS-XE, NX-OS, IOS XR, etc), Juniper with Jun-OS, Nokia SR OS, Arista EOS or any other vendor, they all have CLI and this is how the devices have been operated for decades. Therefore, many engineers, who develop tools, and who is fresh to network automation world start thinking: “Can someone quickly type commands instead of me?” That is the core concept for CLI-based automation:

• There is certain logic to prepare configuration in the same way as engineers used to do before in a format of the properly sequenced CLI commands.
• Then these commands are delivered via SSH to network device imitating the way humans are typing it.

As network engineers already know the the CLI syntax, it is relatively easy to start with such type of automation and, obviously, often people start building automation using CLI. However, this method has a number of significant drawbacks, such as:

• You always need to think about the sequence of CLI commands, when you apply configuration, as the sequence here matters.
• Collecting and parsing the operational state of devices via CLI, so called “show commands”, is not a trivial task, as parsing text with regular expressions is not a reliable. The one can say, hey, there are available TextFSM templates created by NTC; however, that only can say someone, who never used that at scale. The CLI scrapping is always tricky and no 100% accurate no matter which templates you use.

All in all, it is good to get a bit experience with CLI-driven automation, mainly to make yourself comfortable with the tool, like programming language or configuration management tool, which you are to use further. However, it is recommended to avoid using CLI-based automation in real production automation systems.

Category To Network Device: Model-driven Automation

Applications talk to other applications via API. This is the proper way to build automated systems, and this is what the model-driven automation brings to the party. The model-driven automation is an umbrella term, which means that network devices are configured using APIs rather than CLI. There are three key items to each API:

• data model, which is in network automation expressed with the help of YANG modules.
• serialization format (JSON, XML, YAML, Protobuf)
• transmission protocol (NETCONF, RESTCONF, GNMI)

In our training programs we dig deep into each of these elements, so with them you get ready to the real production automation.

Compared to CLI-driven automation, the model-driven automation provides you a significant benefit: you don’t need to scrape and parse with regexp anything. You are sending data to network devices as a collection of key-value pairs containing the configuration parameters and you retrieve the data back in the same way, so that it is easy to compare the desired configuration state against the real operational state.

All the real-life automation system in critical networks, such as Google data centers, and others, are built using model-driven automation, such as NETCONF/YANG and GNMI/YANG.

Category From Source of Truth: GitHub (GitLab, etc)

Besides interacting with network devices, which is a key focus for network automation for sure, you need to take the info what to configure on network devices from somewhere.

We intentionally put aside quite a popular input type, which is Excel spreadsheet. Yes, a lot of people are still using it, but that is not a reliable way forward.

Git repositories, backed up by some popular tools such as GitHub and GitLab are often popular choice for many companies for software developers to store the code. They do provide possibility to collaborate on the same project for multiple people, version the content over the time and even to use CI/CD pipeline for the automated execution of the changes.

As such, it is possible to store the configuration files, entirely for the CLI-driven automation or as a collection of variables processed by automation tools in case of model-driven automation.

Usage of the built-in mechanisms, such as PR (Pull Request), allow to add the resiliency to the process by enforcing the mandatory peer review of the configuration before the configuration changes are merged with the master configuration, which is being pushed to the network via CI/CD tools.

Category From Source of Truth: NetBox (other purpose build DBs)

One of the problems with usage of the GitHub and GitLab specifically for network automation is that it doesn’t have any purpose-built database to store the configuration data. The only way you can store it is some text files, such as YAML. Despite this is possible, that is not very convenient, especially when you are preparing the configuration of network-wide service and want to see the dependencies or the proposed change in the real time. This is where the NetBox comes to stage, as the best-in-class tool for the network modelling. NetBox allows to prepare the vendor agnostic network model with all the connections, VLANs, VRFs, EVPNs, provider circuits, data centres, with all the smallest parameters, which you may want to configure. Then, you will request this data from NetBox via REST API (or GraphQL API) and will receive the data, which you can use in the configuration.

In our Zero-to-Hero Network Automation Training we covers both Git Ops and NetBox, so that you can choose yourself what better suits you.

Stages of Network Automation

There are, from our experience, three stages that each company pass on the network automation journey.

Local executions and individual contributors

Normally it starts with the local initiative of some employees, which are either curious and are looking for ways to improve their work (or at least to experiment with new tools and technologies) or some new comers, who already participated in automation projects in previous companies. Such persons work on their own by building some tools locally, which are not productized properly. That means, that this automation will be able to work only from someone’s laptop or desktop, but anyone else wont be able to use it.

Shared environments and team contributions

I such local experiments have been successful enough, meaning there are some tangible results, other people starts being engaged in this process in two ways:

• first of all, they gradually start using the results of others job (e.g., if you created script, which generates a good report quickly, your colleagues may be using it to gather this data as well).
• afterwards, they may start contributing the automation tools back.

At the point, when others start using automation, it is important to ensure that all the users have the same user experience; therefore, the teams start building jump hosts, where the automation tools are installed with all the necessary dependencies and permissions, so that everyone, who needs to use the tool, can simply log to the host and to get the job done. The central automation hosts have other useful capabilities, such as logging of execution attempts, log storage of the automation’s execution and others.

Holistic network automation systems

Once the team have developed automation to the level that it starts making real positive impact on the operational processes, it typically arises the need to properly productize the automation. That requires the following questions to be answered:

• How to provide access to other people, which are outside of the team and, therefore, implicitly are not trusted?
• How to ensure that logs are available for accounting and security reasons in central repositories?
• How to integrate automation with other applications?
• How to ensure that the platform, where the automation is running is properly monitored and maintained, as it starts playing a crucial role in company’s operation.

The list of questions grows very fast, when the one starts thinking how to properly build and automate the system.

By the way, in Zero-to-Hero Network Automation Training we give you detailed advises how to transition between stages to be successful

Tools Used and Skills Needed in Network Automation

So far we haven’t talked at all about the tools you will use or things you need to know. The main reason for that is very simple: when someone starts with tools without vision and understanding what he or she wants to achieve and why, he/she becomes dangerous to production network and IT infrastructure in general. Having said that, we don’t discourage you to learn new things; learning new technologies and tools are important. However, it is imperative first to understand what you want to achieve and then to build a study plan.

From our experience of running Network Automation Trainings for more than three years and from the feedback from our students, the sensible way of starting journey in the network automation is:

• Learn solid Linux administration foundations. Automation tools are build in Linux and are executed in Linux. Seriously, no one develop infrastructure and network applications for Windows. As part of this journey you will familiarize yourself with various Linux tools including Bash and Git.
• Understand Linux even further by understanding Linux networking, virtualization and containerization. Besides that it is important for you to build labs and ensure they work properly, it will give a good understating how modern application are working, as sooner or later you will need to containerize your network automation tools, if you succeed.
• Build foundation with all data serialization formats, transmission protocols and framing used in network automation, so that NETCONF/YANG and GNMI/YANG become your natural choice and best friends for network automation instead of being alien and predator chasing you.
• Then it is a time to finally start writing some code. The proper configuration management tools, such as Ansible, Salt, Terraform can help you to get up to speed, so that you can getting some results.
• Once you are comfortable with tools, it is time start going further and use not only the code created by others, but start building what you really need. That would require you to start learning software development, at least starting with Python or Go. There is a huge amount of other programming languages, but these two are by far the most suitable for infrastructure automation (though, their capabilities are not limited by the infrastructure automation and you can do literally everything with their help.
• Finally you get to the point, where your software can be integrated with other tools via APIs, so you may start relying on NetBox and other tools, likewise exposing via API your own tool.
• … There is no “finally” in network automation, however. The next typical step is to choose a workflow engine, such as AWX/Ansible Tower, StackStorm, Apache Airflow, Temporal and others.
• Then you can start experimenting with data bases, such as Postgres or Prometheus and InfluxDB how to store and analyze the network data, how to correlate it and use it for making decisions in closed loop network automation.

Ultimately, the sky is the limit.

Many of these things together in a proper sequence and in right context you can learn in our Zero-to-Hero Network Automation Training.

Summary

Network automation is a journey: it can be easy and pleasant, it can be also harsh and draining. Therefore, in order to increase your chances for success and reduce efforts you put in automation, you shall create a good foundation for yourself first. With a good foundation, you will be able to properly develop the network automation tools and to progress in your career. Without this foundation, you still can be a network engineer, but amount of efforts and time you will be spending to many cases will be overwhelming. However, the time is the only truly finite resource that the one have in life. Take care and good bye!

Need Help? Contract Us

If you need a trusted and experienced partner to automate your network and IT infrastructure, get in touch with us.

P.S.

If you have further questions or you need help with your networks, we are happy to assist you, just send us a message. Also don’t forget to share the article on your social media, if you like it.

BR,

Anton Karneliuk