StableNet® Blog

Regular posts on all things StableNet® from a sales, techie, or marketing perspective

StableNet® Blog

Regular posts on all things StableNet® from a sales, techie, or marketing perspective


Robert’s Corner

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

Robert Bschorr Senior Technical Account Manager


Robert’s Corner

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

Automation Series – Part 5

Network Automation – Configuration Generation

August 5th 2021, Würzburg

This post is part 5 of Robert´s ongoing blog series about Network Automation. Please do not hesitate to check out the previous ones: Part 1, Part 2Part 3, and Part 4.

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

configuration management

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.

This is exactly what the StableNet® NCCM Configuration Engine and the Config Generator user front end provides: the ability to create device configurations from pre-defined resources from the outset in order to lay the groundwork for simplified, automated workflows well into the future.

Config Generator Workflow Introduction

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

Config Generator

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:

StableNet Automated Solution Table Graphic

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:

StableNet Network Automation Graphic
StableNet® also provides a Config Snippet Management system, which facilitates the handling and maintenance of the growing config snippet library.

Config Generator Workflow Revisited

After having applied all these parameters in the various building blocks, the final running configurations for selected (leading) devices are created in step 7. Those files can be either deployed directly to network elements or fed into other StableNet® network automation tools. 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.
Config Generator Portal

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.

Introducing the StableNet® network configuration and change management framework guarantees error free configurations, avoids time consuming trouble shooting and automates workflow processes. The complexity of today’s multi-vendor and -technology environment can benefit exponentially from efficiency increases in day-to-day business operations by freeing up valuable resources from repetitive tasks that have now become automated.

If you want to read more about Network Automation, you can check out previous posts on that topic: Part 1, Part 2Part 3, and Part 4.

Robert Bschorr

Senior Technical Account Manager @ Infosim® GmbH & Co. KG

Robert has been active in the network management and telco space for over 30 years and is a strong advocate of automated processes as a means of efficiency improvement, performance consistency, and optimized user experience. He currently focuses on developing techno-economical concepts with StableNet® as a vendor-agnostic Network and Service Management Platform for process automation in the field of network infrastructure for large-scale businesses and service providers.