Network Engineers create and operate prototype networks all the time. Prototype networks are used to validate designs, test features or changes, troubleshoot use-case scenarios, and often just for learning. Typically, pre-prod testing environments are set up in such a way that device host names, attributes, configurations, IP assignments, software versions, and topologies are mostly inconsistent with production environments. This inconsistency is counter-intuitive, considering that accurate design validations should closely match reality to avoid any mistakes when deploying in production.

Cumulus Linux can run as a virtual appliance, allowing network engineers to build to-scale virtual networks for activities like modeling changes and performing validations, while opening the door for similar DevOps methodologies application developers have operated with for years: validated testing before deploying in production for continuous integration.

Enter Cumulus VX

Cumulus VX (Virtual Experience) is a Cumulus Linux virtual appliance. You can test drive Cumulus Linux on a laptop, while those fluent with Cumulus Linux can prototype large networks and develop software integrations before deploying into production environments.

Cumulus VX is a platform — just like Cumulus Linux on a real switch — and therefore is designed to perform just like an actual switch running Cumulus Linux. Every feature you could run in production could also run virtually in Cumulus VX without the concerns of supported functionality.

For example, virtual appliances typically use artificial port numbers that don’t match the actual interface IDs used in production. Cumulus VX is unique in that it allows you to customize and reuse the exact configuration that’s used in production, including the exact interface IDs. Developers at Cumulus created a tool called Topology Converter that generates virtual topologies using the interface IDs you specify in the topology.dot file.

Deploying a Cumulus VX is a breeze. Just download the appliance and import it into your hypervisor of choice, such as VMware, KVM, Vagrant, or VirtualBox.

Building the Prototype Network using Cumulus VX

Ideally, the prototype network should match the production network as closely as possible, even if the production network is only in the conceptual stage and has yet to be deployed. Assuming you’re already running an extensive network with Cumulus Linux, configurations and topologies can be gleaned to generate templates and build the entire environment virtually using Cumulus VX. Automation tools such as Ansible or Puppet can aid in pulling production configuration and essential state information for replicating in the prototype environment.

Vagrant can be especially helpful with provisioning the environment and bootstrapping essential components. Likewise, Open Network Install Environment (ONIE) is supported with Cumulus VX, meaning you can do Zero-Touch Provisioning (ZTP) just like you would in production.

Cumulus VX releases are in sync with Cumulus Linux releases, meaning you can model the prototype network using the same version of the code. Keep this in mind as you start to think about testing changes, such as code upgrades, in a prototype network before deploying to production.

If the network is too vast to replicate fully, consider only prototyping a single pod or sub-set of pods rather than all of them. (It’s worth noting, though, that each VX instance requires less than 1GB of RAM and can span servers, allowing for very large topologies.)

Automated Testing Using Prototype Networks

Deploying configurations is a basic functionality of any automation tool. However, if we are to get to the stage where changes in prototype networks are then deployed in production networks, we need a way to perform reliable testing.

Cumulus NetQ is a telemetry solution that production Cumulus networks utilize. It significantly simplifies the validation process, allowing engineers to execute numerous complex tests without having to write additional code.

Cumulus VX comes loaded with the same NetQ agent as production Cumulus Linux, making it easy to leverage your production NetQ Telemetry server to execute tests in the prototype network. Proposed changes get deployed in the prototype environment and automatically tested; after being deployed into production, they’re tested again with the same NetQ scripts to validate that the deployment executed as intended.

Alternatively, consider incorporating automated testing with tools such as Ansible, or frameworks such as Robot Framework, which integrate well with CI/CD pipelines.

Moving the Prototype Network to Production

The goal, conceptually, is taking a prototype network and moving it to production. However, it’s not quite as literal as that. Thinking in terms of code rather than networking, what you need is a way to deploy or patch production “code” based on the successful deployments and validations evident in the test environment codebase, similar to the way applications are developed and deployed.

It’s standard, accepted practice that application developers have performed rigorous testing before deploying client-facing software changes. Network engineers can adopt similar methodologies, deploying changes in a prototype network and executing validations to provide confidence that the proposed change is successful in production.

Using Ansible as an example, you could write abstracted and agnostic playbooks, executable in both the test environment and in production. Say, for instance, you need to deploy some new tenant VRF into the EVPN fabric. A simple playbook can execute the change in the prototype network, followed by automated testing using NetQ. The results published into a change ticket or CI/CD pipeline. Upon approval of the change, the same playbook used to execute the change in the prototype network is used to execute the change into production, followed by the same validations to ensure intent. This workflow is essential for intent-based networking.

Get That Peace of Mind

Validating intent provides peace of mind. By prototyping production networks and performing rigorous unit testing and change validation, the network becomes elevated to a standard far superior to the traditional approaches of finger-in-the-air testing that often results in shrugged shoulders and embarrassment when changes go awry. Test out some of these ideas by spinning up an environment in the cloud, or building your own prototype lab today, referencing some of the GitHub demos.