StableNet^® Blog

Network Automation Insights

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

Network Automation – Configuration Generation

August 5^th 2021, Würzburg

Remember part 3 when we looked at network automation market perspectives? Eventually not, because it was published quite some time ago. No harm if you dial back in, but here’s a quick summary:

Whilst the market considers “network configuration and change management” (NCCM) an equivalent to “network automation”, the StableNet^® platform provides a much wider application framework which offers automations for discovery, inventory creation, backup & restore, configuration change, policy & compliance checking, common vulnerability exposure & lifecycle management and workflow & business process automation, to name the most important ones.

In this blog post, my focus will be on technical concepts for network automation when using the entire StableNet^® NCCM toolkit as well as the value of optimized configuration generation.

Configuration Management Toolkit

Most market contenders do not cover the above outlined array of functionalities for configuration management. They start their “network automation journey” with the prerequisite that an operational configuration is already in place which needs to be deployed or modified.

But where do you start if that is not the case? By ringing up the network engineers (who are most certainly not sitting “idle” in their offices awaiting a call to get going on the task)? Chances are that folks won’t even pick up the phone as they are busy and have other important things to cover, with enough priorities and time pressure to worry about.

Smart people may have taken care in advance and constructed several home-grown configuration generation scripts. However, even if those work for them, they probably only cover a single vendor and specific models, do not have an underlying resource database, miss an easy-to-operate GUI, and lack sanity checks to ensure that all required unique local parameters are considered with correct syntax. Essentially such scripts are very limited and not meant to be universal configuration tools, which were optimized to present a minimum of site-specific inputs, thereby avoiding misconfigurations by the end user to warrant error-free configuration file-creation in all circumstances.

The smartest architects however saved their valuable development time and leveraged a pre-built configuration generation tool that has all the aforementioned building blocks in place. Such a solution can be equipped with data models and parameter sets right at project start, whilst the underlying workflow process is kept very flexible for adaption to individual configuration requirements.

Config Generator Workflow Introduction

Let’s explore the “mechanics” and the associated workflow for Config Generation:

The below outlined steps are required prior to using the Config Generator.

• Creation of resource pool definitions (data model; essentially database tables)
• Definition and collection of available configuration data input sources
• Creation of resource pools (the associated parameter set repository

Those are illustrated in the workflow diagram under step 1 (prerequisites).

Resource Management

The concept of resources and resource pools refers to relational databases. A resource pool definition determines which properties modelled devices have and translates this to a table definition. The resource itself is a concrete instance based on a resource pool definition, for example a virtual model of a networked device (e.g. a distinct switch or router type).

Every resource belongs exactly to one resource pool and refers to a single record in a specific table. The resource pool itself is a collection of resources which contains all available instances of the same resource pool definition. For example, a resource pool named “New Building“ may include all devices which are pre-planned to be deployed in that location. These resource pools are database tables and contain actual data sets.

StableNet^® resource management has resource pool definitions with resource properties. The resource pool definition management gets populated from the outset with predefined resource pool definitions to facilitate the starting point. The inbuilt resource pool management organizes resource pools.

Project Management

One primary application for resource management is the automated creation of device configurations. The entire configuration generation process uses distinct resource pools which are organized into projects.

Projects are created and then linked to resource pools. The projects are finally executed in the web-based Config Generator, which is the graphical interface the end user interacts with.

Below is an example of a project that demonstrates associated data sets which were previously defined by a network architect:

Before a project is executed, resources and global Job inputs (if the Job templates contain <input> elements) can be specified. Thus, Config Generator is able to run the same project for different combinations of resources and job inputs. There can be several project runs for the same project at the same time. A project run can have three states:

• Open: Every project run starts in this state. While in the open state, changes can be made to the assigned resources and jobs. Most of the functionality of the Config Generator concerns open project runs.
• Finished: Once a project run is in finished state, all workflow steps have been executed and the configurations have been created. In this state, project resources remain either blocked or get released (assuming they are defined for multiple use). At this point, the specific project run cannot be changed anymore.
• Error: The error state denotes that one of the project steps failed. An erroneous project run can be converted into an open project run by fixing the problems and repeating the steps that previously led to that error.

Configuration Job Engine

Now that we’ve covered the underlying data model and the nature of project runs, we get back to the workflow diagram of Config Generator. Step 5 in the job input section involves executing the template-based configuration job in order to build complex command structures. The template can be created with powerful XML syntax to implement the required logic and allow predefined jobs for recurring tasks.

Templates contain name, description, version, optional lists of input elements, validation elements, global variables, and lastly a command sequence element to define the execution. Commands can contain placeholders that will be replaced by referenced values. Placeholders are necessary to reference input parameters or environment variables.

The XML template leverages config snippets, which are software configuration extracts used by network equipment. These modules are able to master different configuration complexity levels when used for checking or configuring network devices. CLI commands, which are contained in snippets, are either directly executed (simple) or enriched with input variables for more generic and thus flexible usage when queried by templates.

For configurations and policy checks, it is possible to define different config snippets that are using the same name and thus allow a group of snippets to do checks for specific situations on different network equipment.

For example, one snippet can be designed to apply to Juniper devices and another one – with the same name – works on Cisco nodes only. However, both are used for a similar configuration function. This is achieved by setting device filters, which ensure the correct match between different config snippets that have the same name but contain another syntax for specific vendors or device models. Essentially the filter determines, which snippet is going to be used.

The below diagram visualizes input and output options for snippets and templates as building blocks of the configuration job engine:

Config Generator Workflow Revisited

The configuration engine provides very flexible options for engineers to build complex configurations with the objective of simplifying and automating specific tasks in the field.

An end user in contrast will never get in touch with any of those mechanisms, as the Config Generator front end GUI hides them. The recorded project run gives an impression and overview of the entire workflow process, which in turn creates specific configurations that are fed into end user outputs.

Conclusion

The StableNet^® Configuration Engine is designed as a generic tool that can be adapted to a wide array of different technical requirements and scenarios. This translates into both an optimized and automated network configuration workflow.

For the end user, the complexity of network configuration has been translated into a user friendly and straight-forward process. The StableNet^® Config Generator provides a web-based graphical front end that is easy to handle. Resource & project management, snippet & job management and a powerful XML template logic facilitate setting up device configurations from the outset with a minimum of site-specific input parameters.

Config Generator file outputs can be deployed directly in the network and used by additional automation tools like multi-vendor zero touch provisioning, policy checks & compliance and workflow & business process jobs.