Deploying OpenStack Neutron for NFV, requires a risk-free Neutron module and plugin means validating a number of protocols, network domains and security parameters. The simplest and most efficient way to validate the virtual networking module is to assess performance using virtualized IP test solutions which are orchestrated within OpenStack.

The virtualized IP test solution should equate to a virtual network function (VNF), enabling test data as a service (TDaaS) on the cloud-managed platform.

Network functions virtualization (NFV) is now synonymous with OpenStack. When people say NFV, there is an implication that they are talking about OpenStack. OpenStack as an open-source project has greatly simplified the path to virtualization for many. Not only has OpenStack reduced the costs of deploying cloud managed platforms (CMP), it has greatly simplified management of the underpinning infrastructure through modularizing several core components. These core modules include: compute resource (Nova), networking (Neutron), storage (Swift), a user management interface (Horizon) and a virtual machine repository (Glance).

The latest release of OpenStack - Icehouse contains many new features. In particular, the networking module Neutron has many new advancements. In addition, Neutron’s continued success has been achieved by enabling drivers and plug-ins from a number of vendors including Cisco, IBM, and Nuage. Interestingly, Neutron’s inclusive model has also enabled adoption of control and management technologies for software-defined networking (SDN). The Neutron module includes an OpenDaylight plugin, which is an open platform for network programmability.

Neutron is quickly becoming one of the more complex modules to understand and deploy. Many online OpenStack installation tutorials cite the Neutron install as a separate lesson, if covered at all. With each new release of OpenStack the addition of further plugins will enable greater feature capability, but in turn increases the complexity of using the networking module.

Clearly a successful CMP deployment hinges on correctly configuring the Neutron networking module. Which is instrumental in getting traffic in/off the CMP, but more importantly is key in enabling communication between the Nova compute nodes and virtual machines. Before considering scaling or defining elasticity of the CMP and NFV systems, a major challenge is to correctly dimension the Neutron module. This challenge can be divided into two key areas:

Infrastructure Dimensioning: Verify the correct configuration and deployment of the native OpenStack functionality i.e. vswitch, security groups, and NAT tables. Verify that the additional networking plugins are configured and operating accordingly.

Virtualized Network Function (VNF) Dimensioning: Ensure that the virtual machines (VM) core to the VNF have the necessary networking capability. Validate the VNF and services being delivered on the CMP as operational.

Dimensioning any network, networking component, or application requires knowledge of the underpinning network protocol, and in the case of OpenStack, extends across a range of protocols. More often than not, all this expertise is not readily available in-house. However, there are a number of specialized network test tools available that can overcome the lack of expertise. Using dedicated tools users can configure protocol-specific test scenarios often through a simplified graphical user interface or even command line interface.

By using dedicated tools it’s possible to emulate or represent stateful traffic with the necessary protocol stack, but more importantly provide the necessary performance metrics to dimension transportation links, ensuring the high availability of services. But is this enough?

The simple answer is no. The goal of NFV systems is to enable services in a more agile way e.g. a VNF enabling test data as a service (TDaaS). This new age of agility also means that the performance measurement tools should be deployed as NFV components. Interestingly, the VNF used for infrastructure/service validation should use the available NFV system meta-data, so as to deploy a highly optimized test resource. Take the example of a simple service chain, it should be possible to automate the relevant dimensioning test scenario or traffic flow based on the validation tools position in the chain. This can only be achieved in the NFV system by hooking into the NFV management and orchestration meta-data. TDaaS and the validation tools should enable agile performance testing.

Another consideration for the NFV system is the rapid rate of advancement and releases coming from the OpenStack community. There is a genuine need for all NFV suppliers to keep up with the major releases of OpenStack: Grizzly, Havana and Icehouse. Traffic emulation and performance measurement tools should be seen to assist with the continued progress of OpenStack and support these advances.

From a first principles standpoint, the ability to launch a 3rd party NFV component gives some indication on the readiness of the OpenStack deployment e.g. Users can load images into Glance, Nova is shown to be running the virtual machine (VM) image and the Neutron module is operational as it enables access to the instantiated and launched VM.

But from lessons learnt, it’s suggested that users of OpenStack should be in a position to discover how well the cloud managed platform holds up under real load traffic conditions. The ability to deploy a static VM which is not consuming any compute cycles is by far the worst thing to gauge success upon.

As already indicated, the ability to deploy a traffic emulation tool into the CMP offers some visibility into the actual robustness of the CMP. A further consideration for using validation tools is when it comes to hosting multiple tenants. The ability to dimension the CMP is critical to ensure tenant privacy and security.

A privacy architecture can be achieved in a number of ways, a common practice is the use of virtual LAN (VLAN) tagging on tenant traffic. However, VLAN tagging has a limited address space (4096 IDs) which then forces the CMP architects to look to other mechanisms of traffic segmentation. At scale, the most readily adopted practice is the use of a tunnelling mechanism such as GRE or VXLAN. Again, when selecting to use performance dimensioning tools, users should assess the ability of the tool to support both under and overlay networking protocols.

