CWNP Blogroll

Misguided Meru

2013-05-25T09:24:00Z

--Mobile post--

Meru gets confused about control-plane versus management-plane functionality in one of their recent blog posts. (I am not linking to the blog post because I don't want to help drive traffic to potentially the worst Wi-Fi article in a long time).

There are many things wrong in the blog, and I won't bother to go through them point by point. But I'll highlight one that hasn't been mentioned on Twitter discussions yet. I'm also posting this on my site since they've already demonstrated that they won't publish comments that disagree with them on their own blogs or have a real discussion about their position. They just want to blast marketing FUD.

They state: "...'what' the control-plane function provides is much more important than 'where' the function resides. Therefore the model you choose (local, WAN, cloud, private cloud, virtual, AP) should have no bearing on the functionality of your Wi-Fi."

What?! Are they really serious?! This is inherently wrong because a control-plane outage has operational impact on the network. That's why enterprise network admins spend so much time designing WAN architecture and redundant controller architectures.

If I were an enterprise customer, I would seriously be questioning the ability for Meru to understand customer requirements at this point, let alone build products to meet them.

Cheers, out!
Andrew

Hospital deploys Aerohive Wi-Fi to support staff and patients

2013-05-24T17:01:00Z

Antwerp University Hospital is one of Belgium's leading hospitals and is renowned for the superior quality of its patient care. It employs more than 500 physicians, specializing in more than 40 different fields, to treat more than 180,000 patients every year. With more than 570 beds, the hospital offers a wide range of diagnostic and treatment services — including specialized services in the fields of cardiac science, neuroscience, surgery, critical care, and ophthalmology.

The hospital offers comprehensive care for patients with complex disorders. Everyday its specialists conduct pioneering clinical research, constantly using this research to develop new treatments, with the ultimate goal of providing every patient with top-quality medical care.

The hospital was looking to implement a high-performance WLAN that could support staff, patients, visitors, and students studying at the university. The existing WLAN, however, was unable to support the hospital's ambitions or provide the scalability they needed as a growing organization. Now with Aerohive’s controller-less Wi-Fi, staff, patients, and students have continuous high-performance connectivity and can utilize a variety of devices and applications to do their job as required and without impacting network performance.

"Anywhere, anytime connectivity throughout the hospital is vital for providing staff with access to bedside medical applications such as qcare, metavision, pdms, and c2m ... Aerohive’s controller-less architecture minimizes points of failure in the network."

Wolfgang Wauters
ICT Manager
Antwerp University Hospital

Read the full case study here.

Aruba Model 220 Access Point new with 802.11ac!

2013-05-24T14:46:00Z

This week was the official launch of Aruba's new 802.11ac access point. Blake Krone, Chris Lyttle, Daniel Cybulskie, Keith Parsons, Ryan Adzima and I attended the product launch announcement as a members of the Tech Field Day Roundtable group. The day's agenda for the kickoff event was to announce the technical aspects of the new access point, perform a live demonstration of its capabilities and

Lacuna Systems

2013-05-24T03:29:01Z

I had the pleasure of speaking with the people from Lacuna Systems at Interop a few weeks ago. I wasn’t familiar with them at all, and since they happened to have a booth on the expo floor, I was able to meet up with them and talk about their Indico platform. I’ve used a few APM(application performance management) solutions, so I am a little familiar with the space. However, Lacuna Systems is doing something a little different. Before I mention what that is, allow me to point out a few negative things regarding some of the APM implementations out there.

Cons of APM

1. Can be extremely difficult to implement. - Some APM implementations take months and many engineers to get up and running.
2. Can be extremely difficult to use. - Some APM products have so many nerd knobs that you can get lost in the sheer amount of options. If you don’t have a dedicated monitoring engineer, your APM solution might become a really expensive tool that is never used by anyone.
3. Software agents. - Installing software agents on a bunch of servers can become problematic. The agents have to be updated on occasion, and depending on how they are implemented, they can cause stability issues.
4. Interface monitoring. - It is fairly common to have to mirror all traffic coming in and out of chokepoint interfaces(physical or logical) and relay that to the APM system. Quite often, the APM system itself does not have the number of interfaces needed to aggregate all this data and you have to buy a really expensive network tap solution(eg Gigamon or Anue/Ixia). You can also potentially use up the limited number of monitoring sessions available on your hardware platforms and have to make hard decisions as to which of your monitoring platforms is more important.

Not every APM solution out there has all of the problems listed above. Some have only one or two and others don’t have any of those problems. How is Lacuna Systems different? It’s quite simple. They are only watching your load balancers, or ADC’s, for those of you who refuse to use the term load balancer.

Why Load Balancers?

How many data centers do you walk into these days that DON’T have some sort of load balancer in production? Not many, unless you are dealing with smaller environments. The traffic that flows through a load balancer is probably pretty important to an organization. Any revenue generating applications are probably sitting behind one or more load balancers. You’d want redundant servers at each tier to ensure constant availability. The easiest way to do that is with a load balancer.

Considering the traffic flowing through a load balancer is pretty important, why not focus your monitoring efforts on that traffic? That’s what Lacuna Systems does. You might think that they are missing out on a lot of other stuff in the network by only watching the load balancers. They would agree with you because they are also not trying to be all things to all people. What they are betting on is that the bulk of the information you care about from an APM perspective, is flowing through your load balancers.

How Does It Work?

Simple. They use the built in API’s from each load balancer to get the monitoring information. No network taps or port spans are needed. No remote agents on servers. None of that. They basically just need login information to your load balancer and then they can pull all the data out that they need for monitoring purposes. The Indico platform will take in all of this data and automatically build a baseline of your traffic. When there are deviations down the road, alerts get sent. I’d like to say that there is more to it than that, but that is basically how it works.

If you add new members to a load balancing pool or create new virtual IP’s on a load balancer, the Indico platform automatically detects them. You don’t have to manually update the system every time a change is made to a particular load balancer that is being monitored by Indico.

How Can I Use It?

Today, Lacuna Systems is focusing on F5, Citrix, and A10. However, that doesn’t mean those are the ONLY vendors they will support. I asked them about future plans to support other vendors, and they told me that they’ll support whichever vendor they need to based on customer demand. Obviously, the vendors they support will also have to allow API access. Otherwise, you are looking at screen scrapes off a GUI session, which is messy trying to convert it to text, or using CLI to get data and then parsing it into a usable format.

Think beyond monitoring though. What if you could provision things for multiple load balancers from a central location? What if you were able to do this for load balancers from multiple vendors all at once? That’s where I see an additional use case with Indico. Granted, you can do that apart from Indico just by using the API’s, but since Indico is able to talk to multiple vendors, if you happen to use a variety of load balancers, it might make sense to push those changes through the Indico platform. Maybe that is something they could bake into the product down the road. Of course, customers would probably have to ask for that feature first.

More Info

Here’s a quick 15 minute video from Robert Scoble and Rackspace where Derek Andree from Lacuna Systems is interviewed about the Indico platform. It is a nice summary of the overall solution.

Just to give you a general idea of what their platforms can monitor, here are the numbers for the virtual and 2 physical appliances(Dell servers):

More information is found here: https://lacunasystems.com/products.php

Closing Thoughts

There are a lot of players in the APM space. Most of them are very expensive. Depending on your needs, you may not need all of the bells and whistles that the larger APM players provide. Maybe you just need to know how your core applications are performing. If they happen to flow through a load balancer, Lacuna Systems just might be a vendor that can meet your needs. They also don’t require you to mirror your network traffic into another device for monitoring purposes since they are using API’s.

All in all, I thought it was an interesting way to monitor applications. You can check them out at www.lacunasystems.com.

Lacuna Systems

2013-05-24T03:29:01Z

Cons of APM

Why Load Balancers?

How Does It Work?

How Can I Use It?

More Info

Here’s a quick 15 minute video from Robert Scoble and Rackspace where Derek Andree from Lacuna Systems is interviewed about the Indico platform. It is a nice summary of the overall solution.

Just to give you a general idea of what their platforms can monitor, here are the numbers for the virtual and 2 physical appliances(Dell servers):

More information is found here: https://lacunasystems.com/products.php

Closing Thoughts

All in all, I thought it was an interesting way to monitor applications. You can check them out at www.lacunasystems.com.

Wardriving: Problemo o No Problemo?

2013-05-23T20:55:00Z

Happy (belated) Cinco de Mayo! In honor of Mexico (whose El Tri I actually like a heck of a lot less than Les Bleus), today's discussion of Guerra de Conduccíon has a Spanish language title.

As noted by noted sarcastor Keith R. "The R Stands for Reassociation" Parsons, in some ways wardriving is a topic whose time has passed. We've known about it for years. Wardriving tells hackers where your network is. Most WiFi networks are encrypted. What else is there? Hackers can try to connect, but if you use a long WPA2 Personal passphrase, they won't be able to. Hackers can try to sniff, but if you're using WPA2 Enterprise, then decryption of data frames is impossible (as far as us non-NSA employees know).

But imagine you are an NSA employee. Or the CEO of a noted defense contractor. Or holder of some other high-profile job where the nation's prosperity is dependent on your secrecy (like USC's head football coach). Then if a hacker knows where you live or work, it could be a problem even if your WiFi is encrypted. Maybe.

