Virtualization, long a hot topic for servers, has entered the networking realm. With the introduction of a new management blade for its Catalyst 6500 switches, Cisco can make two switches look like one while dramatically reducing failover times in the process.

In an exclusive Clear Choice test of Cisco's new Virtual Switching System (VSS), Network World conducted its largest-ever benchmarks to date, using a mammoth test bed with 130 10G Ethernet interfaces.

The results were impressive: VSS not only delivers a 20fold improvement in failover times but also eliminates layer-2 and layer-3 redundancy protocols at the same time.

See our slideshow of performance charts 
How we tested Cisco's Cisco Catalyst 6500 virtual switching
Archive of Network World tests
Subscribe to the Network Product Test Results newsletter

The performance numbers are even more startling: A VSS-enabled virtual switch moved a record 770 million frames per second in one test, and routed more than 5.6 billion unicast and multicast flows in another. Those numbers are exactly twice what a single physical Catalyst 6509 can do.

All links, all the time

To maximize uptime, network architects typically provision multiple links and devices at every layer of the network, using an alphabet soup of redundancy protocols to protect against downtime. These include rapid spanning tree protocol (RSTP), hot standby routing protocol (HSRP), and virtual router redundancy protocol (VRRP). (Compare switch redundancy features in the Network World's Switch Buyer’s Guide.)

This approach works, but has multiple downsides. Chief among them is the "active-passive" model used by most redundancy protocols, where one path carries traffic while the other sits idle until a failure occurs. Active-passive models use only 50% of available capacity, adding considerable capital expense.

Further, both HSRP and VRRP require three IP addresses per subnet, even though routers use only one address at a time. And while rapid spanning tree recovers from failures much faster than the original spanning tree, convergence times can still vary by several seconds, leading to erratic application performance. (Strictly speaking, spanning tree was intended only to prevent loops, but it’s commonly used as a redundancy mechanism.)