Wednesday, February 7, 2018

Chapter 2 - Data Units, their names and roles

As data is passed through the layers and sublayers, they take on different forms. Each with different information being added or stripped depending on the direction (up or down through the layers.) Each of these forms will have a different name to help differentiate them from each other.

MSDU - MAC Service Data Unit - This is the upper layer data from L7-L3 that needs to be passed along. Technically its actually the LPDU from the LLC that was passed along to the MAC layer thus making it a MSDU.
  • All 802.11 frames that contain data have an MSDU. But Management frames do not contain any data so they don't contain an MSDU.

MPDU - MAC Protocol Data Unit - This is the MSDU that is being handed down to the PLCP (top sublayer in the PHY layer)

PSDU - PLCP Service Data Unit - This is actually the MPDU only now that its on the PHY layer its called the PSDU.
  • The PLCP sublayer adds information to the PSDU and passes it along to the PMD sublayer calling that new data unit containing the PSDU and extra information a PPDU.

PPDU - PLCP Protocol Data Unit - This is the last stop. Everything that has been passed down from L7 and encapsulated is now ready to be transmitted. 

Chapter 2 - Beacon Frames

Beacon frames are a special type of 802.11 management frames. They contain a number of important information elements regarding the AP or STA's capabilities.

Timestamp - As discussed previously these are used for synchronization

Beacon Interval - Specifies the time between beacon transmissions

Capability Information - This is aptly named since it is used to communication various capabilities. Notably security requirements and if the service set is in an ESS or an IBSS. The book mentions that there are other capabilities advertised here that are specified in the 802.11 standard and its amendments, but does not go into further detail.

SSID - This is the ID or the "name" of the network that the beacon is identifying. I'd say this is a pretty important one.

FH Parameter Set - This is used by old Frequency Hopping STA's

DSSS Parameter Set - An element used by old DSSS PHY methods.

CF Parameter Set - This would be an element used with PCF. However since PCF is not actually used, this isn't used.

IBSS Parameter Set - Only used by STA's participating in an IBSS. Contains the ATIM Window information used for power saving in an IBSS.

TIM - Traffic Indication Map - An Element used by STA's that are using some form of power saving mode. Also the name of the enchanter in Monte Python and the Holy Grail

Supported Rates - This is a list of up to 8 data rates. Some of which would be "Basic" Rates. Defining these Basic rates, in turn defines modulation methods. Which essentially ensures that both the AP and the STA can speak the same language. From those basic rates there are other supported rates, and potentially other modulation methods that the beaconing device supports. But those are not required for a connection. They are just potential modulation methods if both the STA and AP support them.

Extended Supported Rates - This just includes other supported data rates that aren't included in the first 8 supported rates.

ERP Information - This element is only included on the 2.4GHz spectrum. Its used to communicate if a Non-ERP STA is in the cell, a neighboring cell is detected that only allows non-ERP datarates.

RSN - Robust Security Network (RSN) - This element contains information regarding the devices RSN capabilities. Such as their Authentication Cipher, Encryption Cipher, etc.

HT Capabilities - This is used with 802.11n networks, defining maximum MPDU length, short GI, various elements surrounding beamforming, and new to 802.11n (at this point) supported spatial streams.

HT Operation - Further defining some 802.11n capabilities. Such as channels, frequencies, and any protection modes being used.

 VHT Capabilities - Much like HT Capabilities defined 802.11n capabilities, this defines 802.11ac capabilities. Such as max MPDU length, short GI, beamforming options, and supported spatial steams and MCS's

VHT Operation - Defines the 802.11ac channels and frequencies 

Chapter 2 - Physical Layer Operations - In Depth... or at least deeper

Lets talk about the PSDU and the MPDU again. Guess what? They're still the same thing. Its just that they are called different things depending on what layer you are on. The MAC layer calls it the MPDU (Note the "M") and the  Physical layer calls it the PSDU (Note the "P") 

The book says its which side of the door you are on, is it the entrance or the exit. It's still the same door, its just a matter of from what direction are you looking at it. When you are outside its the entrance, when you are inside and looking at it, its an exit. Now, we could get all existential and say things like "Well, yeah, but if you are outside and looking at it, it could be an *exit* from the outdoors as well as an entrance." Sure, we could say that. But we won't. Because this isn't a philosophy class, we're learning about WiFi. 

So anyway, if you are at the Physical Layer, its a PSDU. If you are on the MAC Layer its a MPDU. Just to recap in case you have forgotten what all of the acronyms mean, like I did by this point.