The topic is of interest to the author after a recent discussion with a person who is, in fact, an employee of a noted defense contractor. The author's position is that Wardriving could be a problem. His position is that it isn't.

Yours truly's scenario lays out as follows. Important Person gets on an airplane. Important Person opens her laptop and dutifully attaches her laptop privacy screen. After browsing adult videos for an hour (that's what Important People really do behind those screens, isn't it?), Important Person does a little bit of work, all the while ensuring that she doesn't connect to the airline's potentially-unsecure WiFi.

What Important Person may be unaware of is her laptop is revealing her location. Check out the capture of probe request frames I got on a recent MCO-LAX (WiFi-enabled) flight:

Highlighted in that Wireshark screenshot is a probe request frame looking for the SSID of "BHNTG862G2332". That means that somebody somewhere connected to a WiFi network with that SSID some time prior to fleeing Orlando.

If an enterprising hacker were to take advantage of wardrivers' data, an enterprising hacker could pin down the location of this Important Person's home or work. Check out what Wigle shows when querying the SSID of "BHNTG862G2332":

Eso mapa (returning to our Mayo de Mejico theme) tells us that somebody on the author's flight lives pretty darned close to 2450 Euston Road, Winter Park, FL 32789.

The argument that wardriving doesn't matter boils down to this: What's the hacker do now? The hacker possibly has no idea which person has the probing device. And even if the hacker does, additional information would be required to make this a National Security issue.

