New stackable switch offers decent bandwidth at great price.

Nortel's

Baystack 5510

New stackable switch offers decent

bandwidth at a great price

n By John Bass, Network world Global Test Alliance

tackable switches - such as Nortel's new Baystack 5510 - are gaining a lot of momentum in enterprise networks because they let you buy a small, stand-alone switch now, then grow it to accommodate more bandwidth as you need it.

Nortel has entered the stackable switch fray with the BayStack 5510, which comes in 24- and 48-port 10/100/1000Base-T models. The price is very sweet at $7,000 for the 48-port variety.

In our performance tests, the BayStack 5510 achieved tolerable, but less than wire speed, throughput on a single switch and 87M bit/sec maximum stack bandwidth with good latency values.

Nortel offers good quality-of-service (QoS) features, but they are cumbersome to configure. While the company offers a broad set of administration tools and a decent set of user interfaces, there are some holes in the configuration tool set that could make it unruly in a large network.

The BayStack 5510 doesn't support Layer 3 forwarding but does support Layer 2 switching, fast spanning tree, virtual LANs, VLAN tagging (802.1q), Ethernet priority (802.1p), QoS, port mirroring, cross-stack port trunking and Internet Group Management Protocol snooping.

Management varies

Nortel provides several interfaces for managing and configuring a stack of 5510s - a text-based menu interface, a command-line interface (CLI) and a Web interface.

The menu-based interface - which is fairly intuitive and straightforward - is available through the console port on the front of the switch or through an Ethernet port using telnet over IP. This is the interface we used most often to configure the switches we tested.

The CLI is accessed through the menu interface and looks a lot like Cisco's CLI. Its commands are useful because they let you create scripts or command chains to implement complex configurations. The switches can then upload and apply these scripts in a text file format via Trivial File Transfer Protocol (TFTP). So you can create text configuration files from a text editor on a PC, then apply the configuration to the switch. Unfortunately, you can't save the current configuration as a text file and then edit that file, leaving no way to create a large text configuration file except by hand. This could be a huge hassle if you need to alter the configuration on multiple switches.

Using the CLI, menu or Web interface, the switch's or stack's configuration can be sent via TFTP off the switch to a server. Unfortunately, this file is in an unreadable binary format, so a user can't easily modify the configuration file outside the switch.

All commands are applied immediately on entry and are saved in non-volatile memory available when the switch or stack is rebooted. So while there is no need for a save configuration command, at the same time there is no easy way to list the current switch configuration. This could create some confusing situations when managing several switch stacks or trying to debug a configuration.

The Web interface is accessible through a Web browser via any Ethernet port on the stack. The interface is very responsive and useful, and offers the same functionality as the other management options.

Stacking operations

The switches are connected in a stack with two stack cables. The cables have high-density pin connectors on a quarter inch, braided wire. All switches in the stack connect to upstream and downstream neighboring switches, forming a ring. Each stack port has two 10G bit/sec channels in and two 10G bit/sec channels out. This all adds up to 80G bit/sec bandwidth at the stack interfaces.

Our performance testing comprised individual switch throughput, stack throughput and latency, QoS with both 802.1p and Differentiated Services, and multilink trunking (see How we did it, www.nwfusion.com, DocFinder: 9132).

We tested a full stack of eight switches using a complex mesh traffic configuration. The stack sustained 87G bit/sec, which is a far cry from 320G bit/sec Nortel advertises, but it's more than twice the bandwidth of the Cisco 3750 stackable switch reviewed earlier this year (DocFinder: 9126).

Nortel engineers agreed that the stack bandwidth for a full mesh traffic pattern is approximately 80G bit/sec. Our numbers were higher because some of the traffic in our test was confined to ports on the same switch and thus not limited by the stack bandwidth.

Latency through the stack was minimal (in the order of 6 to 20 microsec), which means the stack should support delay-sensitive traffic easily.

