Mike Kiev - Fotolia
Service providers and enterprises often ask how to start their transitions to software-defined networking (SDN). In particular, they want to know how to deal with traditional networking devices they're not ready to upgrade or replace. The good news is that DevOps and orchestration tools have officially made their way into the networking world. So, even though orchestration and SDN are not one and the same, orchestrating changes across traditional networking devices is a viable option to start the journey to SDN.
With that option in mind, let's look at how to use Ansible's free software platform, YAML's human-readable data serialization format, and Jinja2's templating language to solve the real-world problem: orchestrating quality of service (QoS) changes across a traditional network for real-time applications like voice and video.
Historically, there's no shortage of complaints about the complexity of managing QoS. Providers often find it too onerous to manage in real-world deployments because QoS changes require strict discipline and planning to ensure consistency across the infrastructure. In large networks, implementing these changes is a time-consuming burden. But the tried-and-true bandwidth solution of over-provisioning the network isn't an option in all scenarios, so video and voice QoS becomes the necessary choice.
Ansible's role in network orchestration
Solving the orchestration and configuration consistency issue can be achieved with Ansible, as well as some supporting technologies.
First some background. Ansible is an open source orchestration tool that allows engineers to create playbooks -- which are YAML files -- to define the desired state of the infrastructure. Ansible typically uses Secure Shell (SSH) devices. This allows network engineers to start using the tool without significant changes to the underlying gear. Ansible uses NetConf over SSH to deploy some desired QoS configuration changes.
Let's look at a sample scenario to see Ansible in action. Perhaps a customer is providing a temporary live video feed and needs the network to temporarily support and ensure delivery of additional voice and video traffic. If this were a highly visible project, the customer might want to orchestrate some QoS changes throughout the network to ensure delivery. The illustration below represents our sample customer network. With a four-router network and an Ansible workstation, we can execute our required configuration changes via an Ansible playbook. The IP addresses in the illustration below are the management IP's that Ansible will use to connect to each device via an out-of-band network.
To get our simple orchestration system up and running, we need to complete three items defined below. First, we need to create a YAML file defining the new data that can be used in our network configurations. Namely, we need to increase the allocated data transmit rate and buffer assigned to voice and video. Second, we need to create a Jinja2 template that can be combined with our previously created YAML file to automatically produce a new QoS configuration. Finally, we need to create an Ansible playbook to automatically produce our network configurations and deploy them to each router in the network.
Let's start by illustrating the YAML file defining the bandwidth allocated to voice and video. In the file below, we essentially have some variables allocating 10 percent of the link's transmit rate and buffer to voice, and 20 percent to video.
For those new to YAML, it is effectively a data serialization language. In this example, we are using YAML to define how much bandwidth to allocate to our real-time applications. This file will be used by Ansible, along with Jinja2 to produce our updated QoS configurations.
Remember in this example that we need to allocate more resources to support additional video and voice QoS. Suppose an additional 5 percent of buffer and transmit rate is required for each type of critical traffic. We can update our YAML file and increase the allocated resources. Note that for those thinking ahead and wanting to ensure we can rollback any changes, it would be wise to back up the original YAML file in a version control system.
Now to step two. The Jinja2 template models part of the video and voice QoS configuration of our network devices. Note that Jinja2 is a templating language typically used with Python. Templates are nothing new to network engineers; often, common configurations are templated using text files, Word documents or spreadsheets. A benefit of using Jinja2 as shown below is the ability to integrate Jinja2 templates with Ansible playbooks and our previously created YAML file to automatically produce updated QoS configurations for our network devices.
Now on to the Ansible playbook, which is also written in YAML. To complete our configuration changes to ensure voice and video traffic delivery, we need to create two tasks in our Ansible playbook. First, we need to produce network configurations based off of our templates. Second, we need to deploy the configurations to each network device. The Ansible playbook to complete this is below.
Just to provide a deeper overview, here is some information on the playbook above. As part of the setup, we have updated an inventory file with the management IP addresses of routers as shown in the topology diagram. These IP addresses are labeled as a group called core_routers, as seen in our playbook above. We are using SSH keys to avoid prompting users for passwords. When we execute this Ansible playbook, the first task is to produce an updated configuration file for each of our core_routers. Then, Ansible creates NetConf over SSH sessions to deploy the configuration to each of the core_routers.
Running the Ansible playbook only requires a simple command-line interface (CLI) in from our Ansible workstation as shown below. We see the following report below from the Ansible CLI tool indicating the change was successful.
Now let's illustrate the change to the network. Prior to executing the Ansible playbook, we had the configuration below on each router allocating 10 percent of buffer and transmit rate to video and 20 percent to voice.
The Ansible playbook runs in just a few seconds, and after, we have the following changes on each device. The playbook has allocated an additional 5 percent to transmit rate and buffer size for voice and video to satisfy the customer's requirements. Assuming we backed up the original YAML file, we could also roll back the change to the original configuration at the end of the live video feed. All of this is achieved without manual intervention on each network device.
In summary, the network now has a wider array of tools to simplify and orchestrate video and voice QoS changes. Tools like Ansible could easily integrate with other larger orchestration systems or even a basic CRON job. Illustrating the basic concept in this example was simple, but we could extend this functionality to cover additional devices or more complex changes like updates to classifiers.
Developing the promise of SDN for real-time communications
SDN could ensure UC performance and reliability
White-box switching promises programmable networks
Approaching SDN implementation with open source tools