Benchmarking WLAN switches: Let me count the ways

The nature of the beast is forcing us to cobble together test beds that would make Rube Goldberg proud, and the testing complexity is increased dramatically.

Benchmarking new technology is a key element in understanding where it might fit in your infrastructure. While rarely easy, standardization of product features and development of sophisticated test tools by the likes of Spirent Communications and Ixia made testing of LAN switches quite straightforward. With the advent of wireless LAN switches, all that has changed. The nature of the beast (WLAN, that is) is forcing us to cobble together test beds that would make Rube Goldberg proud, and the testing complexity is increased dramatically.

At the core of the challenge, naturally, is wireless. Where a legacy LAN switch was concerned only with data flow between two “like” ports (that is, Fast Ethernet to Fast Ethernet or Gigabit Ethernet to Gigabit Ethernet), the “partner” port in a WLAN switch configuration is the wireless access point plugged in to the switch port. In all cases, that access point implements a shared-use protocol on the wireless side.

So where traditional testing would feed identical traffic bidirectionally through matched ports, that option disappears when the wireless edge is involved. But it gets worse.

Most WLAN vendors implement proprietary tunneling that logically couples the access point into their WLAN switch. Thus, for example, a 64-byte frame that enters a wired Fast Ethernet port destined for a wireless user will exit the Fast Ethernet port on its way to the access point as perhaps a 104-byte Ethernet frame (depending on the vendor’s encapsulation scheme). Once received by the access point, the tunneling packet is stripped away and the frame is sent out on the wireless adapter as an 802.11b/a/g standard frame. If it sounds complex, you’re getting the picture.

Unlike their wired brethren, WLAN switches can implement enormously complex internal logic. In order to handle roaming, the switches have to keep track of client state, access point loading and more – for perhaps hundreds or even thousands of clients.

Add to this the difficulty of trying to scale wireless testing – interference, number of nodes and the like – and you arrive at an interesting destination. That is, “wireless” testing that doesn’t use any wireless.

So in order to prove scalability of WLAN switches, we have found ourselves “force feeding” an asymmetrical stream of traffic through the Gigabit Ethernet ports of a WLAN switch, “simulating” the internal load that would be placed on the switch had it been servicing a huge amount of actual WLAN clients – or so it is supposed.

Because each vendor uses its own proprietary encapsulation protocol and access-point-to-WLAN-switch “handshake” protocol, it is no surprise that “canned scripts” aren’t available. Instead we are back to the days of capturing one live session, loading it into the test tool and then using that information to synthesize the large traffic load. Not ideal, but it is the best we can do today.

And, what I’ve just described is the simple part of the test. When we get to roaming, VoIP and QoS, we face even greater challenges.

With that in mind, let me use this column to gauge vendor interest in an idea. I propose that, this fall, The Tolly Group and Network World host a meeting at our lab of WLAN switch and test tool vendors to attempt to articulate the challenges we face. And, more importantly, try to establish at least some consensus to help guide the efforts of test tool vendors to the benefit of all. Interested?