Professional Documents
Culture Documents
Aerohive-Whitepaper-Cooperative Control Wireless LAN Architecture
Aerohive-Whitepaper-Cooperative Control Wireless LAN Architecture
Aerohive-Whitepaper-Cooperative Control Wireless LAN Architecture
Table of Contents
Introduction ........................................................................................................................................... 4
Cooperative Control Architecture ............................................................................................... 4
Centralized Management, Distributed Control, and Distributed Forwarding ........................... 5
Key Concepts and Naming Conventions ..................................................................................... 7
Cooperative Control ............................................................................................................................. 8
HiveAP Auto Discovery & Self Organization .................................................................................. 9
Roaming Issues with Autonomous APs ........................................................................................... 9
Fast/Secure Layer 3 Roaming ....................................................................................................... 11
Tunnel Load Balancing in Large Scale Layer 3 Roaming Environments .................................. 13
Radio Resource Management (RRM) .......................................................................................... 13
Station Load Balancing.................................................................................................................. 13
Policy Enforcement at the Edge ........................................................................................................ 14
User Profiles and Identity-Based Policy ......................................................................................... 14
QoS at the Edge ............................................................................................................................. 15
QoS with Dynamic Airtime Scheduling ........................................................................................ 17
Service Level Agreements (SLAs) and Airtime Boost .................................................................. 20
HiveAP Security and Theft Protection........................................................................................... 21
Wireless Intrusion Protection System (WIPS) - Rogue AP and Client Prevention ...................... 22
Voice- and Video-aware WIPS Scanning .................................................................................... 23
Integrated Protocol Analyzer Integration and Client Monitoring ............................................. 24
3rd Party WIPS and Protocol Analyzer Integration ....................................................................... 25
Wireless Decryption at the HiveAP Allows Advanced Security at the Edge ........................... 26
RADIUS Server Built into HiveAPs .................................................................................................... 27
Built-in Captive Web Portal ............................................................................................................ 27
Identity-Based Tunnels .................................................................................................................... 28
Guest Access Policy Enforcement at the Edge .......................................................................... 29
Private Preshared Key (PPSK) Security .......................................................................................... 30
Virtual Private Networking (VPN) .................................................................................................. 32
Best Path Forwarding and Wireless Mesh ......................................................................................... 34
Wireless Mesh .................................................................................................................................. 34
Scalable, Layer-2 Routing and Optimal Path Selection ............................................................ 36
Scalability with Best Path Forwarding ........................................................................................... 37
Introduction
The first generation of WLANs were autonomous (standalone) access points and were
relatively simple to deploy, but they lacked the manageability, mobility, and security
features that enterprises required, even for convenience networks. Then centralized,
controller-based architectures emerged to address these issues and others such as
fast/secure roaming for mobile devices, radio resource management (RRM), and peruser or per-device security policies. Unfortunately, they also introduced opaque overlay
networks, performance bottlenecks, single points of failure, increased latency, and
substantially higher costs to enterprise networks. As Wi-Fi is increasingly embraced as a
critical part of the enterprise network and enterprises deploy demanding applications
(e.g. voice and video) over an extremely high-speed Wi-Fi infrastructure, the
consequences of this movement are magnified and are leading the industry to
reexamine the validity of todays centralized WLAN architecture.
Aerohive Networks has responded by pioneering a new WLAN architecture called the
Cooperative Control architecture. It is a controller-less architecture that eliminates the
downsides of controllers while providing the management, mobility, scalability, resiliency,
and security that enterprises require in their wireless infrastructure.
Cooperative Control Access Points (HiveAPs) that have dual radios that support
simultaneous use of the 2.4 GHz and 5 GHz spectrums for wireless access and/or
wireless mesh connectivity. HiveAPs implement robust security such as:
WPA/WPA2-Enterprise, WPA/WPA2-Person, de facto standards such as
Opportunistic Key Caching, Private PSK, integrated WIPS, stateful firewall policies,
and L2-L4 denial-of-service (DoS) prevention. Each HiveAPs SLA capabilities are
based on advanced QoS policies, Dynamic Airtime Scheduling, and Airtime
Boost capabilities using an easily-configured management application. A single
radio HiveAP is also available.
Policy enforcement at the edge: the ability to enforce granular, user-based QoS,
security, and access policies at the edge of the network where the user
connects.
Routers
Switches
HiveAPs
Management Plane
Responsible for
configuration, monitoring,
and troubleshooting
Control Plane Responsible
for making forwarding
decisions and
programming the data
plane
Centralized Using
an NMS platform
Centralized Using an
NMS platform
Centralized Using
HiveManager, a centralized
WNMS platform
Distributed Using
Protocols (OSPF,
RIP, BGP, etc.) to
determine how
traffic should be
forwarded
Distributed Using
Protocols such as
spanning tree protocol
(STP) to avoid loops
and MAC address
learning to determine
where traffic should go
Data Plane
Responsible for processing
and forwarding data
Distributed
Processed and
forwarded by
each router
Distributed Processed
and forwarded by
each switch
Extending the proven architecture used in switched and routed infrastructures to WLANs
through the use of distributed control and data planes is especially important as
HiveAP: The product brand name for Aerohives CC-AP (Cooperative Control
Access Point). HiveAPs coordinate with each other using cooperative control
protocols to provide critical functions including seamless mobility, automatic radio
resource management (RRM), policy-based security, and best-path forwarding.
HiveOS: The firmware developed by Aerohive Networks that runs on HiveAPs.
HiveManager: A centralized wireless network management system (WNMS) that
enables sophisticated identity-based policy management, simplistic device
configuration, HiveOS updates, and monitoring and troubleshooting of HiveAPs within
a cooperative control WLAN infrastructure. HiveManager is available as an
appliance, a virtual appliance, or a SaaS offering called HiveManager Online.
Hive: A Hive is a group of HiveAPs that share a common name and secret key that
permit them to securely communicate with each other using cooperative control
protocols. Within a Hive, clients can seamlessly roam among HiveAPs across layer 2
and layer 3 boundaries, while preserving their security state, QoS settings, IP settings,
and data connections.
GuestManager: A guest management platform that provides a simple web
interface for allowing administrators, such as receptionists or lobby ambassadors, to
create temporary user accounts that provide guests with access to the wireless
network.
Wired Backhaul Link: An Ethernet connection from a HiveAP to the primary wired
network, typically called the distribution system (DS) in wireless standards, which is
used to bridge traffic between the wireless and wired LANs.
Wireless Backhaul Link: Wireless connections between HiveAPs that are used to
create a wireless mesh and to provide wireless connections that transport primarily
control and data traffic.
Bridge Link: An Ethernet connection from a HiveAP that allows a wired device or
network segment to be bridged over the WLAN onto the primary wired LAN.
Wireless Access Link: The wireless connection between a wireless client and a
HiveAP.
Portal: A HiveAP that is directly connected to the wired LAN via Ethernet that provides
default MAC routes to mesh points within the Hive. This role is dynamically chosen. If
the wired link is unplugged, then the HiveAP can dynamically become a mesh point.
Mesh Point: A HiveAP that is connected to the Hive via wireless backhaul links and
does not use a wired link for backhaul. This role is also dynamically chosen. If a wired
link is plugged in, the HiveAP dynamically becomes a portal, if permitted by the
configuration.
Cooperative Control Signaling: The control-plane communication between HiveAPs
using Cooperative Control Protocols
Cooperative Control
By utilizing cooperative control, HiveAPs cooperate with neighboring HiveAPs to support
control functions such as radio resource management, Layer 2/3 roaming, client load
balancing, and wireless mesh networking, eliminating the need for a centralized
controller.
Cooperative control is made possible with the following self-organizing and
automatically-operational cooperative control protocols:
AMRP (Aerohive Mobility Routing Protocol) Provides HiveAPs with the ability to
perform automatic neighbor discovery, MAC-layer best-path forwarding through a
wireless mesh, dynamic and stateful rerouting of traffic in the event of a failure, and
predictive identity information and key distribution to neighboring HiveAPs. This
provides clients with fast/secure roaming capabilities between HiveAPs while
maintaining their authentication state, encryption keys, firewall sessions, and QoS
enforcement settings.
ACSP (Aerohive Channel Selection Protocol) Used by HiveAPs to analyze the RF
environment on each channel within a regulatory domain and to work in conjunction
with each other to determine the best channel and power settings for wireless access
and mesh. ACSP minimizes co-channel and adjacent channel interference in order
to provide optimized application performance.
DNXP (Dynamic Network Extension Protocol) Dynamically creates tunnels on an asneeded basis between HiveAPs in different subnets, giving clients the ability to
seamlessly roam between subnets while preserving their IP address settings,
10
11
Step 1 The client performs seamless, fast/secure layer 2 roaming within subnet A.
Step 2 After the client successfully roams to HiveAP 2, HiveAP 2 will send an
encrypted control packet over the Ethernet infrastructure to HiveAP neighbors in
the neighboring subnet. The control packet contains, as a minimum, the clients
identity, security and QoS information, SIP call state, and the clients originating
subnet.
Step 3 Because the clients identity and key information, including SIP call state,
is proactively synchronized between neighboring HiveAPs, when the client roams
to HiveAP3, HiveAP3 has all the information it needs to enforce policies and to
tunnel permitted traffic, over the GRE tunnel, to a portal HiveAP in the clients
original subnet. This behavior allows the client to maintain its IP address and
active sessions as it roams. Predictively, HiveAP3 forwards the wireless clients
roaming information to HiveAP4 in anticipation of any further roaming.
The ability for a client to maintain its IP, QoS, firewall, and security settings while roaming
across subnet boundaries ensures that client application sessions do not get dropped
while roaming. Based on a configurable idle time or number of packets per minute,
HiveAPs can be set to disassociate these wireless clients so that they can reconnect and
receive an IP address in their new subnet allowing traffic to be locally forwarded. If a
client roams across subnet boundaries when it does not have any active sessions in
12
13
HiveAPs can make decisions to offload stations from one radio to another within the
same HiveAP (Bandsteering) based on client capabilities and/or to offload stations to a
HiveAP that is better suited to handle the load in the immediate area. Transitioning
clients between radios and between APs is done without breaking the application
session.
Use of admission control can prevent over-utilization by ensuring there is enough
headroom for stations that roam to the HiveAP. It also prevents overloading a single
HiveAP, especially when there are other HiveAPs nearby that can better handle the
load. This is useful with VoWiFi, because it helps ensure that a HiveAP has availability to
support new or roaming voice stations, and that there is enough airtime available for
excellent voice quality.
14
15
WMM, it is possible to mitigate L2 frame loss and to ensure higher performance for lowerpriority applications as well.
In order to provide highly-efficient voice and video transmission and to alleviate the
problems that occur when packets are dropped because of momentary congestion of
WMM queues, Aerohive has augmented WMM by implementing advanced
classification, policing (rate limiting), queuing, and packet scheduling mechanisms within
each HiveAP.
The following diagram shows a simple example and workflow of the QoS engines within a
HiveAP.
16
Strict priority Packets in queues that are scheduled with strict priority are sent
ahead of packets in all other queues. Strict priority is typically configured for user
queues that are assigned to low latency traffic such as voice.
Weighted round robin The scheduler can allocate the amount of airtime or
bandwidth that can be transmitted by the user of a wireless client device based
on weights specified for a user profile, individual users within a user profile, and
the eight queues per user. Based on weighted preferences, the scheduler moves
packets from the individual user queues to the appropriate WMM access
categories for transmission onto the wireless network.
Because a QoS packet scheduling engine is built into every HiveAP, HiveAPs have the
ability to closely monitor the availability of the WMM access categories and to instantly
react to changing network conditions. The QoS packet scheduling engine only transmits
to WMM access categories when they are available, queuing packets in eight queues
per user in the meantime. This behavior prevents dropped packets and jitter, which
adversely affect time-sensitive applications such as voice. It also prevents TCP
performance degradation caused by contention window back-off algorithms that are
invoked when TCP packets are dropped.
Step 8 Finally, WMM functionality transmits L2 frames from its four access categories
based on the availability of the wireless medium. Packets from higher-priority access
categories are transmitted with a smaller random back-off window to allow transmission
onto the wireless medium with less delay.
17
the network, and moving behind obstructions all contribute to low data rate
connections. Slow clients consume more airtime to transfer a given amount of data,
leaving less airtime for other clients, which decreases network capacity and significantly
degrades the performance of all clients on the network. By enabling Aerohives new
patent-pending wireless Quality of Service (QoS) technology Dynamic Airtime
Scheduling - these problems are solved.
The benefits of Dynamic Airtime Scheduling are compelling both to the IT organization
and to the users of the WLAN, as it enables clients connected at higher data rates, in a
mixed data rate environment, to achieve up to 10 times more throughput than they
would get with traditional WLAN infrastructures - without penalizing low-speed clients.
This means that users see faster download times and improved application performance,
and it means that low-speed clients dont destroy the performance of the WLAN for the
rest of the users. This allows IT to implement a phased upgrade to 802.11n and
immediately reap the benefits of the new 802.11n infrastructure, even if it takes years to
upgrade all of the clients. And, because a user connecting at the fringe of the WLAN
can no longer consume all of the airtime, the network impact of a bad client or a weak
coverage area is diminished. This allows IT to reduce their infrastructure investment,
saving IT time and increasing user satisfaction.
With bandwidth-based QoS scheduling, the AP calculates the bandwidth used by clients
based on the size and number of frames transmitted to or from a client. Bandwidthbased scheduling does not take into account the time it takes for a frame to be
transmitted over the air. Clients connected at different data rates take different
amounts of airtime to transmit the same amount of data. By enabling Dynamic Airtime
Scheduling, the scheduler allocates airtime, instead of bandwidth, to each type of user,
user profile, and user queue, which can be given weighted preferences based on QoS
policy settings. When traffic is transmitted to or from a client, the HiveAP calculates the
airtime utilization based on intricate knowledge of the clients, user queues, per-packet
client data rates, and frame transmission times, ensuring that the appropriate amount of
airtime is provided to clients based on their QoS policy settings.
Dynamic Airtime Scheduling is made possible because it is performed directly on the
HiveAPs responsible for processing the wireless frames. This gives the scheduling engine
access to all the information needed, in real time (at the microsecond level), allowing
the HiveAP to react to instantaneous changes in client airtime utilization that occur when
the client is moving.
Managing airtime usage is critical and needs to be dynamically scheduled because it
affects all clients within the cell and varies drastically by client, based on distance from
the AP, PHY being used, signal strength, interference, and error rates. With Dynamic
Airtime Scheduling, airtime can be dynamically scheduled to increase aggregate
network and client performance and to allocate network capacity based on IT-specified
policies.
To demonstrate the advantages of Dynamic Airtime Scheduling, a series of tests have
been run and documented in the Aerohive whitepaper: Optimizing Network and Client
Performance Through Dynamic Airtime Scheduling.
The following test, which is an excerpt from the whitepaper, simulates a typical WLANs
transition to 802.11n where 802.11n APs are servicing a mixture of 802.11n clients and
legacy (a/b/g) clients. These tests show how Dynamic Airtime Scheduling prevents a
18
19
20
Encrypted and/or Hashed Passwords and Shared Keys in Command Line Interface
If the bootstrap configuration is not set or if someone knows the admin name and
password and is able to gain access to the HiveOS command line interface, all
passwords and shared keys are hashed and/or encrypted so they cannot be
obtained.
HiveAP RADIUS Users Stored in DRAM Are Removed When HiveAP is Powered Off
If the HiveAP is configured as a RADIUS server and uses a local user database, this
database can optionally be stored in DRAM, which is cleared when a HiveAP is
powered off or rebooted.
Bootstrap Configuration
If the hardware reset button functionality is enabled, you can set a bootstrap
configuration on a HiveAP so that when the HiveAP boots, after a hardware reset, it
will be configured with:
A strong admin name and password for serial console or SSH access;
disabled wireless interfaces;
disabled console access;
and optionally disabled Ethernet interfaces.
21
Note that if you do configure the bootstrap to disable console access, wireless
interfaces, and Ethernet interfaces, the HiveAP will essentially become a paperweight in
the event it is stolen.
In the unlikely and unfortunate event that a HiveAP is ever stolen, Aerohive has provided
these security mechanisms to prevent loss of secure data and to prevent the misuse of
the HiveAP.
22
23
24
25
26
27
Identity-Based Tunnels
Along with firewall policies, QoS policies, and VLAN assignment, when a client associates
with an SSID and gets assigned to a user profile, the clients traffic can be directed to be
tunneled to a HiveAP in a pre-defined location or subnet.
The following diagram provides a common use-case for identity-based tunnels. An SSID
called Guest-WiFi is configured on HiveAPs in the internal network. When a guest client
associates with the SSID, they are assigned to the Guest-DMZ user profile that has a policy
to tunnel all the guest clients frames (layer 2 traffic) via L2-GRE to one of the HiveAPs in
the DMZ. The client obtains its IP address from a DHCP server accessible from the DMZ,
which can optionally be running on a DMZ HiveAP.
When a guest attempts to access the network, the guest traffic is restricted by the
captive web portal on the local HiveAP until the guest has authenticated with a user
account created using GuestManager or a RADIUS server, or the guest has completed a
28
Diagram 17. A Common Use for Identity-Based Tunnels Placing Guests in a Firewalled DMZ for Internet-only Access
While this diagram shows an example of using identity-based tunnels for guest access,
identity-based tunnels can be used for a variety of other scenarios as well. Using identitybased tunnels, network resources can be accessed from any location in the wireless
network as if they were physically there. For extra scalability, HiveAPs can use round
robin to build tunnels to a set of HiveAPs at the destination, and tunnels only exist while
they are in use by clients.
29
accessing corporate resources, but to allow them to still access the Internet. If VLAN
segmentation is not possible due to the network architecture at the access layer,
guests can be tunneled, using the identity-based tunnel functionality, directly to one
or more HiveAPs within a firewalled DMZ area, such as a lobby.
3. User Profile-based Firewall Policies these policies can be used to allow a different
set of MAC and IP firewall policies to be applied to guest users to limit their access to
specific resources. This can be used as an alternative to VLANs or tunneling or as an
additional layer of control beyond VLANs and tunneling to control guest use of the
network.
4. Per-SSID RADIUS server settings allows a guest SSID to use a separate RADIUS server
for authenticating guest users. This is important because GuestManager and most
third-party guest management solutions utilize their own RADIUS servers. These
RADIUS servers are equipped with a graphical interface to allow lobby administrators
to create temporary guest user accounts, as guests are registered at the front desk.
With RADIUS server settings per SSID, your corporate users authenticate with
corporate RADIUS servers, while guest users authenticate with RADIUS servers tied to
guest management solutions.
5. Per-SSID DoS settings allows stricter management frame DoS settings and airtime
flood prevention settings to be applied to guests.
The Aerohive guest access solution provides the flexibility of using features integrated into
each HiveAP while allowing seamless interoperability with third-party guest access
solutions.
30
On the other hand, with PPSK, as shown on the right, every user is assigned his/her own
unique or private PSK, which can be manually created or automatically generated by
HiveManager and sent to the user via email, printout, or SMS. Every PPSK can also be
used to identify the users access policy, including their VLAN, firewall policy, QoS policy,
tunnel policy, access schedule, and key validity period. Because the keys are unique,
keys from one user cannot be used to derive keys for other users. Furthermore, if a
device is lost, stolen, or compromised, the individual users key can be revoked from the
network, preventing unauthorized access from any wireless device using that key. As for
the client users, the configuration is the same as using a standard PSK.
31
32
In the teleworker home office, a secure SSID is broadcasted from a HiveAP for secure
corporate access, but a home SSID provides access to home resources and the Internet
without access to the corporate VPN. Whether in a branch or teleworker home office,
with best path forwarding and split tunneling, remote users have direct access to local
resources such as printers, desktop PCs, or servers, even if these resources are not on
corporate subnets.
33
Wireless Mesh
Using cooperative control protocols that operate over the wired and wireless network
segments, HiveAPs can establish wireless mesh connections with neighboring hive
members. Because HiveAPs have two radios one that supports 2.4 GHz channels and
the other that supports 5 GHz channels the administrator has the option to specify the
use of one radio for wireless access and the other for wireless mesh.
Wireless mesh can be used where wired connectivity is not feasible or is difficult to
deploy, such as in historic buildings or stairwells where wireless access is required for
VoWiFi solutions or location-based services. Wireless mesh can also be used where a
network needs to be rapidly deployed, such as for a conference or a disaster recovery
situation. Even if wired connectivity exists, wireless mesh can be used to augment the
wired network. This gives the HiveAPs extra resiliency capabilities by being able to route
around a failure like an Ethernet link that has been accidentally disconnected or an
access switch that has failed or has been powered down.
All a HiveAP needs is power, and the cooperative control protocol suite does the rest.
The HiveAPs automatically build wireless mesh connections with each other to provide
wireless coverage that is not limited to Ethernets 100-meter maximum twisted pair length.
34
Over the wireless mesh, Aerohives cooperative control protocols are used to provide
best path forwarding, fast/secure roaming, optimal radio channel and power selection
for wireless connections, and high availability with dynamic and stateful re-routing of
traffic in the event of a failure.
Because cooperative control protocols have been designed to scale to support very
large wireless mesh networks, they prevent flooding by limiting the scope of broadcasts
for the distribution of routes and roaming cache information. This, in combination with
QoS, DoS prevention, and firewall policy enforcement at the HiveAP, keeps unnecessary
traffic off the mesh, ensuring optimized WLAN performance though the mesh.
Another powerful capability delivered by Aerohives mesh technology is the ability to use
the mesh to bridge between two LANs. By configuring an Ethernet interface on a HiveAP
to function as a wireless bridge, the HiveAP will learn the MAC address of devices on a
local LAN segment and distribute that information throughout the Hive to allow traffic to
be forwarded to and from those devices over the wireless network and to the primary
wired LAN. This is especially useful for connecting devices such as video surveillance
cameras that are in a building, parking lot, or outdoor area where running Ethernet
cabling is too costly, or not possible, but power is available.
35
With the centralized control and centralized data plane architecture, all wireless traffic is
directed to a dedicated WLAN controller, which may be many hops away or even at a
36
High Availability
The Aerohive Networks cooperative control architecture is a perfect fit for organizations
that require mission-critical reliability with no complex planning and minimal budget.
Aerohives high availability features come standard within the HiveAPs and provide
many levels of resiliency and redundancy.
37
there is a problem with the PoE switch or Ethernet cable, the HiveAP disables its wireless
interfaces and returns its Eth0 and Eth1 interfaces to 10/100/1000 Mbps speeds so that the
HiveAP can be managed at full speed. This safeguard includes unique functionality such
as support of LLDP and CDP that allows an administrator to find the switch manufacturer,
port number, and operating system and then fully provision the AP so that when
appropriate power is restored, the AP is ready to function at full capacity.
For extra power and resiliency, both gigabit Ethernet ports on the HiveAP 340 have been
equipped with Smart PoE technology, which allows both ports to draw power at the
same time. Even if both of the links are connected to legacy PoE (802.3af) switches, the
HiveAPs can operate at full capacity.
38
39
40
Versions of HiveManager
HiveManager is available in many versions, included 1U standard and 2U high-capacity
appliances, a virtual appliance (VMware virtual machine), and as a software-as-aservice (SaaS) offering called HiveManager Online. Each mode of delivery has its own
unique benefits, and theres even two operational modes: Express and Enterprise.
HiveManager Express has a streamlined graphical user interface (GUI) for those
organizations who prioritize ease-of-use above most other features and who have a
uniform company-wide access policy. HiveManager Enterprise is a maximized
implementation of HiveManager, offering a tremendous level of configuration,
monitoring, and configuration flexibility and sophistication.
41
42
On HiveManager 1U and 2U appliances, there are both MGT and LAN interfaces,
allowing the separation of HiveManager administration from the management of
HiveAPs. By default, the MGT interface is used for both the HiveManager administration
and HiveAP management. However, the administrator can dedicate the LAN interface
for HiveAP management and use the MGT interface solely for HiveManager
administration.
43
HiveAPs then use CAPWAP to contact the HiveManager, authenticate, and then build
an encrypted tunnel. HiveManager then displays a list of the discovered HiveAPs. The
administrator simply assigns WLAN Policies to HiveAPs and accepts them as devices to
manage. After that, the administrator can use one-button configuration updates to
send the configuration to one or more HiveAPs, or to schedule the configuration updates
for a later time. Likewise, if the operating system needs updating, the administrator can
select one or more HiveAPs to immediately send or schedule operating system updates.
Auto-Provisioning
By default, when HiveAPs locate the HiveManager, they will be displayed in
HiveManager in the New HiveAPs Automatically Discovered list. This gives the
administrator control of when and how a HiveAP should be managed. However, the
management process can be automated by using the auto-provisioning feature in
HiveManager. Using auto-provisioning, the administrator can import or manually enter a
list of serial numbers for HiveAPs that will be deployed, and then pre-define a WLAN
policy, operating system version, radio profiles, topology map, and VLAN for the HiveAPs.
When a HiveAP with one of the entered serial numbers is discovered, HiveManager will
automatically push configuration and/or operating system updates to each newlydiscovered HiveAP with no administrator interaction required.
44
HiveManager allows an administrator to view all of the active clients in the WLAN,
showing their IP addresses, MAC addresses, hostnames, user names (If RADIUS
authentication is used), SSIDs, session start times, signal strength values, the HiveAPs
clients that are associated with, and a variety of other parameters. This information is
stored within the HiveManager and can be exported as a CSV file for advanced
troubleshooting and network forensics. For ease of identifying clients, administrators
have the ability to add comments and to modify user details for clients which remain
persistent across logins. This is especially useful when testing and troubleshooting.
A wide variety of information can be exported for reporting purposes and pre-defined
and custom reporting features are standard in HiveManager. To be proactive,
administrators can configure email notifications so that they can be immediately
informed of alarms on the WLAN.
More detailed information about each client is available by selecting the client from the
list. This information includes the SSID and APs the clients have been associated with,
45
ag a
30
e a age
eta ed
ct
eC e t
at o
their signal levels, connection rates, RSSI values, duration, and traffic utilization statistics.
The illustration below shows an example of some of the information that can be obtained
about individual clients, which is often useful for learning about client behavior,
troubleshooting problems, and looking for dead spots in wireless coverage.
46
g
y
Policy using a single WLAN policy
Cooperative Control WLAN Architecture
simply clone an existing WLAN Policy, make the necessary changes, and apply the new
WLAN policy to one or more HiveAPs. The second method is to use HiveAP classification.
HiveAP classification allows an administrator to define network objects used in WLAN
policies (including VLANs, IP addresses, MAC addresses, and RADIUS attribute groups)
and to assign different values to these objects based on the topology map, where
HiveAPs reside, three text strings (called tags) defined in HiveAP settings, or by specifying
individual HiveAPs. The following diagram shows how a single WLAN policy can be
applied to HiveAPs in Area 1 and Area 2, but with area-specific changes.
When HiveManager updates the configuration policy on HiveAPs, it can identify HiveAPs
by location on a map, HiveAP classification tag, or specifically chosen HiveAPs. In this
example, the HiveAPs in area 1 and area 2 are identified by the topology map they are
located on within HiveManager. When you define VLAN or IP address objects, you can
specify how they will be applied to HiveAPs based on HiveAP classification criteria. As an
example, the following picture shows how you can define a VLAN object from within
HiveManager that will be assigned to a user profile. You can see that the object
Employee-VLAN will be configured as: VLAN 2 on HiveAPs located on the Area1
topology map and VLAN 7 for HiveAPs on the Area2 topology map.
47
You can also use HiveAP classification settings for IP objects. In a similar fashion, you can
define the RADIUS server IP address to use 10.1.1.55 in Area 1, and 10.6.1.55 in Area 2. This
allows an administrator push one configuration policy to all HiveAPs while allowing the
objects within the policy to be applied differently to individual HiveAPs based on
classification information.
In this example, when a user authenticates with SSID Corp_WiFi, the RADIUS server returns
the user profile attribute number 100 for that specific user, and the HiveAP uses that value
to bind the user to a user profile (ensuring the appropriate policies are enforced for that
user). This mapping of user profile attribute numbers into specific user profiles can be
different in different parts of the network, allowing for either global user policy
enforcement or location-specific user policy enforcement. In this example, in some
locations, a user is assigned different VLANs and QoS policies, but the same firewall
policy and layer 3 roaming policies. Likewise, other users assigned to different user profile
attributes may follow the same physical path, but can be assigned to different VLANs
and policies. This allows administrators to create access policies based on identity and
location.
Guest Manager
Aerohive's GuestManager is a guest account management and authentication server
that completes Aerohives robust and secure guest access solution. In combination with
HiveAPs, the GuestManager enables guest users to be simply and securely authorized for
access to a guest network. Aerohive GuestManager makes it simple for authorized
employees to create guest accounts while keeping the guest network secure by
authenticating and reporting on all guest users.
48
A user-friendly authentication
and authorization process
49
Credentials
The simple distribution of unique guest credentials is one of the key operational benefits
of GuestManager. Credentials can be randomly generated or specified during
registration to provide a unique login identity for the guest. Once the user credentials
are created, the credentials can be emailed or printed on letter-sized paper or a label
along with instructions on how to access the network.
Delivered as an Appliance
GuestManager is delivered as a standalone appliance or an instance on HiveManager
to ease deployment and maintenance of guest services. The GuestManager appliance
has been hardened (secured) against malicious attack, and vulnerabilities are fixed as
the system is upgraded.
50
Conclusion
Supporting near-100% uptime for mission-critical, real-time, and high-throughput
applications demands an architecture that can provide unprecedented availability and
security while still being simple to deploy, scale, and manage. Eliminating bottlenecks,
single points of failure, and scalability limitations is the next step in Wi-Fis continuing
evolution. The future of Wi-Fi is distributed intelligence and its name is Cooperative
Control.
51
About Aerohive
Aerohive Networks reduces the cost and complexity of todays networks with cloudenabled, distributed Wi-Fi and routing solutions for enterprises and medium sized
companies including branch offices and teleworkers. Aerohives award-winning
cooperative control Wi-Fi architecture, public or private cloud-enabled network
management, routing and VPN solutions eliminate costly controllers and single points of
failure. This gives its customers mission critical reliability with granular security and policy
enforcement and the ability to start small and expand without limitations. Aerohive was
founded in 2006 and is headquartered in Sunnyvale, Calif. The companys investors
include Kleiner Perkins Caufield & Byers, Lightspeed Venture Partners, Northern Light
Venture Capital and New Enterprise Associates, Inc. (NEA).
Corporate Headquarters
Aerohive Networks, Inc.
330 Gibraltar Drive
Sunnyvale, California 94089 USA
Phone: 408.510.6100
Toll Free: 1.866.918.9918
Fax: 408.510.6199
info@aerohive.com
www.aerohive.com
EMEA Headquarters
Aerohive Networks Europe LTD
Sequel House
The Hart
Surrey, UK GU9 7HW
+44 (0)1252 736590
Fax: +44 (0)1252711901
WP1000110