7. Enterprise Integration

Ultra Config may be integrated with any other IT system that supports HTTPS APIs. In this section, we'll discuss the conceptual components required to build a scalable enterprise-grade architecture for network automation.

First, click on the diagram below to take a look at the key components and steps. We'll then go over each step.

7.1 Workflow Triggers

All automation workflows require a trigger to kick off the job.

A trigger can be any kind of event. Here are several examples.

Customer Action - A workflow could trigger each time a customer places an order through a self-service portal.
Administrator Action - A network change could trigger each time an administrator gives approval in a change-management process.
Time - A cron job could trigger each day at midnight to collect statistics from network-infrastructure.
Zero Touch Provisioning - A CPE such as a customer edge router could trigger provisioning when it comes online for the first time.

7.2 Orchestration

Once triggered, orchestration software will begin to execute the workflow.

In a complex workflow, tasks need to be automated across multiple systems, applications, and services. The coordination of these tasks is handled by orchestration software.

In our network automation architecture, the orchestration software manages four primary tasks.

Listen for triggers to commence the execution of a workflow.
Retrieve network metadata from an inventory source.
Generate network configuration using Ultra Config REST APIs.
Push configuration to network devices using protocols such as SSH, NETCONF and RESTCONF.

Ultra Config is agnostic to the orchestration tools chosen by a user. As long as the tool supports HTTPS APIs, it will be compatible with Ultra Config.

Here are a few popular tools and frameworks that may be used for orchestration.

Ansible Automation Platform and Ansible Tower
Backend frameworks such as Django, Spring Boot, ExpressJS, etc
SaltStack
Nornir Automation Framework
Node-RED
BMC TrueSight Orchestration

7.3 Network Inventory

Orchestration software will require knowledge of network infrastructure. For a scalable solution, this data should be sourced from a dynamic inventory source to avoid manual management.

Ultra Config is agnostic to the inventory source chosen by users. Here are a few examples of common inventory sources.

Databases such as MySQL and MongoDB with workflows developed for record management. For example, ZTP technology could be leveraged to automate the creation of a record when a CPE comes online.
Auto-discovery tools such as Infoblox Network Insight

7.4 Generating Configuration

So far, we've discussed triggers, orchestration, and inventory. At this point, the orchestration software will know what action it needs to perform and the infrastructure it needs to perform that action against.

Before the workflow can complete, however, configuration will need to be generated if the action involves a config change.

This is where Ultra Config comes into the workflow. Ultra Config abstracts away complex config generation through a simple API.

Let's take an example. Imagine a user submits a job to update a network device through a portal. The configuration required to reflect this change in the network can vary immensely. Here are several examples of variables that may modify the configuration required.

Vendor & SKU - Different equipment manufacturers and device models have their own syntax and YANG models.
Software Version - The syntax and YANG models of network devices can even vary between software versions of the same device.
Action Types - The configuration will be entirely different depending on the action type. For example, does the user wish to provision an Access Control List or a VLAN interface or a DHCP server?
Deployment Data - Configuration is different for the same action type and device when the deployment data changes. For the VLAN interface example, the configuration will vary depending on the VLAN ID being provisioned.
Business Rules - Edge cases frequently require the need for business rules and conditional logic during the generation of config. For example, vendors don't all support the same feature sets. Business rules provide the granular control needed to roll out a scalable solution.

Config generation can be managed through basic lookup tables when a network is small. But as networks grow, a powerful config generator becomes a necessity.

Ultra Config Generator allows users to build powerful configuration templates using the "Jinja2" language.

The orchestration software will then only need to provide input data when invoking the API. Ultra Config will generate the required configuration and return it to the orchestrator.

7.5 Pushing Configuration

After configuration has been generated, it is ready to be pushed to network infrastructure.

Many protocols and methods exist for remotely pushing configuration. Support will vary between network devices. Here are some common protocols and methods.

CLI (Command Line Interface) - A CLI session can often be established over SSH. Libraries like Netmiko are supported by frameworks like Ansible for this approach.
NETCONF & RESTCONF - NETCONF & RESTCONF are good protocols for automation due to their strict compliance with well-defined YANG models. Any HTTP client will be compatible with RESTCONF and libraries like "ncclient" will support NETCONF. And once again, frameworks like Ansible will support this approach.
HTTPS APIs - Many vendors now build HTTPS APIs into their network devices. Nearly all orchestration software will support this approach.