In this video, Abby Strong explains how Aerohive addresses the Wi-Fi challenges in today's healthcare facilities, such as having the abilty to provide flexibility to caregivers for any device access, HIPAA compliance, and ease of management for healthcare IT.
In the sixth installment of our “Aerohive Getting Started” series on how to deploy Aerohive controller-less Wi-Fi, we cover the next step, connecting an iPhone to a guest SSID on an Aerohive AP.
This video follows our five previous videos — (1) Introduction and Resources, (2) First Time Access to MyHive and HiveManager Online, (3) HiveManager Express Mode: defining employee SSIDs with WPA2 Personal (4) Defining a simple guest SSID, and (5) Uploading the configuration to APs.
In the next getting started with Aerohive video blog, we will cover Viewing Active Clients and Using Client Monitor. Click here to skip ahead and view all the videos now.
Assisted living provider, Brookdale Senior Living, deployed Aerohive Wi-Fi to enable mobility, EMR support and guest Wi-Fi. Watch this video and hear what Chris Fadrowski, Senior Director of IT Infrastructure, has to say about why his organization deployed Aerohive.
Read the complete case study here.
Using cloud-enabled management allows companies to easily configure, manage, and deploy networking devices such as wireless access points. At the same time, IT departments must be cognizant that the cloud service provider is in full control of the infrastructure, the security measures in place to protect customers’ data, the maintenance cycles, and even the upgrade schedule in certain cases.
With regards to offering cloud management for wireless access points, it’s important to get clarification on how a vendor associates the cloud with their access points. There’s a fundamental difference between a true cloud-managed solution versus a cloud-controlled solution for wireless access points.
The cloud-based wireless controller approach
Today, there are vendors that claim the wireless access points they sell are “100% cloud managed,” but this can be a misleading proposition unless you investigate what this really means. These vendors provide a cloud-based wireless controller system. The controller in the cloud is the control plane for the Wi-Fi infrastructure and the vendor’s wireless access points require the customer to connect to the cloud controller for full functionality.
In other words, the cloud is used to control the access points and the cloud’s primary function is not for “100%” management. If the cloud goes down, so does the full functionality of your wireless network.
With a cloud-based controller, you are at the mercy of the cloud for your wireless connectivity, and this has serious ramifications in environments where continuous wireless network uptime is essential. For example, in healthcare facilities, having continuous wireless access 24/7 for doctors and nurses is critical to help these users access patients’ records, view patients’ prescription history, or look at medical images. In education, a loss of WLAN capabilities during online standardized testing is a failing proposition for teachers, students, and IT. In retail, losing PCI compliance due to WLAN WIDS being unavailable is not acceptable. There are similar examples in virtually every industry, as the dependence on using an all-wireless access layer becomes the standard.
In addition, these cloud-controlled vendors force customers to upgrade their networking devices when a vendor decides to upgrade their cloud platform. The customers’ access points are in service and are working well, but a platform upgrade forces customers to fix something that is not broken. Customers are basically forced to upgrade when they may not be ready and they cannot use the cloud for management or configuration until the devices are upgraded.
The cloud-managed approach
With Aerohive Networks, first and foremost, cloud-based management is truly a 100% management solution. Aerohive’s HiveManager Online is a cloud-based SaaS solution for network management. It is not a controller in the cloud, does not house the network control plane as controllers do, and is not required for on-going Wi-Fi network operation.
HiveManager Online is a network management platform only - period. With an Aerohive’s controller-less Wi-Fi architecture, all control and data traffic are handled exclusively by the access points (not the cloud), allowing unlimited scalability and eliminating bottlenecks, expensive controllers, single points of failure, and latency.
The access points handle all aspects of authentication, association, fast/secure roaming, data forwarding, power and channel management, etc. If the cloud or WAN link goes down, the Wi-Fi stays up, and you can still reach mission-critical network resources such as file servers and printers.
This is a huge difference from vendors that place the controller in the cloud where customers’ access points will lose functionality and certain features like data roaming and Captive Web Portal if the cloud goes down.
To have such crucial functionality as the control plane dependent on cloud connectivity leaves full WLAN functionality at the mercy of things outside IT’s control (leaving IT prone to the old adage, “it’s not your fault but it’s your problem”). A disruption in the WAN circuit, the ISP’s internet service, the cloud-controller data center, or a disruption caused by a forced upgrade all have very visible and detrimental impacts on cloud-controlled WLANs.
In the end, this impacts end users, and IT’s phones start ringing. With Aerohive, you get all the benefits of the cloud without any of the cloud-controlled negatives. In the event of an outage of the cloud, only management via HiveManager is lost (i.e., SNMP, syslog still provide visibility and reporting, the AP interface script still provides for configuration changes). There is no disruption in service for the wireless network or wireless users. This is a fundamental advantage of cloud-managed over cloud-controlled.
In addition, Aerohive’s unique, flexible upgrade policy ensures that customers are never forced into any upgrades on their Aerohive network devices or their cloud management platform. Customers have the luxury of waiting up to two feature releases before upgrading to the latest version.
This means IT staff is not forced into upgrading quickly and can focus on other immediate tasks on their radar. Plus, customers can continue to take advantage of cloud benefits while on older versions of HiveManager Online and network devices.
What is cloud-enabled management?
Not all “cloud-managed” solutions are equal and it’s important to investigate each vendor’s cloud service offerings. Aerohive provides a pure cloud-enabled management solution for your wired and wireless network. With Aerohive, you get:
This is the second in a two-part series of blogs about configuring, troubleshooting, and using the Aerohive Bonjour Gateway.
Apple’s Bonjour protocol can locate devices such as printers, Apple TVs, computers, and the services that those devices offer on a local network using multicast Domain Name System (mDNS) service records. All devices using the Bonjour protocol must reside on a single subnet. As most of you already know, Aerohive Networks released the very first Bonjour Gateway solution that allows devices to access Bonjour-capable network services across multiple broadcast domains.
The Aerohive Mobility Routing Protocol (AMRP) automatically elects a Designated AP (DA) on each subnet. The DA is the Aerohive device with the lowest MAC address. The DA of each individual subnet will function as the Bonjour Gateway device.
As shown in Figure 1, VLANs are unique within a single routed domain. VLAN IDs may be reused in a network that is segmented by routers which is often common with VLAN 1. Aerohive Bonjour Gateway service supports unique VLANs throughout a network and networks that reuse VLAN IDs for the Bonjour Gateway service. Bonjour Gateways that reside in different management subnets have the ability to communicate with each other.
Figure 1
APs in different subnets can automatically locate each other wirelessly, or can be set manually as L3 roaming neighbors. We will discuss how the Bonjour Gateways locate each other in greater detail alter in this blog. As shown in Figure 2, AP1 functions as a local Bonjour Gateway Device (BGD) while AP2 functions as a remote Bonjour gateway device. AP1 will advertise the Apple TV service to AP2 so AP2 can respond to Bonjour discovery messages from client device on VLANs 1 and 50.
Figure 2
As shown in Figure 3, AP2 operates as local Bonjour Gateway Device (BGD), and AP1 is the remote Bonjour gateway device. AP2 will advertise the Printer service to AP1 so AP1 can respond to Bonjour discovery messages from client devices on VLAN 1 and 10.
Figure 3
The command “show bonjour status” will verify that Bonjour Gateway devices (BDD) in different subnets are communicating with each other. Figure 4 shows a local Bonjour Gateway in the 10.5.1.0/24 subnet that is aware of a remote Bonjour Gateway in the 10.7.1.0/24 network
Figure 4
Bonjour Gateways in different subnets communicate with each other regarding the Bgd IP interfaces each gateway has created. They will also share the service information that is maintained in a table by each Bgd IP interface.
The command “show bonjour services local detail” displays the tables maintained by the Local Bonjour Gateway as seen in Figure 5. This information is shared with the Remote Bonjour Gateway. Conversely, the command “show bonjour services remote detail” will display the tables maintained by the Remote Bonjour Gateway. The Remote Bonjour Gateway information is also shared with the Local Bonjour Gateway.
Figure 5
So the million-dollar question is how do Bonjour Gateways that reside in different subnets communicate with each other? BGDs use the same cooperative control mechanisms that are used by Aerohive APs when layer 3 roaming is enabled.
Aerohive devices on different subnets can signal each other wirelessly using the 802.11 beacon management frame. As shown in Figure 6, Aerohive Bonjour Device capability information is advertised in beacons and can be understood by Aerohive APs in the same Hive. The Aerohive APs scan all channels and hear beacons from other Aerohive APs within physical vicinity of each other.
Figure 6
The beacon frames contain a proprietary information element (IE) field that indicates the use of Bonjour Gateway services and the management IP address of the access point. This information is encrypted with the Hive key and can only be decrypted by other Aerohive devices that belong to the same Hive. As shown in Figure 7, once access points on different subnets know about their Bonjour services capabilities and know each other’s management IP addresses, they can establish a cooperative control channel using UDP port 3000. After that, they can then learn about the management IP address of the existing DA on each subnet. The DA’s of each respective subnet function as the Bonjour Gateways and can immediately exchange the available Bonjour service information tables across subnets.
Figure 7
Look familiar? This is very similar to the mechanisms used by the Dynamic Extensions Networking Protocol (DXNP) — which is the Aerohive cooperative control protocol used for Layer 3 roaming.
The process of communication that was just described requires that APs in different subnets be able to hear each other’s beacon frames. What if they cannot hear each other? The answer is simple: set up a static cooperative control route between the Bonjour Gateways on each subnet.
First you will need to determine which device is functioning as the Bonjour Gateway. When a network policy has been configured with a Bonjour profile, one Aerohive device will function as a BGD on each management subnet where Aerohive devices reside. To determine which AP is the Designated AP (DA) on each subnet, use the Utilities/SSH Client or Utilities/SSH Proxy tool to console into any Aerohive AP. An SSH connection can then be established via the CAPWAP tunnel between HiveManager and the Aerohive AP.
Figure 8
As shown in Figure 9, simply type the command “show amrp” to determine the IP address of the DA. You now know which Aerohive device is functioning as the Bonjour Gateway of that subnet.
Figure 9
Once you have determined the IP address of the DA on each subnet you can then configure a static cooperative control route between Bonjour Gateways. As shown in Figure 10, simply designate each AP as a neighbor under Optional Settings/Roaming Configuration within the AP specific settings of each AP that you have determined functions as the Bonjour Gateway.
Figure 10
This will ensure that the Bonjour Gateways on each subnet communicate with each other even if they cannot here each other’s beacon management frames.
Once again, the command of “show bonjour status” will verify that Bonjour gateway devices (Bgd) in different subnets are communicating with each other as shown in Figure 11.
Figure 11
In conclusion, even though there is a different AP in each management subnet that operates as a Bonjour Gateway, these devices can still communicate with each other about available Bonjour services. Also please keep in mind that just about any Aerohive device can function as a Bonjour Gateway including all Aerohive access points, a BR-200 router, and a HiveOS Virtual Appliance.
~~~
Part one of David's series on Bonjour Gateway is Bonjour Gateways Galore.
Greenway Medical Technologies, which offers a web-native integrated practice management, managed care and electronic health record (EHR) solution, was in search of a more manageable, reliable, and cloud-managed Wi-Fi solution. The IT healthcare provider replaced its existing Cisco WLAN with a controller-less WLAN from Aerohive, allowing it to keep pace with its rapidly growing EHR customer base.
Aerohive has enabled Greenway to meet company-wide, cloud-based IaaS, PaaS, and SaaS network initiatives. It has also dramatically reduced time spent managing, monitoring, and upgrading the wireless network infrastructure.
Watch the video to hear why Greenway Director of Information Technology Ty Puckett chose Aerohive:
Read the complete case study here.
Six years ago, Aerohive turned the Wi-Fi industry on its head by eliminating the WLAN controller. Today, Aerohive is about to turn multiple industries on their heads by completely eliminating the need for wires to deliver power to your network!
The Aerohive Employee Pet of the Month is Haley Recio’s horse Rupert!
Employee: Haley Recio, Sr. Director of Human Resources
Pet Name: Top Dun Cody Rose (aka – Rupert)
Age: 9
Breed: Quarter Horse
Favorite toy: Eating pink roses, competing, driving the mares (lady horses) crazy – he’s a flirt!
Tell us about Rupert: Rupert came to us as an international competition horse for my husband (FEI level in Reining).
Here is a (must-see!) video of Rupert in competitive action, which also helps illustrate the sport of Reining.
When he arrived at our ranch I was up at the house and my husband was down at the barn. I saw him being unloaded from the trailer and called my husband on the cellphone. I said one word – “Mine”. My husband made me trade him one of my other competition horses and I’m happy I did. This year my husband is competing Rupert in the Open ( Pro ) division.
Rupert taught me how to compete in Reining; previously I was a three-day eventer. He’s a very talented individual and quite a character. He’s named after a character in "Family Guy." Rupert is Stewie’s teddy bear.
~~~
The "Employee Pet of the Month" is a friendly event run by the HiveForce committee of Aerohive employees leading the charge in community, culture and fun. The first Pet of the Month was Rocco, beloved family pet of Aerohive PR/AR/Social Media Director Jenni Adair.
RHA Health Services, a provider of services and support for people with developmental and intellectual disabilities, deployed Aerohive Wi-Fi to enable EMR support, PPSK (Private Pre-Shared Key) security, and to leverage meshing for AP redundancy. Watch this video and hear what Scott Daniel, Senior Network Architect, has to say about why his organization deployed Aerohive.
Read the complete case study here.
Free AP webinar: Application Visibility and Control for your Network
In our training classes, we often talk about the fact that Aerohive Networks has thousands of “bells and whistles” available when deploying our access points, branch routers, and other devices. Because Aerohive offers a vast array of “bells and whistles,” our cooperative-control architecture can integrate into some of the most complex enterprise networks imaginable. An object-oriented approach is an efficient way to control the myriad of configuration settings necessary in a robust environment. The downside of object-oriented configuration is that often the vendor GUI is a disaster.
The good news is that HiveManager GUI is very user-friendly with a workflow that assists the network administrator is a logical manner. This is a first in a series of blogs that will discuss the basics of Aerohive’s object-oriented configuration.
Let’s start with discussing the “welcome page” that a super-user administrator will encounter the first time that he/she logs into HiveManager as shown in Figure 1.
Figure 1
The first thing that needs to be configured is the name of the default “Hive.”
What exactly is a Hive?
In my mind, the initial default Hive is the only Hive an organization should ever have to create (unless the administrator wants to purposely block cooperative control between certain Aerohive devices). Aerohive devices must belong to the same Hive so they will have the ability to communicate with each other. The bulk of cooperative control protocol communications are within a single subnet. Aerohive devices will only talk to each other across routed boundaries if necessary – for example, if Layer 3 roaming has been implemented. Additionally, Aerohive devices will only talk to each other across a WAN link if an IPsec VPN has been configured.
The second thing that needs to be designated at the welcome page is the HiveManager operational mode. You can operate HiveManager in one of two administrative modes: Express or Enterprise. Express mode provides a simple set of configuration components designed for managing a single simple network. Enterprise mode provides a complete set of configuration components for managing multiple networks that require more advanced settings. Express mode only allows for the configuration of one uniform Network Policy that all Aerohive devices must use. Enterprise mode allows for the configuration of numerous Network Policies. Because the HiveManager GUI is very user-friendly in both modes, I almost always recommend that you choose Enterprise mode so that you can have full access to the entire collection of cool “bells and whistles.”
The third thing that needs to be configured in the welcome page is the administrative passwords. The Quick Start SSID Password is a simple 8-32 character passphrase that is used for the default SSID as well as the access console SSID. An access console SSID is a special SSID that provides wireless console access to an Aerohive device when it is not accessible through the wired or wireless network, which negates the need for using a physical console cable to recover access to the device.
The HiveManager Password becomes the super-user admin password for logging into the HiveManager network management server. The HiveManager password initially also becomes the command line interface (CLI) password for all Aerohive devices. I would recommend that you give your Aerohive devices a separate CLI admin password that is different from the admin password used to login into HiveManager. Device CLI passwords can be globally set from Home/Device Management Settings as shown in Figure 2.
Figure 2
If you want to give every Aerohive device a unique CLI admin password, individual managed device passwords can be set from Monitor/Modify/Credentials as shown in Figure 3.
Figure 3
Once an administrator completes the welcome page, more configuration settings are generated automatically. HiveManager uses the initial Hive name to as the name for automatically generated QuickStart objects such as the DNS service, NTP service, QoS Classification profile, LLDP profile, ALG profile, etc. Figure 4 shows an example of the DNS QuickStart object.
Figure 4
Most QuickStart objects will provide the necessary functionality and normally do not need modification. However, the QuickStart objects can be edited and in some cases should be edited. For example, the NTP object shown in Figure 5 should be edited to reflect the proper time zone where the Aerohive access points or other devices physically reside.
Figure 5
So why are these QuickStart objects so important? The QuickStart objects are embedded in any new Network Policy templates that you create as shown as shown in Figure 6. Because the objects are always pre-created, network policy configuration is simplified. You do not need to create the objects from scratch. You can however, edit the objects if you need to make some minor changes.
Figure 6
Starting with 6.0 code, QuickStart objects are automatically generated and then embedded in any network policy as shown in Figure 7.
Figure 7
In a later blog, we will have a further discussion of the various types of Network Policies. We will also discuss the four major basic objects and how the HiveManager GUI guides you through the configuration process. Finally, we will discuss the difference between Network Policy configuration and device-specific configuration.
To access online training videos that introduce the HiveManager GUI and guide you through HiveManager configuring a network policy step by step, along with several other basic HiveManager configuration procedures, click here.
The training videos are best viewed in full-screen mode on 14" screens or bigger. Also, ensure that sound is working.
Skilled Healthcare, a support-services provider to the long-term care profession, deployed Aerohive Wi-Fi because it needed a network that can be added quickly to its nursing facilities, the ability to switch networks while keeping costs and training expenses down, and an online management tool that can quickly configure and manage selected access points. Watch this video and hear what Shawn O'Malley, Project Manager, Engineering, has to say about why his organization deployed Aerohive.
In this podcast, Abby Strong, Aerohive’s Senior Product Marketing Manager, and Anoop Dawar, Aerohive’s Director, Platforms Product Management, sit down with blogger Blake Krone at the No Strings Attached show earlier this month.
Abby and Anoop discuss the highlights and benefits of Aerohive’s new switches, HiveManager 6.0, and how this fits in with our existing controller-less Wi-Fi lineup.
Listen to the podcast here.
Want to see a demo of HiveManager 6.0 in action? It’s right here.
This is the first in a series on setting up a guest WLAN.
Many studies have shown that providing WLAN guest access is beneficial to your business.
Guest user traffic should always be segmented from employee user traffic. Four guest WLAN best practices include:
A From-Access guest firewall policy is by far the most important component of WLAN guest management. The goal is to keep wireless guest users away from corporate network resources and only allow them access to a gateway to the Internet, which is especially important if you do not configure a separate VLAN for guest users. Figure 1 shows an example of the default Guest Firewall Policy in HiveManager.
Figure 1
The guest firewall policy can be much more restrictive. A good practice is to block SMTP so users cannot SPAM through the guest WLAN. If necessary, many more ports and/or applications can be blocked. Ports that should be permitted include DNS/UDP port 53, DHCP-server/UDP port 67, HTTP/TCP port 80 and HTTPS/TCP port 443. So that guest users are capable of using an IPsec VPN when connected to the guest wireless network, IKE/UDP port 500 and IPsec NAT-T/UDP port 4500 should be also permitted.
The firewall is built into every Aerohive access point; therefore the guest user traffic firewall policies are always enforced at the edge of the network.
As shown in Figure 2, Aerohive Networks application visibility and control also gives you the ability to permit or block access to Layer 7 applications at the user level.
Figure 2
Guest users should always be prevented from peer-to-peer connectivity on the guest VLAN/subnet. This prevents your guest users from attacking each other while they are connected to the same guest WLAN. Peer-to-Peer blocking can be configured in the Guest SSID Profile settings: Optional Settings > DoS Prevention and Filter >Traffic Filter. As shown in Figure2, all you need to do is uncheck: Enable Inter-station Traffic.
Figure 3
Another good idea is to always rate limit the bandwidth for the guest WLAN. No senses in allowing your guest users to operate as bandwidth hogs. Guest traffic can be throttled with a rate control policy. Bandwidth throttling can be configured in User Profiles > Optional Settings > QoS Settings > Rate Control and Queuing Policy. Figure 4 depicts a good guest rate control policy that limits your guest users to 1 Mbps.
Figure 4
All guest WLANs should have a captive web portal login pages. Captive web portals may be linked to a backend RADIUS server for authentication purposes, users might self-register via a captive web portal login page, or maybe only a simple use-policy acceptance page is required. The legal disclaimer is one of the main reasons for a captive web portal login page. Guest users need to promise to behave themselves when using your guest WLAN and furthermore they should understand that your business is not liable if they somehow get hacked while using your guest network.
As shown in Figure 5, when a guest user browses to a URL, a DNS redirect is used to send the guest user to the captive portal login pages. If a captive portal stops working, there is most likely a DNS problem. If guest user authentication is required, the AP will then query a RADIUS server with an authentication protocol such as MS-CHAPv2.
Figure 5
Aerohive has a large selection of pre-configured captive web portals. The captive web portal pages use cascading style sheets so that they display properly on a computer screen, tablet screen, or smart phone screen. Upon authentication, guests can be redirected to external URL or the initially requested URL.
Figure 6
Figure 7
As shown in Figure 7, the captive web portal pages can be customized within HiveManager. Advanced customization can be done with an external HTML editor and pages can be imported back into the system and then used as templates.
Some examples of the available web portal login pages include user authentication, self-registration, and use-policy acceptance as seen in Figure 8.
Figure 8
Aerohive also offers multiple language support as shown in Figure 9.
Figure 9
The robust firewall that is built into every Aerohive access point is more than capable of providing protection at the edge of the network as discussed earlier in this blog. However, sometimes a customer may have a written security policy that mandates that the guest VLAN not reside at the edge of the network. The guest VLAN can only exist in a DMZ. If that is the case, Aerohive APs can be configured to tunnel the guest traffic back to a HiveOS Appliance server that resides in the DMZ as shown in Figure 10.
Figure 10
Aerohive does not recommend “open” guest WLANs. You should always use encryption to protect your guest users. In my next blog about guest WLANs, I will discuss the many ways Aerohive can provide secure guest management.
Riverside Health Care Systems manages four facilities in Westchester County, just north of New York, with more than 2,000 total employees and 400 affiliated physicians. Medical facilities often pose challenging environments for WLANs, and those operated by Riverside were no exception, particularly St. Johns Riverside Hospital-Andrus Pavilion.
A new, system-wide Aerohive wireless LAN opened up the health care facilities to many labor-saving applications including bedside registration, drug administration, and verification, and RFID patient tagging, as well as the convenience of a guest Wi-Fi network for patients and visitors.
Challenges
Results
Read the full case study here.
A 60-acre outdoor Wi-Fi network is about to go live in Douglassville, Ga - and Aerohive APs are at the heart of the wireless network project.
Complete HealthCare Resources was committed to deploying, eMAR (electronic Medication Administration Record) throughout its client facilities, and needed a flexible and easy-to-manage Wi-Fi network to support it.
Aerohive next-generation controller-less Wi-Fi paired with AirWatch mobile device-management streamlines and automates connectivity, management, and monitoring of mobile devices and BYOD.
Saber Healthcare Group has been on a steady growth path due to a series of skilled healthcare facilities acquisitions that have earned it an accumulated 40 years of healthcare experience. With 50 facilities and counting across Ohio, Pennsylvani
a and Virginia, Saber is committed to providing quality care to the people of its community.
Aerohive's Abby Strong walks us through the new features in HiveManager 6.0, including the updated dashboard, application visibility and control, and Google Maps integration.
More information about HiveManager 6.0 as well as our new switch line can be found here. Or you can visit our online community, HiveNation, to ask questions about this or any other Aerohive products.