PLCP - Physical Layer Convergence Procedure
PSDU - PLCP Service Data Unit - Yo dawg, I heard you liked Acronyms, so I put an acronym in your acronym.

Alright, so lets try and follow the path again.

If coming from the upper layers down to the Physical Layer - L3-7 info comes down to L2 which is split into two layers. The first one that it hits is the LLC, here the L3-7 data is in the form of an MSDU. That MSDU is then passed down to the next sub-layer of L2, the MAC sublayer. Here the MSDU is encapsulated into an MPDU. The MPDU is then passed down to the Physical layer. Which, like L2 is split into two sub-layers. The first one that it hits is the PLCP. Now that its here, its considered a PSDU. Remember going from L2 to L1 means that somewhere along the lines the MPDU went off to college and changed its name to PSDU because it thought that sounded edgier. Now that it has had its name legally changed, it gets a PHY header and a preamble added to it. Thus creating a PPDU or PLCP Policy Data Unit. The PPDU is then passed from the PLCP sub-layer down to the PMD sublayer, where its actually modulated as bits.  

Great! We just transmitted data wirelessly. Well, at least thats the progression of the protocol. 
Now lets take a bit of a deeper look at the PPDU, which remember is the PLCP Policy Data Unit. The components of the PPDU are the recently rebranded PSDU that was handed down from the MAC Layer (remember it was the MPDU at the MAC layer) the PLCP Header, and lastly, although it comes first in the transmission, the PLCP Preamble. 

A preamble? Like -- We the bits of this wireless frame? Well, in a way, yes. A preamble by definition is a preliminary or preparatory statement such as an introduction. Here, the transmitting station will send out a series of bits (1's and 0's) to give the receiving STA a heads up that the frame is incoming and how to synchronize to it. 

The book lists six different preambles. Three that were defined in the 802.11-2007 standard and another three that were defined in the 802.11n standard. If there were any additional that were introduced in 802.11ac they aren't in this book. But if I come across them I'll edit this. 

802.11-2007 Preambles
Long PLCP preamble 
Short PLCP preamble
OFDM PLCP preamble

802.11n additional Preambles
Non-HT legacy PPDU
HT-mixed PPDU
HT-Greenfield PPDU

Long PLCP Preamble
This is a 144-bit PLCP Preamble, with 128-bits of that coming in the form of a sync field, and the remaining 16-bits are a "Start of Frame Delimiter" (SFD) A receiving STA will start to synchronize with the incoming signal when it detects the sync field. But now that the synchronization has started, how will the receiving STA know when the actual data has started? Because it detects the SFD. As soon as the receiving STA hears the SFD, it knows that the PCLP Header is incoming. Its important to note that the receiving STA doesn't need to hear the entire Sync field, as long as it identifies the SFD. The Long Preamble is transmitted using DBPSK (Differential Binary Phase Shift Keying) at 1Mbps, as is the PLCP Header. However the modulation method of the PSDU is not necessarily the same as the preamble or the header.  It can be transmitted at 1, 2, 5.5, or 11 Mbps. The whole transmission of the preamble and header takes 192┬Ás.

From the CWAP PW0-270 Book

Short PLCP Preamble
The Short PLCP Preamble is... shorter! In fact, its half the size at 72-bits versus the 144-bits of the Long Preamble. Those 72-bits are made up of a 56-bit Sync field and a 16-bit SFD. Note that the SFD is the same length with both Preambles. Their content is actually just reversed. The short Preamble is transmitted using the same DBPSK as the Long, transmitting at 1Mbps. However the Header is transmitted at 2Mbps using DQPSK (Differential Quadrature Phase Shift Keying) Just as with the Long preamble, the Short Preamble and Header both have fixed modulation, but the PSDU can differ. 

From the CWAP PW0-270 Book

OFDM PLCP Preamble
This is often referred to as the OFDM training structure - It uses 10 short symbols, and 2 long symbols with a guard interval separating them. Following the second long training symbol are Signal and the Data Fields. However between the training symbols and individual subsequent fields, are Guard Intervals. 

From the CWAP PW0-270 Book

PLCP Header
Following the Long and Short PLCP Preambles, comes the PLCP Header. It's 48 bits long and contains four fields. 
Signal (8 bits) - Indicates what modulation type the PSDU will be used to transmit the PSDU
Service (8 bits) - 5 out of 8 bits of this are actually used. Each bit thats used determines a different thing.
     - Bit 3 is used to indicate which modulation method is used. Whether its CCK (0) or the seldom used PBCC (1)
     - Bit 2 is used to indicate that the transmit and frequency clocks are derived from the same oscillator
     - Bits 5-7 are used to resolve data length field oddities if PBCC is actually used for whatever reason. 
