Automating Traditional Telco Networks with Ansible

How Ansible can help to automate Virtual Network Functions (VNF) configuration deployment?

Check out our whiteboarding video here!

What problems do we see from the traditional VNF deployment? 

Ansible Architecture Overview

1.Model Driven Architecture with Ansible

 In a traditional Telco network, you will typically spend 4-6 weeks deploying a service.

You’ll spend time in purchasing, installing and configuring with vendor CLI tooling, as well as provisioning service. This can be a long process.

• Leverage Ansible to separate data model from execution to deliver multi vendor orchestration.
• Enhance network operation models through scalable, repeatable pattern

When you virtualize your applications using virtual machines and hardware, you can accelerate the process. You will create configurations to specify where to deploy it and how to configure it.

If we can describe our services using Ansible’s code-based playbooks. We can specify how many VNFs the service has and how many interconnected components are in use. We can use Ansible to do automatic deployment and monitoring.

• DevOps

 You can prepare your Ansible scripts as part of the development CI / CD (continuously integrated, continuously deployed) pipeline including tests to verify your Ansible playbook and monitor your Ansible deployment status in different environments. The Ansible scripts can be checked into a git repo, which means that as soon as any change is pushed to the git repo, Jenkins will kick off the VNF deployment and verification. If any of the Ansible tests failed, Jenkins will fail the build process and reject the new change. This will help to ensure that the new Ansible change is always in a high quality.   

• Cloud Native VNF

In the legacy network applications running on blade servers, one box may have 10-20 blades. Three blades are typically used as network controllers, while the remaining blades are used for running the payloads. The first approach is to put the service running in these blades to virtual machines. However, when virtual machines are replicated, you will also replicate the software running inside the virtual machines, and which includes things that you may not need. This approach is not a scalable solution. We need to think about how to transform traditional applications to cloud-native apps.

What are the characteristics of the cloud-native VNFs?

• Scalable
• Self Healing
• Support DevOps approach
• Decompose to micro-services with APIs to talk to each other

 What is the road from traditional VNF to Cloud Native?

The micro-services need to contain the logic functions of the traditional network functions.

Examples include a database storing how much data you can use, how many minutes you can use with your phones, your personal data, contacts, etc.

Network functions to process MAP (Mobile Application Protocol) traffic. Requests are coming from different nodes in the network to retrieve information, or modify the profile, etc.

 With the functions mentioned above, we need to decompose the applications to microservices. When there is a high peak traffic in the network, microservices can easily be scaled up.

If the service farm is running out of memory or running out of disks, the databases can be scaled as well.

 Sometimes, legacy VNFs may need to be kept due to various reasons, however, Ansible can handle both legacy and new VNFs at the same time. Traditional VNF network functions use PCI address to consistently name the network interfaces for connection. When an application is virtualized, Ansible can still do PCI address injection to the virtual environment, as well as in the cloud.

Virtual Device Role Tagging

Because of the mass number of virtual devices involved in the VNF system, it is important to use role tagging to put tags to PCI devices. The tags will allow us to look up the devices based on roles and responsibilities. A simple micro-service such as metadata services can be useful to manage the tag information. For example, the tag information will be stored in the metadata service. Similarly, the tag information can be retrieved from the metadata service. With the micro-services in place, Ansible can take the PCI address, identify the device, and send the information to the network to perform the intended functions.

In addition, Ansible Playbook Cloud Provider could specify which cloud to use for deployment and which Ansible Playbook VNF Config is used for deployment.

In summary, automating VNF with Ansible can avoid a lot of problems with the traditional Telco Network. It lowers the costs of operations, ensuring the quality of the deployment. That allows the Telco industry to provide faster and better services to their customers.

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn