Showing posts with label hivemanager. Show all posts
Showing posts with label hivemanager. Show all posts

Wednesday, April 20, 2011

Aerohive HiveAP Initial (Guided) Configuration

Once armed with HiveAPs that are provisioned and have successfully connected to the HiveManager system, and a working knowledge of the HiveManager configuration workflow, we are ready to create and deploy an initial configuration to our HiveAPs.

Administrators can opt to configure the HiveAPs through the Guided Configuration or the Advanced Configuration. I recommend that administrators use the guided configuration until they are comfortable and fully understand all of the settings contained in the advanced configuration section.

Guided Configuration
As the HiveManger online help system states:
"When you first start using HiveManager, the number of configuration objects can be somewhat overwhelming. Common questions that arise at this stage are "What do I need to configure?" and "Where do I begin?"
HiveManager Guided Configuration Section
Luckily, the HiveManager Guided Configuration takes the administrator through the basic configuration steps required to setup HiveAPs to get a WLAN up and running. Navigate to the "Configuration" section of HiveManager. The Guided Configuration section will be visible along the left side of the screen (shown right).

To create a basic configuration to get up-and-running, we'll tackle the basic settings for each of the four objects described in the HiveManager workflow, as well as provide an overview of the optional settings in each section. Note - we will configure individual "HiveAPs" at the end, as it makes a bit more sense to do this last.

Additionally, the HiveManager Help system is context-sensitive, so if you get stuck or need to lookup an item you are unfamiliar with you can simply select Help > HiveManager Help from the upper right corner.

Note - Configuration of these profiles does not affect the current operation of the wireless network until they are applied to HiveAPs and the updated configuration is pushed out, which is covered at the end of this article.

User Profiles
Create a new user profile which controls the default settings applied to users mapped to this profile. User profiles can be applied to users statically through SSID assignment or dynamically through RADIUS assignment based on returned attributes by the server.

Basic settings include the default VLAN access and the Attribute Number used for RADIUS policy assignment of users into the correct user profile. RADIUS attributes 64, 65, and 81 are used for both VLAN and User Profile assignment, with different values of-course (shown below).

Mapping LDAP User Groups to Local User Profiles with RADIUS Attributes
Optional settings in this section include GRE or VPN tunneling for station isolation (guest WLANs) or other security requirements, L2/L3 firewall policies, QoS settings for rate limiting, queuing, and call admission control (CAC), user profile availability schedule (day & time restrictions), and SLA settings for throughput and airtime fairness.

It should also be noted that many of the settings nested within these main objects are linked to corresponding Advanced Configuration objects. These links can be followed by clicking on the "Plus" (Add) or "Notepad" (Modify) icons next to the configuration item. Once the advanced item has been configured, the user is returned to the main object to continue configuration where they left off. 

Link to Add or Modify an Advanced Configuration Item
SSID Profiles
Within the SSIDs configuration section, administrators define logical wireless networks that control the methods by which client and access points communicate with each other, which often includes authentication and encryption settings (as shown below).

SSID definition and security settings configuration in HiveManager
Advanced Access Security Settings can be displayed where indicated by the red line by clicking the link in the figure above. This allows the administrator to fine-tune Group and Pairwise (User) encryption key lifetimes and timers, including an option to enable Proactive / Opportunistic Key Caching (PKC/OKC).

It should also be noted that Aerohive has developed a unique feature called Private Pre-Shared Key (PPSK), that enables the provisioning of unique PSKs to individuals, rather than sharing a single WPA/WPA2 PSK with everyone on the same network. This prevents users from eavesdropping on each other, makes network access revocation tied to individual users, and eases access revocation by eliminating the need to update PSKs on all workstations any time an individual user access is revoked. This is a great feature for small businesses with growing user bases to maintain network security and manageability without having to invest in enterprise class authentication with 802.1x/EAP. Often times small businesses struggle with the expertise, expense, and support involved with deploying an 802.1x solution, and this helps them transition and scale until they are ready. PPSKs are also useful in guest networking scenarios as an alternative to an open network, typically with a clerk, concierge, or attendant providing guests with unique PSKs upon arrival at the establishment.

