In Search of Tech

A Quick Guide To Configuring An Aerohive AP

Posted on December 4, 2018 by Matthew Norwood

Whether through a purchase or demo gear, you have your hands on an Aerohive AP. If you have never dealt with Aerohive before from a wireless perspective, you might be asking yourself how to configure the AP. This post is meant to serve as a starting point to take that AP and put some configuration on it so that you can start connecting clients.

This post is not meant to be an exhaustive reference, as there are MANY things that can be configured. Rather, it is meant to be a starting point in which the reader is introduced to the overall configuration mechanisms within HiveManager at a high level. At the time of publishing(December 2018), these are the steps needed to put in AP into operation. However, the nature of the rapid pace at which HiveManager is updated means that things could change that alter the configuration flow. It is also worth noting that this post utilizes the public cloud/Internet option for HiveManager. Although there are 3 different deployment options for HiveManager(public cloud, private cloud, single VM), this post utilizes the public cloud option. Configuration between the 3 different models is relatively the same.

Before You Plug That AP In

If you have experience with wireless vendors that use local forwarding from each AP, then you are already accustomed to having APs connected to switch ports configured as 802.1q links/trunks. If your only experience has been with controllers that were only configured with centralized forwarding, an Aerohive deployment is going to look a lot different as you will move from using access or single VLAN switch ports to using 802.1q trunk ports. Should you have some sort of requirement to tunnel traffic back to a central location for things like guest access, fear not. The Aerohive solution allows you to pick and choose which users need to be tunneled over the network to a particular location. Notice that it is particular users and not an entire SSID. The flexibility of the Aerohive solution allows to you be very granular with which traffic is tunneled and which traffic is switched locally.

You probably already have VLANs set aside for your various types of traffic. If you don’t already have one, you will want to create another VLAN for management purposes. Each Aerohive AP will have its own management IP, which will be used to talk to HiveManager, as well as any other Aerohive APs on the network. The management IP will also be used to make connections to RADIUS servers and any additional management systems for things like SNMP and syslog.

Plugging The AP In

Once you plug an Aerohive AP into your network, the AP is going to “phone home”. It can utilize a number of mechanisms to find where it needs to go in the same way that a controller based AP will. The typical method is going to be DNS. By default, the AP will come online, grab a DHCP lease, and try to connect to redirector.aerohive.com. In order to do that, it is going to have to have access to DNS servers, which will almost always be provided via the DHCP lease. However, in addition to DNS, the AP will attempt to set its internal clock with NTP. In order to make a secure connection to the redirector site or ultimately HiveManager, the AP will need to have its system clock set to a fairly current time so that the certificate on the Internet side of the connection is viewed as valid. There are certain defaults the AP can and will use for DNS and NTP, but if the outbound firewall blocks the ports for DNS and NTP, there is a chance the AP will fail to connect. There are ways to manually intervene via a console or SSH connection to the AP, but one of the benefits of cloud networking is making connections work right out of the box without having to perform staging operations on hardware. You should be able to just ship it to the desired location and plug it in.

Assuming the AP is plugged in, gets a DHCP lease, sets its timing, and can perform DNS resolution, it will connect to redirector.aerohive.com. It will sit there until you add the AP to HiveManager using its serial number. We’ll cover that aspect shortly. Once the serial number has been added to your virtual hive, the redirector system will then tell the AP where it should move to for management purposes. This all happens in the background once you add a device serial number to HiveManager.

You can plug in the AP right away, or plug it in after you have built out the initial configuration. You’ll know you have a secure connection to redirector or HiveManager if you see a white light displayed on the AP. Some models, like the wall plate AP(model 150W) will use a green light instead of a white light. Generally speaking, if you see anything other than a red/amber light, consider the device properly connected.

Initial HiveManager Setup

HiveManager is meant to be a self-service operation. As long as you have a license key(in lieu of this, you can trial HiveManager for 30 days with full feature functionality), you can provision your own environment without having to wait on Aerohive to build out your environment for you. This brings up another point. There are two flavors of HiveManager. The most common is referred to as HiveManager Select. This option requires an entitlement key for each of your devices(e.g. AP, switch, router). The second option is referred to as HiveManager Connect. With Connect, the management piece is free. All you have to buy is the hardware. The difference between Connect and Select is that with Connect, you have far fewer configuration and management options. You also will have to use the forums on the Aerohive HiveCommunity site for support. There are options to have phone support with HiveManager Connect if desired. With HiveManager Select, you have ALL options available in HiveManager as well as 24×7 web and phone support.

The first thing you want to do is open a web browser connection to https://cloud.aerohive.com. This is the site you will access HiveManager from for all future connections after registration, so you will want to bookmark or memorize the URL. Since you probably don’t have a login, you will want to click on the “REGISTER” link on the page. Fill in the appropriate information on the registration page. The only field you don’t have to fill out is the one that relates to sending a copy of the registration to a partner or Aerohive representative.

Once you click on “REGISTER”, you will receive an e-mail within a few minutes. Within that e-mail, there will be a link to set a password for the account you created.

If there are going to be multiple administrators within your HiveManager environment, only one person needs to fill out the initial registration information. You can add additional accounts once your virtual hive(VHM) is created through a much easier process. It is worth noting that once you click on “REGISTER”, another screen will appear with the following verbiage as well as an embedded HiveManager onboarding video:

This video will give you a general overview of the onboarding process as well as a basic overview of HiveManager. It is worthwhile to watch it if you are new to Aerohive, and in case you miss the link or just want to watch the video without going through the registration process, it is linked below:

Your password has been set, and now you see the following screen:

I am going to use the default 30 day trial option, but if you have an entitlement key, you can enter it here as well. Once I click on the “Get Started!” button in the bottom right, the following screen appears:

Click on the “Onboard Devices” button to get rid of this screen. You won’t see this screen again, and it is better if we learn how to configure things in the way in which we will normally do so within HiveManager. You should be looking at the “MONITOR” tab within HiveManager now. We’ll come back to this page in a bit. First though, we want to build an initial network policy, so click on the “CONFIGURE” tab at the top of the screen.

You should now see the following:

Note: The network policy is the container in which almost all configuration of a device is stored. Apart from device specific things like the hostname, almost everything you will do configuration-wise for all of your devices will live within the network policy. I’ll cover things like the network policy, user profile, and radio profiles in another post as each of those items require a much more detailed breakdown.

Click on “ADD NETWORK POLICY” and you will see the following screen:

In order to avoid configuration sprawl, we could configure wireless and wired devices under a single network policy. However, since all we are worried about for this particular post is wireless, uncheck the boxes that say “Switches” and Routing”. Give your network policy a name and then click “SAVE” at the bottom right of the screen.

You should see the following screen now:

Since we are only building a policy for wireless, you will notice that the “Router Settings” tab at the top is now grayed out. There is no point in going to that tab since we are not dealing with routing in this policy. What we are looking at now is the “Wireless Networks” tab. On this tab, we can create an SSID, or select an existing SSID if we had created one in another policy and wanted to re-use it. Since this is our first policy, click on the “ADD” button. You’ll notice that when you click on the button, two choices appear:

If we were creating a guest network, we could click on “Guest Access Network” and it would give us a streamlined way to configure guest type SSIDs. For this particular post though, we just want to create a simple WPA2 Personal SSID which uses a standard passphrase. Click on “All other Networks (standard)”.

You should now see the following screen:

Type in a name for your SSID. Notice there are two fields at the top. The “Name (SSID)” field is simply the name of the SSID object as it will appear in HiveManager. If you hit the tab key or simply click on the “Broadcast Name” field below, it will duplicate whatever you typed in on the “Name (SSID)” field. The “Broadcast Name” is what will actually be advertised over the air via a beacon. Under the SSID Usage section, you will see the various authentication types that can be used within this particular SSID. We want to create a basic WPA2 Personal SSID, so click on the “Personal” button. Private Pre-Shared Key(PPSK) is something similar to the standard WPA2 Personal authentication, but it uses multiple passphrases. See here for more info on PPSK.

Enter a passphrase in the “Key Value” field. If you want to make sure of what it will be set to, click on the “Show Password” box to display what you actually typed in the “Key Value” field.

Note: If at any time you are unsure of what you are looking at on the screen, there is always a question mark icon on the far right of the screen. If you click on that question mark, it will open up another tab and display the help documentation about that particular section or feature.

Click on “SAVE” at the bottom right. It should return you to the main “Wireless Networks” screen like the following:

Click on “NEXT” in the bottom right of the screen. Now, you will be looking at the “Device Templates” tab. Since we turned off switching and routing for this particular network policy, the only thing you see in the “Device Templates” tab is a section labeled “AP Templates”. If switching was turned on, it would display another section labeled “Switch Templates”.

We’re going to skip the “Device Templates” section in the interest of just getting an AP up and running. I’ll cover this tab in another post. Click “NEXT” at the bottom right and it should bring you to the “Additional Settings” tab as shown below:

We are going to skip this tab as well. It contains a bunch of different things that will be covered in another post. Click “NEXT” and it should bring you to the “Deploy Policy” tab which looks like this:

If we had any APs already added to HiveManager, this screen would show the APs in a list and then you could select the AP(s) you wanted to apply this policy to. However, we have not added an AP yet, so we are finished with the network policy configuration. Click “EXIT” on the bottom left of the screen.

Now you are taken back to the “Network Policies” screen. You should see the network policy we just created and it will look like this:

The basic network policy configuration is complete. The next step is to get the AP added to HiveManager and push the configuration to it.

Adding An AP To HiveManager

If you have not plugged in your Aerohive AP, go ahead and do that now. Eventually you should see a solid white light on the AP, or if it is one of the models like the AP 150W, it will be a green light.

Click on the “MONITOR” tab in HiveManager. Next, click on “ADD” and select “Advanced Onboarding”. You will see the following:

On this screen, add the serial number of the AP in the appropriate box. If you have multiple APs, you can add multiple serial numbers separated with a comma. Alternatively, you could use a CSV file to bring in a large number of APs at once. With the serial number(s) in place on the screen, click on “Next” at the bottom right. The following screen will appear next:

On this screen, you will be creating an “Organization” which directly correlates to the “MAPS” tab, which is where you can setup all of your different locations, buildings, and floors within a given building. When you fill in each of these lines, it uses the “City and State” to create a location, the “Street Address” to create a building, and then creates a default “Floor 1”. You can then assign each AP to a particular floor within a building, but you will have to add a floor plan first, which cannot be done from within this onboarding wizard. You can also go over to the “MAPS” tab and change the name of the location, building, etc. For now though, fill in each section and click on “Next” at the bottom right. The following screen will be displayed:

By default, the “Create Network Policy” screen will try and get you to make a new network policy for the device(s) you are onboarding. However, we previously created a network policy, so change the selection to “Use an existing network policy” and it should default to the name of the network policy you built previously. With that existing network policy selected, click on “Next” at the bottom right. The following screen will be displayed:

At this point, you should see the “Review Summary” screen. Click on “Finish” at the bottom right.

You will now be placed back in the main HiveManager interface in the “MONITOR” tab section. If your AP was recently powered on, it may look like the image below:

