First Thing's First: Requirements.

*Originally published on Eddie's

I was at a meeting today with a large Mechanical/Electrical Engineering firm who was in need of some wireless expertise. More, and more they are getting asked to include wireless "designs" for building projects and are finding (as many do) that it's not as simple as it seems.

The discussion took many turns, but often came back to something like, "So, if we have a school with say 35 students per classroom how many APs do we need?" My answer would be, "it depends." What does it depend on? Their requirements.

How many clients (not users, but devices)? What type of clients (1 stream, 2 stream, 3 stream)? What applications will they be using (e-mail & web, video streaming vs. YouTube caching, voice, etc) What are the bandwidth requirements for their State testing? And more.

The point was - just like they could not just "make up" an electrical, or engineering design out of the blue (How many people need to be in the space? What's the total power consumption required? Do we need HVAC in all locations?) - one could not just "make up" a WLAN "design" (Well, one could, but then you get what you get). That made total sense to them which was good.

I love explaining how wireless works and seeing their eyes light up. I love how it makes sense to them when I explain why they're not going to see 1.3GBs throughput, or adding more APs is not a default answer to a problem, how coverage & capacity are different things, how having a bunch of low-end single stream devices is not as efficient as have a bunch of 2, or 3 stream devices, etc.

The FIRST step to wireless network design, and the best way to avoid the BAD-FI, is to determine the REQUIREMENTS and EXPECTATIONS of the customer. Here just a few of things you should consider:

  • How many clients will be using the WLAN?

  • What are the types/capabilities of the devices? (# of streams, 5GHz support, DFS support, 802.11r/k/v support, etc.)

  • What applications will be using the WLAN and what are the requirements of those applications?

  • Is there a budget for the project?

  • Are there accurate, scale floor plans available?

  • What security and authentication types are you looking to support?

  • What the total bandwidth coming into your facility?

  • What is the time-frame for the project?

  • Aesthetics: Are external antennas ok? Do LEDs need to be off Should APs be inconspicuous?

  • Cable lengths: where are/is the MDF/IDFs located? More than 300ft from the APs?

These are a few off the top of my head, but you get the gist. DEFINE your requirements and expectations BEFORE you design a solution.

Anything else and you're just guessing.

Single VLAN Architecture for WLANs

Aruba has just posted their most recent VRD (Validated Reference Design). In the past we've relied on VLAN pooling for large WLANs do to the issues with broadcast and multicast in large subnets. Optimization of these now allows WLANs with a single large VLAN/Subnet simplifying deployment.

"Rather than using conventional design with VLAN Pooling and multiple smaller subnets, we think that there is a better way to design WLAN today using 'Single VLAN with One Large Subnet' to serve all the wireless clients connecting to an SSID. This paper explains how we came to this conclusion."

Download VRD now →

You should also take advantage of Aruba's entire VRD Library →


Bigger ain’t ALWAYS better. 802.11ac & 80/160 MHz Channels.

Last week we were asked to come and troubleshoot a WLAN that was experiencing connectivity issues. All we knew was this was a brand-new installation and that it was the latest hardware available from this particular vendor.

The first thing we did upon arriving on site was scan the area as we walked around. Immediately we saw something that was troubling. All of the brand-new 802.11ac access points were broadcasting on 80MHz channels, and there were no DFS (Dynamic Frequency Selection) channels being used thus limiting their channel re-use options even more.

As you can see in the chart below there are only TWO 80MHz channels available for use without DFS channels (the entire UNII-2) :

5MHz Channels in the US.

Even in a deployment as small as this one (they only had eight APs) using 80MHz channel is a non-starter. The WLAN was literally interfering with itself. Even enabling DFS channels would have been a difficult thing to make work, even if (theoretically) we could have SIX channels. However, channel 144 is ONLY usable by 802.11ac devices. So, typically, the 80MHz channel that includes 144 is not used. Also, the TDWR (Terminal Doppler Weather Radar) channels are not used so now we're down to FOUR 80MHz channels. Four channels may work in a small environment, but then you have to consider WLANs other than yours.

Unless you are in a secluded area there will probably be other WLANs within earshot of your network. So, if any of the sub-channels that make up the 80MHz channel that you are on, are also in use by other clients, you will experience issues. In this case, the WLAN was in an office building that had other tenants with their own WLANs. So, using 80MHz channels in the scenario was the main cause of their problems. (Even if they were secluded usage of 80MHz channels would not be practical.)

The fix was simple. We enabled DFS on their controller and disabled 80MHz support in the ARM profile for that AP group. This immediately dropped all APs (access points) to using 40MHz channels. And, with the use of the now available DFS channels, we had NINE channels to use among 8 APs. The point here is DFS gives A LOT more channels to work with - so it's worth using them.

We can't blame the customer for this. The installer should have known that 80MHz channels in an enterprise environment is not practical, or in this case, even viable. It was clear what had happened. The system defaults were left as-is, and there was little to no customization of the WLAN.

By default, 80MHz channels were enabled. 

By default, DFS was disabled. 

By default, all APs were set to transmit at maximum power.

This just shows the importance of knowledgable, experienced professionals deploying your wireless network. It's more than mounting APs and creating a few SSIDs. It's understanding how RF (radio frequencies) work, what its limitations are, and how to design around them.

One last note on using DFS channels. I have seen great success using them, but the reason DFS channels are not enabled by default is because they share spectrum with radar systems:

DFS is a mechanism to allow unlicensed devices to use the 5GHz frequency bands already allocated to radar systems without causing interference to those radars. The concept of DFS is to have the unlicensed device detect the presence of a radar system on the channel they are using and, if the level of the radar is above a certain threshold, vacate that channel and select an alternate channel.
— Aruba, an HP Enterprise company.

For this reason DFS is disabled by default on Aruba controllers. If near an airport, a marina, or military installation, you should consider the possibility of radar events. A radar event occurs when an AP hears (or, thinks it hears) radar on the channel it's on. When this occurs the AP immediately switches to another channel (as per FCC regulation). This will cause all the clients on that AP to be disconnected. They will then probe for a new AP and reconnect. With a few events per month this may not be a big issue. But, if you have mission-critical applications (a hospital perhaps) radar events may not allow DFS to be an option. You may even need to go down to 20MHz channels so you can have more spatial re-use with non-DFS channels.

We recommend enabling DFS. Then monitor your network for events. If they never occur, or are very infrequent then continue using DFS. If you see events that seem to be centered on certain frequencies disable just those DFS channels. 

Enabling DFS channels.

Disabling 80MHz support.

The easiest way to monitor for DFS events on an Aruba controller is from the CLI. SSH into your controller and use the following command:

(controller) # show log all | include Radar

Do this every few weeks. Then if all seems good - once a month, or so. If you're lucky enough to have an NMS (Network Management System) perhaps you could setup alerts for these events.

The four things I hope you get from this post are:

1. 80MHz channels are impractical for enterprise use.
2. Use DFS channels whenever you can (which should be most of the time).
3. NEVER take the default settings from manufacturer at face value.
4. When in doubt hire a professional.

Thank you for a fantastic "Shoot to Win" event!

Thanks to all of you that came to our “Shoot to Win” event. The event was a success thanks to you! We had a fantastic time at the wonderful Whistling Pines Gun Club West with you and Aruba.

HUGE thanks to Olympic Shooters Amber English and Keith Sanderson. Your expertise, instruction, and amazing generosity made the event. We can't wait to do another one with you!

I'd like to congratulate Cindy Senger of the Senger Design Group who won the new AppleTV for best shooting as judged by Amber and Keith. Our Olympians were quite impressed with Cindy - who is new to shooting - deeming her "a natural". Indeed!

And now, the winner of the drawing for the ARUBA IAP-225, 802.11ac access point:

Ken Fry of Colorado Springs Christian School

Congratulations, Ken, enjoy your new AP! You will be receiving your prize next week.



Wireless LAN Troubleshooting & Design Guide

Aerohive Networks is offering this free WLAN Troubleshooting and Design Guide authored by CWNE #4 David Coleman and CWNE #7 David Westcott. This is actually chapter 12 of the Certified Wireless Network Administrator Guide (CWNA)

We would recommend buying the CWNA Study Guide to anyone who interested in, or has the responsibility of managing, WLAN. Put it on your shelf next to your copy of "Microsoft Exchange for Dummies" 😬. Read a chapter a day and you'll be amazed how much you'll learn and come to understand about how wireless works.

Either way, take advantage of this free download and the generosity of Aerohive Networks. Way to go guys! 👍


UPDATED: ClearPass Device Profiling Technote

Danny Jump at Aruba Networks has just updated the ClearPass Device Profiling TechNote. He's added in details of the features from the CPPM 6.5 release, such as TCP Fingerprinting, On-demand SUBNET scan, SNMP Updates and the framework developed to allow administrator’s to perform custom device classification of unknown devices. Basically it allows admins to create custom rules from an endpoint using profiled attributes.



Why Site Surveys Matter

There are those that think site surveys are a waste of time, and that Predictive Surveys alone (they are not surveys by-the-way) are enough to get the job done. Sometimes, if the building is new construction, or a very open floorpan, etc. you'll get lucky and things work out. But, as the Tweet above shows, just because a wall looks like it’s regular old drywall, doesn’t mean it is. Site surveys save a lot of heartache by taking as much guess-work as possible out of the equation.

I'm not saying that a full "AP-On-A-Stick" type survey needs to be done throughout the entire facility, but I am saying that you should collect as much data as possible. We do “Predictive Models” here at CommunicaONE for most of our designs. However, we take as much guessing out as we can by performing a site survey at the location we’re designing for.

Things you really want to know: attenuation/loss through walls, glass, tile (is this REALLY just drywall, or is or merely a facade over BRICK?) ; is there RF interference that may cause issues, are there fixtures, appliances, building materials that cause unexpected RF attenuation, reflections, refraction (oh, the 200 gallon fish tank wasn't in the floor plans?), scattering, etc. These are things that can only be known by a site survey. 

The moral here is when designing a WLAN you should get as much information as possible to about the environment you are designing for. Knowing what your building materials are, and what their RF characteristics are, will help go a long way in making WLAN designs as accurate, and successful as possible.

Not everyone has the time, nor can afford the tools needed to properly perform a survey. CommunicaONE can help by performing site surveys, spectrum analysis, and valuable data collection about your existing infrastructure, device types and capabilities, applications, and more, to help make sure that we have as much information as possible to design the best WLAN for your organization.

Hey, it’s a corporate blog, did you not expect a sales pitch? 😏

For a good overview of how to properly determine and document  wall attenuation see Devin Akin's blogpost here.