User profiles are also assigned to users connected to this SSID. In the User Profiles for Traffic Management section, define the default user profile for all users accessing this SSID. Optionally, if using WPA/WPA2 802.1x (Enterprise) also select the user profiles that are allowed to be dynamically assigned to users by a RADIUS server. If the RADIUS server does not return a user profile attribute, or returns a non-selected user profile from the list, then the default user profile is applied. For advanced security, strict enforcement of selected user profiles available for dynamic assignment can be applied, and can be configured to instruct the access point to either disconnect the user, ban the user for period of time (e.g. 60 sec.), or ban the user forever. This is a great security feature which allows a single RADIUS server (or server cluster) to handle authentication for multiple user groups while still enforcing strict network access policies. This prevents SSID hopping whereby a valid user who authenticates successfully connects to a different SSID to gain higher privileged network access rights.

Optional settings in the SSID profile include radio data rates for both 2.4 GHz and 5 GHz network bands, denial of service prevention settings, traffic filtering for management access and client-to-client traffic handling, SSID availability schedules (day & time restrictions), and several advanced configuration settings such as maximum client limit, DTIM period, fragmentation threshold, Wi-Fi Multimedia (WMM), SSID broadcast / hiding, and U-APSD power save.

WLAN Policies
The WLAN policy is the top-level object underneath which all other configuration objects are stored (except for individual HiveAP settings), and are pushed to HiveAPs to apply the operational network settings. As such, the WLAN policy ties together many objects which have previously been configured with a few new ones.

After giving the WLAN policy a name and description, define the Hive that will be used for all access points which are assigned this WLAN policy. A Hive essentially allows multiple HiveAPs to coordinate distributed wireless network control plane and data plane operations, forming a virtual software controller using Aerohive's Cooperative Control architecture. This includes forwarding and routing paths, consistency of QoS and firewall policy enforcement, layer 2 and layer 3 client roaming, and radio frequency and power management. Hive members may be on the same subnet or different subnets. It is recommended that all HiveAPs which clients can seamlessly roam between (without disconnecting) be included in the same Hive.

Configuring a WLAN Policy in HiveManager
Next, add one or multiple SSID profiles to the WLAN policy, which defines the SSIDs that will be pushed to the HiveAPs for network access. Also define the default management interface VLAN and native (untagged) VLAN for the HiveAPs. These VLAN settings help administrators segment management traffic from user traffic to meet performance and security requirements common in most organizations.

Optional settings in the WLAN policy include HiveAP physical interface traffic filters, service settings for application layer gateway (ALG) and WIPS, management servers for SNMP, syslog, DNS, NTP, and location services, QoS classification and marking, dynamic airtime scheduling, VPN service settings for identity-based tunneling (guest DMZ termination for example), and statistics collection settings.

Note - QoS classification and marking is performed globally within the HiveAP, but QoS queuing structures are defined per user-profile.

Note - If you plan on assigning HiveAPs static IP addresses, ensure that DNS servers are defined in the WLAN policy applied to the AP so that it can resolve and connect to HiveManager.

Individual HiveAP Settings
In addition to User, SSID, and WLAN Policy settings, unique settings can be configured for individual HiveAPs. Select the "HiveAPs" link from the Guided Configuration section, which will redirect to the Monitor > HiveAPs screen. Be sure to select the "Config" option button before drilling into an AP to modify the configuration instead of viewing statistics.

Once in an individual HiveAP, administrators can configure various settings that are typically unique to a single AP. These include host name, map location, assigned WLAN policy, radio modes (access, bridge, mesh), and static channel and power settings.

Configuring individual HiveAP settings


