New to Aerohive

  • 1
  • Question
  • Updated 3 years ago
Hi all!

I ́m new to Aerohive but have been working several years with WLANs mainly with Aruba products. We ́re currently looking in to the Aerohive products and I would like to learn more about how Aerohive deployments look like and function. I thought the community must be a great place to start :)

So any recommended reading or comments on the following would be greatly appreciated:

  • Intra cluster communication. How do the APs in a cluster communicate with one another? Are all traffic sourced by every individual AP or is some traffic routed through some "master" ap?
  • Is there a dynamic channel/power feature and if so, how does it work?
  • The role based access, how can we derive roles on a single SSID and what filtering/throttling are available for the different roles?
  • Are there any 802.11ac wave 2 APs waiting around the corner?
  • The branch solutions with VPN termination, is there a best practise guide I can check out? Can the VPN be built from the AP cluster itself or do we need the router as gateway on each branch?

Looking forward to learning more about Aerohive! 

Cheers and have a great weekend,
Chris
Photo of Christoffer Jacobsson

Christoffer Jacobsson

  • 2 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Hi Chris, and welcome over from the dark side.

There is a lot of information in the online documentation as well as on this forum. The official training and certification is also very good.

  • Intra cluster communication. How do the APs in a cluster communicate with one another? Are all traffic sourced by every individual AP or is some traffic routed through some "master" ap?
There is no "clustering" in the traditional sense. Aerohive APs which are members of the same "Hive" and that can "see" each other either on their Ethernet port within the same broadcast domain or on their WiFi interfaces form adjacencies similar to distributed routing protocols like OSPF. It is also possible to configure static adjacencies, though this is virtually never needed. The main protocol which shares information between APs to support user roaming and other functions normally managed by a controller is the Aerohive Mobility Routing Protocol (AMRP).

In smaller deployments in a small building, you can put all APs on the same management network everything will work fine (every AP will have an adjacency with every other). You can then either have the user VLANs also be tagged to every AP so there is no layer-3 roaming, or you can have different VLANs tagged to different APs (e.g. to have a user VLAN per floor), and layer-3 roaming is handled by the dynamic creation of GRE tunnels between APs.

To support scaling in larger deployments in a single building (say a building with more than 5 or 6 floors) or in a campus, you can have multiple AP management VLANs (say a different management VLAN for each floor) and the APs will form adjacencies with the other APs on the same floor and also APs on adjacent floors through discovery on the wireless interfaces. This can then support layer-2 and layer-3 roaming across the whole building without having to have every AP in the building form an adjacency and maintain updates with every other AP (if a user is roaming from an AP on the top floor to an AP on the bottom floor without romaing through the intermediate floors, then they've probably fallen out of the window, so roaming is the least of their worries!)

For multi-site deployments, there is obviously no point in maintaining adjacencies across the different sites as users cannot roam between sites (well, until teleportation is invented). You can still have all your sites using the same Hive settings, but the APs at each site will just form isolated hives and everything will work fine.

The hive concept is also used for other features, such as simplifying the deployment of RADIUS when you have Aerohive devices acting as RADIUS servers. In this case, the security settings within the Hive allow APs to act as RADIUS clients to an Aerohive RADIUS server without the administrator having to manually manage NAS clients and secrets.
  • Is there a dynamic channel/power feature and if so, how does it work?
Yes. This is achieved through Aerohive Channel Selection Protocol (ACSP). Each AP can monitor all channels for channel occupancy, CRC rates, interference etc. and assigns each channel a "channel score". Each AP then essentially selects the channel with the best score. To prevent adjacent APs from "choosing" the same channels at the same time, an AP within the hive is dynamically elected as the ACSP arbiter which then brokers requests from other APs to use a particular channel, ensuring that the APs in the network make their channel selections in an orderly fashion. You therefore get the same end result that you would have with a controller making the channel selection decisions centrally without the scaling issues you get with a multi-controller deployment. Channel selection occurs when APs first boot up and can be scheduled to run periodically thereafter. APs can also be configured to switch to a better channel if CRC or interference exceeds a configurable threshold - channel switching can optionally be deferred if there are connected clients, or clients with active voice traffic to prevent disruption to users. Automatic tx power selection can also be configured - a max power level can be configured and an AP can adjust its power from that max level down to a minimum level (in the forthcoming 6.6 release, the minimum level is also configurable - in older releases adjustment down from the maximum level will be from 0 to 9dBm).
  • The role based access, how can we derive roles on a single SSID and what filtering/throttling are available for the different roles?
Roles ("user profiles") can be derived from RADIUS AVPs returned by a RADIUS server, or from local group membership for local users and Aerohive's PPSK user feature (if you haven't looked at PPSK yet, check it out in the documentation as it is a really neat feature). User profiles can be "switched" after initial connection based on client classification rules (MAC OUI or OS Detection based on user-agent or DHCP option 55 signatures). So for example, you can have Android devices use a different user profile than Windows laptops. A user profile defines a whole range of properties for the user from the backhaul VLAN on which they are placed, through QoS configuration including rate-limiting etc. through to layer-2, layer-3 and layer-7 firewall policy.
  • Are there any 802.11ac wave 2 APs waiting around the corner?
I would imagine so ;)
  • The branch solutions with VPN termination, is there a best practise guide I can check out? Can the VPN be built from the AP cluster itself or do we need the router as gateway on each branch?
That's a simple question with quite a complex answer. It depends on what topology you are looking for. You can have simple GRE tunnels from remote sites over a WAN back to a central data centre. The tunnels are created from the APs back to either APs in the data centre/central site or to a VPN gateway device (or devices) which may be physical appliances or virtual machines or a particular model of Aerohive switch.

For connectivity over the public Internet, you can create either layer-2 or layer-3 IPSec VPN connections back to a VPN gateway (again physical or virtual with an HA option if needed). For layer-2 IPSec connections, you can think of this as being more like an encrypted version of the GRE tunnel. The actual network on which users are logically placed exists in the central site and is extended over the IPSec tunnel to the remote location. For a layer-3 IPSec VPN, you need a branch router at the remote site which will route traffic over a more traditional IPSec VPN. Your user networks are then local to the remote site. The beauty is that the policy-based management of all this through HiveManager means that you can create a cookie-cutter deployment and deploy hundreds or thousands of branch office locations with very little admin overhead. For example, you can define IP supernets in the policy and then each site you deploy will automatically carve out subnets without you having to manually allocate and configure networks and interfaces on each site.

If you register for a login at support.aerohive.com, you can access all of the documentation and deployment guides there.
Photo of Christoffer Jacobsson

Christoffer Jacobsson

  • 2 Posts
  • 0 Reply Likes
Haha, many thanks for your detailed answers! I will register to the support site and start playing around when I get a kit :)

Cheers,
Chris