Throughput of a single switch was less than perfect but results were tolerable. With 64-byte frames, the switch could pass packets at wire speed, but the performance of the switch degrades as the frame size increases. These results are opposite of the results of most switches we have tested. Normally, performance degrades when frame size decreases because there are more frames to process per unit of time. Nortel engineers had no comment on these numbers.

The stack requires a base unit, which keeps up with the configuration of all the switches, unifies them into one configuration, replicates the console ports, and handles software upgrades for the stack. The base unit is set by a toggle switch on the back of the unit. The user interface button on the front can be used (with some cumbersome and non-intuitive Morse-code-like button pushing) to define the base unit. All this adds up to a lot of confusion.

The good news is once you properly define the base unit, the stack seems very stable in that it did not crash after we tried booting, rebooting, failing or trying to break it.

Stack management is fairly straightforward. Each switch in the stack is given a switch ID. The switch IDs are saved in the stack's memory based on media access control address. If the base unit changes, the stack doesn't suddenly renumber its interfaces.

The UI button - lit by a white LED on the front of each switch - lets you reboot an individual switch or the entire stack from the front panel of any of the switches in a stack.

In our tests, the stack rebooted in approximately 100 seconds. This is well within the norm for these types of devices. A single switch can reboot in about 70 seconds, which is good for this and comparable boxes.

Assessing QoS

Nortel advertises packet prioritization by 802.1p and Differentiated Services Code Point (DSCP). Each port on the BayStack switches, including the stack ports, features eight egress queues. The egress queues had the 802.1p values mapped to them. DSCP values can then be mapped to the 802.1p values. The default configuration that maps 802.1p values to a particular physical output queue should work fine for most enterprise networks.

Testing 802.1p with the default queue mappings showed that the queues and queue servicing algorithms operated as expected. The frame drop and latency management of all the flows destined for the various egress port queues was flawless.

Nortel lets you configure QoS to a high level of detail. However, with this configuration flexibility comes a confusing user interface and shortcomings in the documentation. More examples in the documentation would have been a great help.

One of the basic problems with QoS configuration is the sheer number of items needed to define and link together. If there is a problem with one definition, there is no hint of a problem until the final step of applying a policy to an interface group. The confusion is compounded when the stack provides vague error messages when it can't apply a policy. We were quickly bogged down with little help from the documentation or the user interface. This left us rolling the dice with a virtually endless set of configuration combinations to apply in attempting to get a QoS configuration to work. We had to rely on Nortel engineers to get through the DSCP configuration so the stack would accept the policies.

Once we had the policies configured properly, it worked like a champ. We saw a distinct difference in packet loss and latency between the various service levels we defined in the switch.

Redundancy features

The stack can support up to six multilink trunking (MLT) links that span multiple switches. We configured the first port in each of four switches in a stack and connected them to another stack of four similarly configured switches. We added MLT links until we reached the maximum of six allowed on the stack. The feature worked as advertised. This configuration gives connectivity redundancy between stacks if a switch fails in a stack.

To help increase switch uptime if there should be a power supply failure, a redundant power supply (RPS) port is provided on the rear panel of each switch in a stack. This port allows the switch to be connected to an optional remote power supply. This configuration allows for continuous power if the built-in power supply fails. We didn't receive an RPS to test, but the option is worth noting.

The bottom line is that the BayStack 5510 offers a great price, provides a good amount of bandwidth between the switches in a stack, should support latency sensitive applications well, and has a highly flexible QoS feature set. But it does have several holes in its configuration capabilities that might prove to be a hassle in a large network.

Bass is a senior technical staff member at North Carolina State University's Centennial Networking Labs (CNL) in Raleigh, N.C. CNL tests networking equipment and network-attached devices for interoperability and performance. Bass is co-author of Building Cisco Multilayer Switched Networks, and designs and leads the execution of the test suites. He can be reached at john_bass@ncsu.edu.

Chintan Desai and Reza Manavi of CNL assisted with the testing. All large port number tests were conducted in Spirent Communications' Smartlab.

Thanks

Chintan Desai and Reza Manavi of CNL assisted with the testing. All large port number tests were conducted in Spirent Communications' Smartlab.