NFV Tests & Trials

Validating Cisco's NFV Infrastructure Pt. 1

As part of the New IP revolution, NFV (network functions virtualization) is going to change the world of communications networking and services. It's just a matter of when, not if.

Part of the journey towards the "cloudification" of wide area communications networks involves the development of coordinated hardware and software systems that will enable the creation, delivery, management and tear-down of virtual network functions (VNFs). Collectively, those systems are referred to as the NFV infrastructure (NFVi).

A reliable NFVi is critical to the introduction of VNFs into any communications service provider (CSP) environment. So, as you'd expect, there's no shortage of technology companies that want their NFVi to be at the heart of CSP strategies, to be the foundation upon which new, revenue-generating applications can be reliably launched and provisioned.

As a result, it's incredibly important that network operators, as they start to introduce commercial services using New IP technologies, can turn to third-party organizations to find out if an NFVi can deliver what they need.

Together, Light Reading, as an independent and trusted media organization at the heart of the global communications technology community, and its respected test lab partner EANTC are in a prime position to help network operators with their New IP strategies.

Earlier this year, Light Reading asked the EANTC team to visit the San Jose, Calif. labs of Cisco Systems to conduct a series of validation and verification exercises on a number of Cisco cloud, software-defined networking (SDN) and virtualization platforms. (See Validating Cisco's Service Provider Virtualization & Cloud Portfolio.)

To follow up that successful project, Light Reading asked the EANTC team to return to San Jose in late September to evaluate Cisco's NFVi.

This report, which will be published in two parts, is the story of how EANTC planned the new project and the outcome and findings of its evaluation.

Part 1 provides an overview of the aims of the evaluation, a look at Cisco's NFVi and an in-depth, multi-page performance evaluation of Cisco's virtual switch technology.

Part 2 covers: Carrier-grade high availability and reliability; the integration, features and performance of key applications -- Virtualized Video Processing (V2P), including Cloud DVR, and virtual EPC (evolved packet core); and an evaluation of Cisco's "single pane of glass" management capabilities with regards to its NFVi. See: Validating Cisco's NFV Infrastructure Pt. 2.

Here is what is covered in Part 1 of the report on the following pages:

Page 2: Cisco NFVi introduction and test overview
Page 3: The virtual switch performance test introduction
Page 4: Test goals
Page 5: Test methodology and setup
Page 6: VM-to-VM performance
Page 7: Full virtual path performance
Page 8: Virtual Switch FIB Scalability
Page 9: Evaluating the Cisco IOS XRv 9000
Page 10: Conclusion of vSwitch Test Findings
Page 11: Cisco and EANTC evolved vSwitch test methodology

— The Light Reading team and Carsten Rossenhövel, managing director, and Balamuhunthan Balarajah, test engineer, European Advanced Networking Test Center AG (EANTC) (http://www.eantc.de/), an independent test lab in Berlin. EANTC offers vendor-neutral network test facilities for manufacturers, service providers, and enterprises.

Part 1 of the report can also be downloaded in PDF format: click on this link to get the report.

Next page: Cisco NFVi introduction and test overview

1 of 11
Next Page
[email protected] 10/22/2015 | 12:03:34 PM
Re: Where is Part2 Part 2 is imminent.... a minor clarification neede dto be verified.

NPUArchi20846 10/20/2015 | 5:25:21 PM
Where is Part2 "Part 2, which will be published on Monday October 19"
ashvin213 10/13/2015 | 12:12:27 AM
Some inconsistencies Hi there,


I found some issues that I did not follow:

1.      Throughput in PPS and Gbps don't seem to match. For example, I do not understand how 2.2e6 fps translates to 7Gbps for large frames (it should be around 26Gbps).

2.      Even for small packets, the latencies are in us. Shouldn't they be in ns? The authors claim 20us is in line with ASIC based switches (which I don't think it is. Most hardware switches take a few ns to switch packets. For example, Trident-1 took around 600ns for L3 forwarding and 400ns for L2 forwarding. This was way back in 2009).

3. Adding more MAC addresses must simply increase the memory size. Given that all of these are exact-match tables, I fail to understand

Sign In