Length (16 bits) - Indicates how long in microseconds will be required to transmit the PSDU
CRC (16 bits) - Cyclic Redundancy Check

But wait! There's more... with the ratification of the 802.11n amendment came two new PPDU's, and the sort-of reuse of an older one to allow for legacy devices to coexist with newer HT devices. Below are their explanations, and below that is a figure showing all three. 

Non-HT Legacy PPDU
This format was developed is for the standard to essentially mimic and provide backwards compatibility to legacy STA's. And is essentially the OFDM Preamble with 10 short symbols and 2 long symbols.

The beginning part of the HT-Mixed Preamble is the exact same as the Non-HT, with the 10 short and 2 long training symbols. This is so that legacy devices can decode the preamble and essentially understand enough to know that they have to wait to transmit, and that the following data isn't for them. The rest of it can be decoded by HT devices though. This HT portion contains information necessary for MIMO.
This is probably the most commonly used format for 802.11n since it supports both legacy and HT type devices. 

It works on both 20MHz and 40 MHz channels. If a 40MHz channel is being used, then all of the broadcast traffic that might be used by legacy devices needs to be sent on a legacy 20MHz channel. Obviously if a transmission is destined for a Non-HT client then they would be use only the 20MHz channel. 

HT-Greenfield PPDU
This method is *not* compatible with legacy devices. Because of this its support is only optional. 

From the PW0-270 Book

Of course mrn-cciew has a great writeup on this as well

Also, you may have noticed that the captions mention the PW0-270 book. Thats because it is. The CWAP-402 book touches on this, but only lightly (in comparison to the PW0-270 book). 

Chapter 2 - 802.11 Communications

This portion of the chapter discusses the methods/processes/procedures of finding and associating to an AP.  The 802.11 MAC layer has a number of mechanisms in order to do this, as well as to help traffic along.

Scanning - STA's are not just magically associated with an AP. They need to be able to find them first. Scanning is the methodology used to find BSS's. There are two types of Scanning, Passive and Active. These will be gone into further detail later

Synchronization -  There are certain features that may require the STA's to all reflect the same time. Beacon frames can provide a time stamp value for STA's to update their clock with

Frame Transmission - Nowadays this is DCF (Distributed Coordination Function)

Authentication - This takes place before the Association… its um, where the STA authenticates.

Association - The next step after a STA is Authenticated is becoming associated with the BSS. This process is much more akin to becoming associated with someone/something. The STA and AP find out various capabilities of each other. What they support, what they don't, etc. Much like getting to know someone.

Reassociation - We use wireless so we aren't tied to a specific location. As such, we often need to roam from one AP to another within the same ESS. To roam to the new AP, the STA must "reassociate" with it.

Data Protection - Since wireless uses plain ol' RF, it can be "listened to" by those who may be inclined to do so. Data Protection allows us to use encryption techniques to try and thwart potential attackers.

Power Management - Most, if not all STA's utilize battery power. Which, as anyone who uses a Smart Phone can attest, is a valuable commodity. With this in mind, Power Management features have been created to help optimize the battery life of these devices. They do so by allowing devices to go to "sleep" for certain periods of time. Therefore they don't "pull" any extra power.

Fragmentation - The wireless medium can have a number of influencers on its stability. Due to this, it may be prudent to fragment frames before they are sent. This will be covered more deeply later on.

RTS/CTS - Request to Send and Clear to Send are basic functionalities of the 802.11 standard. These help prevent (but are not 100%) hidden node issues. This too will be covered more deeply later on. 

Chapter 2 - MAC & PHY

Layer 2 - The Data Link Layer has two sublayers
  • Logical Link Control sublayer - Shared sublayer across all 802 standards
  • Medium Access Control sublayer

Layer 1 - Physical Layer is often abbreviated as PHY - Also divided into two sublayers
  • Physical Medium Dependent (PMD)
  • Physical Layer Convergence Protocol (PLCP)

Carpenter, Tom. CWAP: Certified Wireless Analysis Professional: Official study guide: Edition CWAP-402. Certitrek Publishing, 2016.


PMD - Physical Medium Dependent - This is where the data is actually modulated. You can remember that because if you look at the name, its Dependent on the Physical Medium. At least if you read it backwards.
  • The 802.11 standard states that every PHY provide different PMDs. The majority of these different PMDs are the modulation schemes.
  • The MAC layer remains the same for most of the current PHY's deployed today. Although some will have special features. Such as protection mechanisms or optional features like QoS.

