Review: Aruba Virtual Branch Network (VBN) RAPs - Page 2

By Lisa Phifer

August 24, 2009

Building a foundation

No matter how provisioned, RAP firmware and policies must be supplied by an Aruba controller. Thereafter, RAPs treat that controller as their VPN hub, which processes tunneled traffic, applies central NAC and firewall policies, authenticates users, and aggregates intrusion alerts. Aruba sells six controller series, designed for different network sizes and topologies.


We had hoped to use a new 600 Series controller to activate our RAPs. We even trialed the Aruba 651 ($1495), a "branch-in-a-box" controller that incorporates a firewall/router/VPN gateway, 8-port PoE switch, file server, print server, and dual-band 802.11a/b/g/n AP. The 651 can be deployed solo at a medium office (256 users), supervising up to 64 RAPs. Alternatively, the 651 can participate in a bigger network, under the direction of a master controller like the Aruba 6000.


Alas, zero-touch is only supported today by 3000/6000 Series controllers running an "RN" ArubaOS image (e.g., v3.3.2-rn3.0). If we wanted to manually provision our 2WG or 5WN, our 651 could have supervised them like any other RAP. But we wanted to experience the benefits and limitations of a zero-touch VBN rollout. So we settled for a remote walk-through an Aruba-installed 6000 controller that supervised our zero-touch-provisioned RAPs.


That let us experience VBN RAP set-up and troubleshooting from IT's perspective, without installing our own 3000/6000 controller. However, anyone contemplating their own zero-touch VBN rollout must include TCO for at least one 3000/6000 controller. To learn about designing and deploying an entire VBN from scratch (including controllers), consult Aruba's 234-page, intensely detailed, but well-illustrated Virtual Branch Networks Validated Reference Design.


Many early adopters will be Aruba customers with existing controllers, now adding VBN RAPs to reach venues previously deemed too expensive. Zero-touch makes the biggest bang in large-scale unattended deployments, but we hope zero-touch provisioning gets added to smaller controllers. For example, SMBs with entirely-distributed workforces (e.g., insurance agents) might buy a pair of 651 controllers and dozens of RAPs, but can't ask their one-and-only IT guy to baby-sit 100+ remote installs.


Planning a VBN deployment

Aruba's VBN Reference Design breaks remote network deployment into six steps:

1)      Deploy data center

2)      Install pilot sites

3)      Provision backhaul circuits

4)      Train the help desk

5)      Stage site equipment

6)      Execute full deployment


We started at step 2 by adding two RAPs at our office to a demo network at Aruba HQ. To perfect network design and finalize configs, Aruba suggests piloting 5-20 venues that represent a variety of small branches and telecommuters, wired and wireless devices, and backhaul scenarios relevant to your business.


As in most pilots, we encountered a few bumps ironed out before full deployment. Only later did we receive the factory-shipped Install Guide or controller-generated QuickStart Guide. We then simulated step 6 by carrying our RAPs to over a dozen "real end-user" venues. At each, we had a volunteer use Install/QuickStart Guides to a freshly-reset 2WG without assistance.


We bypassed step 3 by using whatever Internet link was available at each venue, ranging from 3G and residential broadband to hotspot T1 and large enterprise LAN. Aruba had already completed step 5 by shipping us whitelisted RAPs, along with a VoIP phone configured to receive calls through the demo network.


That left step 4. To really cut TCO, most installs must go smoothly and any problems must be resolved quickly. Four of our approximately 18 installs required help—but that includes two "pilot" installs. A large-scale rollout might well achieve a higher success rate. Nonetheless, every Help Desk needs a "what can go wrong" RAP install and diagnostic checklist. The aforementioned Reference Design doc is an excellent place to start developing your own.


In our view, this otherwise thorough process overlooks a crucial step: end-user documentation. We strongly recommend supplementing Aruba's printed and online end-user help. The Install Guide is written for network-savvy readers. For example, after connecting a WAN (but not LAN) cable, readers are told: "Once the boot cycle is complete you can connect to your company or corporate network. See the Provisioning-at-Home section if you are unable to connect successfully."


At this point, every volunteer pondered "Boot cycle?" or "Connect how?" They were also confused by some RAP progress messages (see below). Simple questions like these are easily avoided by developing road-tested end-user instructions before full deployment—but could become costly if ignored.


Pulling the trigger

So what's really required from end-users during zero-touch install? Connect Ethernet port 0 to Internet link, Ethernet port 1 to laptop/desktop, and plug in AC. Wait 1-2 minutes for port 1 to light persistently (i.e., DHCP done), then open a browser window to any URL. When the RAP's Setup page appears, enter an employer-supplied Aruba controller IP or hostname. Sit back and watch a sequence of geek-speak appear (below), ending with a reboot pop-up.



Click to enlarge.


So far, so good. Unfortunately, that pop-up promises to launch the RAP console when done, which never happened. Volunteers got impatient and resorted to browser refreshes, eventually ending up at a guest login prompt instead. Why? The policy activated upon reboot (usually a 5-8 minute wait) bridged Ethernet clients onto a guest network that prohibits console access.


Thus, our best case always included brief confusion, but yielded a fully-functional RAP, auto-magically configured with three demo WLANs: a captive-portal rn-demo-guest SSID, a best-effort WPA2-PSK rn-demo-employee SSID, and a prioritized WPA2-PSK rn-demo-voice SSID. In any VBN rollout, IT decides how to divvy, secure, prioritize, and monitor remote wireless/wired access by creating AP Group policies. The RAPs assigned to each AP Group enforce those policies at the VBN edge, based on each client's role.


Our RAPs were configured to give teleworkers clientless demo network VPN access and guest/family Internet access. They filtered and prioritized incoming calls to our VoIP phone without exposing that sensitive service to remote misuse. the features required to support these policies—WPA2, WMM, VLAN, RADIUS, role-based access controls—are enterprise AP table-stakes. VBN makes it easier to apply these complex policies to smaller remote sites, in larger volume, at lower cost.


Pages: 1 2 3

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