Using a simple OpenStack architecture of cloud controller, networking and compute as shown in the Fig. 1 above, it’s possible to show the extent of the dimensioning challenge. Even with a simple deployment one of the key questions that needs to be asked is what impacts the compute distribution on the operational effectiveness of the deployed OpenStack CMP?

To understand the impact of distribution on the OpenStack CMP and virtual networking, the first place to look at is in the Neutron server on the networking node. The Neutron server consists of a number of unique entities called agents. These include: Neutron Meta Data, Neutron DHCP, Neutron L3, and the Neutron plugin. This high level view of the Neutron server further demonstrates the need for the dedicated performance measurement and emulation tools.

One way to assess the reliability of the distribution is by launching stateful virtual machines (VM). Again, by selecting a tool that can be deployed as VNF will enable the ability to emulate thousands of VM instances. The ability to launch and connect thousands of VMs to the open vswitch (OVS) is the only effective way to dimension the limits of the OVS.

Each virtual network interface (vNIC) needs an active VM in order to register the interface as in-operation within OpenStack. Without dedicated tools, this part of the dimensioning challenge becomes even more cumbersome. The alternative, is to waste resources by developing and maintaining scripts to launch thousands of VMs. Plus there is the need for further scripting to configure user activity on each of the VMs, such as ICMP PING to determine VM network connectivity and finally collect/correlate metrics.

However, with dedicated IP test tools users can do much more, such as quickly validate the dynamic IP addressing scheme being managed by the Neutron DHCP agent. The Neutron DHCP agent maintains the collection of IP address pools which are in use across the CMP. The first purposeful validation is to determine that each of the address pools are accessible, that additional DHCP options are functional, and more importantly that the address pools do not overlap.

Building on the success of validating the IP address allocation in the OpenStack CMP, there is the need to validate traffic segmentation from the perspective of security. Considerable effort is put into ensuring privacy, which is achieved by correctly isolating the tenant traffic flow. Again, the traffic emulation tool should support the use of VLAN IDs or virtual extensible LAN (VXLAN), depending on the scale of the CMP.

Traffic management in OpenStack is not limited to native Neutron functionality but can be extended using a plugin e.g. OpenDaylight’s programmable networking. With each additional plugin in use on the CMP, the greater the risk is of the configuration impacting the performance of the traffic flow. This further strengthens the argument for validation, but validation with stateful application flow.

From the perspective of a CMP tenant, the key is to determine if there is performance degradation at layers 4 through 7. In respect to NFV systems, there should be greater awareness of the impact that the managed networks has on the interconnection of component VMs in a VNF. For example, if the vswitch or network paths are under the management of a 3rd party plugin, a misconfigured setting has the potential to impact the functional operation of a particular VNF and therefore the overall NFV system service. Orchestration and network automation are key composites which drive the need for test data as a service on CMP.

Up until now, the focus has been on dimensioning the deployment and architecture of OpenStack. However, a widely recognized attribute of OpenStack, is the ability to facilitate the tenant with their own network orchestration and management for their own virtual network requirements. At a tenant level, network isolation can be achieved through unique IP subnets using the Neutron L3 agent, with the network address translation done in a virtual router. The Neutron virtual router also acts as the primary interface to the wider network. Within these networks it’s clear that the tenants should be able to deploy VMs to communicate in the tenant network and where appropriate, communicate out of the tenancy. Correct validation should show the layer 3 address translation as operational and adds very little in terms of packet latency.

However, the multi-tenant CMP raises an even more interesting question: What impact has a noisy neighbor on the surrounding tenants? In most cases, the multi-tenant configurations will use dedicated compute nodes, ensuring a level of isolation and security of the tenant. But in OpenStack there is the ability to overcommit the available CPU and memory. This means that the OpenStack Nova scheduler, by default, allocates up to 16 virtual cores per physical core. Therefore, for a socket with quad-core CPU, there is the potential for up to 64 virtual cores. The trade-off for this increased number of potential OpenStack VM instances is the reduced compute performance per VM instance.

Re-iterating again what has been discussed, but only by choosing the correct network validation tool—one that can be orchestrated and launched in OpenStack— it is possible to quickly determine the impact of a noisy neighbor on the surrounding tenants. For example, a virtualized IP test solution can be used to create the scenario by emulating a tenant with intensive computing needs and supporting thousands of TCP sessions. In the second tenant, the emulation tool is representing a low usage tenant. The automated emulation tool makes it possible to scale/contract both tenant use scenarios to help determine the pinch points on the compute and network modules.

As part of a wider CMP management strategy, these validation techniques can help to define a set of networking policies to effectively deal with the noisy neighbor in an automated manner. Furthermore, automated validation enables CMP architects to quickly assess usage scenarios with real tenant characteristics so as to precisely dimension the distribution and configuration of each of the Neutron server agents.

By choosing the correct validation tool, architects of OpenStack cloud managed platforms can be reliable and quickly assess whether the theoretical architectural specification match what is needed to deliver a reliable and robust cloud managed platform in OpenStack.