PLCP - Acts as a mediator and/or translator between the MAC layer(s) and the PMD. 

Chapter 2 - 802.11 Communications - Bits/Bytes/Segmentation/Encapsulation/etc. REALLY brief

Layer 4 - Segments (TCP) Datagrams (UDP)
Layer 3 - Packets
Layer 2 - Frames
Layer 1 - Bits 1's and 0's

There is a little discussion in this chapter about bits to bytes. As well as converting bytes to decimal values.

Chapter 1 - Troubleshooting Tools

As with any profession, the tools of the trade are incredibly important. A carpenter without a hammer or saw is just a person. Or a dentist without their picks and drills and other instruments of torture is just someone with an infatuation with dental health. Likewise, a WLAN Professional without the requisite tools, is just a person with a lot of knowledge about something people cannot see or touch.

Networking Tools
Throughput Tester: These are Tools like iPerf that test TCP/UDP traffic. Normally work off a client/server model to test throughput. It's important to note that throughput testers test for overall data throughput, not the data rate. This is incredibly beneficial when validating performance issues. Just because you have a fast advertised data rate, doesn't mean that your end-to-end throughput will match that. In fact, with normal overhead and contention, it never will.

Protocol Analyzer:
These allow you to capture and decode frames and packets. A perfect example of this is Wireshark. According to the book there will be an entire chapter dedicated to Protocol Analyzers (understandably given the context of the book.)

Spectrum Analyzer: These allow you to actually see the RF. Not just the WLAN, but all of the RF in the area. Allowing you to determine the actual strength of the signal, pinpoint sources of interference, and determine the channel utilization. For the utilization piece again, its how much of the channel is taken up by all RF sources, not just WLAN ones. This is important because although you may not see any other networks on Channel 6 for example, due to a poorly shielded microwave or a wireless security camera, it might be more utilized than another choice of channel.

Operating System Tools

Ping: Used to test connectivity/reachability between devices. Sends an ECHO ICMP to the target IP address.
  • -l (Lower case L) will change the data size in the ECHO message. The default ECHO message is only 32 bytes, so it may not reveal issues that a large message would.
  • -t will run the ping continuously until a interrupt command is issued (Windows its CTRL+C) This can be used to verify random connectivity issues, or to consistent roaming, or when testing reachability during HA failovers.

Traceroute: Determines the "path" that packets take to reach their destination. Using ICMP ECHO's (much like Ping) Traceroute will show each hop along the route that the packet needs to take.

Pathping: This is essentially Traceroute, but with more details included in the response.

Nslookup: Used to query DNS servers to resolve hostnames to IP Addresses.

Netstat: Shows network statistics for all network connections from the host machine. This can be run "ongoing" to help show any new connections that are created.

Netsh: This is a Windows-Only command that shows information about both the wireless adapter, connections, and configurations. It has a number of sub-commands (my term) four of which are going to be focused on in the exam. Those are detailed below. Note: The command will be "netsh wlan" followed by the sub-command below. For example "netsh wlan show drivers"
    • Shows details about the currently used wireless interface and profile.
      • Including the Authentication type
      • Channel
      • Data Rate
      • Signal Strength
    • Shows all visible wireless networks
    • To gain more detailed information the "mode=bssid" tag be added to the end of the command
      • This will show you the actual MAC Address of the radio(s)
      • Authentication Type
      • Radio Type
      • Signal strength
      • Channel
      • Basic Rates
      • "Other Rates"
    • Shows the actual wireless driver files being used by the adapter
    • Shows the security methods offered/supported by the adapter
    • Shows the PHYs that are supported
    • This will show all wireless profiles configured on the machine
    • If a specific profile name is provided it will then show a more details about that specific profile
      • Example "netsh wlan show profiles name="DCRWireless"
      • If the additional "Key=clear" command is used at the end of the above command it will show the PSK in cleartext. Which is fun. Remember to lock your systems when you walk away from them kids.

Chapter 1 - Troubleshooting Methodologies

Troubleshooting Methodologies

Only the CWNP Troubleshooting method will be tested on. However the book goes into Cisco, Microsoft, and CompTIA's methodologies to compare and contrast them.

