Vous êtes sur la page 1sur 11

Spirent Communications Whitepaper

Implementation Issues around Virtualization of Network Elements

Chris Chapman July 2012

Implementation Issues around Virtualization of Network Elements

Spirent Communications, Inc.

26750 Agoura Road Calabasas, CA 91302 USA

2011 Spirent Communications, Inc. All Rights Reserved. All of the company names and/or brand names and/or product names referred to in this document, in particular, the name Spirent and its logo device, are either registered trademarks or trademarks of Spirent plc and its subsidiaries, pending registration in accordance with relevant national laws. All other registered trademarks or trademarks are the property of their respective owners. The information contained in this document is subject to change without notice and does not represent a commitment on the part of Spirent Communications. The information in this document is believed to be accurate and reliable, however, Spirent Communications assumes no responsibility or liability for any errors or inaccuracies that may appear in the document.

Limited Warranty
Spirent Communications, Inc. (Spirent) warrants that its Products will conform to the description on the face of order, that it will convey good title thereto, and that the Product will be delivered free from any lawful security interest or other lien or encumbrance. Spirent further warrants to Customer that hardware which it supplies and the tangible media on which it supplies software will be free from significant defects in materials and workmanship for a period of twelve (12) months, except as otherwise noted, from the date of delivery (the Hardware Warranty Period), under normal use and conditions. To the extent the Product is or contains software (Software), Spirent also warrants that, if properly used by Customer in accordance with the Software License Agreement, the Software which it supplies will operate in material conformity with the specifications supplied by Spirent for such Software for a period of ninety (90) days from the date of delivery (the Software Warranty Period). The Product Warranty Period shall mean the Hardware Warranty Period or the Software Warranty Period, as applicable. Spirent does not warrant that the functions contained in the Software will meet a specific requirement or that the operation will be uninterrupted or error free. Spirent shall have no warranty obligations whatsoever with respect to any Software which has been modified in any manner by Customer or any third party. Defective Products and Software under warranty shall be, at Spirent's discretion, repaired or replaced or a credit issued to Customer's account for an amount equal to the price paid for such Product provided that: (a) such Product is returned to Spirent after first obtaining a return authorization number and shipping instructions, freight prepaid, to Spirent's location in the United States; (b) Customer provides a written explanation of the defect or Software failure claimed by Customer; and (c) the claimed defect actually exists and was not caused by neglect, accident, misuse, improper installation, improper repair, fire, flood, lightning, power surges, earthquake, or alteration. Spirent will ship repaired Products to Customer, freight prepaid, based on reasonable best efforts after the receipt of defective Products. Except as otherwise stated, any claim on account of defective materials or for any other cause whatsoever will conclusively be deemed waived by Customer unless written notice thereof is given to Spirent within the Warranty Period. Spirent reserves the right to change the warranty and service policy set forth above at any time, after reasonable notice and without liability to Customer. TO THE EXTENT PERMITTED BY APPLICABLE LAW, ALL IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, ARE HEREBY EXCLUDED, AND THE LIABILITY OF SPIRENT, IF ANY, FOR DAMAGE RELATING TO ANY ALLEGEDLY DEFECTIVE PRODUCT SHALL BE LIMITED TO THE ACTUAL PRICE PAID BY THE CUSTOMER FOR SUCH PRODUCT. THE PROVISIONS SET FORTH ABOVE STATE SPIRENT'S ENTIRE RESPONSIBILITY AND CUSTOMER'S SOLE AND EXCLUSIVE REMEDY WITH RESPECT TO ANY BREACH OF ANY WARRANTY

Implementation Issues around Virtualization of Network Elements

Virtualization of network elements such as routers, switches, firewalls, server and caches are an inevitable evolution of networking. While providing tremendous value to an enterprise or provider. Virtualization of network elements will provide a testing challenge that come with the paradigm shift toward shared competition for processing resources and the separation of element function from dedicated hardware resources. The purpose of this whitepaper is to document the transition challenges.

Why Virtualization of the Network Element?

