Recreating customer SD-WAN networks as virtual twins in ~90 minutes instead of ~15 days

The challenge

Every customer may be running a different version of SD-WAN, including different features enabled on a different topology. Whenever a defect appears in one of those networks, engineers have to reproduce it. Also, when a new feature is ready, it has to be validated against something close to the customer’s real network before it gets deployed to production. Building those replicas by hand was slow and costly, and the more complex the topology, the longer it took.

What was at risk:

• Lengthy reproduction caused slower turnaround on customer defect resolution, features released without realistic validation, lowering confidence in the delivery

What we did

• Virtual Twin solution delivered through an intuitive, easy-to-use application with graphical network representation
• Rebuild each network from data the customer already has, its backup dumps containing network configuration, so nobody has to describe the topology by hand
• Replicate the whole network, transport side and service side, as a virtual twin on standard hypervisors instead of physical lab gear.
• Automate the conversion end to end, so creating a twin needs no manual steps
• Calculate the compute and server capacity a twin needs before conversion starts, so lab resources are reserved up front, not found short mid-build.
• The deployed Virtual Twin network is compatible with the client’s existing, custom test framework, so current automated tests can run against it.

How it works

The twin goes from raw customer data to a running replica that the client’s tests can use, in five stages.

1. Input The application works in one of two modes. In backup processing mode, the tool takes the customer’s backup files from the SDWAN controller, NMS. In graphical test environment editor mode, the user draws the network to be recreated in the virtual environment, adding nodes and the connections between them.
2. Topology model From that data, it rebuilds the full topology, covering both the transport side and the service side. The application reads the backup file and translates it to the virtual deployment tool input files. It can also trim a large input topology down to a smaller one: it suggests representative examples, recommends excluding devices with duplicate parameters, and replaces the duplicates with emulations. In addition to the SD-WAN elements themselves, the tool also creates virtual intermediate routers that simulate the WAN and provide the required set of connections, as well as routers on the access side and a server instance that enables traffic generation.
3. Capacity check Before conversion starts, the tool calculates how much compute and server capacity the twin will need. It then unfolds the topology onto an optimally calculated number of servers.
4. Deployment The twin is deployed as virtual machines on ESXi or KVM. The tool reserves servers from the pool and releases them when they are no longer needed. To keep traffic efficient, it places all elements belonging to one geographic location on the same server (for instance, in a non-redundant topology, SDWAN control plane elements share the same node), and it provisions the communication between servers. Typical deployment can take up to around ~90 min.
5. Testing The finished topology works with the client’s custom automated test frameworks or is used for manual testing and investigation. The tool also manages reports from the executed tests and sends notifications to users.

Code coverage. The application is also connected to an external service that collects code coverage information, and the coverage report is visible directly from the application.