Once the AP makes a secure connection to HiveManager, the red hexagon on the far left under the “Status” column will turn green. The AP will push down the configuration from the network policy when it connects to HiveManager for the first time. Additionally, depending on the code level on the AP, it may update to a newer version. Expect it to take a few minutes for the AP to come up, update itself with configuration, and reboot before achieving a normal steady state. You may see the connection status go green, turn red again, and then go back to green.

When the AP has been updated with the network policy and is at a normal state to connect clients, it will look like the following:

Updating The Configuration

Your AP is now up and running in HiveManager, but the configuration was uploaded during the onboarding process. What I would like to do is show you what it looks like when you make a change to the network policy or device and need to push an updated configuration to it. Let’s change something simple like the hostname of the device.

Click on the hostname of the AP. By default, it will choose a hostname of “AH-” and the last 6 characters of its default MAC address.

Under the “CONFIGURATION” menu on the left side of the screen, click on “Device Configuration”. Modify the “Host Name” field to whatever you want to name the AP. Once that is done, scroll down and click on “SAVE” in the bottom right of the screen.

If you scroll back up to the top after clicking on “SAVE”, you will see a box that says “UPDATE NOW”. You could click on that and the changes will get pushed to the AP, but we are not going to do that in order to see what it will look like from the main MONITOR tab page. Click on “Back to Device List” at the top left instead.

Now you should see the main MONITOR tab screen with your AP, but notice there is a red exclamation point next to the green hexagon on the far left. That red exclamation point tells you that there is a difference in the configuration on HiveManager and the AP itself. We need to push this change to the AP before it will take effect.

You can click on the red exclamation point and see what those pending changes are. Go ahead and click on the exclamation point.

Another window opens up with 3 tabs. Since there is a pending change, it defaults you to the “Audit” tab.

The Audit tab shows you the general sections in which the configuration changed. This lets you know what changes were made from a high level. Click on the “Delta” tab.

When the Delta tab is displayed, you can see the exact CLI string that will be pushed to the AP. Note the “hostname” command I highlighted. If you were to click on the “Complete” tab, you would see the entire configuration that HiveManager shows for that particular AP. Click on the “X” at the top right of this window to close it. You could click on “CLOSE” at the bottom right as well if you wanted to.

Now that we know what changes are going to be pushed down to the AP, we want to initiate the push. Select the box to the far left of the line the AP is displayed on.

Next, click on the “Update Devices” button at the top right of the screen.

This new window that opens up gives you some options regarding pushing the configuration, updating the firmware on the device(Aerohive APs run HiveOS), or even scheduling when that updated configuration or firmware gets applied to the AP.

Note: There are two methods to push configuration to a device. Delta will only push the incremental changes and will not affect the AP to a great extent in terms of client connections unless you are changing something that is RF related. Complete will push the entire configuration to the AP, but in doing so, it will reboot the AP. You can use Delta pushes for the overwhelming majority of configuration changes to an AP. The system is smart enough to tell you if a complete push is required and will go so far as to make it to where you cannot select the delta option.

Since all we want to do is update the hostname, ensure that the “Delta Configuration Update” option is selected and then click on “PERFORM UPDATE” in the bottom right of the window.

After clicking on “PERFORM UPDATE”, HiveManager will start to push the delta update to the AP. It should take a few seconds to push it out. Once it is done, the red exclamation point will be replaced with a green check mark. When you see that green check mark, you know the configuration on HiveManager is in sync with the configuration on the AP.

You should be able to make a client connection to this particular AP using the passphrase you set when configuring the SSID.

That’s all there is to it! Well, that’s not ALL there is to it. There are a lot of other things you can configure in HiveManager, but those will be covered in follow-up posts. The goal here was to get some configuration loaded onto the AP so that you can connect some clients to it.

Posted in aerohive, wireless | Comments Off

Configuring Microsoft NPS for Aerohive 802.1X Authentication

Posted on March 26, 2017 by Matthew Norwood

This post is a starting point for anyone who wants to use 802.1X authentication with Aerohive APs and Microsoft NPS. I will provide configuration screen shots for both of Aerohive’s management platforms and for NPS running on Microsoft Windows 2008 Server. It is not intended to be an exhaustive guide, but should be a decent starting point. Every implementation will be different in some respect, and some of these steps may not be the exact manner in which you configure Microsoft NPS. The steps for Aerohive may also be different depending on what you are trying to accomplish. I’ll make sure to note my particular scenario when appropriate.

Versions Used:

HiveManager Classic/HM6/HMOL – 6.8r7a

HiveManager NG – 11.19.99.0 (March 2017)

Microsoft Windows 2008 Server

Assumptions:

Basic understanding of navigation within the HiveManager Classic and/or NG interface.
No RADIUS objects or user profiles for 802.1X authentication have been configured within HiveManager Classic or NG. If you have already configured some of them, just skip the steps that cover the creation of those objects.
Microsoft NPS is installed and a server certificate for the NPS machine has been issued and installed.

Scenario

Company XYZ wants to authenticate Active Directory users on a single 802.1X enabled SSID. They want to be able to treat corporate users and contractors with different security policies, QoS, time of day restrictions, etc. This will involve placing the two different types of users in separate user profiles to control access and end user experience. If a corporate user connects, that user will be placed into VLAN 202 after membership in the corporate users group in Active Directory has been verified. If a contractor user connects, that user will be placed into VLAN 203 after membership in the contractor user group in Active Directory has been verified.

Note: To skip down to the HiveManger NG configuration section, click here.

HiveManager Classic Configuration

From within the Network Policy Guided Configuration, the first step is to add an 802.1X SSID. If you have not already created one, click on “Choose” and then click on “New”:

2. Another screen will open up to configure this new SSID. Name it whatever you want and select which bands it will be broadcast on. Next, ensure the “WPA/WPA2 802.1X (Enterprise)” button is selected and then click on “Save”.

3. You will be returned to the main configuration screen for the network policy and it will look something like this:

4. Now that the SSID is shown, you will need to select the RADIUS server to use. This will be the “AAA Client Settings” object that is found under the Configuration/Advanced Configuration/Authentication section within HiveManager. Since no RADIUS server is defined, you need to click on the “<RADIUS Settings>” segment and choose “New”.

5. Type in the name of this RADIUS object and give it a description if you want. You will need to create an IP address or domain name object and assign it to the “IP Address/Domain Name” field. I tend to favor using IP addresses over host names, but do whatever you prefer. You will also need to enter a shared secret that will need to match what is configured on the NPS side.

6. Click on “Apply” and it should look like this:

7. Click “Save” and it will return you the main configuration screen for the network policy. It probably looks like this:

8. Since we want to place corporate users in VLAN 202 and contractor users in VLAN 203, we need to add some user profiles for each of those VLANs and ensure the RADIUS attributes configured in NPS match the correct user profile. We’ll need to select a default user profile, and then select the user profiles for our corporate and contractor users. The default profile isn’t going to be used, but I created a restricted profile that has no access and goes into a dummy VLAN. Click on “Add/Remove” under the “User Profile” section. Next, choose your default user profile and then select the “Authentication” tab on the left and select the user profiles you want to assign authenticated users into. If those profiles do not exist, you can create them by clicking on the “New” button. I like to match the attribute value to the VLAN in user profiles. If you don’t do this, just make sure you use the attribute value in the NPS configuration and not the VLAN id. There is a way to use the actual VLAN id instead of the attribute value, but it involves using a different RADIUS attribute. In NG, this issue does not exist from a configuration perspective. Once the profiles have been selected, click on “Save” and you should see something like this:

9. Basic 802.1X setup is now complete for HiveManager Classic. Push the configuration changes to the appropriate APs. Next, we will need to configure Microsoft NPS. Click here to move to that section.

HiveManager NG Configuration

NG has an option that HiveManager Classic does not. You can step through the entire process of configuring an external RADIUS server by using the “Guided Configuration” method. On the far right side of every screen within the NG interface, there is a button that looks like this:

When you click on it, another screen appears with a list of all the guided configuration tasks available, and one of them is to create an external RADIUS server.

Here is how you do it without the guided configuration:

Within the “Network Policy” configuration, after you have named the policy and selected whether it will be wireless, wired, or both, click “Next”. At the “Wireless Settings” tab, click the “Add” button and choose “All other SSIDs (standard)”.

2. Select “Enterprise” for authentication type after naming the SSID.

3. Next, you will need to define the RADIUS server, but before that, you will need to define a RADIUS server group. Click on the plus sign next to “Default RADIUS Server Group”. Name the group and then select “Add” and “External RADIUS Server”.

4. Give the RADIUS server a name and description(optional) and then click the plus sign next to the “IP Address/Host Name” field.

5. Give the object a name and type in the IP address of the RADIUS server. Click “Save”.

6. With the RADIUS server IP defined, the last thing you need to do is type in the shared secret that will match what we will configure shortly in NPS. Once that is entered, click “Save”.

7. Now that the RADIUS server is configured, you should see a screen similar to this one:

8. Click on “Save” and it should take you back to the main SSID configuration screen.

9. Scroll down the screen a bit and you will see the “User Access Settings” section, which is where you will add various user profiles that will get applied based on RADIUS attributes that are returned. You will need to check the box that says: “Apply a different user profile to various clients and user groups.” This will allow you to put a user into the correct profile based on what is returned by the RADIUS server.

10. I already had a user profile with no real access defined, so I chose that as the default. I still need to create a user profile for the corporate and contractor users, and that is done by simply clicking the “Add” button and setting a profile name and VLAN. If the VLAN each user profile will be assigned to does not exist, you will need to create the VLAN object by clicking on the plus sign next to the “Connect to VLAN” field. Here are the profiles for the corporate user and the contractor user. There are plenty of things you can set within the user profile, but those specific items will not be covered in this post.

11. Once those profiles have been created, the screen should display something like this:

12. The next step is to add assignment rules so that the RADIUS attributes are used to put the user into the appropriate user profile. Click the plus sign under “Assignment Rules” for the first user profile(CorporateUsers in my case), and then click the plus sign on the following screen that will look like this:

13. Select “RADIUS Attribute” and then put the VLAN number in the “Attribute Values” section.

14. Click “OK” and then do the same for any other user profiles you want to match up with the RADIUS response. It should look similar to this when you are done:

15. Click “Save”. Basic 802.1X setup is now complete for HiveManager NG. Push the configuration changes to the appropriate APs by stepping through the other screens in the network policy or via the Monitor tab. Next, we will need to configure Microsoft NPS. Click here to move to that section.

Microsoft NPS Configuration

Open up the NPS console and expand the “RADIUS Clients and Servers” folder.

2. Right click on “RADIUS Clients” and select “New”. The following window should appear:

3. Fill in the fields as shown below with a “Friendly name” and the IP address(es) of the AP(s) that will be functioning as the authenticator for wireless clients. You can use an entire range as shown below, or you can use individual IP addresses and create multiple “RADIUS Client” objects. Make sure the shared secret matches what was configured in HiveManager. Once that is done, click on “OK”.

4. Now it should look something like this:

5. Next, expand the “Policies” section on the far left side, right click on “Connection Request Policies” and select “New”. We don’t need to get too specific in this section. We just want to ensure that our 802.1X authentication requests get processed locally.

6. Name the policy whatever you want and click “Next”.

7. The next screen is where you will need to specify a condition. Click “Add”.

