Aerohive HiveAP Provisioning Basics

Honeycomb modular furniture, courtesy Disney.
(This is what I imagine Aerohive's
corporate offices looking like :)

Aerohive offers an innovative wireless product that does not require wireless controllers, which seems ideally suited for branch, remote, and home offices where duplicating hardware controllers is prohibitively expensive. One of the company's advantages that make this possible is the "ground-up" design effort that has gone into this product, unencumbered by design choices made 5-7 years ago when the controller-based model emerged to provide system-wide coordinated intelligence required for many wireless LAN functions (radio management, configuration management, key caching, etc.). This gives Aerohive a fresh swing at innovating without the R&D and customer support of legacy product hampering budgets and resources.

For more information about Aerohive and their solution, see their website and resources. Part of the excitement of working in Wi-Fi is the current state of the market, which is extremely innovative, fast-paced, and heating up competitively.

Recently, I've had the opportunity to gain some exposure to Aerohive's line of equipment. As I work through learning and understanding their solution, I'd like to take the opportunity to share what I find.

What is a "Hive"?
In Aerohive's architecture, a "Hive" simply refers to a logical collection of wireless access points that exchange control plane information with one another to facilitate distributed system-wide network intelligence. The HiveAPs coordinate the following functions:

• Consistent QoS policy enforcement
• Seamless layer 2 and layer 3 roaming
• Dynamic best-path routing of client data
• Automatic radio frequency and power selection
• Client traffic tunneling between APs for layer 3 roaming and guest termination

HiveAP Provisioning
The first (post-design) implementation step in deploying a network of HiveAPs is to setup the management console and provision APs.

HiveManager is the company's management console, which I will dive into piecemeal throughout my exposure to their product line and features. Therefore, I won't go into much depth in this post on HiveManager, except to note that HiveManager is strictly a management platform for centralized monitoring and management. It is not in the critical path for network operation (control plane or data plane). The product is available as both an enterprise appliance for hosting within customer premises, or as a virtual appliance hosted by Aerohive as a managed service in the cloud.

Once HiveManager is operational, provisioning of APs can begin. HiveAPs can be configured individually or can be connected to the HiveManager for easier configuration deployment, especially for networks of more than a few access points. I will cover provisioning using HiveManager, as that is the likely scenario for most customers.

If using HiveManger Online (HMOL), upon purchase of a HiveAP customers will want to ensure that the AP serial or MAC addresses are properly registered with the HMOL Staging Server. The staging servers acts as a landing pad for HiveAPs when they cannot discover a local HiveManager appliance through discovery mechanisms listed below, or need to connect to a HMOL hosted server. The staging server redirects HiveAPs to the correct HiveManager appliance, either internal or hosted, as configured by the administrator. To ensure HiveAP registration in these instances, login to your HMOL account and navigate to the Staging Server section.

In the "Monitor > HiveAP Access Control List" sub-tree, ensure the purchased APs are imported using either the AP serial numbers or MAC addresses.

In this instance, I am using a HMOL hosted server and the APs were registered with the staging server automatically when purchased. I'm not sure if this an automatic process for all customers or is unique to my account at this time.

HiveAPs follow a very similar discovery and connection process for HiveManager as most thin-AP architectures for controller discovery. HiveAPs use the CAPWAP protocol for management, and perform the following steps for HiveManager discovery:

1. Manual Configuration - Manually configure the HiveManger IP address or domain name through the AP command line interface. Login to the AP via console using the default username "admin" and password "aerohive". Configure the HiveManager with the command "capwap client server name <name_or_IP>".
2. Layer 2 Broadcast - HiveAPs broadcast within the layer 2 domain (subnet) for a HiveManager appliance or Virtual HiveManager (VHM) appliance.
3. DHCP Options 225 & 226 - Specify the HiveManager server in a DHCP option returned to the AP. Option 225 specifies a domain name and option 226 specifies an IP address. Only one option is required.
4. DNS Resolution - If no HiveManager server was specified by DHCP options, then the HiveAP attempts to resolve "hivemanager.localdomain", where the local domain name assigned through DHCP is appended. If this name resolves to a valid IP address the HiveAP attempts to join the HiveManger at that address.
5. HMOL Staging Server - HiveAPs attempt to reach  the HMOL Staging server at staging.aerohive.com. If the staging server has the AP registered, it will redirect the AP to the configured HiveManager server. If the client is using a VHM cloud appliance then the AP is redirected to hm-online.aerohive.com.

Basic HiveManager Connection Protocols (not an exhaustive list):

• CAPWAP (UDP port 12,222) - Used between the HiveAPs and HiveManager appliance for AP management.
• SCP (TCP port 22) - Used by HiveManager for full configuration and image uploads to HiveAPs.
• NTP (UDP port 123) - Used by HiveAPs for time synchronization with HiveManager.

Determine the method you will use for HiveManager discovery, deploy the necessary configuration to DHCP, DNS, or firewalls, then power on the HiveAP. The AP should then discover the server and connect.

If using the HMOL staging server, check the redirection status of the AP on the "Monitor > HiveAPs" sub-tree:

Once the HiveAP has discovered  a HiveManager appliance, verify the HiveAP has connected using CAPWAP by logging into HiveManager and looking at the "Monitor > Access Points > HiveAPs" sub-tree section:

Verification can also be performed from the HiveAP with the following CLI command:

HiveAP#show capwap client
CAPWAP client: Enabled
CAPWAP transport mode: UDP
RUN state: Connected securely to the CAPWAP server
CAPWAP client IP: 10.10.10.60
CAPWAP server IP: 168.143.86.118
HiveManager Primary Name:hm-online.aerohive.com
HiveManager Backup Name:
CAPWAP Default Server Name: staging.aerohive.com
Virtual HiveManager Name: XYZ_Company
Server destination Port: 12222
CAPWAP send event: Enabled
CAPWAP DTLS state: Enabled
CAPWAP DTLS negotiation: Enabled
     DTLS next connect status: Enable
     DTLS always accept bootstrap passphrase:Enabled
     DTLS session status:Connected
     DTLS key type: passphrase
     DTLS session cut interval: 5 seconds
     DTLS handshake wait interval: 60 seconds
     DTLS Max retry count: 3
     DTLS authorize failed: 0
     DTLS reconnect count: 0
Discovery interval: 5 seconds
Heartbeat interval: 30 seconds
Max discovery interval: 10 seconds
Neighbor dead interval:105 seconds
Silent interval: 15 seconds
Wait join interval: 60 seconds
Discovery count: 0
Max discovery count: 3
Retransmit count: 0
Max retransmit count: 2
Keepalives lost/sent: 1/3185
Event packet drop due to buffer shortage: 0
Event packet drop due to loss connection: 1
HiveAP#

Now that the HiveAP is connected to HiveManager, we're ready to begin configuration!

Overall, the HiveAP provisioning process is straightforward and simple. Check back for more information on the Aerohive solution as I work through my lab deployment!

Cheers,
Andrew