Note - To assign a WLAN Policy to multiple HiveAPs at once, select the check boxes next to each HiveAP in the Monitor > HiveAPs screen and click the Modify button. A subset of HiveAP settings are available for configuration across the selected APs.

Optional settings include configuring the built-in captive web portal and RADIUS functions, DHCP or static IP address assignment, static layer 3 roaming neighbors (beyond the dynamically discovered Hive members), administrative security credentials for console access and CAPWAP security to HiveManager, layer 2/3 routing, VLAN tag settings (override WLAN policy), and HiveAP classification (for use in variable substitution with network objects).

Updating the HiveAP Configuration
Now that all four of the Guided Configuration sections have been completed, it's time to deploy the configuration to HiveAPs.

As a precautionary step, review the configuration audit status of the access points prior to deployment to verify accuracy of the updated configuration that will be pushed to the AP. To do this, navigate to the Monitor > HiveAPs screen, ensure the "Monitor" radio button is selected, and click the red triangle next to a HiveAP to view the configuration audit.

Viewing HiveAP configuration audit details
If satisfied with the configuration items, check the box next to every HiveAP to be updated and select the Update > Upload and Activate Configuration button. Configure the desired settings which instructs how HiveManager peforms the upload, including either a complete or delta upload and activation schedule, then click the save icon. The settings section will roll upwards, allowing the administrator click the Upload button and push the settings to the HiveAPs.

Configuring the HiveManager Upload Settings

The user will be redirected to the HiveAP Update Results screen, which will show the progress of the upload and report any issues that may occur.

Viewing HiveAP Update Results

If successful, the settings configured in HiveManager are now active on the HiveAPs and the wireless network should be fully operational.

Tuesday, April 19, 2011

Aerohive HiveManager Configuration Workflow

Now that the Aerohive HiveAPs have been provisioned so they can discover and connect to a HiveManager management server, let's dive into how HiveManager handles configuration workflow, object definition, and nesting. This will serve as a foundation to prepare us to deploy an initial configuration to our HiveAPs.

The HMOL dashboard shows a new access point is connected
Initial Configuration State
Log into the HiveManager dashboard to get started. If you're using Aerohive's cloud management service, connect to HiveManager Online (HMOL) at https://myhive.aerohive.com and login using your supplied account credentials. From the "Navigate myHive" splash page, select "HiveManager Online" to access the management console. Once there, you should see the new access point listed in the Dashboard.

Navigating over to the Monitor - HiveAPs section, you can see that the access point connection details. You can also get to this page by clicking the "Number of New APs" hyperlink from the Dashboard.

The HiveAP monitor page shows the access point connection details
On this screen, notice that the AP is currently connected (green chain-link), the connection is secured (green padlock), and it is in Portal mode which integrates directly with the Ethernet network, as opposed to a Mesh Point that uses a wireless backhaul into the network through other mesh points or a portal.

Hovering over the red triangle in the audit column displays the pop-up message telling you that no configuration has been pushed to the AP yet. The red triangle alerts administrators that the current configuration on the AP does not match the desired configuration based on HiveManager templates assigned to the AP. Two green squares in the audit column would indicate that the configuration matches the defined template and no action is necessary.

HiveManager Configuration Workflow
Before jumping into the configuration, it's important to understand the workflow used within the system to define configuration items and how items relate to one another. Many enterprise wireless vendors implement a logical nesting, or roll-up, of foundational configuration items into larger groupings / profiles which then are applied to the equipment. This allows for creation of multiple profiles and easier testing, verification, and deployment.

The HiveManager configuration workflow consists of the following configuration items, nesting relationships, and profile objects which are then assigned to individual HiveAPs:


It is readily apparent from this workflow that configuration of four main objects is required:
  1. User Profiles
  2. SSIDs
  3. WLAN Policies
  4. Managed HiveAP Settings
Now that we have an understanding of the logical workflow and object nesting within HiveManager, we are prepared to define and deploy a working configuration to our HiveAPs.

Cheers,
Andrew

Monday, March 14, 2011

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