8. When the next screen appears, you have several options to choose from. I just selected “NAS Port Type”, but you can choose whatever method you want. More complex environments might go a different route than this. Select the method you want to use and click “Add”.

9. For the method I chose(NAS Port Type), I just selected “Wireless – IEEE 802.11”. Make your choice and click “OK”.

10. You should see your condition in the “Specify Conditions” screen. Click “Next”.

11. Click “Next” at this screen. Just accept the defaults.

12. Click “Next” at this screen as well. The defaults are fine. We’ll handle the EAP type in the next section dealing with network policy. However, note that you can override the network policy settings and choose a different EAP type if you were fairly granular in terms of how you setup this connection request policy.

13. Click “Next” at this screen as well. The defaults are fine, but again, you can use this to get far more granular in how you respond to authentication requests.

14. At this final screen, just click “Finish”.

Now you should see your Connection Request Policy that was just created.

The last portion of the NPS configuration is the creation of the network policy. For this example, I will be creating two of them. One for the corporate users and one for the contractor users. Your environment may be completely different. For example, in educational organizations, I normally see this broken up into students and staff/faculty.

15. Select the “Network Policies” folder on the far left side of the screen. You should see a screen similar to this:

16. Right click on the “Network Policies” folder and select “New”. When the new window opens up, give the policy a name and click “Next”. Remember that you will be making multiple policies, so the name should reflect the group of users it will apply to, unless you are just using one user profile on the Aerohive side.

17. The next screen is going to be the “Specify Conditions” screen. This is where we will define which Active Directory group a user needs to be a member of for this policy to apply. Click the “Add” button.

18. In the “Select condition” window, choose “User Groups” and click “Add”.

19. When the “User Groups” window appears, click “Add Groups”.

20. Type in the name of the group you need to authenticate the given group. In my example, I typed in “corporate” and hit the “Check Names” button. It automatically chose the “CorporateUsers” group I had created on a previous occasion. Once the proper group is displayed, click “OK”.

21. It will take you back to the “User Groups” window, but the correct group should be shown. Click “OK”.

22. Now you should be looking at the “Specify Conditions” portion of the “New Network Policy” configuration with your Active Directory group shown. Click “Next”.

23. When the “Specify Access Permission” window appears, you can take the default “Access granted” and click “Next”. Note that you can permit or deny access, so with a wide range of Active Directory groups, you could allow a larger group of users with one network policy, but deny a smaller subset using a different group and network policy and placing the deny entry above the permit entry.

Here is where it might get a little confusing if you are unfamiliar with EAP types. If you don’t know much about EAP, here is a starting point. Basically, with NPS, you are going to configure PEAP using MSCHAP v2 or use the EAP-TLS method which involves client side certificates. This example is going to use the easier PEAP with MSCHAP v2 method. Other than generating client side certificates, there is not much difference in configuring NPS to work with EAP-TLS from the method I will illustrate below.

The following window should appear:

24. Click the “Add” button and select “Microsoft: Protected EAP (PEAP)” as the EAP type to use. Click “OK”. The screen should look like this:

25. Select “Microsoft: Protected EAP (PEAP)” in the “EAP Types” window and click on “Edit”. Ensure that the only entry in the “Eap Types” window is “Secured password (EAP-MSCHAP v2). You may have to click the “Add” button and select it. You may also have to select other entries and click “Remove” to get down to the single option. You should also see the certificate with your NPS server name selected in the “Certificate issued” field at the top of the window. If there is not one, you will need to generate one and start the “Network Policy” configuration over from the start. Click on “OK”.

26. When the “Configure Authentication Methods” window appears, uncheck everything in the “Less secure authentication methods:” section at the bottom of the window and then click “Next”.

27. At the next screen titled “Configure Constraints”, you can keep the defaults and click on “Next”. If you want to get more granular with how the client sessions are treated, there are some options here to do that.

28. The “Configure Settings” window will appear next. This is where we are going to finally define which user profile to put the corporate(in this example) users into. Two attributes should already be present for “Framed-Protocol” and “Service-Type”. You can delete both of these attributes by selecting them and clicking on “Remove”. They won’t be needed.

29. Now we are going to add the three attributes needed. Ensure “Standard” is selected under “RADIUS Attributes” and click the “Add” button. Select “802.1x” for the “Access type” and select “Tunnel-Medium-Type” under the “Attributes” section and click “Add”.

30. When the “Attribute Information” window appears, click “Add”.

31. Select “Others” and then select “IP (IP version 4)” and click on “OK”.

32. Click “OK” when the following “Attribute Information” screen appears:

33. You should see the “Add Standard RADIUS Attribute screen now. Select “802.1x” for the “Access type” if it is not already selected and select “Tunnel-Pvt-Group-ID” under the “Attributes” section and click “Add”.

34. Click “Add” when the following window appears:

35. Since this policy is for the corporate users, we are going to enter “202” for the attribute value as a string. Type in the value and click on “OK”.

36. Now your screen should display the “RADIUS Standard” attribute with a value of “202”. Click “OK”.

37. You should see the “Add Standard RADIUS Attribute screen once again. Select “802.1x” for the “Access type” if it is not already selected and select “Tunnel-Type” under the “Attributes” section and click “Add”. When the following screen appears, click “Add”:

38. Select “Generic Route Encapsulation” under the “Commonly used for Dial-Up or VPN” section and click “OK”.

39. When the following screen appears, click “OK”:

40. You should be looking at the “Configure Settings” screen with the three RADIUS attributes you configured. Click “Next”.

41. At the “Completing New Network Policy” screen, click “Finish”. You should now be taken back to the “Network Policies” screen in the main NPS window. The “Corporate Users” policy is at the bottom of the list. We want to move it to the top, so right click on the “Corporate Users” policy and select “Move Up”. Repeat until it is in the first position.

42. Next, we need to create our policy for the contractor users, but we will use a shortcut to save time. Right click on the “Corporate Users” policy and select “Duplicate Policy”.

43. When the “Copy of Corporate Users” policy appears, right click on it and select “Properties”.

44. Change the name of the policy to whatever you want it to say. For this example, I will change it to “Contractor Users”. Then, click on the “Conditions” tab at the top.

45. Select the “User Groups” condition and click on “Edit”.

46. Change the user group to whatever it should be. In this example, the group is changed to “ContractorUsers”. Once the proper group is displayed, click on the “Settings” tab.

47. On the “Settings” tab, select the “Tunnel-Pvt-Group-ID” in the “Attributes” section and click on “Edit”.

48. Edit the attribute by selecting it and clicking on “Edit”. Change it to whatever value is needed. In this example, it is changing from a value of “202” to “203”. Click on “OK” when the updated value is displayed.

49. Once that is done, you should be returned to the “Settings” screen. If everything looks right, click on “OK”.

50. You will be returned to the “Network Policies” screen in the main NPS window. Reorder the cloned policy and put it in the second position. It should look like this:

That’s all there is to it. You should be able to connect to the SSID and authenticate with Active Directory credentials. If you get a request to trust the certificate after typing in your username and password, don’t be too alarmed. Unless your certificate was issued by a certificate authority that your device trusts, that is going to happen. However, once you trust the certificate, that warning will go away. For example, here is what is displayed on my iPhone after successfully authenticating with a username and password for the first time:

One final note with regards to troubleshooting. If you run into authentication issues, make sure to look at what is being reported in the NPS log. You can find it under the “Custom Views/Server Roles” within Event Viewer.

If you see any sort of access denied message, it is most likely an NPS configuration issue. If you don’t see any entry after authenticating(good or bad), it is probably an Aerohive configuration issue. Additionally, if you do see access granted issues, but the client still will not connect, make sure to check for MAC filtering or other firewall policies on the Aerohive side. They tend to show up as “incorrect username or password” errors on the device, even though that was not the problem. Ask me how I know. 🙂

Conclusion

Hopefully this will help with configuration of Aerohive APs and NPS. I need to reiterate that I am not an expert when it comes to Microsoft NPS. If you run into problems, feel free to leave a comment or ping me on Twitter(@matthewnorwood). I’ll try to help out if at all possible.

Posted in aerohive, security, wireless | Tagged aerohive, security, wireless | Comments Off

Aerohive’s Private Pre-Shared Key Technology

Posted on January 9, 2017 by Matthew Norwood

A fairly common question I get asked when talking to people about Aerohive Networks is “what makes us different?” In other words, why should they choose Aerohive to replace their existing wireless vendor? It is a fair question. After all, plenty of vendors sell APs that can serve the most basic wireless needs. All of the vendors I compete with do a lot of the same things when it comes to general wireless.

One of the things I like to talk to potential customers about is Aerohive’s Private Pre-Shared Key(PPSK) technology. For some organizations, PPSK is not something they are interested in. Maybe they already have a pretty solid 802.1X implementation and don’t have a need for WPA2 Personal(pre-shared key) security on their wireless network. That’s perfectly fine in my book. I have other things I can always talk about with regard to an Aerohive solution. For quite a few organizations though, they see the advantage of PPSK over standard pre-shared key implementations and jump right in to using it. I wanted to briefly discuss what PPSK is and how it can be utilized with an Aerohive solution. No configuration screenshots or long demonstration videos. Just a basic overview.

Some Potential Issues With Standard PSK(WPA2 Personal)

1. The key is the same for all devices connecting to the SSID/WLAN. This means that if the key is compromised, anyone can connect to the wireless network. There are some additional things one could employ like MAC filtering(which isn’t very hard to defeat), but the one thing you will have a hard time doing is preventing someone from eavesdropping on a session, capturing the 4 way handshake, and then decrypting the traffic for that session. See the following:

2. If you fire someone, or have to change the key for any other reason, you have to change the key on all the devices that connect to that SSID/WLAN.

3. Identity is hard to determine since every device is using the same key. You could keep a running list of MAC addresses and use that to determine who a given device belongs to, but that creates an administrative burden and MAC spoofing is relatively easy to do.

Why Not Use 802.1X?

Without getting too far down into the weeds, 802.1X(WPA2 Enterprise) is more secure than pre-shared key(WPA2 Personal). The issue of key compromise is taken care of through the use of dynamic encryption keys for almost every EAP type that would be used in the authentication process and these keys are unknown to the user of the wireless client authenticating with 802.1X. Additionally, identity is going to be very easy to determine when devices authenticate with 802.1X.

The logical thought would be that every device should authenticate with 802.1X and not use the WPA2 Personal method. However, this doesn’t always occur for a number of reasons.

1. 802.1X is not the easiest thing to implement. If you are a seasoned wireless or security professional, you might disagree with that, but the IT world is not always overflowing with people that know how to setup authentication back ends using RADIUS, certificates, directory services, etc.

2. Not all devices support 802.1X. While it is getting harder to find laptops, tablets, and smart phones that don’t support 802.1X, there are literally millions(probably billions by now) of devices that don’t have 802.1X capabilities. The Internet of Things comes to mind. I have quite a few of these “dumb” devices in my home that only support WPA2 Personal and “no authentication” for their connection method.

PPSK To The Rescue!

Aerohive’s Private Pre-Shared Key technology bridges the gap between the standard PSK implementation and 802.1X.

