Architectural Implementation

The tool has four main components, mentioned below. The interface between the components mentioned below is REST.

Frontend (GUI)

The Graphical User Interface (GUI) acts as the frontend for the tool which users directly interact with. The frontend provides a simple wizard workflow to the user. The user is able to upload their Cisco IOS XE config, modify it (if required) using CLI view in the frontend, validate it to view unsupported features in the config, and convert it to device template format for vEdges. The user has the option to modify the template config to add variables in it before downloading it to their machine or posting it directly to vManage. Users can then attach their vEdges to that particular device template from vManage UI.

The UI has been developed using Angular 5. Angular is a complete solution for rapid front-end development and helps create efficient single-page applications (SPAs) which are gradually becoming the industry standard. It relies upon REST APIs which are used by the frontend to communicate with the API server. Due to its extensive support, RESTful client-server communication is commonly used in the industry.

API Server

The API server acts as a bridge between the Frontend UI and the backend tools used to validate, convert, or translate the user provided configs. The frontend invokes API server for all user driven events. Any action performed on the UI will generate an API call to the API server. The API server will then handle this call and perform the relevant operation.

The API server has been implemented using Node.js. With an increasing pool of accessible packages (libraries/modules), the event-driven system followed in Node.js is extremely useful when handling multiple requests simultaneously. Node.js provides major speed advantages using Google’s V8 engine, optimized for JavaScript. Moreover, its asynchronous and non-blocking nature provides major performance benefits. In recent times, Node.js has become an industry standard for API server development.

Database

MongoDB is used as the database for the tool. It contains records of users and all their workflow transactions, configuration files saved from each step per user workflow, current state of the user, and other data required to fulfill the functionality of the tool.

Backend Tools

The backend has been implemented using multiple tools such as CiscoConfParse, Cisco NSO, and Cisco feature template generator tool. These tools provide users with a dynamic, programmable infrastructure to allow model-driven network configuration, management, and operations. The API server translates calls from the frontend to these tools.

The backend implementation uses a combination of Bash and Python scripts to enhance upon the current feature set provided by the afore-mentioned tools in order to fulfil the requirements for the project.

CiscoConfParse

CiscoConfParse is a Python library that reads an IOS-style config and breaks it into a set of linked parent / child relationships. The parent-child objects created by the library can be used to build queries or create specific logic to process and consume the input configuration.

SD-WAN Conversion Tool uses CiscoConfParse to parse the config shown to user in the UI text editor and pre-process it for validation. In order to avoid conflicts with an incorrect config, this process occurs for every screen which has a text editor that provides users with the option to edit or modify the configuration. This ensures that the config being processed by the tool at any given time is syntactically and logically correct.

NSO Backend

The backend for SD-WAN Conversion Tool has been implemented using Cisco Network Services Orchestrator (NSO). NSO is an industry-leading software for automating services across traditional and virtualized networks. It provides comprehensive lifecycle service automation to enable developers to design and deliver high-quality services quickly and easily.

_images/NSO_Backend.png

Figure 1. Architectural diagram of SD-WAN conversion tool

NSO also provides a single network wide interface for all network devices and services as well as a common modeling language and data store for both services and devices.

Following elements of NSO have been used for the SD-WAN Conversion Tool.

Network Element Driver (NED)

NSO uses Network Element Drivers (NEDs) to communicate with the devices. NEDs are not closed hard-coded adapters. Rather, the device interface is modeled in a data-model using YANG (RFC 6020). NSO can render the underlying commands from this model, including for example a Cisco IOS CLI. This means that the NEDs can easily be updated to support new commands just by adding these to the data-models. NSO in combination with the NEDs will apply device configuration changes as atomic change sets.

NSO netsim is used to simulate devices. Netsim can simulate management interfaces like Cisco CLI and NETCONF. It does not simulate the network behavior.

_images/Network_Element_Driver.png

Figure 2. NSO - NED communication

To implement the required functionality of SD-WAN Conversion Tool, comprehensive device packages for Cisco IOS XE, cEdge, and vManage have been created in NSO.

Service Package

The service package is an external application that can be installed into NSO as a plug-in. It provides two distinct features to SD-WAN Conversion Tool:

  1. Evaluate whether certain network configurations in Cisco IOS XE can be supported by vManage
  2. Map the supported features from Cisco CLI to vManage configuration for conversion process

Each service package constitutes of three elements that are designed to implement these features. These elements are explained in detail below.

Service Model

The service model is a collection of network configurations that are common between all devices connected with NSO. For example, in our use case there will be two network devices connected to NSO; cEdge and vManage. The service model will be designed to emulate services that are common between both these devices.

The service model is written completely in YANG and provides NSO the details for service requirements.

Service Template

The service template provides us with a skeleton of how properties of services defined in service model will be implemented in southbound device. For our use case, since the cEdge Tool is converting configuration from Cisco cEdge to vManage, this skeleton contains parent child relationships of network commands understood by the vManage NED.

Mapping

This element provides the actual implementation from service model to service template. Mapping can be done in three ways.

  1. Direct mapping from model to template
  2. Mapping with combination of Java/Python code and template
  3. Mapping purely done in Java/Python, no template required

SD-WAN Conversion Tool uses the mapping combination described in point 2. The service model contains service hooks that trigger Python code as soon as NSO creates a service. The Python code pulls values from source NED and plugs them into the service template. Once all the services have been mapped to their respective service templates, we apply those templates to destination NED.

The following block diagram illustrates the steps that are executed by Service Package.



_images/Service_Package.png

Figure 3. Workflow executed by Service Package

The example below illustrates mapping of interface from IOS-XE to SD-WAN.


_images/Interface_Mapping.png

Figure 4. Interface mapping from IOS XE to SD-WAN

Cisco Feature Template Generator

This tool primarily consists of Python scripts that were initially developed and provided by Cisco team and then modified extensively by Xgrid team for use in automated deployment frameworks.

It is responsible for converting SD-WAN XML configuration into individual feature templates that are created in vManage (using the provided credentials) and then attached to a specific device template generated for each complete user workflow.