Network Automation Insights

Stay tuned and keep informed with our blog series about the future of automation in network and service management

Network Automation – Market Perspectives

May 20^th 2021, Würzburg

Now that all of the Easter eggs have been found, business is back to normal and operations are once again in full swing. Unfortunately, the status quo all too often for network operators is based on the following principle: “the squeaky wheel gets the grease”. And while the time may be ripe to take up a new project for the stepwise implementation of network automation, where is the best place to start?

Let’s look at some definitions first to qualify market perspectives and discuss promising approaches.

What is Network Automation?

Networks are never static. A common theory suggests an approach that consists of “plan, build, run” but the reality in operations is that the focus is more on configure, monitor and troubleshoot.

In many cases diverse sources of “truth” (e.g. popular programs from the MS Office365 suite) are complemented by scripts and, in the best case, a network documentation management system. These are typical “engineering tools” to master everyday network challenges.

There is a high likelihood that the various decentralized documentations are dispersed across multiple departments and most likely out of sync due to continuous changes which are invariably required to run the network. Furthermore, operators are at the mercy of network engineers who are implementing their individual best practices in the production system (which entail a degree of variance from the original plan).

Smart people scout for tools to automate specific network deployment aspects and thus make their lives easier, often turning to the Open Source community. In turn, skilled network engineers cobble these tools together and combine network element CLI scripts, Ansible playbooks and Python programs to orchestrate an entire rollout.

When using this approach, the network automation solution definition reads like this:

“A key component of network automation is the conversion of network configurations to code… and the ability to abstract configurations while using a machine to push commands and templated configuration through a continuous integration/continuous delivery (CI/CD) pipeline.”

Cited from John W. Capobianco – Automate your Network

“A key component of network automation is the conversion of network configurations to code… and the ability to abstract configurations while using a machine to push commands and templated configuration through a continuous integration/continuous delivery (CI/CD) pipeline.”

Cited from John W. Capobianco – Automate your Network

To implement such a framework, you essentially need software developers for the coding part, network engineers for the configuration portions and database experts to reliably store this information together with versioning.

Ansible (now Red Hat) defines its role for the network portions as follows:

“Network automation removes the manual steps necessary to manage networks—such as logging into routers, switches, load balancers, and firewalls to change configurations by hand before logging out. Network automation relies on chained scripts programmed at the command-line interface (CLI) level of an operating system (OS) or prepackaged automation software.”

“Network automation removes the manual steps necessary to manage networks—such as logging into routers, switches, load balancers, and firewalls to change configurations by hand before logging out. Network automation relies on chained scripts programmed at the command-line interface (CLI) level of an operating system (OS) or prepackaged automation software.”

Ansible concepts are quite powerful and have their origin in IT automation. This becomes more apparent once you begin to delve deeper. The definition reveals an emphasis on spinning up virtualized networking functions (VNFs) and equipping them by help of associated onboarding scripts with predefined configurations. Apart from deployments on top of hypervisors (NFVi) or public cloud platforms, your network automation strategy also needs to include hardware appliances, which still represent the lion’s share of deployed network infrastructure.

The proposed automation methodologies rely on the creation of a centralized Ansible playbook repository, the implementation of a branching strategy with an authoritative master, and the leveraging of GitHub for forking code commits. The next step is to work on a playbook library to gather accurate network information from the production network. Next, you must define configuration change and troubleshooting scripts to master and orchestrate the entire rollout.

Oh! And you also mustn’t forget to take care of life-cycle information (EoX) and common vulnerability exposures (CVE), because compliance and security requirements have to be met for the installed base.

Over time, and with a deeper analysis of the actual workflows required, the flexibility of Ansible reaches its limits because network configurations require numerous user-defined parameters. Python nowadays has become the add-on tool-of-choice meant to save the day. Programming tends to be use case driven and specific to a certain application, project or functional domain. In turn, there is a substantial risk that the end result looks more like isolated pieces of an ever growing script and program puzzle, which uses a variety of different methodologies to solve the identified problems. The result is a list of ingredients that do not work together as an entity. However, exactly this would be the prerequisite to evolve into a more holistic automation platform.

The issue of support is yet another challenge for the entire script framework. Scripts tend to lack documentation and are usually only maintained by their originators (best-case scenario). In the case of employee turnover and attrition, code bases and playbooks become unsupported, outdated and stop working.

Does implementing such a framework sound complex? No question – that’s exactly what it is!

StableNet^® Network Automation Ingredients

It is important to keep in mind that StableNet^® addresses the increased heterogeneity and technological diversity of networks. This also targets the integration of deployed cloud, datacenter, core, edge, access, IoT and legacy assets into a single source-of-truth database to monitor all those infrastructure assets from a single pane of glass. Quite the accomplishment, indeed!

At StableNet^®, we define Network Automation for a multi-vendor environment as:

“The StableNet^® umbrella is a vendor-independent, cross-technology solution for holistic network infrastructure automation with service management in a platform that scales.”

“The StableNet^® umbrella is a vendor-independent, cross-technology solution for holistic network infrastructure automation with service management in a platform that scales.”

Quite the mouthful, but there is a lot of important information contained here. Every network automation journey starts with powerful automations in the discovery engine and later expands into a wide array of possibilities for automating workflows of various applications in different areas.

Without a doubt, your most recent deployment will not be your last and there is significant return when investing into Network Automation for associated tasks. As the market considers “network configuration and change management” (NCCM) to be an equivalent to the term “network automation”, we should get back to that particular application and focus on individual aspects and capabilities of StableNet^® for the sake of comparison.

If you want to avoid tool-chain developments from scratch, StableNet^® already offers a pre-built application framework for your requirements in NCCM automation, which are outlined in the table below.

But StableNet^® does not stop here; it complements those NCCM capabilities with a Configuration Generator that combines predefined configuration building blocks (snippets) with site-specific parameters from different originating sources. The web GUI guides the operator through the entire workflow process, which we have termed “runs”. This facilitates customization tasks tremendously and does not require engineering experts to create valid running configuration outputs, which are ready to be loaded into network equipment.

StableNet^® can also take configuration deployment to the next level of automation with a vendor-independent zero touch provisioning solution to support mass rollouts for greenfield and brownfield scenarios.

Without a doubt, the above are quite advanced and demanding network automation applications. Whether or not such an implementation provides a return on investment for you highly depends on your specific operational requirements and tool sets that are already in place.

As a starting point for almost every network, we recommend automating inventory creation by leveraging the StableNet^® discovery engine in order to build a reliable single source of inventory truth in the database.

After creating that baseline, a stepwise approach is best. You can take everything else from there at your own pace and develop individual workflow process automation tool chains by using pre-built modules that can be flexibly added to the StableNet^® platform.

In the next installment, I will discuss the aforementioned “starting point”, namely, Automated Discovery. It is the foundation for a unified, automated network and service management solution for multi-vendor and –technology infrastructures and paves the way for countless simplified workflows and powerful customization opportunities.