1. You still use pre-shared keys to access the network, but under a single SSID/WLAN, you can have a bunch of different keys. Each device, or group of devices can have their own unique key. Whether you need ten keys, a thousand keys, or more; they can all exist under a single SSID/WLAN. See the following:

2. If someone gets fired or their key gets compromised, you can simply invalidate that key and not have to change the key on all devices using the same SSID/WLAN since they are using a different key. Of course, when it comes to key compromise, you would have to know that it was compromised. There are some additional things you can do on the Aerohive side to limit the damage of a key that is compromised without you knowing about it, but I will tackle that in another post.

3. Identity is tied to the key being used, so you WILL know who is connecting to the network based on the uniqueness of their key in the same way that certificates and usernames and passwords are used to determine identity with 802.1X. It just requires less complexity than an 802.1X setup.

Closing Thoughts

Like I said from the start of this post, PPSK is not something that every organization uses. For those with solid 802.1X implementations, they generally prefer to use that over PPSK. Other organizations have actually moved off of 802.1X and rolled out PPSK across their entire network. If nothing else, PPSK is another tool that Aerohive provides as something to differentiate themselves from other wireless vendors. The standard advice we give organizations is that with Aerohive, you can have your 802.1X SSID, your open guest network(if you so desire), and a catch-all PPSK SSID for anything that would connect with a pre-shared key.

In full disclosure, Ruckus Wireless has similar technology they call Dynamic PSK. I don’t have any deep insight into how Ruckus Wireless’ DPSK solution compares to Aerohive. I can only tell you how Aerohive functions, and in my next post, I am going to talk about what you can do once you determine that device identity from PPSK, or even 802.1X for that matter. In short, based on identity, you can assign different firewall policies, QoS settings, and other things, but I will leave that for the next post. While I do tend to talk about PPSK a lot in pre-sales discussions, it really just sets the stage for what can be done after the authentication happens. That’s where it really gets interesting!

Posted in aerohive, security, wireless | Tagged aerohive, security, wireless | 2 Comments

Does Aerohive Scale?

Posted on June 10, 2016 by Matthew Norwood

Note: If you are a TL/DR type of person, let me give you the short answer to the title of the post: Yes! 🙂

For everyone else, I will try my hardest to keep this as short as possible. I will include as many pictures and CLI screens as I think are needed to help answer the scalability question, and no more. While I entertained the idea of making two separate posts regarding scalability, I felt it best to keep it to a single post since AP(Access Point) to AP communication and layer 3 roaming are best explained together. My wife and friends will tell you that I can be long-winded. I apologize in advance.

Let me just start by saying that I work for Aerohive Networks. I have been an employee of Aerohive for about 3 months. In that time, I have learned a tremendous amount about the overall Aerohive solution and architecture. Prior to working for Aerohive, I worked for a reseller that sold for Cisco(to include Meraki), Aruba, and Aerohive. I wasn’t unaware of Aerohive, but let’s be honest for a minute. Aerohive doesn’t have a lot of information out there around how their various protocols work. This isn’t unique to Aerohive, as plenty of vendors withhold deep technical information. It isn’t necessarily done on purpose. It just takes a lot of time and effort to get that information out there in a digestible format for customers and partners. The smaller the company, the harder that is to do. Lastly, there are plenty of people within IT that don’t really care how it works, just as long as it works.

My goal with this post is simple. I will attempt to expound on Aerohive’s scalability. This topic comes up in pre-sales discussions from time to time. I have not been an Aerohive employee long enough to have it come up more than a handful of times. I can tell you that in my former position at a reseller for multiple wireless vendors(Aerohive, Aruba, Cisco, Meraki), this topic DID come up with customers and internally among the folks within the reseller that I worked for. I suspect that in the months and years to come with me working in a pre-sales capacity at Aerohive, it will come up even more.

I’ll try to address the two biggest scalability issues. They are:

AP to AP communications, to include associated client information
Layer 3 roaming

Before I dive into that, a bit of initial work is needed for those unfamiliar with Aerohive and the concept of Cooperative Control. Through a set of proprietary protocols, APs talk to each other and exchange a variety of information about their current environment or settings, to include client information. For a basic overview of Cooperative Control and the protocols used within it, you can read this whitepaper on Aerohive’s website.

Got it? Good. Let’s tackle the first scalability “issue”.

AP to AP Communications

Imagine you have a building with multiple floors and about a thousand APs. You know that there are other wireless vendors with controller based systems that can support this amount of APs. You wonder how Aerohive would do the same thing with no central controller managing the RF environment and the associated clients. How can 1,000 APs manage to keep up with each other? Certainly, the controller that can handle 1,000 APs has sufficient processing power and memory to perform this task. No AP on the market would have similar processing power in a single AP. So how does Aerohive do it?

A few quick points:

It is very likely that these 1,000 APs are not on the same local subnet from a management IP perspective. Maybe you divided up the APs in 2, 3 or 4 subnets for management purposes with the intent of keeping the BUM(broadcast, unknown unicast, and multicast) traffic down to a reasonable level.
All 1,000 APs are not going to be within hearing distance(from an RF perspective) of each other. This is an important point to remember, so hang on to that one in the back of your mind.

The basis of AP to AP communications revolves around the Aerohive Mobility Routing Protocol, or AMRP. To take the definition from the whitepaper I linked to above:

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.

Since I don’t have 1,000 APs and associated PoE switches to build out my hypothetical multi-floor building, I am going to shrink it down to 2 switches and 7 APs. 5 of the APs will be on one switch and all APs on that switch will share the same management subnet and client VLANs. The other 2 APs will be on another switch and will use the same VLAN number for wireless client access, but that VLAN will have a different IP subnet than the switch with the 5 APs on it as well as a different AP management VLAN and IP subnet. The switches will also be separated with a layer 3 boundary. My lab environment looks like this:

The switches and APs will boot up and start talking to each other. I’ll deal with automatic channel and transmit power selection in another post. AMRP will ensure that all APs are talking to each other. Since I am dealing with 7 APs in relatively close proximity to each other, they will all hear each other at pretty good signal strength. I’ll drill down more into that RF range aspect shortly.

Let me connect to one of the 5 APs on switch 1. I can do this from either HiveManager, or by simply using SSH to connect to the AP locally. Alternatively, I could also use the local console port on the AP to grab this information. I am going to take a look at the neighboring APs from an AMRP perspective.

As you can see, this AP can see 4 neighboring APs. It doesn’t show the other 2 that reside on switch 2. The reason for this is due to the fact that those APs are on a different subnet from a management perspective. Even if it can hear the other APs over the air, they still don’t show up in the AMRP neighbor list. We’ll get to that when we cover layer 3 roaming.

If I connect a client to the SSID(GoFast2) these APs are all advertising, I can now see that client in the “show amrp client” CLI output. It appears on all APs within the same local subnet. In the first image, I am connected to an AP on the same local subnet, but not the one the client is directly associated to.

In this second image, I am connected to the AP the client is directly associated to. You can see the output is different as it shows the interface the client is connected to and not the IP address of the AP like in the previous CLI output.

Just to clear up any misunderstanding, AMRP is NOT building tunnels between each AP for communications purposes. It is handled in a secure way, but it is not done via a tunnel. All connected client information will be shared among the APs on the same local management subnet via AMRP. That brings me to an important issue regarding scalability.

In order to increase scalability, Aerohive gives you the ability to ONLY share client information between APs that are within RF range of each other. By default, all APs on the same management subnet will share client information with each other. While this is perfectly fine in many environments, if there are a large number of APs on a given management subnet, you probably want to change that default setting and only have client session information sent to APs that the client can actually roam to. Keep in mind that restricting it to APs within RF range will also include any APs that a layer 3 roam could happen on. In Hive Manager NG, this is done in the following location:

Configure/Common Objects/Hives

Select the Hive containing the APs you want to change. At the bottom of the screen in the Client Roaming section, just uncheck the box labeled “Update hive members in the same subnet and VLAN.” Update the configuration on your APs and you will now remove client session sharing between APs not in radio range of each other.

So now, instead of this:

You have this:

As a client roams from one AP to another, the AP it roams to will now share that client session with all of its APs within RF range. The AP that the client roamed off of will stop sharing that client info with APs that are in RF range of it since it no longer maintains the client session. The cycle repeats itself as the client roams to yet another AP. Using this method, the APs do not have to know about all client sessions on all APs within the same local management subnet. That allows Aerohive to scale out from a layer 2(and layer 3) roaming perspective.

Layer 3 Roaming

Layer 3 roaming is handled by another Aerohive protocol entitled Dynamic Network Extension Protocol, or DNXP. To take the definition from the whitepaper I linked to above:

DNXP (Dynamic Network Extension Protocol) – Dynamically creates tunnels on an as needed basis between HiveAPs in different subnets, giving clients the ability to seamlessly roam between subnets while preserving their IP address settings, authentication state, encryption keys, firewall sessions, and QoS enforcement settings.

How it works is pretty interesting. To explain it, I will have to go back and talk about AMRP. On a given AP management subnet, AMRP takes after OSPF to a certain extent. If you are familiar with how OSPF works on a shared Ethernet segment, you know that there is this concept of a designated router or DR. Additionally, there is a backup designated router, or BDR. The DR and BDR exist to reduce the amount of OSPF traffic flowing between OSPF neighbors. The DR is responsible for sending updates to all the other routers to inform them of the network topology. If it fails, the BDR takes over. Using that same concept, Aerohive APs on a shared Ethernet segment(i.e. layer 2) elect a designated AP, or DA for short. They also elect a backup designated AP, or BDA. This can be seen by running the “show amrp” command on a given AP. Take a look at the following CLI output:

You can see here that the DA for the shared segment these APs are on is 172.16.100.2. The DA serves several different functions, but one of things it keeps track of is the load level on all the APs within a given segment. When it comes to layer 3 roaming, this DA has a pretty important job. It decides which AP on its given Ethernet segment will spin up the tunnel required for layer 3 roaming. Instead of just spinning up tunnels from the AP the client left during the course of its layer 3 roam, it will seek out the least loaded AP on the given Ethernet segment and have that AP setup the tunnel to the AP the client roamed to. This chosen AP establishes the DNXP tunnel to the AP that the client roamed to on a different subnet and ensures that the network knows that this now roamed client is reachable through this chosen AP.

To see which APs are running as the DA or BDA, but without all the AMRP info from the previous command, you can use the “show amrp interface eth0” command, assuming your connection to the network from the AP is using eth0. It may be using a different interface.

I used the above AP, because it was not the DA or BDA. I wanted to show an AP that was in the “Attached” state. The APs that are not the DA or BDA will have a state of “Attached” in the same way that OSPF would show a “DROTHER” on a router that was not the DR or BDR.

An additional thing to note with regard to layer 3 roaming, is that you can restrict which clients can perform a layer 3 roam. This is controlled within the user profile, and in a given SSID, I can have multiple profiles based on a number of different classification methods. Whether you want to allow or deny layer 3 roaming, Aerohive gives you the choice and at a fairly granular level.

To turn on layer 3 roaming for a particular user profile in Hive Manager NG, you simply modify the user profile.

Configure/Common Objects/User Profiles

Turn on layer 3 roaming via the Traffic Tunneling tab and if needed, adjust the idle timeout/traffic threshold values. Save the user profile and update the applicable APs.

