My first few blogs have all centered around the education vertical, but the elegance of Aerohive’s solution can also be applied in other environments.
In this blog I would like to highlight how one network admin used two different tools 
available in HiveManager to solve a big problem he didn’t know he had, on gear that wasn’t even Aerohive product, at a medical clinic in Texas, all while sitting in his office chair over 600 miles away
To set the scene, this story starts back when this customer was still getting familiar with Aerohive. Often when we discuss initial network architecture for large deployments, we like to discuss Aerohive’s AVC engine and its benefits, my topic a few blogs ago.
The customer, we will call him Robbie for this discussion, dismissed some of these benefits explaining that all remote traffic from the clinics and hospitals was routed back to their corporate data center and run through a series of strong filters to ensure proper adherence to the corporate Internet use policy. The topic of AVC was dropped at this point.
Months later, I was working with Robbie reviewing the in-progress deployment of Aerohive access points when I glanced at his Application Dashboard and noticed a significant amount of Netflix traffic flowing across his wireless network. When this traffic was brought to his attention, he dismissed it as incorrect as Netflix was blocked at their firewall.
Further investigation within HiveManager proved the traffic to indeed be Netflix streaming - all from one specific clinic, all from one tablet.
This piqued his interest enough for him to investigate the firewall configuration and sure enough there was one loophole in the Netflix policy on the firewall. That loophole contained the subnet for this small clinic.
After closing the loophole on the firewall, we saw a load decrease on the access points at the clinic in question because Netflix was no longer allowed. Robbie called a contact at that location to ask if they noticed that the wireless was any faster. He got more than he bargained for.
As it turns out, for the last few months (the Aerohive access points were deployed only a few weeks prior) the wireless was very unreliable in the patient rooms. The medical carts and devices would frequently get kicked off of the network or experience very poor performance. As the story continued to unfold, almost all of medical staff were using the break room on one side of the building for wireless access as that was the only part of the building where Wi-Fi reliably worked. They had not complained to corporate yet as they assumed the new access points were not ready for use.
Robbie was obviously puzzled. Why did the new Aerohive access points not resolve this unknown issue that had apparently stretched across the old installation and new Aerohive installation? After explaining the phone call to those of us working with him, we encouraged Robbie to activate the Aerohive WIPS (wireless intrusion prevention system) to look for rogue devices in the area.
In light of the recent FCC ruling against Marriott, let’s take a brief aside to discuss exactly what is a WIPS. Traditional WIPS will contain two components: an intrusion detection element, and an intrusion prevention element. The detection element is passive and perfectly legal to use in most cases as it does not violate the rules around the fair use of unlicensed spectrum. The prevention element means an active mitigation procedure, and often is not legal to use as it violates those same rules. Most companies lump these two elements into one product and name them WIPS. In the case of this blog, we were only using the passive, detection elements of Aerohive’s WIPS implementation and were careful to leave the active mitigation elements disabled.
Once Aerohive’s WIPS detection functionality was implemented, it quickly became apparent that this particular clinic was in a multi-tenant environment. We saw numerous unclassified rogues that were clearly not part of Robbie’s network. These were acceptable (they had to be as there is nothing Robbie can legally do to them) and not part of the problem the medical staff had reported. After we focused on the access points in the patient room areas the actual problem became evident. The access points covering the patient room reported several rogue ad-hoc devices.
Let’s take another aside to describe ad-hoc versus infrastructure modes. An ad-hoc device is a wireless device that has been configured to work peer-to-peer instead of through an infrastructure element like an access point. An analogy would be taking an ATV or golf cart and driving across lawns in a straight line to visit your neighbor instead of taking your car along the roads and appropriate driveways. The ad-hoc (ATV) is quick and easy and simple but ignores numerous rules and laws governing vehicles and doesn’t scale to numerous simultaneous users. The infrastructure solution access points (car) takes into account rules, laws, and user safety along with communal use but also includes more overhead.
After we explained to Robbie why these ad-hoc devices were bad, he made another phone call to the medical clinic. A bit of discussion uncovered that roughly two months ago (around the time the problem started) the clinic deployed new printers for printing patient discharge papers. Those printers were placed near the rooms for ease of access. They came from the factory configured in ad-hoc mode on a random channel per the user manual.
That same user manual walked the local contact through the steps to disable the wireless interface (all of the printers were wired into the network and didn’t need Wi-Fi.) Testing showed a massive, immediate, and sustained improvement of the Wi-Fi experience inside the patient rooms.
Today this clinic continues to use medical devices and handhelds to better provide patient’s quality service, all through the use of Aerohive access points.
While this story centers on Robbie and his remote medical clinics, I think anyone who has a large firewall configuration or printers in their organization can see how this story could apply to them. It should be noted that neither of the problems Aerohive helped identify were actually problems with the Aerohive system. And, to be fair, Aerohive was not used in either case to solve the problem.
However Aerohive’s HiveManager provided a robust collection and visual representation of the data to help Robbie discover and troubleshoot two previously undiagnosed problems.
That is the beauty of having a top notch Network Management System with rich logging and reporting capabilities; it might not be able to solve every problem on your network, but it can help you discover and diagnose problems you didn’t even know you had with products that it doesn’t even manage. And that is the power of the Hive.