There are four critical reasons why virtualization of the network element will paradigm shift the current network model. The first fundamental reason is cost and monetary advantage of virtualization of the network element. Cost can be measured in many ways such as direct hardware savings, less space and power, or a more efficient use of computing cycles. The cost advantage of virtualization is no single data point, but a combination of many savings compounded. The next fundamental reason is control. The producers of the OmniBox that will host the network will have a high degree of control to certify elements in their AppStore. This advantage will also be used by customers to ensure certified virtual elements have been placed thought a uniform degree of quality. Another advantage of control us the ability of the end user to virtually build out and pre-test the network before production. Tools like Spirent TestCenter Virtual endpoint can help the user model both topology and traffic. Lastly, the new virtualized network is a minimum requirement for the hardened' network. Security exploits attacking the network will not only be inevitable, but expected.

Implementation Issues around Virtualization of Network Elements

The Hardened Network

The current box per element model of the network cannot handle tomorrows security threats. There are too many permutations of vendors, code versions. Since the take down of the network elements would produce a dramatic security challenge, the current paradigm degree of defense is a Weakest link strategy. Given that Cyber warfare is a permanent condition, we must not only expect it, but build defense into the DNA of the paradigm to combat it. The modern network is rapidly morphing into an organism with discrete functions and vulnerabilities. This is most clearly evident by the evolution of the attack toward the network. The only effective way to protect the body of the network is to build a system wide immune system that has network-wide reach and control. Therefor a virtualized network will not only consist of elements, which function organs of the network, but a monitoring immune system.

Virtualization is a Contradiction
End users want more capacity, in a smaller space, at a lower cost, with 99.999% uptime. In addition, they want full end to end QoS and QoE management. To place this in perspective, the previous comparable network, the POTS phone network, did not achieve this goal worldwide even after 50 years and hundreds of billions of dollars of investment. In addition to the advantages of virtualization, users will still expect, and thus measure, performance based on the older network. Therefore, when we test and measure the virtualized network, we must judge the network performance based on Service Quality, not just individual networks like bandwidth. To achieve Service Quality over the virtualized network, we must blend network optimization, multicore balancing, bus technology and advanced coding techniques simultaneously. Virtualized network can be extremes of success and failure. When it works, its highly valuable. When it fails, its fails big.

Implementation Issues around Virtualization of Network Elements

End Users want what they had in the old POTS Network
The end user of the virtualized network want the save service quality as the old POTS phone system, specifically:

You pick up the receiver and you get excellent quality 99.999% of the time You have an expectation, which self-reinforces day after day, year after year Failures (not just at the service level, but even at the dip in quality level) become unthinkable. A the perception of the impact of a failure becomes deeply magnified

What does this mean for Perception?

Service quality perception is both self-reinforcing and radicalizing. The more good quality the user perceives, the more that quality becomes average and expected. When a failure occurs, sometime just a drop in quality, the users perception is multiplied. The minimum unit of evaluation is service perception over time (Mean opinion score). This now is the atomic unit of measure. Sub-metrics like Packet Loss and Bandwidth are components of the solution, but are no longer individually meaningful. Further, older metrics like RFC-2544 have limited value Do I get why services when I want them, at the quality I want, all the time

Implementation Issues around Virtualization of Network Elements

Implementation Issues
In this section, we will discuss unique testing challenges of the virtualized network.

What is the impact of shared memory on virtualized network services?

In a classic memory, different memory sub-systems are physically isolated and are independent In a virtualized network, network elements compete for: Impact: If memory capacity is not tuned, open session capacity will suffer If memory access performance is not predictable, then Process Jitter may occur. In this problems, the memory sub-system goes into a Blocked mode and network element VM temporary halts. Incorrectly tagged VM processes may starve critical virtualized network elements Finally, current memory queues access methods like FIFO transfers could starve many processes. Available RAM Access performance Time cycles

Implementation Issues around Virtualization of Network Elements

What is the impact to Network Elements due to CPU core allocation and distribution
Classic network have multi-core systems that as a unit are physically isolated In a virtualized system, the OmniBox Hypervisior allocated cores based on: Priority Performance System need