Layer 3 Roaming Test

Although AMRP only shows neighbors on the same Ethernet segment, DNXP is aware of other APs that are nearby, but use a different subnet for the AP’s management IP. You can see these APs with the “show amrp dnxp neighbor” command as shown below:

Notice that 4 of the APs are in an L2 state. These are the APs on the same Ethernet segment(switch 1) for the management IP. The other 2 APs are in the L3 state. The AP knows that clients could roam to these layer 3 neighbors. In order for this to work, the APs need to be a member of the same “hive”, which is a fancy name for a shared administrative domain. Think of it like an autonomous system number that you would see in routing protocols like BGP. These APs within the same hive share a common secret key, which allows them to communicate securely with each other and trade client state and other AP configuration information. If I look at an AP that resides on switch 2(separated from switch 1 via layer 3), the opposite information appears, with 1 AP in an L2 state, and 5 APs in an L3 state.

I still have my client connected from the previous example discussing AMRP. It is connected to the AP 390 on switch 1. The 2 APs on switch 2 are separated by a layer 3 boundary from the other 5 APs, so is it aware of the client connected to the AP 390 device? Yes. Since all APs are within RF range of each other, client information is passed between them all. However, in the case of clients separated by a layer 3 boundary, DNXP comes into play. You can see these client sessions in another subnet by looking at the DNXP cache.

Note that although this client has not performed a layer 3 roam, the CLI output tells you where the tunnel is going to originate from across the layer 3 boundary when it does roam. This is because the designated AP(DA) has already determined which AP is the least loaded on the subnet that the client will roam from and has assigned that least loaded AP with tunneling duties if the client needs to make a layer 3 roam.

I have moved the client closer to one of the APs on switch 2 so that it roams. I had to actually move the AP out of my office and into the hallway and moved the client into the next room so that the RSSI value on the AP it is currently connected to would be low enough for it to actually roam. As you can see in the CLI output below, the client has roamed over to the AP that resides on switch 2.

Now, I should be able to see a tunnel spun up between this AP 250 on switch 2 and the AP that the DA connected to switch 1 chose(172.16.100.6).

Here it is from the perspective of the AP the client roamed to on switch 2:

Here it is from the perspective of the AP(172.16.100.6) on switch 1 that was responsible for building the tunnel to connect the two subnets:

Other APs on switch 1 are also aware of this tunnel:

Let’s go one step further and add another client. I associate a client to an AP on the switch 1 side. For the purposes of maintaining some brevity, I won’t show all the CLI around that client before it roams. I moved the client into the same room as the first client and it associates to the AP 250 on switch 2. We can now take a look at how the layer 3 roam was constructed for this second client.

We can see above that both clients are attached to this AP via a layer 3 roam. This can be verified additionally with a “show amrp tunnel” command.

If we take a look at an AP on the network(switch 1) that these clients roamed from, we see that these APs are aware of the clients and how to reach them via the AP that setup the tunnel to the other side.

Here is that view from one of the APs on switch 1:

And the view from another AP on switch 1:

There is one thing in particular I want you to notice. Both clients have executed a layer 3 roam and have tunnels spun up bridging these two separate subnets. However, notice that the tunnel end point on the switch 1 side is different for each client. That is because the DA told one AP to setup a tunnel for layer 3 roaming purposes for the first client, but told a different AP to setup a layer 3 roaming tunnel for the other client. Remember that the DA is aware of each AP’s load on a given subnet it is responsible for. It is spreading the load(no pun intended) among the various APs to keep from overloading any single AP. If there were a lot of clients on my home lab network and several of them performed a layer 3 roam at once, you might see tunnels originating from even more APs. It is this distribution of tunnel origination that allows layer 3 roaming to scale and not overload one particular AP.

Closing Thoughts

If you made it this far, congratulations. I told you this was going to be a long post. If nothing else, I hope I have shed a little more light on how Aerohive can scale when it comes to APs cooperating with each other and with regard to layer 3 roaming. As I mentioned earlier in the post, I did not cover automatic channel and transmit power selection. That is covered by a different protocol(ACSP) that works in conjunction with AMRP, and I hope to write another post soon showing how that works.

As with any solution, there are limits. Whether a controller based wireless network, or a cooperative control environment like Aerohive’s, at some point you can break it. It would be impossible for me to acquire the number of clients and access points to do this on my own. Not to mention the fact that I would need a decent sized building to spread out the APs enough to where they aren’t able to hear each other. I hope I was able to at least demonstrate the scalability, albeit on a smaller scale.

Let me know your thoughts or if you have any additional questions in the comments section below.

Posted in aerohive, wireless | 2 Comments

From Multi-Vendor To Single-Vendor

Posted on March 2, 2016 by Matthew Norwood

Careers take a funny turn a lot of times. Opportunities come up that you weren’t expecting and the timing is never as perfect as you want it to be. At least, that is how it has always been with me. I’ve learned though, that sometimes the best thing for you is to charge full speed ahead through the door, roll the dice, and take your chances. That is where I find myself right now. Having accepted an offer from Aerohive Networks to serve in a pre-sales engineering role in my local area, I am leaving behind a job and a company that I have enjoyed tremendously. Yes, there were times when I had to be talked off the ledge and keep on going. I think that comes with most jobs though. Overall, it has been a very rewarding almost 5 years working for a value added reseller(VAR) and I will miss it greatly.

In the span of a few months, I had to decide to give up the following:

1. Multi-vendor implementations and support.
2. Studying for the CCIE Wireless lab exam with 1 failed lab attempt already under my belt.
3. Involvement with other vendors courtesy of social media(blogging, Twitter, etc). – My involvement with Tech Field Day, HP, and other vendors has brought me into a whole different level of vendor interaction that I didn’t know existed.
4. Extensive travel across the greater US, which isn’t always fun, but I enjoy different locales and different networks to work on. I also haven’t paid for a hotel room or flight for my family in years.
5. Working with people and clients I have known for years.

For all that I gave up, I gained some things.

1. Being able to get really deep in a limited set of products from a single vendor.
2. Travel much closer to home and for shorter durations.
3. Potentially being able to get a better look at how products are brought to market.
4. Potentially being able to understand a vendor’s technology at a much deeper level than I ever could on the partner or end customer side(e.g. The secret sauce around RRM).
5. Potentially having more time for blogging, which I have neglected greatly over the past few years.
6. No more nights and weekends working on customer projects. – This may not totally go away, but it will decrease tremendously.
7. I have always wanted to work for a vendor to complete my overall picture of the IT industry.
8. The chance to compete against larger competitors. – It takes a lot of work to unseat incumbent vendors, or win deals against much larger competitors. Not every deal will be won, but when you can win in an ethical manner, it is a good feeling.
9. Better compensation. – None of us work for free, and I don’t want to be working until I am in my 70’s. Of course, if I can’t sell anything, I might be working until I am in my 70’s.

Which list is better? I came to the conclusion that what I was gaining would outweigh what I was giving up.

The Heart of the Matter
One thing that comes up when talking to peers is being able to go into the single vendor mode mindset after being multi-vendor for so many years. Can it be done? The short answer is yes.

I have worked with a number of networking vendors over the years. However, if I were to break down percentages and allocate them to each vendor, Cisco would have the largest share of the pie. Probably upwards of 75%. I have implemented solutions from Cisco, Meraki, HP, Brocade, Aerohive, Aruba, Meru, Sonicwall, Riverbed, Barracuda Networks, Dell, and a number of other smaller vendors. I have worked with, but not implemented, solutions from F5, Extrahop, Solarwinds, Juniper, and a few others. I wouldn’t claim to have high proficiency in any of them, except Cisco, and “high proficiency” is a rather subjective term. Put me in front of a Cisco Catalyst switch, give me a set of configuration requirements, and I can go to work right away. Put me in front of another vendor’s switch, and I have to stop and think about what needs to be done. I’ll fumble through the CLI, but eventually get it done. Does that make me multivendor proficient?

In all reality, to be proficient in more than one vendor requires consistent exposure and experience with each vendor’s products. I can tell you that even within Cisco, there are products I am very familiar with, and other products that I am not as familiar with. There are just too many products and too many caveats to function at a very low level on more than a handful of products from Cisco. That is the problem with multi-vendor work. Even if it is consistent, there are so many things to learn about each one. This was a lesson I learned when studying for the Cisco CCIE Wireless exam. I spent months on switches, wireless controllers, APs, Prime, ISE, and the MSE, and I still don’t feel like I am anywhere near an expert with those platforms. I am definitely a lot stronger with those products today than I was a year or two ago, but I still have much to learn.

Perhaps the biggest benefit to being multi-vendor focused is the awareness of each vendor’s product set. I don’t necessarily have to know how to configure each nerd knob. I just have to know what the capabilities are. In short, vendor analysis is as big a part of being multi-vendor as is doing the actual configuration and troubleshooting work. Does working for a vendor like Aerohive mean I cannot spend time learning about how wireless is done at any of their competitors? On the contrary, I think it requires that. If you are going to sell against the competition, you better know what you are selling against. If you rely on vendor competitive documents, you will get bit eventually. Those documents are rarely up to date, and I have seen them from numerous vendors working in the VAR space.

In short, I think you can be multi-vendor while working for a single vendor, but from the standpoint of understanding the competition. I know where my paycheck is coming from, so as long as I can do things in an ethical manner, I have no problems only presenting products from the company I represent. I already do that to a certain extent on the VAR side. It isn’t a foreign concept to me.

On another note, if my new job and CWNP studies allow, I plan on doing a lot more blogging. However, don’t be surprised if a fair amount of those posts are “how to’s” on Aerohive. I am VERY excited about being able to get as deep as I can in their products, since I do very little Aerohive work these days. I plan on sharing what I can when I can in the hopes that it will help someone out there. For an IT community that has given me so much, it is the least I can do to return the favor.

Posted in aerohive, career, wireless | 1 Comment

In Pursuit of the CCIE

Posted on October 1, 2015 by Matthew Norwood

Just a short post to let you know this blog is not dead. I have not written anything in several months. While I have several posts that are partially complete, I have not been able to finish them…..yet.

For the past several months, I have been busy studying for the CCIE Wireless lab exam. Prior to that, I was sort of working towards the CCIE Route/Switch written and lab exam. I wasn’t fully committed, so my studying was sporadic at best. My heart just wasn’t in forcing myself to learn more about IPv6, multicast, MPLS, and some of the other blueprint items.

Somewhere along the line it changed. Maybe it was having another co-worker who was serious in his pursuit of the CCIE Wireless. Maybe it was that my job working for a reseller had me doing more and more Cisco wireless work. Maybe I just liked the fact that wireless was hard. I’m not really sure. I just know that at some point, a switch flipped inside my head and I just decided to go all in on my studies. Honestly, I should have done this years ago, but the timing just didn’t seem right.

I’ve been studying most nights every week for a few months. I don’t sleep a whole lot these days. A lot of times, I fall asleep in my chair up in my office and don’t wake up until my wife comes up to check on me. On those nights when I do make it to my bed, I think about the lab blueprint until my brain finally shuts down and I drift off to dream. I have dreams about odd things like wireless authentication. My thoughts are always on the lab. Whether I am in a meeting with a client, sitting in church, or just driving down the road, it consumes me.

