How we tested Cisco's switch

We assessed the Cisco Nexus 7000 in six areas: high availability (HA) and resiliency; performance with layer-2 traffic, layer-3 IPv4 traffic, and IPv4 multicast traffic; features; and manageability and usability. A detailed version of our test methodology is available here.

We assessed the Cisco Nexus 7000 in six areas: high availability and resiliency; performance with layer-2 traffic, layer-3 IPv4 traffic, and IPv4 multicast traffic; features; and manageability and usability.

For all tests, we configured the Nexus switch to use 256 10 Gigabit Ethernet ports, redundant management modules and up to five switch fabric modules. Also in all tests, we configured the Nexus switch to use a 7,000-line security access control list to each of eight line cards; a 500-line QOS ACL to each of eight line cards; and Cisco NetFlow to track up to 512,000 flows.

We measured high availability and resiliency with three sets of tests. The first involved killing the Open Shortest Path First (OSPF) routing process from the command line (and having Nexus automatically restart the process) while concurrently offering 64-byte frames on all ports destined to each of 51,200 routes. At the end of the test, we used the Spirent TestCenter generator/analyzer to verify that the Nexus device forwarded all packets without loss despite the restart of the OSPF process.

The second high availability/resiliency test involved physically removing up to four of the Nexus' switch fabric modules, again while offering 64-byte frames on all ports to each of 51,200 routes. In this test, we determined that no frame loss occurred with two or more fabric modules in place. By examining forwarding rates with one fabric module active, we also validated Cisco's performance claim for the capacity of each module. We also monitored fabric utilization as reported by the Nexus switch to calculate approximate fabric capacity.

The final high availability/resiliency test involved upgrading and then downgrading the system's software image, again while offering traffic on all ports. As in the other tests, we used measurements from Spirent TestCenter to verify that Nexus dropped no packets during an upgrade and then a downgrade of its system image.

In the performance tests, we configured Spirent TestCenter to offer 64-, 128-, 256-, 1518- and 9216-byte frames to each of 256 10G Nexus ports in a fully meshed pattern to determine throughput and delay. We measured delay at 10% of line rate, consistent with our practice in previous 10G Ethernet switch tests.

In the layer-2 version of this test, the Spirent TestCenter analyzer emulated 20 unique hosts on each port, making for 5,120 total hosts. In the layer-3 version of this test, we configured TestCenter to bring up an OSPF neighbor on each of 256 interfaces and then sent external link-state advertisements representing 51,200 networks (or 200 per port). We then offered test traffic destined to all 51,200 networks. In the multicast test, we configured one Spirent TestCenter port to act as a multicast transmitter to 200 groups, each with 50 sources. We also configured Nexus to join all groups on each of 255 other ports. Spirent TestCenter then offered IPv4 multicast traffic to the "source" port, which Nexus then replicated to all 255 subscriber ports.

We assessed features, manageability and usability in conversations with Cisco about the Nexus switch; in using the switch during testing and in comparing the switch with competing products.

< Return to test: Cisco Nexus 7000 aims for data center dominance >

Editors' Picks
Join the discussion
Be the first to comment on this article. Our Commenting Policies