Management and usability: Extreme goes its own way

Power consumption: Blade is most efficient

For most switches tested, the main question when it comes to usability is "Can you speak IOS?" Every switch tested except Extreme's has a command-line interface (CLI) that resembles Cisco's. That's a smart design choice considering more network engineers are conversant in IOS than any other environment.

Surprisingly, we found the CLI in the Cisco Nexus 5010, which looks like IOS but is actually a process running on the switch's NX OS, to be less convenient in some ways than IOS itself.

For example, IOS uses one simple command to download a configuration from a TFTP server. NX OS issues a warning that the command has been deprecated, and instructs the user to execute four other commands instead. Similarly, enabling jumbo frame support requires numerous policy-map and service-policy commands, compared with a single command in some Cisco Catalyst switches. Cisco says it's fixing the TFTP issue. We're glad to hear that; this is networking made cumbersome.

On the plus side, the Linux-based NX OS is modular, so a problem with any particular process won't bring down the entire system. That's a big improvement over monolithic IOS, and should enhance stability.

Arista's EOS also runs on Linux, and does more than any other switch tested to make Linux features available to users. This isn't just piping command output to any Linux program, handy as that is. The command set also allows network managers to drop into a Bash shell and run virtually any Linux command – including applying bug fixes without a reboot, a unique feature in this test.

Extreme's XOS is the only CLI tested not to emulate Cisco's IOS. We found XOS to be relatively simple to learn and use. That said, there were some fit-and-finish issues; for example, the switch allows swapping between primary and secondary configuration files but would not load a configuration using a different filename, even though the documentation says this is possible.

All switches tested support standard SNMP management information bases (MIB), and all except Arista's support the remote monitoring (RMON) MIB. All switches except Arista's also support at least some management methods over pure IPv6 networks. The Arista, Cisco, Extreme and HP switches also allow hierarchies of administrators to be defined with different privilege levels.

Power consumption: Blade is most efficient

Given that electricity is a major cost for any data center, it's not surprising that networking vendors have started to focus on power efficiency.

We measured power draw in this test using four configurations: With 12 ports idle and fully loaded, and again with 24 ports idle and fully loaded. We ran the 12-port tests to determine if switches saved additional power when only some switch ports have fiber-optic transceivers in place, as often happens in initial deployments. (We used 10GBase-SR transceivers in all tests.)

To measure maximum draw, we configured a Spirent TestCenter traffic generator/analyzer to offer 64-byte frames at line rate in a fully meshed pattern. That's a highly stressful pattern, and should produce power-draw readings at or near the maximum possible for any given switch. We then used a Fluke True-RMS 335 clamp meter to measure power consumption.

Chart of power consumption

The clear leader in the power-measurement tests was Blade's G8124. It drew less power in the worst case (181 watts with 24 fully loaded ports) than most other switches' best-case numbers (all other switches except Dell's drew more power in the 12-idle-ports tests). Notably, the G8124 was the only switch to use proportionately less power with fewer transceivers attached.

The Dell and then Arista switches were the next most efficient across all test cases. The Cisco and HP switches were the least efficient of the bunch.

MAC address capacity: HP ProCurve sets the bar

MAC address capacity is a key differentiator between data center and enterprise switches. It's long been an article of faith in enterprise network design that broadcast domains – and thus the size of switches' MAC address tables – should be kept small through the use of routers and subnetting.

Virtualization changes all that. With migration tools such as VMware's Vmotion, all virtual machines must reside within the same broadcast domain. After all, a virtual machine in a given IP subnet won't be visible if it moves into a different subnet.

As a result, data center switches need large MAC address tables. In the old enterprise model, a top-of-rack switch might learn around 40 MAC addresses per server rack, plus a few MAC addresses for attached routers.

In the new data center, each server in that rack might accommodate up to 32 virtual machines (likely to rise to 50 or more using technologies such as Cisco UCS). That's 1,280 MAC addresses per rack – and in a large data center, there may be dozens or hundreds of such racks. Considering that all virtual machines need to see all others in Vmotion environments, switches may need to learn tens of thousands of addresses.

In our tests, the clear leader in MAC capacity was the HP ProCurve switch, which forwarded traffic to nearly 65,000 unique addresses without flooding, more than double the capacity of the Dell and Extreme switches, which came next. The Blade, Arista and Cisco switches all learned roughly 14,000 to 15,000 addresses.

For data center applications not involving virtualizations, any of these capacity numbers is more than adequate.

See next part: Latency and jitter: Cut-through design pays off for Arista, Blade

Return to main test

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2010 IDG Communications, Inc.