Virtual network testing tool

Source : https://supportforums.cisco.com/docs/DOC-26261

Created on: Jul 27, 2012 12:08 PM by tokunath - Last Modified:  Aug 16, 2012 4:14 PM by Lisa Latour

Chalk Talk -  Virtualized Network Testing Tools – Use Cases and Deployment Guidance

VERSION 6 

Introduction

Server and storage virtualization is a hot trend gaining momentum in nearly all industries with its promise of reducing the total cost of ownership in the datacenter. Running multiple virtual machines (VMs) on a single server is not a new concept, but the levels that are now possible open the door to endless use cases and opportunities for scale. This generates both excitement and concern for datacenter operational teams that must ensure critical business applications running on virtual server and storage platforms perform reliably and remain available at all times. Network infrastructure virtualization solutions are also beginning to crop up in datacenters, as VM considerations such as mobility, access, high availability and security must be dealt with. Network architects are evaluating and deploying many of these new technologies including virtual access switches, virtual routers, and virtual security appliances.

Most IT organizations require that some level of certification testing be completed prior to deploying any new datacenter system or design in order to prevent outages that may impact revenue. Most out-of-service, or lab testing efforts involve building a prototype of the proposed network design and then using test tools to generate simulated application traffic on the network under test while it is subjected to stresses such as simulated failures or high levels of network traffic and transactions. As network engineers and testers begin to peel away the various layers of complexity with these virtualized datacenter designs, they will soon come to realize that their legacy testing tools will likely come up short in their ability to test end-to-end solutions, and that the only way to truly validate virtual networks designs is with virtual tools.

VM-Based Test Tool Use Cases

Test methodologies for conformance, functionality and performance testing of network systems and devices have not drastically changed over the years, despite test tools becoming more sophisticated with their ability to simulate applications and quantify a users “quality of experience”. The RFC 2544 standard, for example, was established by the Internet Engineering Task Force (IETF) in 1999, and is still considered the de facto methodology for benchmarking performance metrics of network systems. This RFC provides an out-of-service benchmarking methodology using throughput, back-to-back, frame loss and latency tests, with each test validating a specific part of an SLA. The methodology defines the frame size, test duration and number of test iterations. Network Engineers familiar with this methodology will immediately recognize the challenges applying it to the virtual world. For example, how would you go about benchmarking the maximum no drop rate of a Nexus 1000V software switch that has no physical ports to plug a traffic generator into? How would you gauge database replication performance between two VMs that reside on the same host? Will web performance between two VMs communicating through a virtual firewall match that of a physical device during the busy transaction hours? Network Engineers are realizing that the only way to conduct these types of out-of-service benchmarking tests are with software-based test tools that can reside on a virtual machine, allowing them deepest visibility into the virtual datacenter infrastructure.

Figures 1-4 below illustrate some functional use cases for VM based test tools that can be leveraged to validate the functionality, conformance, baseline performance and security of a virtualized datacenter.

The first test case shown in figure 1 shows how virtual test ports installed directly on a hypervisor can be used to measure VM to VM performance by sending test traffic between test port VMs that reside directly on a host under test. This testing can be limited to intra-chassis VM performance, or extended to inter-chassis and network performance testing by deploying ports on different hosts.

The second test case shown in figure 2 illustrates how a vSwitch such as the Nexus 1000V can be evaluated for performance, scalability and switch feature conformance in accordance with RFC 2889. A large number of VM-based test ports would be utilized to setup various test flows, including unicast and multicast as called for by the particular design requirements.

The third test case shown in figure 3 presents a “Cloud datacenter” design, where the Cisco Virtual Security Gateway (VSG) is leveraged to separate a VM deployment into “zones” so that zone-based firewall rules can be applied for inter-VM communications. An ASA 1000V Cloud firewall is positioned at the edge of each zone to secure the cloud perimeter against network-based attacks. By deploying a combination of VM-based test ports on the hosts, and physical test ports on the network, it is possible to validate functionality as well as conducting the standardized RFC 2647 “Benchmarking Terminology for Firewall Performance” test suites to thoroughly evaluate the performance of the virtual firewalls.

The final example in figure 4 presents a use case to validate the loss incurred during a live VMWare (VM and/or Storage) migration from a primary to secondary datacenter. In this example, test traffic sourced or destined to a VM-based traffic generator would incur loss during VM VMotion, and the duration of this loss could be used as a benchmark for calculating the effect on user applications.

Figures 1-4: Use Cases for Virtual Network Test Tools

Spirent TestCenter Virtual (STCv)