Still, "nadie sufre mas que un hombre pobre o una mujer fea" (I tried to find the Spanish cliché equivalent of "it's better to be safe than sorry", with no luck). If you don't like the idea that someone can find out where you work or live and you think that wardriving is un problemo, then you can do the following:

Disable WiFi when it's not in use. (Because no WiFi means no probing.)

Broadcast your SSIDs. (Because most non-Android devices only probe for Hidden SSIDs. With Android devices you're unsecure no matter what.)

Avoid unique SSIDs. (If our flyer on his/her way to America's finest [or second-finest, depending how much you like Milwaukee] city had used a generic SSID like "Radius" at home, then a bunch of wardriving results would've popped up on Wigle. That makes it near impossible for a hacker to narrow down a home or work location.)

Preventing your WiFi devices from revealing your location via wardriving data requires such simple steps. Home users can just log in to their wireless routers/modems and make sure they have a generic SSID that is broadcasting. Changes an enterprise's WiFi configuration to make it tougher for hackers to know where your office is may take some work, but it's a good idea to at least make that part of the plan the next time the WLAN gets an update.

Of course, all of this is moot if you're an Android user. Android smartphones and tablets probe for all saved WiFi networks, whether hidden or broadcasting. With Android phones, the only way to keep hackers from get information that could reveal the location of su casa is to keep the WiFi turned off when it's not in use.

You’ve Got Mail! ActiveSync with Systems Manager

2013-05-23T17:00:05Z

As many enterprises have gradually— in some cases, grudgingly—adopted BYOD, it is safe to say that email has been the killer app. iOS and Android devices make it incredibly easy to setup an email account with no hassles or calls to the Helpdesk for support.

Perhaps the biggest enabler for this is ActiveSync, the data synchronization application from Microsoft. ActiveSync has been adopted by several mail programs including Microsoft Exchange, Gmail, and a dozen others. One of the nice things about ActiveSync is the ability to seamlessly deliver data to a device without requiring the user to constantly refresh the inbox to check for new mail.

As more and more businesses have adopted the Cisco Meraki Systems Manager MDM platform, we’ve heard from lots of customers who wanted a simple way to configure email settings on mobile devices. Our new ActiveSync feature allows you to securely manage ActiveSync and related settings, like enabling encryption and email formatting.

Associate an email address with a particular client device in one of two ways: set the owner attribute on the client details page, or add new users on the Owners page located in the Configure section and assign them to any enrolled client device.

After a device receives the ActiveSync profile, the user is prompted for the password to complete the setup process. That’s it!

Responsibly Enabling BYOD

Businesses with a BYOD policy or devices issued to employees can leverage this feature to not only configure email on a device, but also just as quickly remove email settings on a device if a device goes missing or an employee leaves the company. If devices need to change hands between users, the ActiveSync profile can be updated without affecting the other data and settings.

Dan Dorato, CTO at Vector Media uses Systems Manager to manage his company’s BYOD program. After using the ActiveSync feature in deploying a new fleet of iOS devices, he marveled at the simplicity. “Meraki SM makes supporting BYOD in our business a no-brainer,” Dan said. “It’s not only easy to use, but the stuff just works!”

Cisco Meraki Systems Manager is still 100% free and continues to receive regular updates with great new features.

ActiveSync support is currently live in the Meraki dashboard for current Systems Manager customers without going through any updates or installations.

If you haven’t already tried Systems Manager, sign up here and give it a spin!

Hospitals Going the Wi-Fi Way

2013-05-23T06:36:04Z

eWeek released an article recently announcing that the new Wi-Fi protocols (802.11ac and 802.11ad) could offer exciting advancements for clinical settings. The new protocols can bridge the gap between wired medical equipment and the future—-a completely wirelessly medical device communications network. Tomorrow’s hospitals will feature medical devices that transfer all data over a wireless network.

Wi-Fi seems to be a winner in healthcare—it’s clear that the greatest chance for RTLS ROI uses Wi-Fi since propriety networks could be abandoned or isolated to only a few applications requiring super-fine location accuracy. With companies such as GE Healthcare and Cisco backing the Wi-Fi standard, it’s not hard to imagine why the most popular RTLS vendors offer Wi-Fi-based solutions. Wi-Fi-based systems have become standard for clinical applications, beating alternatives such as ZigBee which is still used, but for a limited set of applications.

Real-Time Location Systems today use a hospital’s existing Wi-Fi networks to collect and report information such as a patient’s current location or the temperature in a blood bank refrigerator to increase patient satisfaction and safety while also making it easier for a hospital to stay in compliance with Joint Commission regulations.

Hospitals such as Memorial Healthcare in Michigan are already experiencing some of the benefits Wi-Fi-based RTLS. Memorial Healthcare is using RFID-over-Wi-Fi™ solution and tags to record temperatures, track patients and keep staff safe with two-way messaging. Check out Memorial Healthcare’s case study using Ekahau RTLS.

The Ekahau Temperature sensor regularly records temperatures to help with Joint Commission compliance, automating temperature monitoring.

A sticky problem – Wi-Fi clients that won’t roam

2013-05-23T03:07:10Z

I work in a very interesting industry. It seems like in no time, WLANs have gone from being a nice to have but definitely optional thing to something that everyone must have in order to operate their businesses. Part of the issue with this rapid change is that we are left with some decisions made in the past that have turned out not so great in the present day. One of those issues is caused by the decision to leave roaming decisions (if a WLAN client moves to a new AP and BSSID) up to the client. At the time I’m sure this seemed like a good solution. Craig Mathias over at NetworkWorld gave a bit of history around this decision that I wasn’t aware of before. Apparently it was felt that ‘few sites would be purchasing access points, so it was assumed that most networks would be peer-based’

We who deploy WLANs professionally know well the pain caused by buggy client drivers and the wide variance between different vendors on how they decide to do something as simple as roaming to a new AP. In comparison, cellular networks largely leave the roaming decision in the hands of the cell tower, which results in much smoother changes (such as not dropping your calls) in the main for clients as the move about. Two factors are converging to make this issue into a bigger problem for Wi-Fi networks. The first is that speeds are increasing on wireless (with 802.11ac it will go much higher) and people are using the WLAN because of this for more and more critical applications such as voice and video. The second is that the sheer number of devices using Wi-Fi as their only means of accessing the network has exploded since the introduction of the iPad in 2010. As Wi-Fi access becomes something that is relied on to run businesses, people naturally expect to be able to access it from wherever they need to work without a lot of hassle. They are not aware of such issues as limited bandwidth and contention caused by the increase in clients. They only want to know why their video doesn’t run smoothly or their voice call was dropped.

I attended yesterday Aruba Network’s 802.11ac day (as part of Tech Field Day where they announce their newest AP, the AP-220, and had several other things to talk about. Foremost amongst those was the announcement of their new ClientMatch technology to help with the issues with roaming caused by sticky clients. What is happening here is that clients are not making a decision to roam when a much better connection is available to them or when an AP is overloaded with other clients and a much lighter loaded AP is nearby. We have, in fact, a standardized way of dealing with this issue in the 802.11k and 802.11v standards, but not all clients support these standards. Aruba’s solution to this is to build intelligence into the access point and controller to help ‘match’ the client with the best AP from the clients point of view. This intelligence is happening on several levels. At layer 1, the link is being optimized by moving the clients either using 802.11k/v or by disassociating the client and only offering association to the ‘better’ AP. At layers 2-3 the load on the APs is taken into account and then for layers 4-7 what the application is doing is taken into account.

Interestingly enough Aruba believes that what they are doing is particularly unique and therefore patentable. They have submitted the following patent, US20130036188 which describes what they are doing for the clients that do not support 802.11k. Essentially they are creating the beacon reports used in the standard by collecting information from the APs when the client sends probe requests, authenticates or associates with the AP. What happens then is the AP takes the SNR information, does an adjustment and then sends the information upstream to either a controller, IAP or Airwave and that is used to figure out which AP is best for the client. This is a quite clever indirect way of figuring out how the client sees the network. The information that could be gathered is SNR, MAC address (as a key), channel, band, timestamp, noise floors, channel loading, AP capabilities and more. This combined with data the controller already has about applications means a decision can be made to whitelist or blacklist a certain STA on a group of APs. I’ve been told that they discovered in testing this that the actual SNR on the client was off from the readings they were getting from their algorithm by a constant amount, so they were able to just adjust to account for that.

Once you have built up this database of information, the next decisions you have to make is how to use it. Aruba told me that they decided to push this back down to the APs in a distributed way, so that the decision to associate a client wouldn’t suffer from having to look back to a controller or other device. As was pointed out on twitter, moving active voice or video streams off a poorly performing AP is not a decision to take lightly. Most voice calls use a metric called a MOS score to figure out what the quality of the call is. Aruba is using, as much as they can, information from the call itself to figure out the MOS score on a realtime basis and then move other, non-voice clients off the AP if that will interfere with the call quality. This was particularly highlighted by the Microsoft presenter who spoke about how they had opened an API up so that Aruba could gather this type of information about the Lync call. It wasn’t discussed, but I think that the basic client roaming algorithm would move a voice client if it got too far away from an AP for its inbuilt MOS score to be sufficiently high. In this case, the Aruba ClientMatch system would encourage it to pick a much better AP by only offering those that would be good for the client. One final point to make, Aruba was very careful to point out they took a cautious approach with ClientMatch so they were not moving clients with an 80% score just to get a 90% score. They wanted to make sure they concentrated on the bottom percentage of clients so that the improvement would be much larger and this would increase stability of the WLAN in general.

There are some additional uses that can come from being able to track what is happening from the client point of view. These uses come in Aruba’s Airwave product where the information is being used to add to the ability of Airwave to troubleshoot user’s connectivity. Aruba has created additional reports to give more visibility into client behavior, one of which is called the steering report. This report gives you information about what clients are being steered by ClientMatch and how often they have been steered. This gives you some clues into which clients might have firmware or driver issues that should be looked at because they are constantly sticking to poor AP connections. VisualRF additionally shows the status of client connections, indicating in a nice red color when a client has a poor connection. All this builds your control over what is happening on your Wi-Fi network and especially control over the client behavior that you haven’t had before.

Whew, this has definitely been one of my longer blogs. There was quite a lot of information to get through and I wanted to make sure, as much as I was able, to have it correct. If anyone from Aruba reads this and see’s I got something very wrong in my explanations of what’s going on I’d love to hear from you so I can correct this. Indeed I would also love to hear from anyone else with an opinion on this technology. I think this could be the start of fixing something that has been very annoying for some time, the ‘client’ problem. I know I’m looking forward to doing some testing of my own of ClientMatch once its released.

Getting Started with HiveManager: Bell And Whistles, Part 2

2013-05-22T21:18:00Z

As we discussed in my last blog, Getting Started with HiveManager: Bell And Whistles, Part 1, Aerohive offers a vast array of “bells and whistles,” and our WLAN 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 WLAN 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 in a logical manner. This is the second in a series of blogs that will discuss the basics of Aerohive’s object-oriented configuration.

HiveManager is a cloud-based Network Management System (NMS) for simple policy configuration, firmware upgrades, and monitoring of up to thousands of Aerohive devices. These devices can be access points, branch routers, switches or HiveOS Virtual Appliances. Aerohive devices are configured via HiveManager through three easy steps in the following order:

Network Policy Configuration – A Network Policy is an amalgamation of various configuration settings that can be applied to multiple Aerohive APs, switches, and routers that share a common characteristic, such as being located at the same site or working together to connect multiple remote sites through VPN tunnels. The type of Network Policy you choose depends on whether your Aerohive deployment consists of only wireless devices (APs), a combination of wireless and wired devices (APs, switches and routers), HiveOS Virtual Appliances or perhaps Aerohive devices deployed exclusively as Bonjour Gateways.
Device Specific Configuration – In contrast to the Network Policy settings, which you can apply to numerous devices, there are also settings that are best applied to individual devices. These are settings such as their location on a topology map, radio profiles, interface settings, and login credentials. Aerohive devices can also operate as RADIUS servers, RADIUS proxies, VPN servers and DHCP servers. Any time an Aerohive device functions as a server, the server configuration settings are specific to that device.
Update Devices – Once you have configured the more generic Network Policy settings and the more device-specific settings, you upload the configuration from HiveManager to the devices as shown in Figure 1.

Figure 1

The HiveManager Network Configuration GUI consists of three panels as shown in Figure 2. You can click on any panel header to migrate to the respective panel. Clicking on the Configure & Update Devices panel automatically saves the Network Policy configuration. Clicking on the Save or Continue buttons also will save the Network Policy configuration.

Figure 2

Panel One – Configure Network Policy: As shown in Figure 3, the Network Policy panel is where you first choose, create a Network Policy.

Figure 3

When you create a Network Policy, you must give it a name and then choose the components of the Network Policy. As shown in Figure 4, you can configure four different types of Network Policies, which all have different purposes as well as different configuration workflows. Furthermore, HiveManager gives you the capability of Unified Policy Management. You can create a Wireless Access Network Policy and then later add Switching and/or Branch Routing to the policy.

Figure 4

Panel Two – Configure Interfaces and User Access: After you take the first step of selecting your Network Policy, you then proceed to the second panel where the Network Policy configuration takes place. The great news is that despite the many bells and whistles that exist, HiveManager will walk you through the configuration process. Different workflows exist for linking various configuration objects together. A more in-depth explanation of the core objects will be discussed in the next blog. Figure 5 depicts a Wireless + Branch Routing network policy that was created for a bed & breakfast in New Albany, Indiana – The Admiral Bicknell Inn.

Figure 5

Panel Three – Configure and Update Devices: Once you have finished configuring your Network Policy, you click on the third panel for the final two steps. From this panel you configure device specific settings and you can also upload all the configurations to the devices. First you must configure the device specific settings. To do this, select and the checkbox next to the device and then click on the Modify button or simply click on the hostname of the device

Figure 6

You can now begin the device specific configuration. For example, you can assign the device a Hostname, designate a logical location, and assign the device to a topology map. As shown in Figure 7, all radio settings are configured here such as operational mode (client access and/or mesh), Radio Profiles and channel/power settings. Radio profiles are detailed settings for your Wi-Fi radio interfaces. Radio Profile settings include, band-steering, load-balancing, background channel-scanning, high-density settings and much more.

Figure 7

As seen in Figure 8, other device specific settings include the management interface IP settings, and the operational mode of the Ethernet ports. More advanced settings include device classification tags and service settings to designate RADIUS, VPN or DHCP server functionality.

Figure 8

Once you have completed your device-specific settings, it is time for the final step: uploading the configurations to the devices. Simply check a single device or multiple devices and then click on the Upload button as shown in Figure 9. The Network Policy configuration and the device-specific configurations will then be sent to all the Aerohive APs, switches and routers. The very first upload sends the entire configuration and a reboot will be necessary. All subsequent uploads only send configuration changes and no reboot is necessary.

Figure 9

To quote Michael Jackson, “Easy as 1-2-3 and as simple as do, re, mi.” – Aerohive devices are configured via HiveManager through three easy steps:

Network Policy Configuration
Device Specific Configuration
Update Devices

In the final installment of the “bells and whistles” blog series, we will discuss the different types of Network Policies and the major core objects.

Getting Started with HiveManager: Bell And Whistles, Part 1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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. For Part 1 of this blog, click here.

The training videos are best viewed in full-screen mode on 14" screens or bigger. Also, ensure that sound is working.

[Cross-Post] New Analysis: Comprehensive BYOD Implementation Increases Productivity, Decreases Costs

2013-05-22T19:40:13Z

The growth of connected devices is impacting enterprises worldwide. The key to unlocking value, however, is shifting from the number [...]

Wi-Fi networks in 5 GHz: a few observations

2013-05-22T19:07:58Z

There is a lot of talk in the air about 802.11ac; and accordingly, there is also a lot of talk about 5 GHz Wi-Fi networks. Lisa Phifer recently wrote a tech note on Webtorial discussing this current topic. It was great talking to her as always on hot topics in Wi-Fi. From these types of [...]

Not Your Mom’s Shopping List

2013-05-22T02:34:19Z

| Today’s Digital Lists Can Increase Basket Size and Build Loyalty | I remember my mom’s shopping list. Usually written on scraps of paper and stuffed in her purse, it served an effective single-function purpose: memory enhancement. And while it was mobile, it was easily misplaced, difficult to replicate, and sharing it with others required [...]

Have You Registered for K-12 & Public Safety May 22nd?

2013-05-21T13:33:06Z

Improving School Safety with Your WLAN See how your campus Wi-Fi can improve emergency response Register Now | May 22, 2013 10AM-11AM PDT Tony De La Rosa shared with us a teaser last week about the riveting webinar we have coming up this week on how [...]

Trac migration and forum crash details

2013-05-21T03:57:00Z

Trac/SVN

You probably didn't notice but I had been working a lot on the servers and I recently migrated our old trac server to a new server.

However, a migration never goes without a glitch (who unleashed Murphy?). A few settings changes needs to be done for Trac and we're done but SVN was behaving. The only solution I saw is moving it temporarily to a separate server/URL: http://svn.aircrack-ng.org
You can also reach it via https but it's a self signed certificate for now.
Since the repository UUID didn't change, you can simply relocate your local copy or check out with the new svn URL.

Trac URL didn't change and it is now also available via HTTPS with a proper certificate

Forum

It had a big issue a few weeks ago. My provider told me their log says the instance was stopped. However, their cloud system crashed the instance.

The non-persistant disk where the OS of the instance is installed goes back to its original state (so any data/customization on that disk is lost) when the VM is stopped or archived. I already had similar issues before but I was able to force the instance to reboot so it wasn't a big deal.

Forum data is hosted on a MySQL database and those files were on the non-persistant disk.

Good news: Forum files and Apache config were stored on the persistant disk and I had a backup script for the DB.
Bad news: last time the backup script ran was in July 2012.
Lesson learned: check every often that the backup scripts are still running.

We lost about 10 month of posts and I am deeply sorry for what happened. I had a discussion with my provider and I'm now downsizing due to that issue, past issues and their customer support. I'll only keep stuff that never gave me any issue: domains.
Trac was the first service to be migrated to the new server a very good friend gave me (I can't thank him enough for that). Other services will be moved on that server too.

Best Wi-Fi books — from 802.11ac to certifications

2013-05-20T23:00:13Z

One of the reasons that I like working at Aerohive is that we have a deep bench of talent. Today, I’m going to take a look at the bench from just one aspect: If you wanted to go read about Wi-Fi, what books should you pick up? Of course, we have a number of white papers you can read that describe how we’ve built Aerohive products, but where would you start if you wanted to get outside the realm of vendor-written material?

One place that people frequently start in Wi-Fi is the CWNA certification program. A number of Aerohive employees have been closely associated with the program since its inception. The official study guides are all written by Aerohive’s own David Coleman:

Certified Wireless Network Administrator (CWNA) Study Guide. If you’re after the first certification in the CWNA sequence, start here.
Certified Wireless Network Security Professional (CWSP) Study Guide. (David co-wrote this with another member of the Aerohive training staff, Bryan Harkins). As security became more complex, it was clear that a second certification was needed. This certification attests to your knowledge about how wireless security protocols work.
Certified Wireless Analysis Professional (CWAP) Study Guide. Have a problem with your network you need to diagnose? This is the certification for you.

In addition to the CWNA courses, there is a deep well of technical information on Wi-Fi in and around the company. Bob O’Hara was the original technical editor of the 802.11 standard, and he wrote possibly the first book on 802.11 for the IEEE press (now in its second edition). It is rare to find somebody who was there from the birth of a technology who can write clearly, and Bob is one of those people.

Finally, you have me. I started writing about Wi-Fi when I broke into the industry, and I’ve continued to write as the technology has developed around me. (It was a bit awe-inspiring to step into Bob’s shoes as 802.11 revision chair several years ago.)

My first book, now in its second edition, is the O’Reilly “bat book,” 802.11 Wireless Networks: The Definitive Guide. Read it to get a foundation for how the 802.11 MAC works, and the basics of the physical layers up through 802.11g. I suppose this is as good a point as any to answer a couple of questions about the book: (1) No, I did not pick the bats on the cover, though I do really like them, (2) Yes, I know the sendmail book has a bat on it, but it is a different bat. I think the sendmail bat is actually a fruit bat, and mine are “real” bats.

My second book, 802.11n: A Survival Guide, came out last year. It’s a companion volume to the original book with updates for 802.11n. You can read it separately, but you do need to have a good understanding of how 802.11 works to get the most out of it.

Fun fact about the 802.11n book: I suggested an animal, but didn’t get the one I wanted. My suggestion was for the Mexican free-tailed bat for two reasons: (1) it is the fastest bat in the world, and (2) there is a reasonably famous colony of Mexican free-tail bats that nests under the Congress Street Bridge in Austin, Texas, a city whose many fine qualities include being the headquarters of the Wi-Fi Alliance.

O’Reilly was unable to obtain a wood cut of the Mexican free-tail bat, though, so I accepted another bat in its stead.

My third book doesn’t exist in final form yet. 802.11ac: A Survival Guide has been in the works since last summer, and is finishing up its technical review process now. O’Reilly has started a program called “early release” which lets you purchase the book now and read the book as it develops, and you get a copy of the final book when I’m finished.

If you’re interested in being part of that, I do have an author discount code I can give you – just drop me an e-mail at (first initial)(last name)(at)aerohive(dot)com and I’ll send it to you.

Whether you are just getting started in Wi-Fi or are an experienced administrator looking for more detail on the how the protocol works so you can become a better network analyst, Aerohive’s authors have you covered.

An extra bonus is that we’re all quite accessible. David and Bryan can be found teaching classes throughout the world, and I am often a speaker at our Hive User Groups.

Any of us would love to sign books (which makes us feel like more famous people than we actually are) or talk to you about what you’re doing, so don’t be shy.

Guest Ambassadors: Providing Simple and Secure Guest Access

2013-05-20T22:19:38Z

Many of our customers use Cisco Meraki wireless to offer guest-wifi at their locations. The MR wireless access points sport a ton of features making it easy to offer guest access to your network without compromising security. The dashboard offers quite a few options for controlling access to your network including device-based policies, integration with a RADIUS or Active Directory server, SMS authentication, paid access, or requiring enrollment in Systems Manager, our free MDM solution. For organizations that want a more hands-on and individualized approach to guest access, Cisco Meraki wireless also includes the guest ambassador feature.

Provide temporary usernames and passwords for access to your guest network

Guest ambassadors can see a single page of the dashboard for your network, allowing them to create temporary login credentials for your guest network. Now access to the wireless network can be tightly controlled, but a receptionist or office manager can quickly grant network access to a visitor without danger of changing any network settings.

Guest ambassadors see only this menu when logged into dashboard.

Create guest ambassador accounts in dashboard on the Alerts and administration menu of your wireless network:

Guest ambassador accounts have even more limited access to dashboard than Read-only accounts

You can grant access to your guest WiFi on an individual basis for increased security without increased complexity. The guest ambassador feature is standard on all Cisco Meraki wireless networks—try it today!

Cisco client debug - 802.11 Association Status Code

2013-05-20T20:34:35Z

When you enable client debug you can be hit with a ton of information. One of the things I look at is the 802.11 association status code. The status code is very telling. It can provide information about your client and if there is a connection issue. Another tool to add to your bag of tricks.

Lets take a peek at a debug log

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a 0.0.0.0 8021X_REQD (3) DHCP Not required on AP 08:1f:f3:e1:8f:c0 vapId 4 apVapId 4for this client

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a Not Using WMM Compliance code qosCap 00

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a 0.0.0.0 8021X_REQD (3) Plumbed mobile LWAPP rule on AP 08:1f:f3:e1:8f:c0 vapId 4 apVapId 4

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a apfMsAssoStateInc

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a apfPemAddUser2 (apf_policy.c:223) Changing state for mobile b4:f0:ab:e3:19:6a on AP 08:1f:f3:e1:8f:c0 from Idle to Associated

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a Stopping deletion of Mobile Station: (callerId: 48)

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a Sending Assoc Response to station on BSSID 08:1f:f3:e1:8f:c0 (status 0) ApVapId 4 Slot 0

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a apfProcessAssocReq (apf_80211.c:5272) Changing state for mobile b4:f0:ab:e3:19:6a on AP 08:1f:f3:e1:8f:c0 from Associated to Associated

Our debug shows a status code of 0. Referencing our chart below we will find our association was a success.

802.11 Association Status Codes

https://supportforums.cisco.com/docs/DOC-33185

Code	802.11 definition	Explanation
0	Successful
1	Unspecified failure	For example : when there is no ssid specified in an association request
10	Cannot support all requested capabilities in the Capability Information field	Example Test: Reject when privacy bit is set for WLAN not requiring security
11	Reassociation denied due to inability to confirm that association exists	NOT SUPPORTED
12	Association denied due to reason outside the scope of this standard	Example : When controller receives assoc from an unknown or disabled SSID
13	Responding station does not support the specified authentication algorithm	For example, MFP is disabled but was requested by the client.
14	Received an Authentication frame with authentication transaction sequence number out of expected sequence	If the authentication sequence number is not correct.
15	Authentication rejected because of challenge failure
16	Authentication rejected due to timeout waiting for next frame in sequence
17	Association denied because AP is unable to handle additional associated stations	Will happen if you run out of AIDs on the AP; so try associating a large number of stations.
18	Association denied due to requesting station not supporting all of the data rates in the BSSBasicRateSet parameter	Will happen if the rates in the assoc request are not in the BasicRateSet in the beacon.
19	Association denied due to requesting station not supporting the short preamble option	NOT SUPPORTED
20	Association denied due to requesting station not supporting the PBCC modulation option	NOT SUPPORTED
21	Association denied due to requesting station not supporting the Channel Agility option	NOT SUPPORTED
22	Association request rejected because Spectrum Management capability is required	NOT SUPPORTED
23	Association request rejected because the information in the Power Capability element is unacceptable	NOT SUPPORTED
24	Association request rejected because the information in the Supported Channels element is unacceptable	NOT SUPPORTED
25	Association denied due to requesting station not supporting the Short Slot Time option	NOT SUPPORTED
26	Association denied due to requesting station not supporting the DSSS-OFDM option	NOT SUPPORTED
27-31	Reserved	NOT SUPPORTED
32	Unspecified, QoS-related failure	NOT SUPPORTED
33	Association denied because QAP has insufficient bandwidth to handle another QSTA	NOT SUPPORTED
34	Association denied due to excessive frame loss rates and/or poor conditions on current operating channel	NOT SUPPORTED
35	Association (with QBSS) denied because the requesting STA does not support the QoS facility	If the WMM is required by the WLAN and the client is not capable of it, the association will get rejected.
36	Reserved in 802.11	This is used in our code ! There is no blackbox test for this status code.
37	The request has been declined	This is not used in assoc response; ignore
38	The request has not been successful as one or more parameters have invalid values	NOT SUPPORTED
39	The TS has not been created because the request cannot be honored; however, a suggested TSPEC is provided so that the initiating QSTA may attempt to set another TS with the suggested changes to the TSPEC	NOT SUPPORTED
40	Invalid information element, i.e., an information element defined in this standard for which the content does not meet the specifications in Clause 7	Sent when Aironet IE is not present for a CKIP WLAN
41	Invalid group cipher	Used when received unsupported Multicast 802.11i OUI Code
42	Invalid pairwise cipher
43	Invalid AKMP
44	Unsupported RSN information element version	If you put anything but version value of 1, you will see this code.
45	Invalid RSN information element capabilities	If WPA/RSN IE is malformed, such as incorrect length etc, you will see this code.
46	Cipher suite rejected because of security policy	NOT SUPPORTED
47	The TS has not been created; however, the HC may be capable of creating a TS, in response to a request, after the time indicated in the TS Delay element	NOT SUPPORTED
48	Direct link is not allowed in the BSS by policy	NOT SUPPORTED
49	Destination STA is not present within this QBSS	NOT SUPPORTED
50	The Destination STA is not a QSTA	NOT SUPPORTED
51	Association denied because the ListenInterval is too large	NOT SUPPORTED
200 (0xC8)	Unspecified, QoS-related failure. Not defined in IEEE, defined in CCXv4	Unspecified QoS Failure. This will happen if the Assoc request contains more than one TSPEC for the same AC.
201 (0xC9)	TSPEC request refused due to AP’s policy configuration (e.g., AP is configured to deny all TSPEC requests on this SSID). A TSPEC will not be suggested by the AP for this reason code. Not defined in IEEE, defined in CCXv4	This will happen if a TSPEC comes to a WLAN which has lower priority than the WLAN priority settings. For example a Voice TSPEC coming to a Silver WLAN. Only applies to CCXv4 clients.
202 (0xCA)	Association Denied due to AP having insufficient bandwidth to handle a new TS. This cause code will be useful while roaming only. Not defined in IEEE, defined in CCXv4
203 (0xCB)	Invalid Parameters. The request has not been successful as one or more TSPEC parameters in the request have invalid values. A TSPEC SHALL be present in the response as a suggestion. Not defined in IEEE, defined in CCXv4	This happens in cases such as PHY rate mismatch. If the TSRS IE contains a phy rate not supported by the controller, for example. Other examples include sending a TSPEC with bad parameters, such as sending a date rate of 85K for a narrowband TSPEC.

Keeping the Momentum with Business-Relevant Wi-Fi Solutions

2013-05-20T15:54:24Z

Can you remember life without Wi-Fi? Mobility is an integrated part of our daily lives – from how we operate [...]

Aruba 802.11ac coverage tomorrow @ 10:00 PDT! Follow on Twitter #11ac

2013-05-20T15:03:32Z

Aruba Networks will be announcing their 802.11ac (wave 1) offering next week 5.21.2013 @ 10:00 PDT.

This is an exciting time for Aruba Networks. Aruba's been pretty tight lipped about their 802.11ac access point up to this point. At the last Tech Field Day the delegates, myself included, received a sneak peek of Aruba's new flag ship offering. I am looking forward to this live event to hear exactly Aruba's deployment strategy, marketing approach and more importantly how Aruba's 802.11ac will operate in the enterprise.

LIVE COVERAGE

Live coverage http://www.arubanetworks.com/11ac

TWITTER

Join us for an in-depth 802.11ac discussion live on Twitter hash tag #11ac

Questions that will be covered #11ac
1. Higher data rates, better access point reliability: How important are these and other 802.11ac Features to your organization?

2. What are the use cases for 802.11ac in your organization - eg. video over Wi-Fi?

3. In your organization, what issues will be solved, or addressed by the 802.11ac standard?

4. When are you planning to invest in the 802.11ac technology?

5. What's your WLAN deployment strategy with 802.11ac - eg. only deploy in high density areas?

Tech Field Day event schedule

Agenda

10:00 am PDT Aruba 802.11ac Announcement with Keerti Melkote, Aruba CTO and Founder

10:45 am Microsoft Lync over 802.11ac Wi-Fi with Pascal Menezes, Sr. Program Manager at Microsoft

11:45 am Tech Field Day 802.11ac Roundtable

2:00 pm Designing Wi-Fi for Voice & Video with Mike Kail, Netflix VP of IT

3:00 pm Next-gen Access Network Design with Arun Kanchi, Exafort CEO

http://techfieldday.com/event/ra11ac/

ARUBA AIRHEADS FOURM

http://community.arubanetworks.com