I’m constantly fighting off the voices in the back of my mind telling me to stop and go back to life as it was before the study urges took over. I have a wife and two kids. I have a job that demands a decent level of performance mentally. I travel a fair amount for work. I work odd hours. I am fairly active in my local church. I also make a decent living, so passing the lab doesn’t mean a massive pay raise for me. There are so many reasons I shouldn’t do this, and they almost overshadow the reasons that I should.

On the positive side, I am convinced there are doors that will not open career-wise, without the CCIE. Will I make more money after passing the lab? Probably. Will I have more recruiters and HR folks pinging me on LinkedIn? Yes. Will I have interesting career choices cross my path? Probably. I’m not planning on doing anything different work-wise after I pass, but as any of you who have CCIE digits knows, you have more options.

Those are all well and good, but if there is one reason I want to pass the lab, it is related to a quote attributed to John F. Kennedy from a speech he gave in 1962 regarding the USA’s attempts to land on the moon:

“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard.”

That’s it in a nutshell. I need to know if I can push myself to finish something that on the surface, seems impossible. When I was 15 years old, I ran a mile(1600 meters) in 4 minutes and 56 seconds on a dirt track in Hawaii. I had been trying to break 5 minutes for a while at that point. I remember that race vividly. I had a great running coach that trained me well. I put in a lot of miles on hills and roads leading up to that point, and I only mentioned the locale(Hawaii) to give you an idea of what kind of “hills” I was referring to. It was the end of our track season and I was in peak shape. Had it been a rubber track, I could have probably run it in 5 or 6 seconds faster. It doesn’t matter though. I broke 5 minutes. For some, that is not a big deal. For a kid who had asthma at a younger age, that was huge. It will always be one of my favorite moments in my life, taking a back seat to only the birth of my children and the marriage to my wife.

I am always telling my kids that they can be anything they want to be as long as they are willing to work hard for it. I can tell them all day long. It’s better if I show them through example. I’ll find out in 18 days when I sit the lab for the first time. I may go back several more times before I pass it, but I am prepared to do that.

Nobody ever talks to me about my sub-5 minute mile I ran. In fact, my father was the only one in my family who witnessed it. When, and it is a “when”, I pass the CCIE Wireless lab, most of the people in my day to day life, outside of work, will not even know what that is. I am perfectly fine with that. I’m not doing this for accolades or pats on the back. I’m doing this for me, and also to secure a potentially greater ability to provide for my family.

When it is over, I will take a break from studying. I’ll stop reading technical books for a few months, and not think about this stuff too much outside of my work hours. I have several hundred books I have put off reading for several years. I also have 60 years of National Geographic magazines that a friend gave me that are sitting in my office closet begging to be read. After a few months and a few dozen books and magazines, I will get back on the study “horse” and push towards the Aruba ACMX.

While I would have loved to create a bunch of blog posts documenting the technical aspects of my studies, I made the decision to devote that time to studying. Anyone who has written even one technical post knows how much time those things take. I am very grateful for people like Rasika who took the time to document all of their studies. If you are studying for the CCIE Wireless as well, you are probably already familiar with his excellent site. Much of that content applies to the version 3 lab blueprint.

Just wanted to put something up here to let you know I have not abandoned this site. I’m still around. I’m just busy studying.

Posted in career, ccie, learning, wireless | 4 Comments

Aruba and HP – The Remaining Pieces

Posted on July 9, 2015 by Matthew Norwood

I wrote previously about the Aruba and HP ecosystems. You can find that post here. I also wrote about Aruba’s culture here, and although I had planned on writing about HP’s culture as I understand it, I don’t know that I need to spend too much time on that. When you look at the difference in the two ecosystems from a wireless perspective(HP is a big company with a broad portfolio), HP is a completely different animal and that HAS to affect their company culture.

Well, what really remains to talk about? I think two things. Execution and product disposition.

Execution

Ask anyone who follows the industry about HP, and you will get a variety of thoughts. However, one of them that always seems to surface is in regards to their ability to execute. There is a history of missteps regarding HP in the executive arena over the past several years. Since Meg Whitman has taken over as CEO, I think we have seen a bit more stability in that regard. When thinking about Aruba and HP combining forces for wireless, I am reminded of a comment that Andrew vonNagy made during a Tech Field Day roundtable at the 2015 Las Vegas Atmosphere conference regarding Meg’s handling of the PayPal acquisition when she was heading up eBay. He mentions that she let PayPal run as a separate entity. Perhaps that will be the same with Aruba, and since the Aruba leadership will be running the campus networking section of HP. it is likely that would be true.

There is one other factor to consider. HP will be splitting into two companies on November 1st of this year. HP Enterprise will be headed up by Meg Whitman, and will handle servers, storage, networking, professional services, and software. HP Inc will handle the personal systems(desktops, laptops, tablets) and printing division. The conventional wisdom coming out of HP is that this will allow greater focus on products catering to specific customers. By having separate marketing, research, development, and sales teams, the two HP companies will be able to bring solutions to the marketplace in a much more focused manner. Time will tell if that is the case. The optimist in me sees this as a good thing. Maybe I am simply recalling Cisco’s attempts to play in the SMB/consumer spaces and mostly backing out of that space. I’ll admit that I don’t see the bigger picture as I am not a finance/business person, so there’s a chance that this could be a horrible disaster, and there are no shortage of articles and commentary with that viewpoint.

In short, HP’s ability to execute well with the future of Aruba’s products is yet to be determined. I suspect it will be mid-2016 before we really start to see if the new HP Enterprise company is a stronger and more nimble enterprise competitor than the legacy HP company. What I am certain of is that you cannot be good at everything. You have to pick and choose certain things and do the best you can. As my friend Devin Akin has pointed out to me, if you try and be good at everything, you will be good at nothing. Even though HP Enterprise will still be broad from a technology perspective, it will definitely have fewer things to worry about than the HP of today.

Product Disposition

When I was at HP Discover in Las Vegas last month, I was able to talk with the individual heading up the product disposition between Aruba and HP. I was told that August 18th is the official date within HP that a decision will be made around which products are staying and which products are going. It was still very early on in the evaluation process, so nothing definitive had been decided, and even if it had, that would not have been shared with me. I had some thoughts during the conference, and mostly, I think the same today as I did in early June. Here is what *I* think will happen:

HP Wireless AP’s and Controllers – These are gone. With the Aruba acquisition, there is no need to keep the HP wireless line. For wireless cloud based management, HP was already rebranding Aruba AP’s, so that should tell you something. I don’t see how the HP and Aruba product lines for AP’s and controllers could co-exist. Development was happening much faster on the Aruba side, so I don’t see why the HP product set would stay around.

Aruba Switches – I am still on the fence about these. I think they will stick around for a little bit longer, but only long enough for HP to incorporate some of their functionality into the ProCurve line that HP already sells. I don’t see why HP would keep them once AirWave and ClearPass are able to manage HP ProCurve switches in the same manner they manage Aruba switches today.

Aruba ClearPass – Although there is some overlap with HP’s IMC in terms of functionality, ClearPass is wholly focused on providing/restricting access. IMC is a much more modular system and has the ability to do a bunch of other things. I am not a user of IMC. I have never installed the product into a production environment, so my understanding of it is purely academic. However, I have used ClearPass and know that it is a very powerful product, especially when coupled with Aruba’s wireless solutions. I don’t see HP getting rid of it anytime soon.

Aruba AirWave – I am still uncertain about this product. As others pointed out to me, it was mentioned several times in keynotes during HP Discover 2015, and they would not have done that if they were going to kill it off in favor of HP’s IMC. I think there is pretty big overlap between it and HP’s IMC product, but I am sure there are things that Airwave does today that would take time to implement in IMC. It may end up being a management play for smaller customers, or it may simply co-exist with IMC.

Aruba Meridian – I don’t see this product going away. I don’t believe HP has anything similar to this in production.

Closing Thoughts

There are still many more months to go before we get to see what the results of the Aruba-HP deal will bring. August 18th will be here soon, and that will help Aruba partners and customers figure out what their future purchases should consist of. The bigger question will be answered in 2016, after HP has split into two separate companies.

Everything I have written is pure speculation. I don’t know all the things that HP and Aruba know. I don’t run companies for a living. I only see things from the field engineering level. I could be right, and I could be wrong. Unfortunately, I think we have another 6 months or so before we get a good feel for where this ship is headed. I am hoping it all works out for the best. Those of you that use or support Aruba products are probably watching this merger just as closely as I am. I hope it works out for the best for all parties. If it doesn’t, the industry will go on, but it will be worse off if a solid competitor in the wireless space fades off into obscurity.

Posted in aruba, hp, wireless | 1 Comment

Aruba and HP – The Ecosystem Is King

Posted on June 9, 2015 by Matthew Norwood

Note: This is part of a multi-post series I am writing that compares Aruba to HP and how the integration of Aruba Networks into HP might play out. You can read my intro post here.

I am a HUGE fan of vendor ecosystems. A HUGE fan. I have written about them before. The last post I wrote on them can be found here. I really do think they are the key to driving a vendor’s success. One could argue that the large vendors have it easy. They have the resources to build those ecosystems. They can spend money that the smaller vendors cannot and can essentially buy loyalty from customers and partners. Of course, at some point, those large vendors were small ones. They did something different to propel them to the large vendor status. Their competition fell by the wayside and either drifted off into obsolescence, or just outright died.

Sorry. There is no TL/DR for this post. Buckle up. It’s a long one.

So let’s get a lay of the land when it comes to ecosystems between HP and Aruba. Let me clear about one thing. This is specific to wireless. This has nothing to do with the many things HP is doing around SDN and other areas of networking.

Let’s focus on the following topics:

Books
Certification Programs
Conferences
Design Guides
External Technical Websites
Forums
Marketing
Resellers
Social Media

The end goal of all of these things is to produce large numbers of networking professionals who are knowledgable and comfortable with the HP wireless portfolio. It carries over into other areas of networking as well. Get people fired up about one section of your product portfolio and it should translate into an uptick in sales for the other products. If they trust you in one area, there is a good chance they will trust you in another area.

HP’s Wireless Ecosystem

Books

The one area that HP has an advantage over Aruba is that of books. Although their books tend to be certification focused, they have at least begun efforts in the past few years to get technical content out there. I suspect that over time they will be able to produce more books that are technically focused outside of the certification process.

Certification Programs

The certification program with regards to HP’s wireless solutions has been up and running for some time now. If you look at the list of available certifications here, you won’t find much in the way of wireless. They do offer the Accredited Systems Engineer(ASE) certification for wireless. They also offer the Master ASE certification for wireless. Neither of these are certifications that I am very familiar with. I have no idea what the numbers are of certified professionals regarding these programs. I could not find any published numbers around either of these programs. If someone can provide those numbers, I would love to see them. Suffice to say, there is not any sort of lab-based exam regarding HP wireless that I am aware of.

Conferences

HP Discover has been going on for several years now, and occurs in multiple parts of the globe. When I attended the Las Vegas conference in 2011, I tried to attend as many networking sessions as I could. Several of them were wireless focused. However, these sessions tended to be very high level and didn’t have a whole lot of technical content. I do recall one session in 2011 that covered their wireless security solutions that had some technical content.