CWNP Troubleshooting Methodology:
  1. Identify the problem.
    1. Do this through asking multiple open-ended questions. Try to determine everything about it, where its happening, what device(s) the user is using, what application(s) its affecting, any recent changes, etc.
  2. Discover the scale of the problem.
    1. Is the issue isolated to just this one user? Is it an application issue that is causing issues across multiple devices and areas?
  3. Define the possible causes of the problem.
    1. As with everything in IT, there could be any number of causes for the issue. Narrowing down and defining these will help in the following steps. It could be anything from a wrong password, to a supplicant misconfiguration, to a down AP, to a down server hosting the application. Or it could be something random like the user changed departments, and their new role doesn’t allow them access to something they used to have access to and as such they are blaming it on the network.
  4. Narrow to the most likely cause.
    1. Using the list of possible causes, use what you know of the issue and of the environment to narrow the list to the most likely cause. Obviously some environments will be more prone to certain types of issues. Use your knowledge of these "traits" to figure out the most likely cause.
  5. Create a plan of action or escalate the problem.
    1. Now that you have identified what you think to be the issue. Create a plan of attack on how to fix the issue. If the cause of the issue is outside of your purview, then escalate the issue and potential cause to those who have the capabilities of fixing it. For example, if it’s a server issue, then escalate it to the team who handles the servers. Document the cause and course of action you plan on taking.
  6. Perform corrective actions.
    1. Execute on your plan established in Step 5.
  7. Verify the solution.
    1. If the plan did *not* work, then cycle through step 4 again for the next probable cause. Documenting everything.
    2. Also ensure that roll back any steps you took during step a.
  8. Document the results.
    1. Really you should be documenting the entire thing.

Cisco Troubleshooting Process:
  1. Define a clear problem statement with symptoms and potential causes.
  2. Gather the facts to help isolate the possible causes.
  3. Consider possible problems based on the facts discovered
  4. Create an action plan based on the remaining potential problems and the most likely cause.
  5. Implement the action plan.
  6. As changes are made, gather results.
  7. Analyze the results and determine whether the problem has been resolved.
  8. If the problem is not resolved, create a new action plan based on the next most likely cause and proceed with steps 5-8. Repeat until resolved or escalated.

Microsoft Troubleshooting Process:
  • Phase 1: Discovery - Gather information about the problem
  • Phase 2: Planning - Create a plan of action.
  • Phase 3: Problem Reproduction - Reproduce the problem, or determine that you cannot reproduce it. If you cannot reproduce the problem then you might not have enough information to confirm there is a problem.
  • Phase 4: Problem Isolation - Isolate the variables that relate *directly* to the problem.
  • Phase 5: Analysis - Analyze your findings to determine the cause of the problem.

CompTIA Troubleshooting Methodology:
  1. Identify the problem.
  2. Establish a theory of probable cause. - Question the obvious.
  3. Test the theory to determine cause.
  4. Establish a plan of action to resolve the problem and implement the solution.
  5. Verify full system functionality, and if applicable implement preventative measures.
  6. Document! Findings, actions, and outcomes.

Wednesday, January 17, 2018

Cloud Management Platform Comparisons and Opinions

One of the largest movements in WiFi over the past decade has been the movement to Cloud Based Management. It seems every single vendor has their own cloud-based management platform. To help differentiate them, I put together a comparison table (at the bottom of the post) that goes over the major features and functionality that many organizations might be looking for. This is by no means an exhaustive list of vendors or of features. Merely the top platforms and feature sets that I encounter out there.

Also, as a disclaimer, these are my personal thoughts and opinions driven by the information that I have seen, and through my experiences on these platforms. I have been hands on with every one of these platforms except for Ubiquiti. But that does not mean that my experience will match everyone’s. As with everything in IT – Trust, but verify.

Meraki was one of the first to market with a Cloud Managed platform. Spawning form the MIT Roofnet project, and then becoming an actual company in 2006. Meraki grew quite quickly, and in late 2012 was acquired by Cisco. Since that acquisition they have continued to grow at an incredibly rapid pace.

Pros: In my opinion Meraki has always had one of the cleanest/most intuitive of all of the interfaces. Despite adding new product categories (Security appliances, switches, cameras, phones, MDM) to their dashboard, they have been able to keep it clean and consistent. With seemingly everything hyperlinked together. So an administrator can easily drill from one thing to another on the fly.

Meraki has also had a strong set of “live-tools” built into their interface. Allowing easy remote troubleshooting through a number of basic tools that can be executed from the dashboard to a device, or from the device itself. Also in most of their devices is a tertiary radio that can be used for spectrum analysis. This can be an incredible tool for troubleshooting random connectivity issues.

Meraki’s single subscription per Access Point contains all functionality that they have built into their dashboard. They have yet to release a wireless feature that requires extra licensing.

