Colubris LMP: Extending hotspot reach - Page 3

Installation and provisioning

As a result of LMP benefits, our test network was installed and operational within a few hours. We did not conduct a site survey or pull Ethernet cable—we just placed MAPs wherever we wanted hotspot coverage. We spent under an hour configuring the MSC and integrating it with our Juniper AAA. We then spent a couple of hours configuring every MAP with identical radio, network, and VSC settings—this part would have gone faster if LMP supported Controlled Mode.

Controlled Mode provides auto-discovery and central provisioning of MAPs within the same mobility group. Management actions that apply to every MAP, like VSC configuration and firmware upgrades, are performed just once on the MSC and pushed to all MAPs. However, data path functions, including QoS and security, are still performed on each Controlled Mode MAP.

Alternatively, Colubris MAPs can operate in Autonomous Mode—the familiar paradigm where each "fat AP" is configured independently. When we started our test, we found that the initial Colubris LMP offering is limited to Autonomous Mode. Colubris told us that Controlled Mode LMP, now in beta test, will be released on 5000 series MSCs by October 2007, but is not being ported to 3000 series MSCs like our 3300.

Autonomous Mode has no impact on DWDS group discovery and self-healing; those local mesh capabilities were fully automated in tested products. What Autonomous Mode lacks is central configuration of VSCs and related radio, QoS, and security parameters. Instead, we had to hand-configure each MAP with identical settings, using a laptop and cross-over Ethernet cable. This was not a big deal because our hotspot was small and our VSCs were simple. But in a larger network with complex VSCs, we believe that Controlled Mode LMP is essential to reduce effort and ensure consistency.

Maintenance and monitoring

Determining mesh status and applying changes was consistently more challenging. After learning a few tricks from tech support and becoming familiar log records, we had little trouble understanding and adjusting our network's behavior. Nonetheless, this is where administrators will spend the bulk of their time and could benefit from a few improvements.

Controlled Mode LMP will be a huge help for routine maintenance. In the meantime, updates require access to each MAP's web or ssh admin interface. This wasn't as easy as you might think. When access is controlled by an MSC, MAPs are treated as users of the first configured VSC. For example, MAPs cannot reach an external time server or syslog server unless they log into the VSC. Similarly, NAT bindings can relay admin requests to MAPs behind an MSC, but responses are dropped if the MAP is unauthenticated.

On our MSC, the first VSC required GuestNet web login. Tech support showed us how to add MAP usernames and passwords to the MSC's local list, then use custom attributes to return those credentials in response to RADIUS Access Requests from each MAP. This is awkward, but it works. Thereafter, each MAP authenticated as soon as it sent traffic after DWDS link (re)establishment and could be administered from our LAN.

Of course, MAPs cannot authenticate when DWDS links are down. When MAPs went AWOL during our tests, we needed to administer them directly. Plugging a laptop into each MAP's Ethernet port was inconvenient, so we configured a hidden VSC on each MAP for Wi-Fi admin access. We would not advise leaving this VSC enabled in a production network, but it was extremely helpful for DWDS testing and fine-tuning.

Admin interface access is a means to an end. For monitoring, each MSC and MAP supports real-time status queries and local log file access. For historical event analysis, you can aggregate individual logs on a shared syslog server. For example, we used those logs to determine when each node lost and re-created DWDS links (see below).

To identify active mesh topology, we had to query each node for its own DWDS group status (below), then correlate all displayed links and MAC addresses to map out paths from root to leaf. SNR measurements for available-but-unlinked nodes can also be seen, but on another screen. Thus, in a 5-node mesh, we had to retrieve 10 screens to get a complete picture of DWDS status. We would love to see that topology accessible from one place (preferably the MSC) in a future release. In the meantime, plenty of useful and necessary information can be found in log files—you just have to dig for it.

Conclusion

Note that we did not attempt to compare Colubris LMP to outdoor muni-wireless mesh products—LMP is definitely not aimed at that space. Rather, LMP is an enhancement for public and private Colubris hotspots, letting operators extend their reach at lower cost. By putting LMP through its paces, we hoped to assess this feature's impact on Colubris hotspot administration and usability.

In static multi-AP hotspots, failures often cause users to connect to APs that "sound good" but lack upstream connectivity. In our LMP-enabled hotspot, users rarely made this mistake. Instead, users could roam throughout the network without persistent loss of connectivity. After minimal tuning, our network availability was good. In the end, significant disruption only occurred when our MSC went down and stayed down—a vulnerability we could have reduced by adding upstream redundancy.

Our tests also demonstrated how LMP lowers the cost and difficulty of hotspot expansion. With the current release, network installation was faster and cheaper than it would have been with Ethernet backhaul. Furthermore, the self-healing DWDS clearly required less care and feeding than static wireless backhaul. However, we found that LMP provisioning and monitoring capabilities are not yet fully baked and look forward to seeing those improvements in the next release.