Although cabled networks will always be faster than radio-based ones, wireless operation has a place in the majority of organisations. When you’re implementing wireless connectivity, the aim is pretty simple – you want it to be a part of the network, not just something separate that you bolt on and administer separately. HP’s approach is the Wireless Edge Services (WES) module for the 5300xl-series switch.
HP's arrival in the switched WLAN space is not before time. For some while it has been subsisting on its HP 700wl Series wireless gateways, a badged version of the gateway from WLAN-turned-securit-vendor Vernier. This year, it has announced a WLAN module. It's not a leading edge box but, in keeping with current trends, it's a true WLAN switch.
But is it "true" HP technology? We'd be very surprised if a vendor built a WLAN switch from scratch at this stage of the game. We have a suspicion of involvement from Symbol - which also makes a switch WLAN module for IBM - but, as with the Vernier box, HP isn't saying where the WLAN guts came from.
What we got
We tried out a ProCurve 5300xl switch, which is an eight-slot chassis with up to two power supplies. Our unit had three modules: a 16-port Gigabit Ethernet unit; a 24-port 10/100TX module with PoE capability; and the WES module, which has no ports but provides the wireless integration via the backplane of the chassis. We also had a boxful of assorted wireless access points, which HP calls "radio ports": the Radio Port 210 (802.11b/g with internal antenna); Radio Port 230 (802.11a/b/g with internal antenna); and Radio Port 220 (802.11a/b/g with external antenna connections). All the APs are PoE-capable, and thus have an RJ45 Ethernet connector and no power inlet.
To implement PoE on the 5300xl, you need to provide an external power source to the PoE-capable cards – the required power simply isn’t available through the chassis backplane. You have a choice of two devices: the ProCurve 610, which provides power to up to four PoE-capable chassis-based cards; or the ProCurve 600, which is actually designed as a redundant power supply to other ProCurve chassis, but can also power up to two PoE cards as well. The external power supply connects to a socket on the front panel of each card it’s powering.
Configuring and set-up
Step one when you power up the switch is to set an IP address; you can do this via DHCP, or using a serial terminal to bash it in via a CLI. Once the unit has an address, point your browser at it and you’ll be given the Web/Java-based configuration GUI (you can, incidentally, use HP’s paid-for ProCurve Manager instead) . This GUI is used to manage almost all aspects of the 5300xl – VLANs, IP properties, QoS, fault alerting, port configuration and so on.
The one thing it can’t manage? The wireless side of things; you have to use the WES card’s own management interface for that. The latter is accessible by pointing your browser at the WES’s IP address – which is, by the way, different from that of the main chassis (again, you configure it via a simple CLI command). The WES’s interface is another Java applet.
Before configuring the wireless world, you’ll want to connect your APs. Hook them up and the lights should start flashing madly, telling you you’ve not set the country code in the WES configuration. A quick pull-down menu selection in the GUI and a reset, and the APs soon start to behave – and in fact in our lab, the WES seemed happy to spot the APs, get them running and “adopt” them as known devices without any further intervention. The APs themselves are visually fairly uncommunicative creatures, with just a couple of flashing lights for telling you stuff, but in fact this is all you need since the “fault” combinations are explained in the manual, and when there’s no fault, you can see them via the GUI.
Once the system has found its APs, you can configure them appropriately. You can define 16 or 32 WLANs (depending on how you’re running them), and for each you can define the security aspects for both admission to the network and encryption of traffic once admitted. Naturally, there are some low-level wireless bits you can fiddle with too, if you so desire – limiting the number of devices on a radio, default channel selections, and the like. Traffic separation is achieved by allocating WLANs to VLANs as required, and if you’ve bought a Redundant Wireless Services module you can configure failover via the GUI too.
How does it stack up?
What do I think of the ProCurve wireless stuff, then? Well, the overall impression is favourable: there’s a decent range of APs, and getting everything connected was an absolute doddle (the manuals are a bit scarily technical in places, but it’s all fairly useful information and is easily offset by the idiot-proof walkthroughs that accompany it). And although PoE is only available by plugging an external supply box into each card requiring PoE, I guess that this is reasonable since the alternative would be to require hefty amounts of power through the chassis’ own PSUs.
There are a couple of downsides, though – not show-stoppers, but things HP might like to consider for the next version. First, the minor niggle that I’d prefer the external power provision for the PoE cards to be provided through the back panel, not the front of the card; although it’s a latching power plug (so you can’t knock it out too easily) I like my power provision on the back, out of harm’s way, thanks very much.
The other annoyance is that managing the wireless world has to be done separately from managing the rest of the chassis – the wireless card has its own IP address and management GUI. I remember the days when the Cisco 5000-series ATM card worked in a similar way – one interface for the chassis, another for the card – and it was a bit of a fiddle; let’s have it integrated before too long then, please chaps!This separation of the two worlds adds to the impression that this is technology which has been licensed in and integrated.
On balance, the positives outweigh the negatives. We had everything set up and working within half an hour, and the documentation was pretty clear (though it took a little while to figure out how to stop the system advertising SSIDs!). Auto-detection of APs was straightforward, and we had no problem finding our way around the GUIs. The downsides are niggles rather than problems, though it’d be nice if HP took the system toward a properly integrated management interface.
Peter Judge contributed to this article.
An SME that needs a bit of wireless probably wouldn’t bother with a chassis-based setup, but if you are big enough to warrant one, it’s worth considering one that does wired and wireless in a single platform.