Spirent Communications http://www.spirent.com/ is one of the leading vendors in the test tool industry, providing network and application test tools used by Enterprise, Service Provider, Government, and Network Equipment manufacturers. Spirent was one of the first vendors to develop a test solution that allows VM-hosted test ports to be controlled by a common GUI and API that is also used to control its chassis based test systems. Test engineers familiar with Spirent TestCenter will find Spirent TestCenter Virtual (STCv) to have the exact same look and feel, where the VM-based test ports appear as dedicated test chassis with a single port installed. All of the standard conformance, performance and functional tests that are supported on physical STC ports are also supported on virtual (STCv) ports.

Spirent TestCenter Virtual (STCv) Test Components

This section describes the various components of STCv, and the infrastructure elements required to host, control, and manage it in a test topology.

• Spirent TestCenter VMWare VM. Each Spirent TestCenter Virtual port is a single VMware (Linux) Virtual Machine. There are two versions of Virtual TestCenter VMs, a 10G version and a 100M version, each requiring separate licenses, purchased from Spirent. The 10G versions are normally used for performance testing, where the 100M versions used for functionality testing.

• Spirent TestCenter GUI: The Windows GUI application that is used to control Spirent TestCenter (virtual and physical) test ports. This application can reside on a physical server or in a VM, so long as there is IP connectivity to the management VLAN that the STCv virtual machine is connected to.

• License Server: As a part of the Spirent VM purchase, the user will receive a 1RU license server. This server runs Montavista Linux, and works to supply the individual VMs a license file or license “seat”. A Spirent SE or other support representative will install the required license files to this server. The only requirement is that a “management NIC” in the Test Center VM be able communicate to the IP address of the license server.

• ESX Host: For Virtualized datacenter Testing it is oftent necessary to deploy the STC VMs on the ESX host under test. For STCv 10G performance type tests (ie: virtual switch throughput, intra-host VM testing, virtual appliance testing) a chassis-based Blade Server (Such as a Cisco UCS 5108) with adequate CPU and uplink capabilities would be necessary. For feature and functionality tests that do not require a high volume of “bit blasting”, a rack based server will normally provide adequate CPU and forwarding throughput to meet testing needs..

• Management switch: An out of band management switch is normally be used to access the management VLAN/vNIC of the host to provide out of band management control and license authorization from the Spirent TestCenter GUI and license server.

• VLAN Fan out switch: (optional). It is often useful to consolidate Virtual Test Ports onto a centralized Layer 2 switch that can be used as a centralized point of connectivity for Physical network devices under test. Care should be taken to ensure adequate capacity on this switch so that it does not become a bottleneck during performance testing.

Figure 5: Example Deployment of a Spirent TestCenter Virtual Testing Solution

Deploying Spirent TestCenter Virtual on Cisco UCS

The following steps will help guide you through an STCv deployment on Cisco UCS.

1. Purchase the appropriate STCv license and required number of seats needed for your testing requirements. The options to choose from include 10G (performance) or 100M (functionality) test port licenses.
2. Install license files on a license server that will have IP reachability to the management vNIC of the STCv Virtual Machines. (This task is typically completed by a Spirent sales or support team systems engineer)
3. Download the VM files from Spirent (www.spirent.com). Select the link(s) for “Spirent TestCenter Virtual 10G/100M for VMware, and download the FW image.
4. Add the TestCenter Virtual files to ESX host’s datastore and Add fto the VMWare vCenter Inventory
5. Connect Network adapters to virtual switches.
6. Each Virtual TestCenter VM has two Network adapters. One adapter is for the management connection and should be connected to a management VLAN having access to the license server. The other network adapter is the 100M or 10G adapter and should be connected to the appropriate VLAN in the test topology (Test Insertion Point). Click OK
7. (Optimization) Set CPU affinity for the TestCenter VM
8. Each Virtual TestCenter VM uses three virtual CPUs. For better performance each virtual CPU should be set with affinity to its own logical CPU
9. Configure TestCenter VM management ports
10. Configuration for the Virtual Test Center VMs will be via the VMware Console. Login to the Virtual TestCenter VM console and configure an IP address/mask/gateway, license server and NTP server from the Linux cli.
11. Add the Virtual TestCenter Ports to Spirent Test Center Application
12. Virtual TestCenter ports can only be used with Spirent Test enter version 3.34 or later. Each Virtual TestCenter port will appear to be its own chassis.
13. Define the test VLANs on UCS and trunk them up to the VLAN fanout switch. Connect the network devices where STCv ports are required to access ports mapped into the appropriate VLANS. Refer to figure 5 above for an illustration.

Tom Kunath, CCIE No. 1679, is a Solutions Architect in Cisco Systems Enhanced Customer Aligned Test Services (eCATS) Team. With nearly 20 years as a consultant in the networking industry, Tom has helped design, test and deploy some of the largest Enterprise, Financial, Service Provider and Federal Government customer networks. In addition to his CCIE, Tom holds a Bachelor of Science degree in Electrical Engineering and industry certifications from Juniper and Nortel Networks.