As for the 2015 conference in Las Vegas that I attended last week, I recall just one session that seemed to be HP wireless specific. I skipped it after learning it would not be Aruba-focused, so I am not entirely sure how much technical depth was in that session. The other sessions I attended that were wireless focused were Aruba-centric. Those sessions were relatively high level and seemed to be more of an introduction to the Aruba wireless line. I attribute that to the very short time Aruba had to prepare for the conference.

I should also point out that except for the keynotes, I didn’t see any video recording of the sessions in either the 2011 show or the 2015 show. When I went to look for past sessions, I found nothing of any significant value. As for videos, the lack of recordings of breakout sessions meant that there was nothing to watch, other than an occasional interview with HP Networking executives. A search for HP Wireless videos on YouTube, simply gave me a bunch of videos with people fixing printer problems.

As for their show floor at HP Discover, they always had their wireless gear on display, except for the 2015 show. If you wanted any sort of technical depth on HP wireless, you had to talk to the people on the show floor.

Having attended the Las Vegas Interop show a few times, I have seen HP with a large booth each year I visited. The wireless group from HP tended to be at all of those shows as well. They had all of their products on display, and if you wanted to chat with someone from the wireless unit, they were available, much like at the HP Discover show I attended in 2011.

Design Guides

I found one. It is from 2010 and can be seen here. I could not find anymore. That isn’t to say that they don’t exist. I even checked the partner site, since I work for an HP partner. If you deal with servers and storage, there is a decent amount of content on the partner site. However, for networking, I found nothing of substance.

External Technical Websites

This would be the place where I tell you about non-HP websites/blogs that write about HP wireless topics. I couldn’t find any. Of course, I don’t speak and read every language across the globe, so if a site didn’t show up in an English Google search, I missed it.

Forums

As for the forums, there are some posts on HP’s support site, but they tend to be relatively sparse. It doesn’t appear to be a very active segment of the HP support forums site.

Marketing

HP has a decent marketing machine. It appears to be directed at management though. I assume they have a pretty decent sized budget, but I am guessing a lot of that effort gets focused on the personal systems, or the server and storage side of the house. I don’t see much in the way of HP wireless, if any. It isn’t for lack of looking on my part. I get tons of e-mails from various vendors. I even allow LinkedIn to send me e-mails when people post to groups. I see an occasional e-mail about HP Networking, but never really about the wireless line.

Resellers

I don’t know how big the partner network is for HP in the realm of networking. I suspect it is the same deal as a lot of other vendor partners. Partners tend to sell big for one or two brands in the networking space and maintain a partner relationship for other vendors they don’t sell as much for. They are essentially partners in name only. Think of it as an insurance policy. If you don’t want my primary vendor(usually Cisco), I can offer you this other vendor(e.g. Juniper, Brocade, HP, etc).

Within the US, there are some big national resellers who will sell HP wireless gear, and probably some more regionally focused partners who do the same. I am familiar with all of the big players in my home market of Nashville, and I am unaware of any of them who move any HP wireless gear in substantial numbers. It may also be regionally focused. I know of one particular reseller with a presence in Nashville who does very little HP business in Tennessee, but sells a LOT of it in Florida. I fully admit I may have a limited view into the HP partner ecosystem, so I may be way off in my assessment of HP wireless sales.

Social Media

HP has a pretty large social media presence, just not in the HP wireless realm. Let me give you a quick test. Go to Twitter’s website. Search for “HP wireless”. Look at the results. Now, search for “Cisco wireless”. Look at the results. See the difference?

I realize there is more to social media than Twitter. I checked Facebook. Nothing to note. I am sure you can find something on LinkedIn, but I am guessing it is more along the lines of finding HP employees to connect with.

Aruba’s Wireless Ecosystem

Books

Sorry Aruba. You have no books to speak of. Considering you do have design guides and a fair amount of training courses, it isn’t all bad I suppose.

Certification Programs

Although not as popular as Cisco wireless certifications, Aruba does have a very healthy certification program. From the basic high-level certification like the Aruba Certified Solutions Professional(ACSP) to the Aruba Certified Mobility Expert(ACMX) and Aruba Certified Design Expert(ACDX) certifications, there is something for everyone. People with the ACMX or ACDX certifications are required to pass a lab exam and are given a number unique to them when they pass. This is not something that is trivial to setup. It takes a lot more work to setup a proctored lab exam than it does to put together 100 or so questions for a written exam.

I am sitting in an Aruba Mobility Bootcamp course this week. It is the third Aruba course I have taken in the past year or so. The courses have materials that are all branded the same, which indicates a unity in course planning and management. It is a well oiled machine. Instructor knowledge varies, but is pretty good in my limited experience. When I took the ClearPass Advanced Labs course last year, it was taught by an ACMX. You can see the full certification layout here.

Conferences

Aruba has its Atmosphere conference every year in multiple cities around the globe. The Las Vegas show is probably the biggest one. The conference is fairly heavy on the technical side. There are multiple tracks, but the Airheads track is for the technical end user.

A large number of these sessions are video recorded, and you can watch the videos on YouTube. Click here for a playlist of the 2015 Las Vegas show session videos. Additionally, as an Aruba Partner, I have access to the presentations that were restricted to Aruba partners. A lot of them were video recorded. The ones that were not recorded have the slide deck available for download.

Although I have never been to an Aruba conference, I expect all of their technology was on display at each event. I have no doubt there were plenty of Aruba experts on hand to talk about any facet of the technology. If you watch some of the breakout session videos, you will see a good amount of technical depth around their solutions.

I fully expect to see the full line of Aruba products on display at upcoming HP Discover conferences. What I will be curious about is if they have the same in depth technical breakout sessions that Atmosphere is known for.

Design Guides