As you grow your network and add new AP’s and their subsequent subscriptions, all of your subscriptions will automatically co-terminate together. This is done through a “weighting” process that’s fairly hard to explain. But as a simple example. If I purchase 10 AP’s with a 1-year subscription in January, and in June after six months have gone by (and I have another six months left on the original 10) I purchase 10 more AP’s with 1-year subscriptions. My final expiration date would actually be in March. Because the Original 10’s expiration date will be dragged *forward* while the second group of AP’s will be dragged *back.* Averaging all of the 20 subscriptions out to a March expiration. Meraki does a much better job of explaining this in their documentation.

Cons: The largest drawback to Meraki has always been their subscription-expiration policy. Meraki is the only provider on the list whose product will stop working if your subscription expires. They do provide you a 30-day grace period, and will alert you in a number of different ways that your subscription is close to expiring.

Another drawback that has always irked me, is that their only external antenna Access Point options are their outdoor AP’s. Which are obviously not very cost effective when compared to their indoor brethren. This makes it expensive to deploy them in high-density indoor environments such as lecture halls.

I’m also going to include here their automatic subscription co-termination, despite also having it as a Pro. I know many finance departments wouldn’t be happy with paying for something for say 36 months, but due to it being added to an existing deployment, end up getting much less than that due to this policy.

Aruba Central

Aruba’s cloud platform was announced shortly after Cisco acquired Meraki. The platform has continued to grow, and since the acquisition of Aruba by HPE, has even grown to start to include the ability to manage many of the HP Networking switches as well.

Pros: Aruba has consistently been one of the most well regarded Wireless companies, with consistent praise for their RF design and their enterprise grade feature sets. With Central, Aruba has provided another way of controlling their outstanding hardware, and is compatible with most of their Access Points that use the "Instant" architecture. However moving forward, Aruba has made the process even more simple with the release of their "Universal" image. This image is only shipping on a few of their newer Access Points, but will take much of the confusion out of the ordering process. Here's a great blog that goes into detail about the new image:

Aruba made a very wise choice when it came to the "flow" of their cloud interface. Borrowing much of the same nomenclature and mimicking the same feel as their widely used controller platforms. This makes it easier for organizations who are already comfortable with Aruba’s management to easily transition and understand their Cloud interface.

Another plus is their ability to manage other devices in the Aruba Networks lineup, such as many of the switches that the lineup inherited from the ProCurve lineup. Many of which retained their famed lifetime warranty as well.

Since this follows on the heels of the Meraki write-up, I’ll point out that if your Aruba Central subscription lapses then their AP’s will retain the last known configuration provided by Central and remain running as “Instant” Access Points. However you will need to remove them from the Cloud inventory before being able to manage them directly again.  

Cons: Although their base platform has a very “enterprise-ready” feature set, there are certain things that Aruba charges additional licenses for such as Guest Management and Presence Analytics.

Their interface uses an “app-switcher” (my term) in the upper left hand corner. With each “app” being a different management section. Also, when you add in the extra functionality this is where those get added into. This layout took a bit of time to get used to. And once I understood it, the only time I knew to navigate to a different “app” was when I didn’t see the necessary feature that I was looking for.


Ruckus is best known for their BeamFlex technology. And maybe second-best known for their odyssey of acquisition over the past few years. If I have their Journey correct, they were first purchased by Brocade in 2016. Then Brocade was purchased in a major acquisition by Broadcom. But then Broadcom spun off Ruckus and the Brocade ICX lineup to Arris. All of this started in 2016 and has just recently started to settle down. Ruckus as a company has done a great job of weathering this storm and done their best to continue to operate as if none of this was going on around them.

When it comes to their Cloud platform, they were certainly a bit late to the party, releasing theirs publicly in the middle of 2016. Unfortunately it still feels as though it is lagging behind the others in terms of features and polish as well. Which is unfortunate because their Access Points and Controllers are rock solid. However they do have a strong roadmap of features coming which should help bring them to parity with the rest of the market out there.

Pros: As I stated above, one of the largest strengths of Ruckus is their Beamflex technology. Their cloud platform works with most of their Access Points (but not all) and as such your deployment gets to take advantage of this as well.

All of these platforms offer some form of Guest WiFi. However it’s always in how it’s deployed that sets them apart. As much as I’m a fan of simple and open Guest networks, many organizations like to be able to lock down access to those that they deem necessary. This is often done through some sort of on-boarding process. Whether it’s a self-supported process, or if access has to be sponsored from someone within the organization.  Ruckus allows you to have a guest administrator who can hand out personalized credentials to guests. As part of this process, the administrator needs to put in the guests information such as name, email address, phone number, etc. Ruckus has made this even easier by implementing a feature on their mobile app that can actually scan a business card, and auto-fill the corresponding information fields. This is a really slick method and make the process much more efficient. Also as part of the process, the administrator can choose how long the users credentials are good for, and how many client devices can use those same credentials.

