Review: Aerohive HiveUI - Page 3

By Lisa Phifer

March 27, 2009

Radio profiles

During our test drive, we experimented with various 802.11n configurations; in part 2 of this review, we examine the relationship between 802.11n parameters, QoS controls, and WLAN performance. In HiveUI, 802.11n parameters are determined by radio profiles (see Figure 6).

Fig6-RadioProfiles_sm.jpg

Figure 6. Dual-band 802.11n radio configurations. Click to enlarge.

Two pre-defined radio profiles are bound to HiveAP 320 and 340 interfaces by default: wifi0 uses radio_ng, while wifi1 uses radio_na. The default radio_ng profile supports 802.11g and 802.11n clients using a 20 MHz channel and 3x3 MIMO, without short guard interval or 802.11b protection. The radio_na profile supports 802.11a and 802.11n clients in a similar fashion.

To modify 802.11n parameters, we created our own radio profiles--the HiveManager "clone" feature is not available in HiveUI. For example, we created a my_radio_na profile to allow only 802.11n clients, using a 40 MHz channel and 3x3 MIMO with short guard interval. We then applied that radio profile to each HiveAP's wifi1 interface--the ability to apply the same interface update (radio profile, auto/specified channel, access/backhaul mode) to several APs would be nice to avoid inconsistencies.

Small WLAN admins may not appreciate potential impacts, like configuring an 802.11b/g/n profile to use 40 MHz channels. To address this, HiveUI provides a fairly extensive context-sensitive, searchable Help system. We found most answers that we looked for in Help, with one noteworthy exception. The same radio cannot provide simultaneous backhaul and access, but this fundamental limitation is buried under SSID Advanced Settings Help.

We noticed this problem after we defined our radio profiles and SSIDs without error, but observed our SSIDs beaconed at 2.4 GHz, but not 5 GHz. Using the CLI to query interface status, we discovered that wifi1 was not bound to our SSIDs. It turns out that wifi1 had been left in its default backhaul mode, causing our 5 GHz SSID assignments to fail. A more prominent warning in the radio profile help section might have helped avoid this, but we also think that HiveUI should have flagged the conflict when the SSID was applied to both bands/radios.

Finally, when HiveManager radio profiles were carried into HiveUI, one advanced knob ended up having no visible impact. With either management system, HiveAP radios can be configured to perform periodic background scans for rogue APs. HiveManager provides policies to classify rogue APs and a window through which to view rogue APs, but HiveUI does not. Rogue detection could be useful to small businesses if carried over more fully into HiveUI.

Provisioning and update

One major difference between HiveManager and HiveUI is the way in which HiveAP configuration changes are applied.

Like a typical enterprise NMS, HiveManager accumulates pending changes until an admin decides to apply them to one or more HiveAPs immediately, after a specified delay, or at next reboot. This approach is appropriate when making a number of related changes that really should be deployed (or rolled back) as a single step, minimizing network or user disruption. HiveManager also provides explicit control over profiles used to auto-provision new Hive APs.

In contrast, HiveUI changes are applied to all affected HiveAPs as soon as the Apply button is clicked on any configuration panel. For example, if an SSID is modified to require a different type of security, HiveUI attempts to push that new configuration to all HiveAPs immediately. If a static channel assignment is changed on one wireless interface, HiveUI updates that HiveAP immediately.

The HiveUI approach stops small WLAN admins from forgetting to activate updates, or having to decide which HiveAPs they should be applied to. However, this approach is most convenient only when all goes well. If one of several HiveAPs is down when a change is made, its current config will not match the HiveUI config. The HiveUI Device list draws attention to mismatches and provides tools to remedy them (see Figure 7). These same tools can also be used to explicitly provision a new HiveAP accepted into an existing hive.

Fig7-Resync.jpg

Figure 7. Resolving a HiveUI / HiveAP config mismatch

This is one area where we found HiveUI's simplified approach somewhat limiting. HiveUI does not let you apply different SSIDs to selected HiveAPs, as you can with HiveManager. HiveUI also does not appear to detect or describe HiveAP config errors as well as HiveManager. On the other hand, HiveUI does let you load firmware onto selected APs only--essential to avoid wireless backhaul link disruption when updating mesh points.

Monitoring and reporting

Transparent HiveAP discovery and simplified configuration are HiveUI's strong suits. In our experience, we believe that many small business hives can indeed be provisioned and maintained using nothing more than HiveUI. However, HiveUI provides only limited monitoring and no historical reporting. If these capabilities are important to your business, invest in a full-blown HiveManager.

HiveUI Status merely indicates whether HiveAPs are connected or disconnected to the CAPWAP server (i.e., HiveAP running HiveUI.) Syslog file tails can be retrieved from any single HiveAP and CLI commands can be sent to one, some, or all HiveAPs (see Figure 8). For example, show interface shows which virtual AP MAC addresses and auto-selected channels are now used by configured SSIDs, while show ssid <name> station lists currently associated clients and their session attributes.

Fig8-CLI_sm.jpg

Figure 8. Using HiveUI cut-through to invoke HiveAP CLI commands. Click to enlarge.

CLI cut-through is helpful but not a replacement for real-time status monitoring and reporting. For example, CLI commands proved helpful when we needed to diagnose our SSID / interface / radio profile configuration error. But we found them insufficient to debug authentication failures caused by defining SSIDs that required internal RADIUS authentication when we had not yet enabled that service.

Small businesses may need to combine HiveUI with shareware WLAN analysis tools to trouble-shoot problems and monitor WLAN utilization. Larger businesses that buy into HiveManager receive a healthy collection of near-real-time and historical reports and graphs that did not make their way into HiveUI. We would hope to see HiveUI narrow this gap in a future release by giving small businesses a few basic reports--for example, an SSID traffic summary and a client session log. In the meantime, a CLI "cheat sheet" for small WLAN admins would be handy.

Conclusion

With HiveUI, small businesses can tap Aerohive's cooperative control architecture to build feature-rich WLANs without having to pay for enterprise controllers or management systems.

New admins will not only find HiveUI approachable, but may build more secure WLANs by using the embedded captive Web portal, RADIUS server, and IP firewall. Those who require more control--especially per-user QoS priorities and bandwidth limits--can dig deeper without having to spend $3K for a HiveManager.

However, companies with more than a dozen HiveAPs--including those with small remote office WLANs--should step up to HiveManager to get features required by large distributed networks, including topo maps, real-time monitoring, and historical reporting. Stay tuned for part 2 of our Aerohive review, where we'll use HiveManager to explore alternative QoS strategies.

Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies. With over 25 years of experience in the NetSec industry, she has been involved in wireless product and service design, implementation, and testing since 1997.

Pages: 1 2 3
Originally published on .

Comment and Contribute
(Maximum characters: 1200). You have
characters left.