The Use Case for the Network Configuration Generator

This post is part of the series “How to build your own Network Configuration Generator”. You find the overview about the entire series here. The last state of the code is available at the Network Configuration Generator GitHub repository.

Today I like to describe the target scope and use case that I plan to implement in the Network Configuration Generator. Furthermore, I like to describe the Integration and API capabilities that the tool provides. At the end of this post, I discuss some limitations and functionalities that are considered out-of-scope for the first version.

Zero-touch provisioning, the missing piece…

I think that Zero-Touch-Provisioning solutions are for quite some time a trend in the entire networking industry, because they provide a faster and less error-prone deployment of networks. The basic idea behind every Zero-touch-Provisioning solution is the deployment without any manual steps during the provisioning of a new or replaced network device.

There are many solutions available on the market for almost every area within the network (LAN, WAN and Data Center). Every solution in this area that I’ve seen in the past provides many ways, how to put a configuration to a device in a (sometimes) secure and automated fashion. The missing piece in almost every solution that I know is the configuration generation part, if you look for example on Cisco AutoInstall or Network Plug-and-Play.

If you ask the question about this topic, you’ll always get an answer like: “we will implement this in a later product version” or “we need to start somewhere, therefore we start with deployment process” and so on. Don’t get me wrong, it’s cool to attach a device to a network and after some “magic”, it’s running without manual intervention, but if I still need to create these configurations manually, it’s an incomplete solution from my point of view.

This tool should provide a solution for this part of the story.

The initial Use Case

The first version will be some kind of “next generation” mass mailing function for configuration files, as you eventually already use in Microsoft Word. It should run on your local computer (either directly on your OS or within a Vagrant VM), later on, it should also run on a central server. For this reason, I create a Web service from day one instead a Desktop tool.

The following diagram outlines the first use case for the Web service. I outline both versions in this diagram: the left side describes only the configuration generation process, which is completed with the download of the resulting configurations. The right side shows a possible integration with the Cisco APIC-EM Network Plug-and-Play solution. If you like to learn more about this solution, take a look at the Cisco APIC-EM Network Plug-and-Play Solution Guide.

In short, the following functions/requirements should be implemented within the first version of this Web service:

  • Upload a configuration template with any number of variables (variables are dynamically detected)
  • Bulk Upload of values using CSV or Excel templates (templates for the upload are generated within the tool)
  • Basic data structure: Projects that contains Configuration Templates that defines Value Sets that are used to generate the resulting configuration
  • The configuration should be downloadable file by file or as a ZIP archive
  • The template language must support if-then-else constructs
  • API access to the configurations should be possible (pull operations)

As already mentioned, the tool should run as a Web service, either on a local notebook or a central server. I plan to use this service through a central proxy server in the future, therefore all pages and resources should be reachable using a sub-path URL.

The Data Model

The following diagram outlines the high-level data structure within the Web service.

The Project is just a top-level data element to structure the data within the Web service. Within the Project, you define one or more Configuration Templates. These templates are the basic element for the configuration generation process. It stores the configuration template itself and the variable names that are used within the template. Every Configuration Template contains one or more Value Sets. These store the concrete values for the config template variables. the Value set and the configuration template itself are used to generate the resulting configuration.

The following list shows an example that I had on my mind during the creation of this Web service:

  • Project as top-level data element
    • Configuration Template for the edge router
      • Value Set for primary CE router
      • Value Set for secondary CE router
    • Configuration Template for Switches
      • Value Set for the primary aggregation/distribution switch
      • Value Set for the first access switch
      • Value Set for the second access switch etc.

You might note, that the resulting configuration is missing within the data model diagram. These should be created on-demand if they are required. I know that this adds some load to the server, but it simplifies the initial implementation and deployment of the Web service, because the tool doesn’t depend on an background task or cache engine. These features can be added in later versions.

Integration and API capabilities

The integration and API part is a critical part for the Web service. The first version should provide the following API endpoints:

  • lookup/search of a host configuration within a specific project (convert the hostname to the ID)
  • claim a configuration for a host (based on ID)

From an integration perspective, it is possible to bundle the Web service with an FTP or TFTP sever to provide the configurations to the network. Another possible integration scenario, which is already part of the use case diagram, is the connection to the Cisco APIC-EM controller to push the configurations into the Network Plug and Play feature. The details about this integration option will be discussed in a later post of this series.

Limitations and out-of-scope topics

As always, there are some compromises associated to the first version of such a tool. The following functions are initially out-of-scope:

  • Complex variable sets (including dictionaries and lists)
  • User authentication and permission system

The primary intention is to give a small group of users a lightweight Web service to generate configurations, therefore I skipped the entire user authentication and permission system. To ensure a basic level of security and control that access the service, you can use HTTP authentication on you web server as an alternative.

As already mentioned in my blog post about the Configuration Generation with python and Jinja2, one-level variables doesn’t scale very well. I believe that this feature is required in more advanced Use Cases, but I won’t support this kind of data structures in the first version. Right now, I have no clue how to implement it, but maybe I get an idea during the coding work within the next weeks.

Conclusion

Okay, I hope you now got an idea what the solution should accomplish and what not. It sounds more complicated than it really is as you seen in the other posts of this series. I’m currently a little bit ahead with the implementation of this Web service, as you can see on the Network Configuration Generator GitHub repository. I already added the basic Flask and SQLAlchemy code that should be discussed in the next post of this series.

That’s it for today, thanks for reading.