Cons: Take a look at the table, their feature parity just isn’t there yet. I’ve also run into some strange bugs in their analytics portion.

One of the largest bugs/issues that I’ve run into has just been getting to the dashboard itself. For a long time now I’ve been unable to get to it using Chrome, and Firefox usually times out as well. When on my Windows device I’m able to get to it through Internet Explorer, although it’s still unfortunately slow. On my Mac it timed out on Chrome and Safari, however I was able to access it using Opera. From what I understand this is a known bug and something they are working on.  

Another drawback is that if your subscription lapses, the Access Points will “halt” until reconfigured as autonomous AP’s, or pointed to a controller. I wish they went with the same method as Aruba, and have them fail to their “Unleashed” platform (which is their equivalent of Aruba Instant.) However I understand that these things might be platform specific and potentially are not possible. At least your investment in Access Points isn’t lost completely. Those AP’s can be reconfigured and continue to be used. I just hate the “halting,” and would much rather they proceed on with the last known good configuration. Obviously any features that are reliant on the cloud would understandably cease, but normal traffic would continue to be passed.

Where do I begin with Aerohive? They have historically been a company filled with some of the top-engineers in the industry. The last headline that I saw was that they employ 14 CWNE’s, to put that into context, world-wide there are only around 265 CWNE’s total. They have consistently been a company driven by engineers. They have heavy adoption in the EDU space, and seemed to have focused on that vertical. Aerohive has also been a large OEM player, partnering with the likes of Dell and others.

Aerohives original platform, which they are now calling Classic, had a huge feature set. However to many, that was actually its drawback. It was an interface that wasn’t entirely intuitive and had a number of nerd-knobs that were in areas that were hard to remember. Much of the flow felt disjointed, with menu selections starting vertically, then expanding horizontally, with drop downs thrown in for good-measure. As with any interface, people who knew it could fly through it. However for those who only touched it sporadically it could be a struggle. That said, it was incredibly granular and provided features that weren’t really available that that time. Aerohive heard the criticism and knew they were being constantly compared against Meraki’s dashboard. So they decided to revamp theirs to make it cleaner and more intuitive and thus released HiveManager NG. Because everything released around that time period had to be Next Generation. Star Trek was apparently way ahead of its time. Unfortunately when NG was originally released it didn’t have anywhere near feature parity to “Classic.” So adoption of it was fairly slow. Further decreasing adoption was that Aerohive never created an easy migration path from Classic to NG. I understand that they were two completely separate platforms more than likely based on two different back-end architectures. However a migration tool, even if an at-cost tool, would have really helped drive adoption. That all said, HiveManager NG, now called Select, does have feature parity to Classic.

Recently, Aerohive released a free version of their HiveManager called “Connect.” Which is essentially a hamstrung version of their platform with some feature limitations. To also provide it for free, you also do not get any support for the product. You can purchase support however. When using Connect, it’s actually running on the Select platform. So by default you can see all the features you are missing out on by not paying for your subscription. However they have graciously allowed you to shut this off.

Pros: Aerohive is a mature product, and although its management interface has gone through a number of iterations, I think it’s come out the other side a better product for it.
One of the features that Aerohive has always touted is their Private Pre-Shared Key (PPSK) feature. This is available in both their Classic and Select platforms. Other products offer this same feature, but Hive has done a good job in their implementation and promotion of the product. They also have made an iOS app so organizations can set up a Kiosk with an iPad for users to self-register and receive their guest credentials.

Another thing that I like about the Aerohive solution is their expiration policy. Obviously this is only applicable to their Select platform, since the Connect platform is free and therefore subscription-less. If your Select platform expires, your equipment will continue to run. However you do lose the ability to actually manage the product until you do one of two things. Either you renew your subscription, or, if you decide that you do not need the entire feature set of Select, you can spin up a new Connect platform and move your AP’s over to it. Unfortunately this migration will not be seamless. So it’s not a completely pain-free policy. But certainly better than others.

Cons: In my opinion HiveManager NG is vastly improved upon Classic. That said, the interface can still feel cluttered and almost rambling. The dashboard portion is fairly solid, but the configuration of SSID’s feels disjointed. That said, for many the setup of networks will be fairly set and forget. With monitoring and troubleshooting being the primary uses of the dashboard.

