Super-NetOps Source of Truth

F5's Super-NetOps delivers network-based services as programmable infrastructure to support DevOps practices and methodologies.

At 2018 F5 Agility in Boston, attendees had access to both education and inspiration around technologies that will continue to drive business.

One technology focus at the forefront of the event was a greater adoption of infrastructure automation and declarative, intent-based networking. This emphasis aligns with F5's Super-NetOps.

I had the pleasure of leading a breakout session on-site at the conference, where we examined how the role of an infrastructure engineer will evolve under the Super-NetOps service delivery methodology.

Imperative Configuration Management

There are currently two models network engineers use for automation configuration and deployment: imperative and declarative. The imperative configuration model has been used by engineers to configure infrastructure devices for over thirty years.

Imperative means expressing commands (using a GUI or CLI) to enter the syntax for multiple configuration objects, enabling a service on the device. The syntax and familiarity with the vendor's implementation of the service is so critical that a certification industry has evolved to validate the engineer's skillset with the device commands.

Declarative Configuration Management

With the other approach, declarative (or intent-based networking), the actual commands required to enable the network service are implemented in code. The engineer responsible for implementing the service maps the input variables to the arguments of the module (or SDN controller) and specifies what role or group of devices are targeted for the change – then executes it.

In this model, the command syntax to configure the device is abstracted, the details of how to implement a service are defined by the developer of the module or controller. The infrastructure engineer is now focused on what services are enabled, but the specifics of the how are less important.

With declarative, intent-based networking, the infrastructure engineer has expanded responsibilities. Managing and manipulating the input data, or the source of truth, becomes a critical component.

For more information about declarative configuration management and NetOps, check out this article from F5 Networks.

Focus on the data

There should be only one source of truth for every configuration artifact. These inputs need not come from the same place, but for any input, there should be only one authoritative source.

With the declarative model, the role of the infrastructure engineer is now that of a systems analyst: employing structured design and analysis techniques to describe enabling a network service as process models and data models. The process model describes what programs manipulate the systems in the workflow. The data model is generated by user input to a ticketing system, along with pre-defined data models, of the target environment.

The modern infrastructure engineer must focus on how the input data is stored, maintained and updated to create and define services on infrastructure.

About the demonstration

In the Super-NetOps methodology, multiple work centers are consolidated into one service delivery workflow. I used the video below to illustrate using a consolidated source of truth for both creating virtual IPs (VIPs) and updating the policy on a firewall. See how ServiceNow, Ansible Tower and a MongoDB manage the developer request for firewall rules to expose the IP address and ports for an F5 virtual IP (VIP) for a new application.

This video illustrates using a consolidated source of truth for both creating virtual IPs (VIPs) and updating the policy on a firewall

To enable this service, data describing the F5 BIG-IP local traffic manager (LTM) configuration is combined with supporting meta data stored in a MongoDB. Using an API call to Ansible Tower, the firewall is configured based on a reference to the database, collection and document identifying the configuration artifact.

To enable auditing, the playbook stores the initiating metadata along with the device configuration following the change in an audit database, and updates the Service Now change request with a pointer to the audit documents. As additional firewall changes are made over time, the audit database can be used to create a report of changes made to the firewalls along with the authorizing change request number.

Outcomes realized

The key points of this demonstration include:

• The configuration artifacts enabling the F5 VIP creation are also used to open the ports, protocols and IP address on the Internet edge firewalls.
• An audit database is used to document when and what changes occurred, on what devices, and the state (running configuration) of the devices following the change.
• The source of truth (the input data) is combined with defined processes, using the knowledge and experience of the Super-NetOps engineer, to create services to support the business requirements.

To learn more about building automation into your process, check out this workshop.