Impact Will the OmniBox allocate CPU core efficiently? Can one process Steal cored from other processes? How optimized will Cross compiled code be?

What is the impact of the Crossbar on the virtual network elements?

Classic devices have highly tuned and high performing crossbars In a virtualized system, all processes share the master bus, which can be multiple factors slower than a single bus solution Impact Systems tuned for predictable, fast cross bards will have to compete for a single system bus Processes can become instantaneously stale, causing performance problems Lots of competition o Always utilized scenario Two or more VMs are always pegging the bus o Oversubscribed in the Burst When VMs microburst, there could be strong bus contention

Implementation Issues around Virtualization of Network Elements

How well does the OmniBox offload software to hardware?

Many modern single box solutions have hardware offload. Virtualized network elements also need hardware offload support? OmniBoxes will offer specialized offload hardware (i.e. FIB, RIB, network processor, etc.) Impact: Offloading performance from software to hardware and back again could be a major bottleneck There will be contention for hardware offload resources where there was none before Session capacity and QoE can be greatly affected.

How well does the virtualized system handle shared SAN storage?
In the classic network element, storage was local to the device Now, storage is intermixed on a SAN Impact: Can the SAN keep up with the needs of the virtualized network elements? How does parallel burst of read requests / write requests effect the Storage Jitter for individual Network element VMs. How does the Cloud manage Storage capacity?

Implementation Issues around Virtualization of Network Elements

What happens when code fails?

Virtualized OmniBoxes have an opportunity to perform an action impossible in classic network elements, detect crashed and revert to a hot standby session The Hypervisior will need to know how to detect a Failure Impact: What is the service convergence time to failover a network element VM? Can a network VM crash the hypervisor? What is the impact to active sessions when VMs migrate to backup sessions?

How secure is the OmniBox

In the classic network, if an element is compromised, the diameter of damage is predictable Virtualized network OmniBoxes are extremely tempting security targets; bring down multiple customers in one attack The OmniBox must have security at its core: Impact: Crash the OmniBox and cause waves of outages across many diameters How well does the OmniBox mitigate attacks? While mitigating attacks, does the OmniBox maintain QoE universally.

Implementation Issues around Virtualization of Network Elements

How secure are Partitions?

The sharing and pooling or resources is the core is a great economies of scale for the service provider, but how secure is one customer from another customer Impact: How well does the OmniBox isolate customer traffic? How well does the OmniBox prevent intra-customer hacking? What is the impact of load and capacity on intracustomer security? Can one customer crash another customer?

How well does virtualized network systems manage site disaster recovery
Virtualized network elements cannot simply exist in the Box, but must be members of the Cloud When a site physically fails, the Cloud must reroute functions in realtime. Impact: What is the service convergence time when the cloud moves services from site to site? What data is lost? Is the process secure?

Implementation Issues around Virtualization of Network Elements


Testing Virtualization is Critical

Because of the inherent complexity of virtualized system, testing from the outside in and the inside out is a critical part of verification of correctness. With inherent barriers to performance such has hypervisor interrupt handling, possible instantaneous loss of real-time resources such as shared CPU cycles, memory pooling, and local VM OS interrupt interactions, verifying your specific network topology and service becomes even more critical to establishing that the hypervisor will be able to perform as expected. In addition, testing security, especially from a compromised virtual machine becomes essential to any managed security policy. The tester must have the ability to not only test classic L2 and L3 traffic patterns, but model real, temporal user behavior utilizing the exact service protocol to be served for the virtual machine.

Vitalization has tremendous potential to optimize hardware, space, and power resources. In addition, virtualization is the only means forward to ensure a system wide and complete security model, improved reliability though App Appliances, and centralized management. With any new paradigm, verification challenges change. The use of shared resources can have unintended resources, such as variable system resources from the perspective of the VM, security challenges, central points of failure, and isolation. Proper verification with a quality test set is the best answer to address these challenges. This includes the ability to emulate temporal realism up to and including the user layer.

Implementation Issues around Virtualization of Network Elements