| Download: |  |
| Mirror Download [FCC.gov] | |
| Document ID | 1000281 |
| Application ID | hbc1bO7V52tgQkJQb57Ecg== |
| Document Description | Users Manual 4 |
| Short Term Confidential | No |
| Permanent Confidential | No |
| Supercede | No |
| Document Type | User Manual |
| Display Format | Adobe Acrobat PDF - pdf |
| Filesize | 396.66kB (4958235 bits) |
| Date Submitted | 2008-09-12 00:00:00 |
| Date Available | 2008-09-12 00:00:00 |
| Creation Date | 2008-08-15 14:44:55 |
| Producing Software | Acrobat Distiller 8.1.0 (Windows) |
| Document Lastmod | 2008-09-12 12:02:58 |
| Document Title | Aerohive Deployment Guide |
| Document Creator | FrameMaker 7.2 |
| Document Author: | Aerohive Technical Publications |
Chapter 8 HiveManager Configuration Examples
This chapter contains a sequential flow of examples that show how to import and organize maps, install HiveAPs on
the network and link them to maps, configure typically needed features, assign these features to HiveAPs, and push
configurations to the HiveAPs across the network. The examples are as follows:
•
"Example 1: Mapping Locations and Installing HiveAPs" on page 91
Upload image files of topology maps to HiveManager and use one of two ways to associate physical HiveAPs
with their corresponding icons on the maps.
•
"Example 2: Defining Network Objects and MAC Filters" on page 97
Define a MAC OUI (organizationally unique identifier), VLANs, and IP addresses for use by other
configuration objects. Define a MAC filter so that QoS classifiers and SSID profiles can reference them. Map
the MAC OUI and several services to Aerohive classes.
•
"Example 3: Providing Guest Access" on page 104
Provide controlled and limited network access for guests. Two approaches are presented.
•
"Example 4: Creating User Profiles" on page 113
Define several user profiles, their companion QoS forwarding rates and priorities, and their VLANs.
•
"Example 5: Setting SSIDs" on page 117
Define sets of authentication and encryption services that wireless clients and HiveAPs use when
communicating with each other.
•
"Example 6: Setting Management Service Parameters" on page 120
Configure DNS, syslog, SNMP, and NTP settings for HiveAPs.
•
"Example 7: Defining AAA RADIUS Settings" on page 123
Define AAA RADIUS server settings to use when HiveAPs send 802.1X authentication requests.
•
"Example 8: Creating Hives" on page 125
Create hives so that sets of HiveAPs can exchange information with each other over the network to
coordinate client access, provide best-path forwarding, and enforce QoS policies.
•
"Example 9: Creating WLAN Policies" on page 126
Define WLAN policies. These are sets of configuration objects (defined in previous examples) that HiveAPs
use to control how wireless clients access the network.
•
"Example 10: Assigning Configurations to HiveAPs" on page 135
Assign WLAN policies, radio profiles, and maps to detected HiveAPs so that you can begin managing them
through HiveManager. Also change HiveAP login settings and country codes.
90
Aerohive
EXAMPLE 1: MAPPING LOCATIONS AND INSTALLING HIVEAPS
EXAMPLE 1: MAPPING LOCATIONS AND INSTALLING HIVEAPS
HiveManager allows you to mark the location of HiveAPs on maps so that you can track devices and monitor their
status. First, you must upload the maps to HiveManager, and then name and arrange them in a structured hierarchy
(see "Setting Up Topology Maps"). After that, you can follow one of two ways to install HiveAPs so that you can later
put their corresponding icons on the right maps (see "Preparing the HiveAPs" on page 94).
Note: All image files that you upload to HiveManager must be in .png or .jpg format.
Setting Up Topology Maps
In this example, you upload maps to HiveManager showing floor plans for three office buildings and organize them in
a hierarchical structure. You need to make .png of .jpg files of drawings or blueprints showing the layout of each
floor. Also, as an easy means of organizing the maps in the HiveManager GUI, you create a file showing the three
buildings HQ-B1, HQ-B2, and Branch-1. By using this drawing at the top topographical level, you can display icons for
each floor of each building. You can then click an icon to link to its corresponding map. This is shown in Figure 2.
Figure 2 Organizational Structure of Level-1 and -2 Maps
Level 1
CorpOffices (Level-1 Map)
This map shows 3 buildings and 20 icons that link to level-2 maps.
Double-clicking a floor icon on the CorpOffices map
(level 1) opens the corresponding level-2 map.
You can also navigate to any map within the
Topology Maps section of the navigation tree in the
HiveManager GUI.
8 icons linking
to level-2 maps
8 icons linking
to level-2 maps
4 icons linking
to level-2 maps
Level 2
Headquarters Building 1 (HQ-B1) Maps
Headquarters Building 2 (HQ-B2) Maps
“HQ-B1-F8”
“HQ-B2-F8”
8 Maps
(one per floor)
8 Maps
“HQ-B1-F1”
“HQ-B2-F1”
Branch-1 Maps
“Branch-1-F4”
4 Maps
“Branch-1-F1”
Uploading Maps
1. Log in to the HiveManager GUI as explained in " Installing and Connecting to the HiveManager GUI" on page 79.
2. Click Topology, right-click World, and then choose Add/Delete Image from the pop-up menu that appears.
3. In the Add/Delete Image window, click Browse, navigate to the directory containing the image files that you
want to upload, and select one of them.
4. Click Upload.
Deployment Guide
91
Chapter 8 HiveManager Configuration Examples
The selected image file is transferred from your management system to HiveManager as shown in Figure 3.
Figure 3 Uploading a Map of a Building Floor Plan
Map showing one
of the floor plans
Management System
HiveManager
Uploading map to HiveManager
5. Repeat this for all the image files that you need to load. In this example, you load 21 files:
•
8 maps for the eight floors in HQ-B1 (Headquarters Building 1)
•
8 maps for the eight floors in HQ-B2 (Headquarters Building 2)
•
4 maps for the four floors in Branch-1
•
1 file (named "corp_offices.png" in this example) that shows a picture of the three buildings
Naming and Arranging Maps within a Structure
1. Click Topology, right-click the top level map "World", and then choose Edit from the pop-up menu that appears.
2. In the Edit Map - World dialog box, enter the following, and then click Update:
•
Map Name: CorpOffices (Note that spaces are not allowed in map level names.)
•
Map Icon: Building
•
Background Image: Choose corp_offices.png from the drop-down list.
•
Environment: Because the CorpOffices "map" does not contain any HiveAP icons—it is an illustration of three
buildings that you use to organize the submaps of the floors in each building—the environment setting is
irrelevant. Leave it at its default, Free Space.
•
Width (optional): Because the corp_offices.png depicts buildings instead of a floor plan, it is not necessary
to specify the width of the image.
3. Click Topology, right-click the top level map "CorpOffices", and then choose New from the pop-up menu that
appears.
4. In the New Map (Submap for CorpOffices) dialog box, enter the following, and then click Create:
•
Map Name: HQ-B1-F
•
Map Icon: Floor
•
Background Image: Choose HQ-B1-F1.png from the drop-down list.
•
Environment: Because the environment is that of a typical office building, choose Enterprise. The
environment assists in the prediction of signal strength and attenuation shown in the heat maps.
•
Width: 80 feet (HiveManager automatically calculates the height based on the aspect ratio of the image.)
A white floor icon (
) labeled "HQ-B1-F1" appears on the CorpOffices image, and a new entry named
"HQ-B1-F1" appears nested under "CorpOffices" in the navigation tree.
5. Click Unlock, select the icon, drag it to the location you want, and then click Save.
6. Click Topology, right-click the top level map "CorpOffices", and then choose New from the pop-up menu that
appears.
92
Aerohive
EXAMPLE 1: MAPPING LOCATIONS AND INSTALLING HIVEAPS
7. In the New Map (Submap for CorpOffices) dialog box, enter the following, and then click Create:
•
Map Name: HQ-B1-F2
•
Map Icon: Floor
•
Background Image: Choose HQ-B1-F2.png from the drop-down list.
•
Environment: Enterprise
•
Width: 80 feet
A white floor icon labeled "HQ-B1-F2" appears on the CorpOffices image, and a new entry named "HQ-B1-F2"
appears nested under "CorpOffices" in the navigation tree.
8. Click Unlock, select the icon, drag it to the location you want, and then click Save.
After adding the CorpOffices "map" (really an illustration showing three buildings), two floor plans for the first
and second floors of "HQ-B1", and dragging the floor icons into position, the display of the CorpOffices map
looks similar to that in Figure 4.
Figure 4 CorpOffice Map (Level 1) with Links to Level-2 Maps HQ-B1-F1 and HQ-B1-F2
The submaps in the
navigation tree and the
icons on this map link
to other maps.
Click a submap or
double-click an icon to
open the map to which
it links.
9. Repeat this process until you have arranged all the maps and icons in place as shown in Figure 5.
Figure 5 CorpOffice Map with Links to All Level-2 Maps
Note: You can add as many levels as necessary to the map hierarchy. You can also delete maps as long as they
do not have any submaps or HiveAP icons on them.
Deployment Guide
93
Chapter 8 HiveManager Configuration Examples
Preparing the HiveAPs
There are several approaches that you can take when mapping the location of installed HiveAP devices. Two
possible approaches are presented below. With the first approach ("Using SNMP"), HiveManager automatically assigns
HiveAPs to maps. This approach does require a small amount of configuration of each HiveAP up front, but after the
HiveAPs form a CAPWAP connection with HiveManager, the automatic assignment of HiveAPs to their appropriate
maps on HiveManager occurs without any further effort. The second approach ("Using MAC Addresses" on page 95)
allows you to install HiveAPs without needing to do any extra configurations, but you later have to match each
HiveAP with the right map in HiveManager manually.
Note: For a summary of how HiveAPs use CAPWAP to discover and connect to HiveManager, see "How HiveAPs
Connect to HiveManager" on page 95.
Using SNMP
This approach makes use of the SNMP (Simple Network Management Protocol) sysLocation MIB (Management
Information Base) object, which you define on HiveAPs. HiveManager can use this information to associate a HiveAP
with a map and provide a description of where on the map each HiveAP belongs.
1. Make copies of the maps you uploaded to HiveManager, label them, and take them with you for reference when
installing the HiveAPs.
2. For each HiveAP that you install, do the following:
1. Make a serial connection to the console port, and log in (see "Log in through the console port" on page 150).
2. Enter the following command, in which string1 describes the location of the HiveAP on the map (in open
format) and string2 is the name of the map:
snmp location string1@string2
For example, if you install a HiveAP in the northwest corner on the first floor of building 1, enter
snmp location northwest_corner@HQ-B1-F1. If you want to use spaces in the description, surround
the entire string with quotation marks: snmp location "northwest corner@HQ-B1-F1".
If the name of a map is not unique, then include the map hierarchy in the string until the path to the map is
unique. For example, if you have two maps named "floor-1", and the one you want to use is nested under a
higher level map named "building-1" while the other is nested under "building-2", then enter the command
as follows: snmp location northwest_corner@floor-1@building-1 . Similarly, if there are two
maps named "building-1" nested under higher level maps for two different sites ("campus-1" and "campus-2",
for example), then include that next higher level in the string to make it unique:
snmp location northwest_corner@floor-1@building-1@campus-1
3. Mount and cable the HiveAP to complete its installation. (For mounting details, see "Mounting the HiveAP
20" on page 29. For information about the PoE port on the HiveAP, see "Ethernet and Console Ports" on
page 26.)
When a HiveAP connects to HiveManager, HiveManager checks its SNMP location. When you accept the HiveAP for
management, then HiveManager automatically associates it with the map specified in its SNMP location description.
You can then click the icon to see its location and drag it to the specified location on the map. Also, on the Access
Points > New HiveAPs > Automatically Discovered window in the HiveManager GUI, you can sort detected HiveAPs by
map name to assign them more easily to WLAN policies and radio profiles.
94
Aerohive
EXAMPLE 1: MAPPING LOCATIONS AND INSTALLING HIVEAPS
Using MAC Addresses
With this approach, you write down the MAC address labelled on the underside of each HiveAP and its location while
installing the HiveAPs throughout the buildings. The MAC address on the label is for the mgt0 interface. Because the
MAC addresses of all HiveAPs begin with the Aerohive MAC OUI 00:19:77, you only need to record the last six
numerals in the address. For example, if the MAC OUI is 0019:7700:0120, you only need to write "000120" to be able
to distinguish it from other HiveAPs later.
1. Make copies of the maps you uploaded to HiveManager, label them, and take them with you when installing the
HiveAPs.
2. When you install a HiveAP, write the last six digits of its MAC address at its location on the map.
When HiveAPs automatically connect with HiveManager, HiveManager displays them in the Access Points > New
HiveAPs > Automatically Discovered window. You can differentiate them in the displayed list by MAC address (node
ID), which allows you to match the HiveAPs in the GUI with those you noted during installation so that you can
properly assign each one to a map, a WLAN policy, and two radio profiles.
How HiveAPs Connect to HiveManager
If HiveAPs are in the same layer-2 broadcast domain (and same VLAN) as HiveManager, they broadcast CAPWAP
(Control and Provisioning of Wireless Access Points) Discovery Request messages to discover and establish a secure
connection with HiveManager automatically. There is no need for any extra configuration on your part.
When HiveAPs and HiveManager are in different subnets, the HiveAPs will not be able to discover HiveManager by
broadcasting CAPWAP Discovery Request messages. In this case, you can use one of the following methods to
configure HiveAPs with the HiveManager IP address or configure them so that they can learn it through DHCP or DNS.
When HiveAPs have the HiveManager IP address, they then send unicast CAPWAP Discovery Request messages to that
address.
•
Log in to the CLI on each HiveAP and enter the HiveManager IP address with the following command, in which
the variable ip_addr is the address of the interface through which HiveManager communicates with HiveAPs:
hivemanager ip_addr
•
Configure the DHCP server to supply the HiveManager domain name as DHCP option 225 or its IP address as
option 226 in its DHCPOFFER. (If you use a domain name, the authoritative DNS server for that domain must also
be configured with an A record that maps the domain name to an IP address for HiveManager.) HiveAPs request
DHCP option 225 and 226 by default when they broadcast DHCPDISCOVER and DHCPREQUEST messages.
Note: If you need to change the DHCP option number (perhaps because another custom option with that
number is already in use on the DHCP server), enter this command on each HiveAP with a different
option number for the variable number:
interface mgt0 dhcp client option custom hivemanager number { ip | string }
•
If HiveManager continues to use its default domain name ("hivemanager"), configure the local authoritative DNS
server with an A record that resolves that name to an IP address. If the HiveAPs do not have a static IP address
configured for HiveManager and do not receive an address or domain name returned in a DHCP option, then they
try to resolve the domain name "hivemanager" to an IP address.
Within the framework of the CAPWAP protocol, HiveAPs are CAPWAP clients and HiveManager is a CAPWAP server.
The client proceeds through a series of CAPWAP states. These states and the basic events that trigger the client to
transition from one state to another are shown in Figure 6 on page 96.
Note: To illustrate all possible CAPWAP states, Figure 6 on page 96 begins by showing a HiveAP and HiveManager
already in the Run state. When a HIveAP first attempts to discover a HiveManager—after the HiveAP has an
IP address for its mgt0 interface and has been configured with (or has discovered) the HiveManager IP
address—it begins in the Discovery state.
Deployment Guide
95
Chapter 8 HiveManager Configuration Examples
Figure 6 CAPWAP Process—Beginning from the Run State
CAPWAP Client
(HiveAP)
Run
State
CAPWAP Server
(HiveManager)
The CAPWAP client (HiveAP) pings the CAPWAP server (HiveManager)
but receives no responses within the neighbor-dead-interval.
...
Idle
State
Discovery
State
When the client determines its neighbor is dead, it transitions
from the Run state to the Idle state.
The client transitions to the Discovery state and begins sending
Discovery Request messages (broadcast or unicast).
...
Sulking
State
Discovery
State
If the client continues to send Discovery Request messages until it
reaches the max-discovery-interval and max-discovery-count but
receives no Discovery Responses, the client then enters the Sulking
state and remains in this state until the silent-interval elapses.
The CAPWAP client returns to the Discovery state and sends
Discovery Request messages.
The CAPWAP server receives the Discovery Request message
and responds with a Discovery Response.
The CAPWAP client and server perform a DTLS (Datagram Transport
Layer Security) handshake to establish a secure DTLS connection.
Join
State
The client sends a Join Request.
The server sends a Join Response.
If the Join Response indicates “success”, the client
clears its WaitJoin timer and enters the Run state.
Note: If the WaitJoin timer expires before the client
receives a successful Join Response, the client
terminates the DTLS connection and returns to the
Discover state.
96
If the Join Response indicates “failure”,
the CAPWAP server enters a Reset
state and terminates the DTLS session.
Aerohive
EXAMPLE 2: DEFINING NETWORK OBJECTS AND MAC FILTERS
EXAMPLE 2: DEFINING NETWORK OBJECTS AND MAC FILTERS
Network objects are the most basic objects that you can configure and only function when other objects such as QoS
classifiers, SSID profiles, and firewall policy rules reference them. IP addresses, network services (HTTP, SMTP,
FTP, …), MAC addresses, MAC OUIs (organizationally unique identifiers), VLANs, Ethernet profiles, and radio profiles
are network objects that make no reference to any other previously defined object.
You define the following network objects that you reference in other examples later in this chapter:
•
MAC OUI for filtering VoIP phone traffic
•
VLANs that you can apply to user profiles
•
IP addresses that you can assign to management services and RADIUS servers
In addition, you define a MAC filter to control access to the SSID for VoIP traffic.
Defining a MAC OUI
You define a MAC OUI for the type of VoIP (Voice over IP) phones in use in the network and assign traffic from it to
Aerohive class 6. Other critical IP telephony services are DHCP and DNS for address and domain name assignments,
and TFTP and HTTP for configuration downloads and software updates. You map traffic using destination port
numbers 53 (DNS) and 67 (DHCP) to Aerohive class 5. This is a fairly high priority level because these services are
vital for VoIP to work properly; however, they are not as high as that for the voice traffic itself. Finally, you map
traffic using destination port numbers 69 (TFTP) and 80 (HTTP) to Aerohive class 2. This is a much lower priority
level, but it is appropriate for these resilient and less time-sensitive services. HiveAPs check if an incoming packet
matches a classifier map by checking for matches in the following order. They then use the first match found:
1. Service
2. MAC OUI
3. Ingress interface
4. Existing priorities used by various standard QoS classification systems (802.11e, 802.1p, and DSCP)
After VoIP clients associate with an SSID and begin sending traffic, the HiveAP maps all DNS and DHCP traffic to class
5, all TFTP and HTTP traffic to class 2, and all remaining traffic—voice traffic in this case—to class 6 (see Figure 7).
Figure 7 MAC OUI and Service Classifier Maps for VoIP Phones
HiveAP
VoIP Phones from the same
vendor (MAC OUI 01:22:34)
When the destination port number in the L4
header is 53 (DNS) or 67 (DHCP), the
HiveAP maps the packet to Aerohive class 5.
When it is 69 (TFTP) or 80 (HTTP), the
HiveAP maps it to Aerohive class 2.
MAC OUI
01:22:34:BF:6C:04
Destination Port Number
Wireless L2
Header
L3
Header
L4
Header
Data
HiveAP
Aerohive Class
01:22:34:57:0B:3F
01:22:34:5D:00:02
Deployment Guide
When the MAC OUI in the L2 header is
01:22:34, the HiveAP maps the packet to
Aerohive class 6.
97
Chapter 8 HiveManager Configuration Examples
By distinguishing voice traffic by the clients’ OUI and mapping it to class 6, HiveAPs can prioritize it above other
traffic types (see "Example 4: Creating User Profiles" on page 113).
1. Log in to the HiveManager GUI.
2. Click Configuration > Network Objects > MAC Addresses/OUIs > New.
3. Enter the following, and then click Save:
•
MAC OUI: (select)
•
MAC Name: Type a name such as "VoIP_Phones". You cannot include any spaces when defining a MAC name.
Enter the following, and then click Apply:
•
MAC Entry: Type the OUI for the VoIP phones used in the network; that is, type the first six numbers
constituting the vendor prefix of the MAC address. For example, if a MAC address is 01:22:34:AB:6C:04,
the OUI is 01:22:34. Type only the hexadecimal numerals without any formatting symbols such as colons
or dashes. If you do type such symbols, the GUI ignores—and does not display—them.
•
Type: Choose Global because you do not need to restrict this network object to a particular set of
HiveAPs, which is what the other three options allow you to do.
•
Description: Type a meaningful comment for the MAC OUI, such as the vendor that the OUI identifies.
Note: If there are phones from more than one vendor, make a separate MAC OUI entry for each one.
Mapping the MAC OUI and Services to Aerohive Classes
First, map VoIP phone MAC OUIs to Aerohive class 6. Next, map DNS and DHCP services to Aerohive class 5 and TFTP
and HTTP services to class 2. Because voice traffic is the only remaining type of traffic from phones whose MAC OUIs
you have already mapped to class 6, HiveAPs map voice traffic from those phones to class 6. Although all these
services are critical for IP telephony to function properly, voice traffic is the least resistant to delay, and TFTP and
HTTP file downloads are the most resistant. Therefore, you prioritize the different types of traffic accordingly.
1. Click Configuration > QoS Policies > Classifiers and Markers > New.
The New Classifiers and Markers dialog box appears.
2. Enter the following, and then click Save:
•
Name: VoIP-QoS (You cannot include any spaces when defining a QoS policy name.)
•
Description: Add a descriptive comment, such as "Mapping for VoIP phone traffic".
•
Network Services: (select)
•
MAC OUIs: (select)
3. Click Configuration > QoS Policies > Classifier Maps > New > General.
The New Classifier Maps dialog box appears.
4. Enter the following on the General page:
98
•
Name: VoIP-Mapping (You cannot include any spaces when defining the name of a classifier map.)
•
Description: Add a descriptive comment, such as "Mapping services and OUIs for VoIP phone traffic".
•
Network Services: (select)
•
MAC OUIs: (select)
Aerohive
EXAMPLE 2: DEFINING NETWORK OBJECTS AND MAC FILTERS
5. Click the Network Services tab, enter the following, and then click Apply:
•
Service: DNS
•
QoS Class: 5 - Video
•
Action: Permit
•
Logging: Select the check box to enable HiveAPs to log traffic that matches the service-to-Aerohive class
mapping. (HiveAPs log traffic whether the action is permit or deny.) The main use of logging traffic is to see
if the HiveAPs are receiving expected—or unexpected—types of traffic when you debug connectivity issues.
You can see the log entries in the event log on the HiveAPs (show logging buffered). Also, if you
configure the HiveAP to send event logs to a syslog server, you can see the log entries there (see "Example
6: Setting Management Service Parameters" on page 120).
6. Enter the following, and then click Apply:
•
Service: DHCP-Server
•
QoS Class: 5 - Video
•
Action: Permit
•
Logging: Select the check box to enable traffic logging, or clear the check box to disable it.
7. Enter the following, and then click Apply:
•
Service: TFTP
•
QoS Class: 2 - Best Effort 1
•
Action: Permit
•
Logging: Select the check box to enable traffic logging, or clear the check box to disable it.
8. Enter the following, and then click Apply:
•
Service: HTTP
•
QoS Class: 2 - Best Effort 1
•
Action: Permit
•
Logging: Select the check box to enable traffic logging, or clear the check box to disable it.
9. Click the MAC OUIs tab, click New, enter the following, and then click Apply:
•
MAC OUIs: Choose the name of the MAC OUI that you defined in "Defining a MAC OUI", such as "VoIP_Phones".
•
QoS Class: 6 - Voice
•
Action: Permit
•
Comment: Enter a meaningful comment about the MAC OUI for future reference.
•
Logging: Select the check box to enable log traffic that matches the MAC OUI-to-Aerohive class mapping, or
clear the check box to disable it.
10. To save the configuration and close the dialog box, click Save.
Deployment Guide
99
Chapter 8 HiveManager Configuration Examples
Defining VLANs
You define three VLANs that you will later assign to various user profiles (see "Example 4: Creating User Profiles" on
page 113). By assigning different VLANs to different user roles, their traffic remains isolated from each other; that
is, voice traffic never shares a broadcast domain with data traffic; and data traffic from guests never shares the
same broadcast domain with employee data traffic. The result is that you can provide access for certain types of
traffic to select areas of the network while blocking unauthorized access to other areas.
The VLAN IDs and the user profiles to which you will assign them are as follows:
•
VLAN ID 1 for the Emp and IT user profiles (and for users not yet registered through a captive web portal)1
•
VLAN ID 2 for the VoIP user profile
•
VLAN ID 3 for the Guests user profile
Note: When defining the following VLANs, choose Global as the VLAN type because you do not need to restrict
these VLANs to a particular set of HiveAPs, which is what the other three options allow you to do.
1. Click Configuration > Network Objects > VLANs > New, enter the following, and then click Save:
•
VLAN Name: VLAN-1-EmployeeData
•
Enter the following, and then click Apply:
•
VLAN ID: 1
•
Type: Global
•
Description: VLAN for Emp, IT, and unregistered CWP users
2. Click Configuration > Network Objects > VLANs > (check box) VLAN-1-EmployeeData > Clone, make the
following changes, and then click Save:
•
VLAN Name: VLAN-2-EmployeeVoice
•
VLAN ID: 2
•
Type: Global
•
Description: VLAN for VoIP traffic
3. Click Configuration > Network Objects > VLANs > (check box) VLAN-2-VoIP > Clone, make the following
changes, and then click Save:
•
VLAN Name: VLAN-3-Guests
•
VLAN ID: 2
•
Type: Global
•
Description: VLAN for guests visiting corporate
1. There is a predefined VLAN definition for VLAN ID 1, so it is not really necessary to create a new VLAN object for it. However,
because later examples in this chapter refer to VLAN 1 by the name defined here ("VLAN-1-EmployeeData"), its purpose will
hopefully be clearer than if it were referred to by the simpler name of the predefined VLAN ("1").
100
Aerohive
EXAMPLE 2: DEFINING NETWORK OBJECTS AND MAC FILTERS
Creating IP Addresses
You use the IP addresses that you create here when defining management services for the HiveAPs (see "Example 6:
Setting Management Service Parameters" on page 120). The IP addresses are used for DNS, SNMP, syslog, and NTP
servers. To understand the locations of the different servers on the network, see Figure 15 on page 120.
DNS Servers
1. Click Configuration > Network Objects > IP Addresses > New, and after entering all the following, click Save:
•
Address Name: DNS-Primary
Enter the following, and then click Apply:
—
IP Address: 10.1.1.25
—
Netmask: 255.255.255.255
—
Type: Classifier
—
Value: Tag 1: hq
By classifying the IP address definition as "hq" and then later classifying all HiveAPs deployed at
headquarters as "hq", only those HiveAPs will use the 10.1.1.25 address for their primary DNS
server.
—
Description: Primary DNS server located at HQ
Enter the following, and then click Apply:
—
IP Address: 10.2.2.251
—
Netmask: 255.255.255.255
—
Type: Classifier
—
Value: Tag 1: branch1
By classifying the IP address definition as "branch1" and then later classifying all HiveAPs deployed
at the branch site as "branch1", only those HiveAPs will use the 10.2.2.251 address for their primary
DNS server. Classifying the different IP address definitions within the same IP address object allows
you to use this one object in multiple locations that have different addressing schemes.
2. Click Configuration > Network Objects > IP Addresses > New, and after entering all the following, click Save:
•
Address Name: DNS-Secondary
Enter the following, and then click Apply:
—
IP Address: 10.1.1.26
—
Netmask: 255.255.255.255
—
Type: Global
Because all the HiveAPs at both the headquarters and branch site use the same secondary DNS
server, you classify it as Global. The server is located at headquarters and HiveAPs at the branch
site reach it through a VPN tunnel.
—
Description: Secondary DNS server located at HQ
Deployment Guide
101
Chapter 8 HiveManager Configuration Examples
Syslog Server
Click Configuration > Network Objects > IP Addresses > New, and after entering all the following, click Save:
•
Address Name: Syslog-Server
Enter the following, and then click Apply:
—
IP Address: 10.1.1.23
—
Netmask: 255.255.255.255
—
Type: Global
Because all the HiveAPs at both the headquarters and branch site use the same syslog server, you
classify it as Global. The HiveAPs at the branch site reach the syslog server, which is also located at
headquarters, through a VPN tunnel.
—
Description: Syslog server at HQ
SNMP Server
Click Configuration > Network Objects > IP Addresses > (check box) Syslog-Server > Clone, change the
following settings, click Save:
•
Address Name: SNMP-Server
—
IP Address: 10.1.1.24 (This is the IP address of the SNMP management system to which the SNMP
agent running on the HiveAPs sends SNMP traps.)
—
Description: SNMP server at HQ
NTP Server
Click Configuration > Network Objects > IP Addresses > (check box) SNMP-Server > Clone, change the
following settings, click Save:
•
Address Name: NTP-Server
—
IP Address: 207.126.97.57
—
Description: NTP admin wjones@time.org
RADIUS Servers
1. Click Configuration > Network Objects > IP Addresses > New, and after entering all the following, click Save:
•
Address Name: RADIUS-Server-Primary
Enter the following, and then click Apply:
—
IP Address: 10.1.1.15
—
Netmask: 255.255.255.255
—
Type: Global
Because all the HiveAPs at both the headquarters and branch site use the same RADIUS servers, you
classify them as Global. The HiveAPs at the branch site reach the RADIUS servers, which are also
located at headquarters, through a VPN tunnel.
—
Description: Primary RADIUS server at HQ
2. Click Configuration > Network Objects > IP Addresses > (check box) RADIUS-Server-Primary > Clone, and
after making the following changes, click Save:
•
102
Address Name: RADIUS-Server-Secondary
—
IP Address: 10.1.2.16
—
Description: Secondary RADIUS server at HQ
Aerohive
EXAMPLE 2: DEFINING NETWORK OBJECTS AND MAC FILTERS
Creating a MAC Filter
A MAC filter is a type of security policy that you can apply to an SSID to allow or deny access to clients attempting to
form associations based on their source MAC addresses. In this example, you define a MAC filter based on the VoIP
phone OUI and apply it to the SSID to which you want VoIP clients to associate. HiveAPs can then filter association
requests and respond only to clients whose OUI matches that in the filter (see "Example 5: Setting SSIDs" on
page 117).
The MAC filter that you create here becomes useful when you define the SSID for voice traffic (see "voip SSID" on
page 118). You apply this filter to the SSID so that only VoIP phones with the MAC OUI 01:22:34 can form an
association with the HiveAPs.
1. Click Configuration > Security Policies > MAC Filters > New.
The New MAC Filters dialog box appears.
2. Enter the following name and description for the MAC filter:
•
Name: corpVoIPphones (You cannot include any spaces when defining a MAC filter name.)
•
Description: Use this filter for "voip" SSID
Choose the name that you gave the OUI, such as "VoIP_Phones" (see "Defining a MAC OUI" on page 97) from the
MAC Address/OUI drop-down list, choose Permit as the action, and then click Apply.
3. To save the MAC filter configuration and close the dialog box, click Create.
Deployment Guide
103
Chapter 8 HiveManager Configuration Examples
EXAMPLE 3: PROVIDING GUEST ACCESS
As a convenience for guests visiting the corporate headquarters or branch office, you provide them with wireless
network access. To preserve bandwidth for employees, the rate limit for guests is somewhat minimized. To maintain
security, visitors are restricted to accessing just the public LAN.
Two approaches are presented in this section:
•
"Guest Access with Preshared Keys": This approach provides visitors with secured network access by using WPA
or WPA2 with preshared keys and TKIP or CCMP (AES) encryption. It does not include a means for enforcing
visitors to accept a network usage policy before receiving network access.
•
"Guest Access with Captive Web Portal" on page 105: A captive web portal is a way to control network access by
requiring users to authenticate or register before assigning them network and user profile settings that allow
them network access beyond the HiveAP with which they associated. With this approach, registered visitors’
activity can be tracked and stored in historical logs on a syslog server for security and compliance auditing.
For the first approach, no extra configuration is necessary other than configuring a guest user profile and SSID. For
the second approach, you might want to customize the registration form used on the captive web portal. To do that,
see "Customizing the Registration Page" on page 108 and "Loading Customized Captive Web Portal Files" on page 111.
Guest Access with Preshared Keys
You can provide visitors with secure but unregistered network access by issuing them a preshared key to use when
associating with the guest SSID. A receptionist can provide visitors with the preshared key along with access
instructions upon their arrival, as shown in Figure 8.
Figure 8 Guest Access Using a Preshared Key
Visitor
Receptionist
Visitor’s Laptop
HiveAP
Internet
The visitor enters the
preshared key
“guest123” when
forming an association
with the HiveAP using
the SSID “guest”.
The guest SSID provides secure network access for visitors. Also, by linking visitors to the guest SSID, you can
differentiate them from employees—who associate with other SSIDs (voip and corp)—so that you can apply one set
of QoS (Quality of Service) settings for visitors and other settings for employees. In addition, the user profiles for
employees and guests further separate their traffic into two different VLANs. For instructions on setting up guest
access with a preshared key, see "Guests QoS and User Profile" on page 115 and "guest SSID" on page 119.
104
Aerohive
EXAMPLE 3: PROVIDING GUEST ACCESS
Guest Access with Captive Web Portal
A captive web portal provides registered users with network access while containing unregistered users. Aerohive
offers two approaches to applying a captive web portal, one using external DHCP and DNS servers on the network
and the other using internal DHCP and DNS servers on the HiveAP itself. In the first approach, both registered and
unregistered users must be in the same VLAN because the DHCP and DNS servers that they use initially before they
register will be the same ones that they continue using after they register. In the second approach, you can separate
the unregistered and registered users into two separate VLANs because the unregistered users access the internal
DHCP and DNS servers on the HiveAPs, whereas the registered users access the external DHCP and DNS servers,
which can be in a different VLAN from the internal servers on the HiveAP.
Captive Web Portal with External DHCP and DNS Servers
With this approach, when the client of a previously unregistered visitor first associates with the guest SSID, the
HiveAP assigns the "Unregistered-Guests" user profile to the visitor. It allows DHCP and DNS traffic to pass through so
that the client can receive its address and TCP/IP assignments and resolve domain names to IP addresses. It also
allows ICMP traffic for diagnostic purposes. However, the HiveAP intercepts all HTTP and HTTPS traffic from that
client—and drops all other types of traffic—thereby limiting its network access to just the HiveAP with which it
associated. No matter what website the visitor tries to reach, the HiveAP directs the visitor’s browser to a
registration page. After the visitor registers, the HiveAP stores the client’s MAC address as a registered user, applies
the "Guests" user profile to the visitor, and stops keeping the client captive; that is, the HiveAP no longer intercepts
HTTP and HTTPS traffic from that MAC address, but allows the client to access external web servers. The entire
process is shown in Figure 9.
Figure 9 Captive Web Portal Exchanges Using External DHCP and DNS Servers
Association Using SSID “guest”
Wireless Client
Wireless Access Point
Address and TCP/IP Assignments
DHCP Client
DHCP Server
DHCP Discover
Association Request
Association Response
DHCP Offer
DHCP Request
DHCP ACK
The client forms an association with the HiveAP
but the visitor has not yet registered. The
HiveAP allows DHCP, DNS, and ICMP traffic
through. It redirects all HTTP and HTTPS traffic
to its own web server and drops all other traffic.
Deployment Guide
The HiveAP allows DHCP traffic to pass
between the client of an unregistered user and
a DHCP server so that the client can receive
its IP address and TCP/IP assignments.
105
Chapter 8 HiveManager Configuration Examples
4 HTTP Connection to the Captive Web Portal
DNS Address Resolution
DNS Querient
DNS Server
HTTP Client
HTTP Server
HTTP GET
DNS Query
Reply
DNS Reply
The HiveAP allows DNS queries and replies
between the client of an ungregistered user
and a DNS server
When the client sends an HTTP or HTTPS
GET command, the HiveAP intercepts it and
sends it to its HTTP server, which replies with
a guest access registration page. The user
must agree to an acceptable use policy, fill in
some fields, and then submit the form.
Registration
HTTP Client
HTTP Server
Registration
Quarantine
MAC: 0016:cf8c:57bc
Registered
MAC: 0016:cf8c:57bc
After a guest agrees to the acceptable use
policy, fills in the form, and submits the
registration, the HiveAP moves the client’s
MAC address from a quarantined list to a
registered list.
DHCP, DNS, and HTTP Forwarding
Wireless
Client
Wireless
Acess Point
Servers
DHCP
DNS
HTTP
The HiveAP then applies the registered user
profile “Guests” and forwards all types of traffic
to the rest of the network, as permitted by
firewall policies assigned to that user profile.
To enable the captive web portal to forward DHCP and DNS traffic from unregistered users to external servers on the
network, click Configuration > Authentication > Captive Web Portal > New, and select Use external DHCP and
DNS servers on the network.
Note: With this captive web portal implementation, you must assign unregistered and registered users to the
same VLAN.
106
Aerohive
EXAMPLE 3: PROVIDING GUEST ACCESS
Captive Web Portal with Internal DHCP and DNS Servers
With this approach, when the client of a previously unregistered visitor first associates with the guest SSID, the
HiveAP acts as a DHCP server, DNS server, and web server, limiting the client’s network access to just the HiveAP
with which it associated. No matter what website the visitor tries to reach, the HiveAP directs the browser to a
registration page. After the visitor registers, the HiveAP stores the client’s MAC address as a registered user and
stops keeping the station captive; that is, the HiveAP no longer acts as a DHCP, DNS, and web server for traffic from
that MAC address, but allows the client to access external servers. The entire process is shown in Figure 10.
Figure 10 Captive Web Portal Exchanges Using Internal Servers
Association Using SSID “guest”
Wireless Client
Wireless Access Point
Address and TCP/IP Assignments
DHCP Client
DHCP Server
DHCP Discover
Association Request
DHCP Offer
DHCP Request
Association Response
DHCP ACK
SSID “guest”
The client forms an association with the HiveAP
but the visitor has not yet registered. The
HiveAP directs all DHCP, DNS, and HTTP
traffic from unregistered guests to itself instead
of allowing it to the rest of the network.
IP Address:
Netmask:
Default Gateway:
DHCP Server:
DNS:
Lease:
172.16.1.2
255.255.255.0
172.16.1.1*
172.16.1.1*
172.16.1.1*
10 Seconds
* By default, a HiveAP assigns IP addresses to
subinterfaces for captive web portal use as follows:
wifi0.1 – wifi0.7 172.16.1.1 – 172.16.7.1
wifi1.1 – wifi1.7 172.16.11.1 – 172.16.17.1
DNS Address Resolution
DNS Querient
DNS Server
DNS Query
DNS Reply
Wildcard A record in the root zone “.” on the
HiveAP DNS server: * in a 172.16.1.1
The DNS server resolves all domain
name-to-address queries to the same IP
address, which in this case is 172.16.1.1.
Deployment Guide
4 HTTP Connection to the Captive Web Portal
HTTP Client
HTTP Server
HTTP GET
Reply
When the HTTP client sends a GET
command, the HTTP server replies with a
guest access registration page. The user
must agree to an acceptable use policy, fill
in some fields, and then submit the form.
107
Chapter 8 HiveManager Configuration Examples
Registration
HTTP Client
HTTP Server
Registration
Quarantine
MAC: 0016:cf8c:57bc
Registered
MAC: 0016:cf8c:57bc
After a guest agrees to the acceptable use
policy, fills in the form, and submits the
registration, the HiveAP moves the client’s
MAC address from a quarantined list to a
registered list.
DHCP, DNS, and HTTP Forwarding
Wireless
Client
Wireless
Acess Point
Servers
DHCP
DNS
HTTP
The HiveAP applies the “Guests” user profile
and forwards further DHCP, DNS, and HTTP
requests to external servers on the network.
Because the DHCP lease is only 10 seconds,
the transition to the external servers occurs
very soon after the registration completes.
To enable the captive web portal to forward DHCP and DNS traffic from unregistered users to its internal servers,
click Configuration > Authentication > Captive Web Portal > New, and select Use internal DHCP and DNS servers
on the HiveAP. By default, the internal DHCP server issues leases with a ten-second lifetime, and if a client with a
nonexistent lease requests a lease renewal, the HiveAP responds by broadcasting a DHCP NAK. You can change the
HiveAP response so that it sends a unicast NAK or ignores the request completely (Keep Silent).
Note: With this captive web portal implementation, you can assign unregistered and registered users to the same
VLAN or to different VLANs.
Customizing the Registration Page
Although Aerohive provides .html and .jpg files for use on the captive web portal server, you might want to
customize them to better suit your organization. There are six files, four of which are shown in Figure 11:
•
•
•
108
index.html (the main registration page)
•
success.html (page that appears after registering) •
reg.php (script stored on internal web server)
•
loginscreen_02.jpg (image at the top of web pages)
loginscreen_03.jpg (yellow line near top of web pages)
loginscreen_05.jpg (image at bottom of index.html)
Aerohive
EXAMPLE 3: PROVIDING GUEST ACCESS
Figure 11 Captive Web Portal Registration Page
http://www.cwp-login-0-1.com/index.html
To modify the registration page,
do the following:
Authenticated Network Access
loginscreen_02.jpg (304 x 56 px)
User Name:
Password:
Submit
loginscreen_03.jpg (450 x 4 px)
Open Guest Network Access
Acceptable Use Policy
1.0 Overview
This company’s intentions for publishing an
Acceptable Use Policy are not to impose
restrictions that are contrary to this
company. Established culture of openness,
trust and integrity. This company is
committed to protecting this company’s
I agree
Fields marked with an asterisk * are required.
* First Name:
* Last Name:
loginscreen