I like what Aruba is doing in the way of design guides. Although just HAVING them is a good thing, they go a step further and make them publicly available to anyone without having to register on their website(You use a fake e-mail address for those sites, right?). You can see the design guides here(http://community.arubanetworks.com/t5/tkb/v2/page/blog-id/Aruba-VRDs/page/1?_ga=1.137053936.1587483989.1417455721). There are about 25 of them available as of this post.

External Technical Websites

There are several Wi-Fi professionals out there that write technical articles about Aruba Networks. I’ll mention three of them, but I can assure you there are more. I specifically mention these three because they have real-world implementation experience with Aruba. Many of us who blog about all sorts of stuff may only have lab experience or an academic understanding when it comes to certain vendors.

Chris Lyttle maintains the Wi-Fi Kiwi site, where he writes about all things wireless. He has done a fair amount of Aruba implementations, and he writes frequently about them.

Eddie Forero maintains the Wi-Fi Republic site, where he also writes about all things wireless. He has a fair amount of Aruba work under his belt as well.

Charlie Clemmer works for Aruba….errrr HP, but maintains his own personal site where he writes about……you guessed it…..Aruba Networks.

Forums

The Airheads community is a vibrant one. You can take a peek by clicking here. Lots of engineers participate in asking and answering questions. In addition to the forum posts that are primarily Q&A based, there are frequent blog posts by Aruba employees as well as by outside wireless folks. You can see the latest blog posts here. I read a lot of these posts and I can tell you that they range from high-level to very deep from a technical perspective.

In addition to just having the Airheads community, Aruba Networks saw fit to appoint Sean Rynearson as chief Airhead, to ride herd over that unruly mob of Wi-Fi geeks. When he isn’t posting his scheduled tweet about joining Airheads(I kid. I kid.), Sean posts some pretty interesting links to technical content. It is nice to be able to reach out to a known human whenever issues or general questions arise!

Marketing

Aruba does a pretty good job of marketing. They understand who they are marketing to and have a good mix of technical and high-level information. Although I am not a fan of webinars in general, Aruba has a fair amount of them available for partners and customers. As far as other marketing content, I seem to get a pretty steady stream of it via e-mail and via their YouTube page. I don’t necessarily like all of the videos, but there is a decent mix of things that would apply to managers and those that apply to more technical people.

One thing I do like in the way of marketing is their website. It is pretty straightforward and easy to navigate. On the parter side of the website, I have access to a fair amount of information. I would especially like to note the Arubapedia site that partners have access to. It is a tremendous amount of information related to all things Aruba from a technical perspective.

Resellers

There are plenty of Aruba partners out there. When it comes to supporting partners, Aruba gets it. I have access to almost anything I need from a hardware and software perspective. The Aruba account teams I work with in Tennessee are always willing to help out in order to make us more effective as a partner. Whether it is training classes, or just help when we run into issues with implementations, they have always been willing to assist. I know that as the organization grows and more partners are onboarded, it will be more difficult for Aruba to give all of them the same service that my company receives today. However, I have access to a local Aruba partner rep, so if we are overloading the account teams, that person is able to step in and help out in any way they can.

Social Media

When compared with the presence of HP Wireless in social media, Aruba has them vastly outnumbered. Consider that Aruba has representation on Twitter from the CTO down to the engineers. Marketing is on it as well. If you need to reach out to someone within Aruba, there is a good chance that you can find them via social media. Go to Twitter and search for Aruba Networks. You’ll find an active corporate Twitter account along with a large number of Aruba employees. You’ll also find them on LinkedIn.

Closing Thoughts

When it comes to ecosystem, Aruba has HP Wireless beat hands down. When I think about what Aruba is to become, being part of HP, it looks promising. I say that knowing that Dominic Orr and Keerti Melkote will lead the HP Networking campus division. They fully understand the value of the Aruba ecosystem. I can only imagine that they will keep it intact. I have to take Dominic Orr at his word when he mentioned during the Atmosphere 2015 keynote in Las Vegas, that nothing will change.

HP certainly has the resources to build a great ecosystem. With the boost to their networking division that Aruba Networks gives them, I expect that ecosystem to grow much larger than it is today. Once HP splits into two companies, more focus can be directed towards winning the business of corporate customers, and adding more resources to their existing and future partners.

Posted in aruba, hp, vendors | 1 Comment

Let’s Revisit The Aruba Networks Acquisition

Posted on June 8, 2015 by Matthew Norwood

Back in February, I wrote a piece entitled “HP Buying Aruba?”. In that post, I provided some context around why I thought HP buying Aruba could end up being a bad idea. I also mentioned in that post that I hoped HP did right by Aruba’s customer base and didn’t put the corporate handcuffs on them.

After several months and many conversations with HP, Aruba, and my peers, I have a different take. I am not 100% ready to back off from my concerns though. The acquisition has closed. The deal is done. However, it is too early in the process to be certain of much of anything regarding the future state of Aruba, its products, and its ability to execute as they have in the past. Let’s just say I am about 75% headed in the opposite direction of my initial concerns.

This past week, I was fortunate enough to attend HP Discover in Las Vegas. HP paid for my travel and expenses for HP Discover. For that, I thank them and I can definitively tell you that I was not pressured into writing anything as a result of this trip. As luck would have it, Aruba had a decent presence at the conference. Since the acquisition of Aruba by HP just closed a few weeks ago, there was a lot that could not be done from a legal standpoint until the deal closed. When I initially registered for HP Discover, I didn’t see much of anything in the way of sessions regarding Aruba Networks on the agenda. Thankfully, that changed in short order and I was able to sit in on numerous sessions related to Aruba Networks and their products/strategy in the past few days.

Most of the sessions were very basic in nature. I attribute that to a very short amount of time that was given to Aruba to prepare, since they couldn’t really cooperate with HP until the deal was closed. Additionally, the assumption was probably made that most wireless people at HP Discover would not be existing Aruba customers. I’d say that was probably a fair assessment. The geek in me would have loved to see sessions similar to what were given at Aruba’s Atmosphere conference, but that would have taken a lot more time to prepare for, and Aruba just didn’t have that kind of time. Nevertheless, it was a valiant effort on the part of Aruba, and I think they did the best they could with the limited time they had to prepare.

Well, if I didn’t learn much in the sessions, except for the Meridian one, was I able to get any additional information at the conference? In short, yes. I had quite a few conversations with a few folks at Aruba and HP, as well as some discussions with other fellow bloggers who were there with me. Although nothing was 100% in terms of future state, I think I got a good feel for where I THINK they are headed with the combined companies.

I’d like to take some time and really expound on a few key areas like ecosystem, company culture, execution, and final Aruba/HP product disposition. However, I also think it is worthwhile to try and get a feel for who Aruba is as a company. If you are familiar with them already, then this post probably isn’t for you. Wait until my follow up posts on the key areas I just mentioned. They should be coming out this week, unless the Aruba training class I am in gets the better of me and I am mentally exhausted after each day.

If you aren’t familiar with Aruba and their company culture, here are a few video clips that may help you understand them:

The following excerpt is from the keynote address that Dominic Orr gave at Aruba’s Atmosphere 2015 conference in Las Vegas. You can watch the whole thing if you want, but I think the interesting part comes at the end when Dominic explains the HP acquisition. If you don’t want to watch it, here is a TL/DR version where I paraphrase Dominic’s comments.

1. The Airheads community is Aruba’s biggest asset.
2. All partners are an incredible asset to the company.
3. Our loyalty and dedication to you will not change. Customer first. Customer last. That aspect of Aruba’s culture will not change. That culture is an appreciation of how customers stuck their neck out and took a chance on Aruba. Aruba will not forget that.
4. Aruba will go out to battle with you. That competitive culture and commitment to being the leader in the mobile access layer will not change.

Watch video up to about 1:30.

Another video out of the same Atmosphere conference was a Tech Field Day roundtable discussion. There are some interesting points made by members of the panel, but I think the real value of this discussion starts with the audience questions. Two main things to note in this portion of the video that begins at 17min45sec into it. First, Ben Carnevale makes a VERY good point regarding company culture, and Ryan Adzima adds relevant commentary around it. Second, Eddie Forero adds on to Ben’s comment with the statement that although he trusts Dominic Orr, he wants HP to NOT make him a liar.

Closing Thoughts

Once you understand how different Aruba Networks is from HP in terms of culture, you understand why there was so much initial hesitation around this acquisition. I’m a lot more optimistic after spending last week at HP Discover, but there are still plenty of unknowns. A lot can happen in the next year. I’ll look into my crystal ball in follow up posts and see if I can make sense of how this Aruba acquisition can be a good thing. There’s also the potential for it to be a bad thing, but I think there are some good things in motion that should prevent that.

Posted in aruba, hp, vendors, wireless | 2 Comments

HP Buying Aruba?

Posted on February 26, 2015 by Matthew Norwood

Two things happened today. First, Twitter blew up at some point with rumors of HP in talks to buy Aruba. Second, my shares of Aruba stock shot up about 20%. I was disappointed with the first and pleased with the second. Of course, they were directly related.

In Case You Weren’t Aware…..

HP has had some issues over the past several years. Not so much issues with their technology, which has always been good, but more so with execution. The latest attempt to right the ship has been to split the company into two distinct entities. Trim the fat off of the corporate monster so to speak. Or, maybe a better way to put it is that HP wants to become less of an “all things to all customers” type of company, and more of a “some things to some customers” type of company. Some customers will be served by one of the two HP companies, and some customers will be served by the other, or both. This allows more focus in certain areas, and focus is never a bad thing.

Why Does It Matter If HP Buys Aruba?

Although this is all speculation, allow me to continue down this road of “speculation”. I realize that neither HP nor Aruba have confirmed any of this. This is probably someone telling someone else something they weren’t supposed to tell. That person tells someone else, and next thing you know, it ends up as an article on a finance site. We all tweet about it and fuel the frenzy, along with the investors who look at balance sheets and run up the stock price of Aruba. By the time it is all over, people will form opinions based on a mix of facts and rumors and one side will have you believe the CEO’s of both companies drown kittens in their spare time. Or, those in favor will have you believe that God almighty came down from heaven and helped to broker this deal. Hopefully, we all end up somewhere in the middle.

To answer the question of why it matters, I have to look at it from differing points of view. The first is that of a shrewd business person. The second is that of a technical person who likes the world of technology, and especially Wi-Fi. These are MY views and mine alone. As always, I could completely misrepresent each position and could be completely wrong. I could also be right. Time will tell, and the Internet never forgets, thanks to archives. 🙂

Business View

Money. That’s it. Spare me the idealism and desire to do good for the world one widget at a time. Profit-based companies exist to return value to their shareholders, be they public or private. Jobs and philanthropy are a secondary benefit. If you are public, there are a lot of people in expensive suits poring over your books and demanding answers to why you came in at 1 cent below expectations for the quarter. Business is war, make no mistake. Pretty it up with other terms, but the goal is always market domination because that returns the most bang for the buck. Why start a profit-based business if you don’t think you have what it takes to succeed? Nobody wants to work into their 80’s just to pay the rent. We all want to retire and enjoy the fruits of our labor in our twilight years.

If, and this is still an “if”, Aruba sells to HP, it is for money. Aruba’s shareholders, and I am one of them, get paid. HP gets a good company with good technology, and thus, they get paid as well. The Aruba portfolio and client list will strengthen HP in the wireless arena. They are already selling Aruba wireless gear today, so it isn’t like Aruba is completely foreign to HP. Of course, so is Dell. Aruba also has semi-partnerships with Brocade and Juniper. As my friend Tom points out:

@maishsk @matthewnorwood Gives HP a new wireless line that they need. And cuts Dell, Juniper, and Brocade out of the market near term.

— Tom Hollingsworth (@networkingnerd) February 26, 2015

From a business perspective, this means that HP can compete a LOT more with Cisco, who teeters around the 50% market share in regards to wireless. If HP can buy Aruba at a decent price, I would say the business folks would be okay with that. Don’t ask me what a decent price is, but my guess is somewhere north of 2 billion USD.

Technology View

Aruba has good wireless technology. Ignore the silly marketing videos from Aruba and Cisco where they are smashing and drowning access points, and consider that if Aruba’s technology didn’t work, they wouldn’t be the number two player in the enterprise market. There isn’t enough lipstick in the world to put on a pig to give it that kind of market share.

If the technology is good, and HP buys Aruba, what is the problem? I submit to you that it is going to be a problem of execution on HP’s side. Take a look at what they are doing in wireless. Does anything stand out? How many HP wireless customers do you know of? I know they are out there. That much is true. What I can tell you is that in the 3 and a half years I have been with my current employer, I have come across one HP wireless install. It was for a school system in the area I live in(Nashville,TN). Just one. I realize that I have not been to every company in the world. I have not seen the networks running thousands of HP wireless access points. I have seen plenty of Aruba and Cisco wireless installs. I’ve come across Aerohive, Ruckus, Ubiquiti, Meraki(pre-Cisco), Extreme, and even SonicWall. In the wild, I have found AirTight, Meru, and Brocade(Motorola), but never HP.

Perhaps I am looking in the wrong places though. Your mileage may vary. Perhaps all you see is HP wireless installs. I HAVE seen, and worked on, plenty of HP ProCurve switches. There’s lots of those around. I just haven’t seen much HP wireless out there.

Back to the present day HP wireless though. Can you think of anything that sets HP apart in the wireless field? Can you describe them the same way you would Ruckus, Aerohive, or even Meru as it relates to technology that sets them apart?

In my mind, their wireless marketing is non-existent. You never see them out there. You never hear about them. Wireless companies with much smaller market share and marketing dollars are out there spreading their message constantly. Whether it is in social media or at technical events, they are out there. Perhaps I am in a bubble though. I fully accept the fact that I may be in a social media bubble as it relates to technology, and all of my peers that I interact with are focused on just a handful of vendors, or in some cases, just one. That is a possibility.

Let’s assume I am not in a bubble though. Let’s just assume that my reasoning is sound. When I think of wireless companies, I don’t rank HP in the top 5. That is not a dig on their technology. Not at all. To me, it is a matter of focus. I had the same problem with F5 dipping into the firewall space, and Riverbed dipping into the load balancer space(Sold to Brocade, by the way.). Brand recognition is important. What a company is known for is important, and changing people’s perceptions of that takes time and a whole lot of marketing.

When I think about HP buying Aruba, I see nothing but a slow death for Aruba’s product set within the HP machine. I fully expect them to get sucked up into a much larger corporation and get beat down with more corporate bureaucracy. I hope I am wrong though. I don’t think I am the only one who expected Meraki to get sucked up into Cisco and slowly killed off from a corporate culture standpoint. I have been surprised at how long Cisco has let them run as is, but with the Meraki founders leaving Cisco recently, maybe it wasn’t as it seemed.

Closing Thoughts

If Aruba sells to HP, I hope that they continue to flourish. I hope that they are allowed to keep doing what they do today in terms of customer and partner engagement. I can tell you that Aruba is a good company to partner with from a technical perspective. The local Aruba team my company is engaged with are good folks. There is never a problem with providing whatever hardware we need to be successful. Training has been forthcoming as well. Aruba also has a really visible online and marketing presence.

I also hope that HP is serious about succeeding in the wireless arena. I hope that they use the goodwill that Aruba has and make their presence felt in the market. Maybe in a few years, HP will be a name that I hear people mention when considering wireless vendors.

I say all of this with consideration of the fact that the overwhelming majority of wireless work I do these days are with Cisco implementations. I’m typing this post in a hotel after finishing another Cisco wireless survey. I like Cisco wireless. It’s a good product. It works. The management piece is a whole different animal. 🙂 I also like Aruba. Maybe a better way to put it is that I like competition. It makes all vendors better. If one vendor dominates a space too much, I think the wireless market as a whole suffers. While I hope that I am wrong with Aruba going off to die in HP, I can’t help but think that Cisco is all too happy to see this acquisition happen, if the rumors are true. Based on the previous years of HP missteps, I can see why this could be a good thing for Cisco.

I would love to hear your thoughts. Am I missing anything? Completely wrong?

Posted in aruba, hp, wireless | 3 Comments

A Quick Guide To Configuring An Aerohive AP

Configuring Microsoft NPS for Aerohive 802.1X Authentication

Aerohive’s Private Pre-Shared Key Technology

Does Aerohive Scale?

From Multi-Vendor To Single-Vendor

In Pursuit of the CCIE

Aruba and HP – The Remaining Pieces

Aruba and HP – The Ecosystem Is King

Let’s Revisit The Aruba Networks Acquisition

HP Buying Aruba?

Archives

Recent Comments