With their Connect platform you can purchase one of their AP’s for a relatively very cheap price. With MSRPs on their AP122 for $229 and AP130 at $299. Personally I’m not a fan of fighting down. I understand that they are trying to get their product out at a cheap price to introduce it to the world and to compete against the UBNT’s of the world. However to reach that price point normally something normally has to give.


Ubiquiti is an interesting company. On one hand, a lot of people swear by their equipment. However to others, it’s the butt of jokes and criticism. One thing that most do agree on however is that their bridging equipment is rock solid, especially for the price point. However this is a blog about their cloud platform. It’s the only one on this list that I have yet to get any real hands on experience with however. So this will be easily the shortest write-up in this post. Also, this was the only vendor that I wasn’t able to confirm any of the information with. Which I’ll get into in the “Cons” section. This is a platform I’m going to try and learn more about as the year goes on because they seem to be growing and their platform and features seem to be very promising. With that said, I’m going to do my best to reserve judgement on the product until that time. Except for the lack of support or contacts. That irks me as I might mention a time or two below.

Pros: Cheap. Most of their AP’s run right about $100, with their cloud dashboard costing $199 for 1yr, but that covers 100 devices. To put this into perspective, Meraki’s 1yr subscription for one device has an MSRP of $150, and that’s pretty standard across the rest of the platforms as well.  From what I understand, you will need their cloud key. Which is actually a cool bit of kit. It looks like a USB key that hangs off of a port on your switch and acts as a gateway from your on-prem equipment to their cloud dashboard. At least that’s how I understand it. Again, I wasn’t able to talk to anyone about it.

Their dashboard seems fairly clean from the demo that I was able to find online. They also do seem to be putting some interesting features and functionality into their devices. But again, I have zero hands on experience outside of seeing the demo online.

Cons: No support. Well, that’s not 100% true, you can get support in a forum. Which does have Ubiquiti employees who respond. But with no dedicated SLA, or even guarantee that you will receive an answer. However there are many rabid UBNT fans on the forum who do what they can to provide answers and help. But I don’t know that I would want to hang my organizations infrastructure on potentially receiving an answer on an issue from a forum.

For transparency I should note that I have seen discussions of UniFi Elite, which apparently provides phone support, but that’s all I have seen, discussions. Nothing solid. But maybe I’m missing something obvious.

A great example of the lack of support is just this post itself. I sent the table to all of the vendors to verify my entries and gain further insight. While I’m sure I could have posted this to the forum and received a response. I didn’t want a response from someone who runs a WISP off of Ubiquiti equipment, I wanted it from the horse’s mouth. Despite working for a company who sells a lot of Ubiquiti equipment, I have absolutely no direct contacts. The only method of directly contacting them that seemed to work was through a Facebook Message from my personal Facebook account. Ubiquiti’s Social Media team did answer saying they forwarded my request off to the appropriate party. However I never received any response, despite following up again. Their Social Media team did respond both times I reached out within 24 hours. But only that they were sending my request off, or following up with the appropriate resources. So that’s why you don’t see them on the table. If I do receive a response I will be more than happy to update the table and this post with the findings.


As you can see, all of these platforms have both strengths and weaknesses. As with anything, it’s taking a look at the different offerings and determining what feature-set coincides best with your organization’s needs. With that, thanks for reading! If you have any questions or comments just let me know!

Function/Feature Meraki Aruba Central Ruckus Aerohive Connect HiveManger NG
Application Visibility Yes Yes Yes No   Yes
Application Throttling Yes Yes No No  Yes
SSID Throttling Yes Yes No, but can limit per AP  No  Yes
Client Throttling Yes Yes Yes  Yes  Yes
Firewall Yes Yes Not yet  Limited  Yes
Guest Network Yes Yes Yes  Yes  Yes
PPSK Support No No Yes - Through Guest Pass  No  Yes
Location Analytics Yes Only through ALE - Add-On $$$ No  No  Yes
RF Visibility Yes AP's are capable, but not Central No  Limited  Yes
802.1X support Yes Yes Yes  Yes  Yes
802.11k support Yes Yes Not yet  Yes  Yes
802.11r support Yes Yes Not yet  Yes  Yes
802.11v support Yes Yes No  Yes  Yes
Available Support Part of Subscription Part of Subscription Yes  Optional  Yes
On-Prem Controller Option No Yes Yes  No  Yes
SSID Scheduling Yes Yes Yes  No  Yes
Subscription Expires Policy 30 day grace period before devices shut down Fails back to "Instant" AP's halt until reconfigured as Autonomous pointed to a controller Lifetime Subscription Equipment still runs, but you lose cloud managability.