Friday, December 27, 2013

Making Apple's OS X DNS Server Work with IPv6

Just a short post to help others out should they be relying on Apple OS X Server for DNS name resolution in their network. If you happen to also be running IPv6 in your network (and at this point WHY wouldn't you be... seriously!) then you will notice that the OS X server won't respond to DNS queries on any of it's IPv6 interface addresses.

Here's what a packet trace looks like. Notice the OS X server responding to the client DNS query over IPv6 with a "port unreachable" error:

Apple OS X Server DNS Resolution Fails on IPv6 Interfaces

Once this occurs, most clients will attempt name resolution over IPv6 to additional configured IPv6 DNS servers. If all of those servers are Apple servers, then all name resolution transported over IPv6 will subsequently fail as well. Should that happen, then the client falls back to name resolution over IPv4 (which you see in the packet trace with frame numbers 3-6). The OS X server will actually provide both A (IPv4) and AAAA (IPv6) records to the client when queried over an IPv4 interface.

Note: remember that is NEVER a good idea to configure a primary internal DNS server and public backup DNS servers (such as Google, OpenDNS, or your ISP). In this scenario, when your client attempts to resolve internal domain names with your OS X server using IPv6 and fails it will fallback to the public DNS servers using IPv6 which will respond that "no such name" exists. At this point, the client has received a DNS response and will NOT fallback to name resolution over IPv4 to your OS X server. Internal name resolution will break for both A and AAAA records. Not good! Instead, configure your internal DNS server with Forwarders to the public DNS servers.

But, we really should have our DNS servers responding to queries on IPv6 interfaces to provide efficient name resolution, clean up our network traffic, and provide native end-to-end IPv6 services without relying on IPv4 sandwiched in the middle.

Taking a quick gander at the open sockets on the OS X server reveals the issue: it isn't listening for DNS queries on any of it's IPv6 interfaces.

Apple OS X Server Only Listens for DNS Queries on IPv4 Interfaces by Default

We can fix this by simply stopping the DNS service, manually editing the BIND named.conf configuration file, then starting the DNS service again.

First, stop the DNS service through Server App, or through the Terminal by entering this command:

sudo serveradmin stop dns

Next, you'll need to edit the BIND named.conf file through the Terminal:

sudo vi /etc/named.conf

Press 'i' to insert text into the file. Navigate to the "options" section and insert the following anywhere in the option list:

listen-on-v6 {

Press 'Esc' to stop editing the file, then type ':wq' to write the changes to the file and quit the VI editor. The option section should look similar to this when finished:

BIND named.conf Support for Queries on IPv6 Interfaces

Finally, start the DNS service again through the Server App, or through the Terminal by entering this command:

sudo serveradmin start dns

Name resolution on IPv6 interfaces should now work! We can see that the OS X server is listing for DNS queries on IPv6 interfaces:

Apple OS X Server Listening for DNS Queries on IPv6 Interfaces

And a quick test by a client shows that the server is indeed responding properly now:

Apple OS X Server DNS Resolution Now Works on IPv6 Interfaces

As a final note, you can continue to create, modify, and delete name records with the Server App and the BIND configuration file will retain the option to listen on any IPv6 interfaces. So you won't be relegated to manual DNS entry updates through the command line in order to retain full IPv6 name resolution.

Why Apple hasn't enabled DNS resolution on IPv6 interfaces by default is beyond me. But at least you now can fully support your IPv6 network deployment with a DNS service that actually works :)


Friday, November 8, 2013

Referencing Wi-Fi Channel Numbers Correctly

It occurred to me today that many people still use the old Wi-Fi terminology for referencing wide channel numbers in the 5 GHz band. Since channel numbering changed with 802.11ac, I thought it might be helpful to get everyone on the same page when we're talking about channel number.

So here is a quick reference guide to referencing the 5 GHz Wi-Fi channels.

Wide channel numbering changed with 802.11ac:

  • 802.11n Channels (the "old" way)
    • One 20 MHz primary channel, with a channel extension above or below
    • 40 MHz Example: Channel 36, +1
    • 40 MHz Example: Channel 40, -1
    • 40 MHz Example: Channel 36+40
    • This terminology should no longer be used

  • 802.11ac Channels (the "new" way)
    • Reference the center channel frequency for the entire 40/80/160 MHz wide channel
    • Designate one 20 MHz portion of the wide channel as the Primary 20 MHz
    • 40 MHz Example: Channel 38 with Primary 20 MHz channel 36
    • 80 MHz Example: Channel 155 with Primary 20 MHz channel 149
    • 160 MHz Example: Channel 50 with Primary 20 MHz channel 44

Andrew von Nagy

Friday, October 25, 2013

Wi-Fi Alliance Voice-Enterprise Certification: Standardized Fast Secure Roaming

Two of the most important aspects of building a successful modern enterprise wireless LAN are enabling transparent user mobility across the network and strong security to protect sensitive corporate data. 

However, these two objectives have historically been difficult to achieve in tandem. A balancing act between mobility and security has caused an unpleasant trade-off for organizations due to the time-consuming processes that strong security methods require. On one hand, high performance mobility can be provided when relatively weak security is implemented with an Open or WPA2-Personal WLAN, but this leaves sensitive corporate data at higher risk of exposure. On the other hand, much stronger security can be implemented with WPA2-Enterprise, lowering the exposure risk of sensitive corporate data, but resulting in poor mobility performance due to the time-consuming 802.1X authentication process. Thus, the introduction of more secure Wi-Fi networks solved one problem (security) but created another (roaming performance).

The industry needed a high performance, yet secure, solution to this mobility problem. The answer lies with fast secure roaming. Pre-standard solutions, such as CCKM and OKC have been around for some time but have failed to realize widespread adoption, especially by client manufacturers. The Wi-Fi Alliance™ Voice-Enterprise certification program, introduced May 2012 and already appearing in major WLAN products, brings a standards-based fast roaming method to market, which serves to align infrastructure and client manufacturers on a common implementation method and provides the benefits of low-latency roaming performance while maintaining strong security with WPA2-Enterprise.

I dive deeper into the Voice-Enterprise certification program and implementation details of fast secure roaming in the new whitepaper, "Wi-Fi Alliance Voice-Enterprise Certification: Standardized Fast Secure Roaming" [PDF].

Whitepaper: Wi-Fi Alliance Voice-Enterprise Certification
(Click to Download)

Download this whitepaper to learn:
  • Challenges in providing both transparent user mobility and strong security
  • Requirements that products must pass to achieve Voice-Enterprise certification
  • Performance criteria that Voice-Enterprise products must achieve
  • Technical details of the Fast BSS Transition specification, based on IEEE 802.11r, for both controller-based and controllerless WLANs
  • Performance optimizations available with Radio Resource Measurement (802.11k) and Wireless Network Management (802.11v), both part of the Voice-Enterprise program

Friday, October 4, 2013

SSID Overhead - How Many Wi-Fi SSIDs Are Too Many?

One of the most commonly cited best practices among Wi-Fi professionals is to the limit the number of SSIDs you have configured on your WLAN in order to reduce the amount of overhead on the network and to maintain high performance. But there is not a lot of public data out there to really drive home this point when explaining it to another engineer, management, or a customer. Simply telling someone that they shouldn't create more than 'X' number of SSIDs isn't very convincing.

Therefore, I've created a visual tool to help you explain WHY too many SSIDs is a bad thing:

The Wi-Fi SSID Overhead Calculator
(Click Image to Download)
Wi-Fi SSID Overhead Calculator

This tool calculates the percentage of airtime used by 802.11 beacon frames based on the following variables:
  1. Beacon Data Rate - beacon frames are sent at the lowest Basic / Mandatory data rate configured on the WLAN. Beacons must be sent at a "legacy" data rate, meaning only 802.11a/b/g rates. Select the beacon data rate from the drop-down menu within the tool.
  2. Beacon Frame Size - beacon frames can vary in size based on the version of the 802.11 standard implemented (802.11a/b/g/n/ac) and features enabled on the WLAN (such as 802.1X authentication, CCX, 802.11r fast roaming, and 802.11u Hostpost 2.0). I recommend using a wireless sniffer to capture a beacon frame from your WLAN for use within the tool. Enter a beacon frame size that represents the total size of the MAC header and data payload.
  3. Beacon Interval - beacon frames are sent at a default interval of 102.4ms, but this may be modified in most enterprise WLAN products. Note that beacons are always sent at a multiple of the Time Units (TUs), where one TU equals 2^10 Kilomicroseconds (or 1.024 milliseconds). Therefore, 100 TUs equals 102.4ms. Enter the time interval between beacons, in milliseconds.
The calculation includes the inter-frame spacing (using WMM), physical layer preamble and header, MAC layer header, and data payload. It calculates the amount of time required for modulation of the bits over the air, but does not account for collisions or retransmissions. Technically, you wouldn't reach 100% airtime utilization on a Wi-Fi network because medium contention due to collisions and retransmission backoff result in a maximum airtime utilization of around 80-90%. But for SSID overhead planning purposes this level of detail is not required because the network will be equally degraded if we represent it with or without the collisions.

The tool also takes into consideration the number of co-channel APs within the physical area. All access points, either from your WLAN or a neighboring WLAN, contribute to the overhead on the channel. Remember, Wi-Fi operates in unlicensed spectrum and everyone shares the airtime!

I have also included a subjective rating of the amount of overhead into the following categories:
  • 0-10% = Low Overhead
  • 10-20% = Medium Overhead
  • 20-50% = High Overhead
  • >50% = Very High Overhead

You should ALWAYS attempt to keep your WLAN at low overhead (0-10%). 

If you have an existing deployment that falls within the medium overhead range (10-20%) you might consider methods to consolidate SSIDs and reduce the amount of overhead as your WLAN needs evolve over time. 

If you have an existing deployment that falls within the high overhead range (20-50%) you are likely experiencing significant performance problems on your WLAN already and should investigate immediate methods to consolidate and eliminate SSIDs at the earliest possible time.

If you have an existing deployment that falls within the very high overhead range (>50%) it is likely that you are in a highly congested area and will need to coordinate the WLAN configuration with your neighbors in order to reduce the amount of overhead to a reasonable level. This is common in dense urban / downtown areas and in multi-tenant buildings. 

I hope this tool proves useful. Enjoy!


Monday, August 26, 2013

Picking the "Right" Wi-Fi Solution for Your Organization

How should an engineer or IT manager go about picking a Wi-Fi network solution? This can be a complex question to answer and involves evaluating products between multiple vendors or even separate products within one vendor's offering when they offer multiple distinct product lines.

Unfortunately, many customers, partners, and professionals in our industry tend to focus a majority of their time on one factor: speed. My friend Bradley Chambers summed up the inadequacy of speed tests recently when he wrote about his thoughts on Wi-Fi bake-offs, whereby a customer solely focuses on speed tests to pick a Wi-Fi solution:
One of the trends I've been noticing among schools is that they are holding "bake-offs" in order to pick their new WiFi vendor. I am concerned that the majority of these tests revolve around speed. Speed is important, but it's just part of the solution. The speed only test also ignores real world situations.
I agree that it's not all about speed. Wi-Fi chipsets and hardware have come a long way since the early days. It's increasingly hard to differentiate on hardware and speed, as all enterprise Wi-Fi products perform very similarly. The real differentiation and value of Wi-Fi solutions over the next few years will revolve around software innovation. Today, these include mobile device onboarding, dynamic security, location tracking, presence, big data and analytics. Tomorrow, who knows. But you can be assured that software solutions sitting on-top of an intelligent network will be the driving force for Wi-Fi's second-wind, leading to significant market growth over the next 3-5 years.

Bear with me while I ramble on about what I consider the most important aspects to focus on when selecting a Wi-Fi solution. Let me be very clear in saying that this is NOT a comprehensive list -rather it is simply a high-level starting point so you can remain focused on what's most important. Engineers tend to relish the details, writing RFPs that list hundreds of features and get into the minutiae of Wi-Fi technical specifications. That's great, however the Wi-Fi solution must be properly framed in the light of what you're trying to accomplish as an organization and understanding what role mobility plays and how the Wi-Fi network contributes to those broader objectives.

[begin rant] For instance, don't choose a Wi-Fi solution because it's 2% faster than a competing product but it doesn't offer the key feature your business really needs. That's a recipe for disaster! Does that 2% speed bump really matter when management or your business partners can't use the solution in the way they need to?  This underscores a deeper trend that many IT organizations fall into, where they try to force technical solutions into place that don't fundamentally meet organizational needs. This could be due to the familiarity they have with a certain vendor's products, fear of change, or lack of desire to continue learning new and different skills. I've seen too many IT organizations and individual engineers be so head-down into the technology that they fail to lookup to try to understand the solutions that the business is asking for and take the time and effort to research the right technical product fit. It's laziness, pure and simple. I challenge these types of engineers to be better than that! [end rant]

Now that I'm off my soapbox, here is how I recommend you go about picking a Wi-Fi solution:

1.) Suitability - What are the critical features and functionality for your business or environment?
Vendors have tons of features, but only a few are likely to be really critical for YOU! Identify those capabilities that will really enable your WLAN to do what you need it to do. For example: retailers need great guest / social WiFi and analytics; K-12 education needs Bonjour and simplicity; healthcare needs great voice service and location tracking; warehousing needs fast roaming and super high availability; Universities need great BYOD workflow and policies and high density. These are obviously generalizations, but you get my point. Identify the vendor and product that is the best fit for your needs! This comes first, ALWAYS!

2.) Simplicity - How complex (or simplified) is the solution?
When designing the network, how complex is network integration? Do you need an expert to design redundancy, failover, traffic flow optimization, tunneling, security and separation between user and device roles. When problems do arise, which they will with every vendor, how easy is it to diagnose where the problem lies and how to correct it? Or do you need to pay a contractor or VAR to come out and figure it out. Vendors might offer similar capabilities, but how have they built their product to do so? There are a lot of differences under the hood that can make your life easier, or more difficult, which cannot easily be identified through RFP check-boxes. Take the time to dig-in to the solution offerings you are evaluating and run through some sample scenarios that you face everyday. Also try to identify how the solution interacts with the larger network and application environment and how it might be affected by outside influences.

3.) Stability - What is the vendor's (or product line's) track-record for hardware and software stability?
How much QA goes into code releases? Does the vendor expect customers to be beta testers to find bugs? How does the vendor design for high availability and how complex is the setup? How many pieces are part of the architecture that all need to be designed for HA? Does the vendor include functionality inside the WLAN or do they require more servers or appliances to integrate which all require separate design for HA? If a failure does occur, what is the potential scope of impact? Is it one AP, one location, or potentially your entire environment? Does the vendor have a strategy for minimizing the scope of impact? What holes exist in that strategy?

4.) Strategy - What confidence do you have in the vendor's strategy?
How do vendors approach product development? Are they experts in your industry, do they have thought-leaders that really take the time and effort to understand your business problems, where your market is going (not their market), and what solutions will enable customers of your type to succeed? In essence, do they have the customer's needs in mind, or are they twisting the current buzzword soup of the day to match their existing product offerings? There is a big difference! I look for vendors that really understand what I'm trying to accomplish and have tailored product offerings to meet those needs.

5.) Sticker Price - What value do you place on the solution that meets your needs?
Make sure the vendor you choose meets the criteria listed above for suitability, simplicity, stability, and strategy... THEN work on negotiating a price that works for you! Many IT organizations are ill-equipped to evaluate the true value that technology solutions have in their organization due to the fact that they don't adequately understand the impact to the business. IT solutions are increasingly enabling new business services that are required to compete and succeed through market transitions (just take retail and healthcare as two shining examples of this today). Viewing IT spend as an expense-center just doesn't cut it anymore. More often than not, the business teams hold the purse strings and are in a much better position to identify the value IT solutions bring and calculate true ROI. Don't place pricing first, otherwise you could easily end up wasting money on a solution that doesn't meet your needs. If that happens, any amount of money spent is wasted, even if its cheaper than other solutions. You'll end up being dissatisfied and ripping and replacing with another solution.

So, just remember The 5 S's for Evaluating Wi-Fi Solutions:
  1. Suitability
  2. Simplicity
  3. Stability
  4. Strategy
  5. Sticker Price


Monday, August 19, 2013

Wi-Fi Site-Surveying 101

What Is Wi-Fi Site Surveying
Wi-Fi site surveying is a critical component of deploying a successful modern WLAN that meets user expectations and the needs of the organization. The site survey process allows you to understand the unique RF propagation characteristics of the facility and environment into which you are deploying the WLAN. You can validate previously gathered design parameters obtained through predictive modeling using live network measurements to ensure that the deployed WLAN will meet the established coverage, capacity, and performance goals. This section introduces various types of Wi-Fi site surveys and provides guidelines on site surveying to meet the demanding needs placed on a modern WLAN.

This blog series only provides an introduction to site surveying, defining each of the various methods, outlining their objectives, and identifying best practices for success. For more detailed information on different types of site surveys and instructions for performing them, I recommend the CWDP training material provided by CWNP, Inc. For information on using specific software applications to conduct site surveys, refer to the documentation and training supplied by the software vendor.

Remember that a modern Wi-Fi network must not only provide adequate coverage throughout the environment, but must also provide sufficient capacity to meet aggregate demand while simultaneously achieving a high level of application performance and a satisfactory user experience. This is accomplished by maintaining high signal strength and a high SNR for client connections. These two factors allow clients to transmit at maximum data rates, achieve higher application throughput, and reduce individual client airtime utilization. Your Wi-Fi network design should also minimize medium contention by avoiding co-channel interference among both APs and clients and distributing clients and traffic load across the available spectrum. The goal of a site survey is to design and validate that these criteria are being met throughout the entire service area.
Wi-Fi Site Survey Software

Three types of site surveys exist:
  1. Predictive modeling
  2. Pre-deployment (sometimes called “AP-on-a-stick”) surveys 
  3. Post-deployment surveys
I recommend that you perform all three types of site surveys for modern WLANs. However, post-deployment site surveys should always be performed (never eliminate this step)! If peak client density and capacity significantly differ between coverage areas, you might need to gather service requirements for those areas and design individualized Wi-Fi plans for them accordingly. I covered predictive modeling in a previous blog post: Tips for Accurate Predictive Site Surveys. Now, let's discuss pre-deployment and post-deployment site surveys, which have different objectives. I will also discuss Active and Passive surveying techniques that can be used for both pre- and post-deployment surveys.

Site surveys should follow proper requirements gathering and capacity forecasting to meet all design goals for coverage and capacity. You can read more about those topics in my High-Density Wi-Fi Design Series (including three videos: Forecasting AP Capacity, RF Design, and WLAN Configuration Best Practices).

Pre-Deployment Site Surveys
A pre-deployment site survey, often-called an “AP-on-a-stick” survey, is performed before a WLAN network deployment. This type of survey determines the RF signal propagation characteristics of the environment. Measuring and recording the RF behavior in a facility results in a better WLAN design, one uniquely tailored to the physical properties of the environment. You can also use it to verify and adjust a preliminary Wi-Fi network design and to minimize changes to purchase orders once you have procured and installed your WLAN equipment. Spectrum analysis is an integral part of a pre-deployment site survey. Use it to identify and remediate sources of RF interference that could cause WLAN performance issues.

The following are the goals of a pre-deployment site survey:
  • Determine the optimal locations for access point placement
  • Verify coverage in all required areas at the desired minimum signal strength and SNR
  • Ensure that adequate coverage overlap exists for client roaming
  • Establish a baseline of the RF noise floor in each area (using spectrum analysis)
  • Identify sources of RF interference that will impact WLAN performance and require remediation or incorporation into the WLAN design
  • Validate actual client performance (when an active site survey is performed)
Notice that a pre-deployment site surveys includes design criteria prior to deployment of the WLAN infrastructure, such as AP placement. This is one of the major benefits of performing a pre-deployment site survey, because moves/adds/changes are more expensive and time-consuming when identified using a post-deployment site survey.

Post-Deployment Site Surveys
A post-deployment site survey is performed after the WLAN equipment has been installed and configured. This type of site survey reflects the RF signal propagation characteristics of the deployed WLAN. At this point, you have already installed the network equipment, and the focus of the survey is to validate that the installation matches the final network design.

The goals of a post-deployment site survey are
  • Verification of sufficient RF signal strength and SNR throughout the coverage area (this includes spectrum analysis, which is described in the tips section later in this post)
  • Verification of adequate coverage overlap between adjacent Wi-Fi access points for fast roaming
  • Measure and reduce co-channel interference (CCI) among access points operating on the same channels
  • Validate actual client performance (when an active site survey is performed)

The post-deployment site survey provides an opportunity for you to make adjustments before putting the network into production. Perform a passive site survey after deployment to measure RF signal levels from multiple installed WLAN access points as a cohesive system. By doing so, you can validate that the network installation matches the final network design.

Active and Passive Site Survey Techniques
An active site survey is performed when the survey device (a client device) associates to a wireless access point to measure signal strength, noise, bidirectional performance characteristics, and other connection parameters. Measurements are recorded for only a single access point at a time, but they reflect the actual performance characteristics that client devices will experience once the network goes into production. Active site surveys are required to reflect the coverage and performance characteristics for each client device type. For access points that include Transmit Beamforming or smart antenna systems, an active survey should always be performed. However, active surveys do not record information on neighboring Wi-Fi installations that might cause interference. Therefore, active site surveys are best performed prior to WLAN installation during a pre-deployment site survey (“AP-on-a-stick”) to design the internal Wi-Fi network for proper coverage, signal quality, and capacity.

For access points that include beamforming or smart antenna systems, an active survey should always be performed, and signal strength should be recorded from both the client and AP since signal gain due to beamforming only occurs in the downlink direction. A passive survey should also be performed to establish the effective cell size for AP discovery and association by clients since broadcast management traffic does not use beamforming.

A passive site survey is performed when the survey device (a client device) passively scans the RF environment. This type of survey detects all Wi-Fi access points operating within range and measures their received signal strength, noise, and other signal characteristics (depending on the survey application). The survey device typically performs channel scanning across multiple channels in succession to detect access points that are either part of the internal network or belong to neighboring Wi-Fi installations. This method provides detailed information about the interaction among multiple APs regarding channel assignment, coverage overlap, and ACI/CCI (adjacent-channel interference/co-channel interference). It also provides information about multiple virtual SSIDs and SSID availability in various locations. However, passive site surveys do not measure WLAN performance characteristics and can only provide signal strength assessment based on broadcast management traffic like beacons. This approach can also provide an accurate Wi-Fi coverage assessment and cell sizing for access points that use beamforming or smart antenna systems because those APs do not use beamforming to direct management traffic to a single client; they broadcast it. This allows you to perform passive surveys successfully by monitoring management traffic, regardless of whether the APs use beamforming for data traffic.

Passive surveys measure broadcast management frame signal strength, whereas active surveys measure data frame signal strength.

Clients discover and assess access point signal strength for initial association and roaming using either passive scanning of broadcast beacon frames, for which beamforming cannot occur, or through active scanning (probing), which often does not provide a sufficient amount of data to allow beamforming to take effect. Passive site surveys still provide an accurate assessment of Wi-Fi cell sizing for client association and roaming, but not for client performance once connected. Passive site surveys are best performed after WLAN installation, during a post-deployment site survey, to validate Wi-Fi network coverage, channel planning, and ACI/CCI levels.

Active and passive site surveys may be performed either pre or post WLAN network installation. Performing both pre-deployment and post-deployment site surveys is critical to success for a high-density WLAN due to the complex RF design that is required to provide high performance for a large, dense client population.

Site Surveying Best Practices
Follow these guidelines for successful site surveying (in addition to the guidelines for predictive site surveys):

1. Define Coverage Requirements
Before performing the survey, establish the minimum signal strength, minimum SNR, and desired AP coverage overlap requirements the network design must meet in all locations. Recommended values are a minimum -67 dBm RSSI, minimum 25 dB SNR, and 10-20 feet of overlap at these signal levels between APs. These values can be carried over from a predictive site survey, if performed.

2. Survey Both Frequency Bands
Perform the survey primarily on the 5 GHz frequency band to determine optimal AP placement, cell overlap, and co-channel separation. Use the 5 GHz band because at shorter distances between APs, which is typical in high-density environments, the coverage is nearly identical to the 2.4 GHz band. However, 5 GHz signals typically suffer greater attenuation through most RF obstructions and require adequate measurements to ensure sufficient coverage and capacity (no coverage holes!).

The survey must also include signal measurements on the 2.4 GHz frequency band. You can accomplish this while measuring the 5 GHz band if your channel scanning includes both frequency bands for a passive site survey or if you use two Wi-Fi adapters at once during an active site survey. If you cannot survey both bands at the same time, then make a second pass through the environment.

3. Channel Scanning
When performing a passive site survey, configure the survey software to scan only the channels that the production WLAN will be using. The number of channels scanned can affect the accuracy of the sampled data. If you select too many channels, it can take a significant amount of time for the survey software to scan all of them. If you spend an insufficient amount of time at every physical location, then the sampled data will not accurately reflect the location where you recorded it. Monitor the survey software to ensure that you scan all the channels at every sampling location. If performing auto-sampling, also ensure that your walking pace allows sufficient time to scan all channels between each sampling location.

4. Signal Propagation Assessment
Configure the client survey software with the correct signal propagation assessment, which controls how far away from collected data points the software will estimate RF signal quality. The distance should mirror your walking pace if using automatic data sampling or should reflect the distance between manual data sampling locations. In general, shorter signal propagation assessments provide more accurate data but require more data collection points. Use a distance between 10-20 feet (3-6 meters); the smaller the better.

5. Collect Sufficient Data Points
Related to the signal propagation assessment value, be sure to collect enough data points throughout the coverage area during the site survey. Collect them at distances that match the signal propagation assessment value, typically every 10-20 feet (3-6 meters). If you do not collect sufficient data points, the survey will display areas where no measurements were taken within the signal propagation assessment distance. These areas might appear to be without RF coverage and will prevent an adequate assessment of signal strength and coverage for network design validation. To prevent this from occurring, make sure to collect sufficient survey data points; do not increase the signal propagation assessment value!

6. Survey Both Sides of RF Obstructions
For site survey measurements to reflect the signal attenuation characteristics of an RF obstruction accurately, it is necessary to survey on both sides of the object. If you do not, the survey software will attempt to predict the signal loss through an object based only on a pre-defined object type (drywall, for example), which is essentially a guess and might not be accurate. Sampling data on both sides of the obstruction provides accurate RF signal attenuation and signal strength measurements, which are critical to network design as it relates to providing adequate coverage and minimizing co-channel interference. For example, how much coverage and interference will an AP mounted outside an auditorium provide inside the auditorium?

7. Access Point Hardware
Use the exact access point models, antennas, and accessories that will be installed in the production WLAN to ensure accurate measurements of signal propagation and performance characteristics. Access points should be placed in the correct locations, and at the appropriate height and orientation at which they will be used in production.

8. Access Point Configuration
Disable dynamic radio management on the survey APs during the site survey to avoid channel and power changes that could result in incorrect measurements. Configure APs with the transmit power levels that will be used in production or the levels estimated in the preliminary design.

9. Active Site Survey Techniques
When performing an active site survey, use either a production client device operating in site survey mode or configure the survey client radio to mimic a production client device, including power output, power-save, and 802.11n spatial stream settings. Align survey client settings with the least-capable client device considered critical on the production WLAN. This ensures that network performance is adequate for all client devices. If possible, it is advantageous to use multiple client device types that will be used on the production network as part of the site survey process and to test clients in all orientations in which they will be used (for example, landscape versus portrait). Perform the active site survey with only one access point at a time to ensure your client is associated with the correct AP to gather measurements. Configure your survey client to associate exclusively with the BSSID of the survey AP to prevent roaming. (Using only one AP at a time is time consuming; some engineers may opt to use more APs at once to minimize the time required to complete the survey but also risk not gathering sufficient data for every AP location. The choice is yours!)

Ensure that the site survey client captures data at the edge of the contention range for each AP (for example, -85 dBm). This ensures that you collect sufficient data to estimate co-channel interference among multiple APs accurately.

Sometimes active survey data is skewed based on the walking path, typically the path away from the access point. If the data appears to be skewed, perform two active surveys in opposite walking directions and then merge them to obtain more accurate data.

10. Design Validation
Perform 20% of a pre-deployment site survey and then stop to validate the network design against the predictive site survey. If you find significant differences between the measured RF signal propagation characteristics and the predictive model, then adjust the network design to incorporate the newly collected data. This process allows you to identify design changes that could affect AP placements early in the pre-deployment site survey process and can prevent surveying incorrect locations.

11. Spectrum Analysis
Include spectrum analysis in both pre-deployment and post-deployment site surveys to provide a baseline of the RF noise floor in the environment and identify potential sources of RF interference that could negatively affect the WLAN. Use a dedicated spectrum analyzer hardware adapter to provide more accurate data than a Wi-Fi adapter, which typically only guesses RF noise levels based on received 802.11 data frames. Spectrum analysis solutions are available that integrate directly into the same software program used to perform the site survey, simplifying data collection and recording. If you use a separate software program to collect spectrum data, ensure the data is recorded and that it can be accurately mapped back to the original physical locations for future playback and analysis.

12. Documentation
Document the exact installation locations, mounting methods, and non-wireless requirements, such as available switch port capacity and cabling runs from switch closets to AP locations.

Do you have additional tips on site surveying? Please leave your comment below and let's discuss!


Friday, August 16, 2013

Tips for Accurate Wi-Fi Predictive Site Surveys

Predictive Site Survey Software
What Are Predictive Site Surveys
Predictive site surveys use computer-based software programs to model the facility and RF environment. These programs allow you to outline the required coverage areas using facility blueprints; define facility structures to estimate RF signal attenuation; establish thresholds for minimum signal strength and application throughput that clients must achieve; predict the quantity, location, and type of access points that should be installed; and provide channel and power settings that maximize spectral capacity while minimizing co-channel and adjacent-channel interference (CCI/ACI).

The goal of a predictive site survey is to establish design criteria, such as AP quantity and placement with relative confidence. Doing so will then reduce the amount of effort required to perform the typically labor-intensive pre-deployment site survey (“AP-on-a-stick”). One of the major benefits of predictive modeling is the ability to quickly simulate various deployment scenarios and to narrow design alternatives. A predictive site survey will never be 100% accurate, and though it might not replace pre-deployment or post-deployment site surveys, it can help expedite them. When you perform adequate requirements gathering and planning, predictive site surveys can result in a Wi-Fi network design that meets requirements with a high level of confidence. It also provides validation of the forecasted AP capacity from the requirements gathering process and allows you to make adjustments by taking unique facility characteristics into consideration.

There are numerous software-based and web-based predictive site survey applications to choose from:
Predictive site surveys should follow proper requirements gathering and capacity forecasting to meet all design goals for coverage and capacity. You can read more about those topics in my High-Density Wi-Fi Design Series (including three videos: Forecasting AP Capacity, RF Design, and WLAN Configuration Best Practices).

Tips for Accurate Predictive Site Surveys
Follow these guidelines for a successful predictive site surveys:

Blueprint Calibration
Use blueprints that are accurately scaled representations of the facilities or coverage areas in which the WLAN will be installed. Calibrate (or “scale”) blueprints in the modeling software so they represent the correct physical dimensions of the coverage area. If necessary use a known distance between two reference points that are fairly far apart from each other to scale the blueprint as accurately as possible. A small error when defining a short distance between two points on the map results in a more serious error in scale when applied to the entire map than would a small error when defining a large distance. For example, scale the blueprint using the width of the building rather than the width of a cubicle, door, or ceiling tile. 

When importing electronic or scanned blueprints into predictive modeling site survey software, be sure to enter the drawing dimensions accurately. These programs often ask for the dimensions of the entire drawing, not the building or floor plan. The drawings dimensions must take into account any extra whitespace or outdoor areas surrounding a building.

Access Point Equipment Selection
Select the appropriate access point models, antennas, and accessories to use in various areas based on facility characteristics and desired coverage patterns. Document the access point models, mounting and external antenna orientation (if applicable) that have been selected to provide the proper coverage patterns and to minimize co-channel interference.

Transmit Power Levels
Determine appropriate access point power levels based on client device capabilities, which you learned during the requirements gathering process. Configure the access point power output similar to that of the client devices to provide successful bidirectional communication with minimal co-channel interference. Also consider differences in receive sensitivity between APs and client devices, if known, which might allow APs to transmit at slightly higher power than clients.

Access Point Capacity
Estimate the peak client device density in each coverage area to ensure that the planned AP capacity is sufficient to process the client and application throughput load on the WLAN. Use the forecasted AP capacity from the requirements gathering process as a starting point for the number of access points required in the environment or in individual coverage areas if requirements significantly differ between areas.

To learn about the requirements gathering process and how to forecast capacity, read my High-Density Wi-Fi Design Guide (PDF). You may also be interested in watching this short video on forecasting capacity that covers the same information.

Start with a foundation of dual-radio access points to provide a base layer of coverage and capacity for each area. If you need additional capacity, use the techniques described in the “Facility Characteristics” section of my high-density guide to supplement the base WLAN deployment. These techniques include deploying APs with directional antennas, deploying additional APs on 5 GHz, or installing additional APs in locations where RF obstructions will limit signal propagation to augment capacity in specific areas.

Access Point Placement
Determine the proper placement of access points to provide sufficient RF signal strength and coverage overlap between APs. The coverage overlap enables client devices to maintain high data rates throughout the environment and roam effectively. Base the minimum signal strength on client manufacturer recommendations or device specifications for receive sensitivity (minimum RSSI and SNR) needed to achieve the maximum supported data rate. If client receive sensitivity specifications are not published and cannot be acquired from the manufacturer, use a minimum RSSI of -67 dBm and SNR of 25 dB in all locations for planning purposes. 

Given the diversity of client devices in most networks, network designers typically use a minimum RSSI of -67 dBm for multimedia-grade network design as a baseline. 
You can best determine coverage overlap by ensuring that multiple APs provide coverage at the required minimum signal strength at the edge of each AP coverage area to facilitate client roaming. If clients will be moving at a higher speed than the typical pace of someone walking (about 5 MPH/8 KPH), then you might need to increase the amount of coverage overlap to provide sufficient time for AP discovery and fast roaming before the client connection with the initial AP becomes degraded.

Channel Plan
Validate that the dynamic or static channel plan assigns 2.4 GHz and 5 GHz channels optimally to minimize co-channel interference. Co-channel interference is minimized when AP placement provides adequate RF signal attenuation between different access points operating on the same channel. In high-density environments, co-channel interference is often the most significant limiting factor of performance and capacity. If you cannot eliminate co-channel interference, which is likely in the 2.4 GHz band, consider adjusting AP placement. It might be necessary to revise the number of dual-radio APs in the base coverage layer and supplement capacity with additional APs on 5 GHz. Finally, ensure that neighboring Wi-Fi APs are operating on nonadjacent 5 GHz channels to prevent adjacent-channel interference.

The ratio of 5 GHz to 2.4 GHz access point radios in the network design will determine the appropriate band steering ratio for client devices.

3-D Planning
The predictive site survey software should be capable of estimating signal propagation in 3-dimensions, that is, across multiple floors of a multi-story building. This will ensure that co-channel interference is minimized across floors through proper access point placement that is typically not directly above or below one another on adjacent floors and through proper channel planning so that APs that are near one another on adjacent floors are not assigned the same channels.

Compile Your Results
The result of a predictive site survey should include an initial Bill of Materials (BOM), which includes the following items:
  • All access point hardware and accessories, such as antennas, power injectors, and mounting hardware
  • Detailed equipment installation locations and instructions, including proper angling of external antennas
  • Configuration parameters, such as channel assignments and power levels
  • Graphical heat maps of anticipated coverage levels
  • Wired network requirements necessary to support the WLAN infrastructure, such as switch port capacity, speed, and PoE

In the next post, I'll cover on-site verification of the predictive model as well as how to perform pre-deployment site surveys in either active or passive modes. Stay tuned!


Tuesday, August 13, 2013

Setup an IPv6 Tunnel through Hurricane Electric on a Cisco Router

I've setup my home network with an IPv6 tunnel through Hurricane Electric. The process is pretty straight forward and I'll share my learnings with you in this post.

How a Manual IPv6-in-IPv4 Tunnel Works
Using an IPv6-in-IPv4 tunnel through Hurricane Electric is useful when your current ISP doesn't offer native IPv6 service or tunneled 6rd service yet. In this case, you need to tunnel IPv6 traffic across an intermediate IPv4-only network (or the Internet). I setup my tunnel broker account through HE as an initial step in learning IPv6 prior to switching to the IPv6 service offered from my current ISP (CenturyLink). In a future post, I'll describe setting up the CenturyLink 6rd tunneling service, which will be slightly different.

The HE tunnel broker service uses a manually configured IPv6-in-IPv4 tunnel. It's pretty straightforward to understand how this works. You will define an IPv4 tunnel source (your local dual-stack router's WAN interface), an IPv4 tunnel destination (the HE dual-stack router), and a default route on your local router that directs all IPv6 traffic across the tunnel. All IPv6 traffic will be encapsulated inside an IPv4 packet and sent across the IPv4-only network. When the frame reaches the tunnel destination router the outer IPv4 header is stripped off and the IPv6 packet is forwarded to it's destination.

Manual IPv6-in-IPv4 Tunnel

There are a few things you'll need before you get started:
  • A static IPv4 address from your ISP - preferred for a manual IPv6-in-IPv4 tunnel so the tunnel destination router can encapsulate return traffic back to your local router. You can use a dynamic IPv4 address, but it requires updating the tunnel definition every time it changes (see this FAQ).
  • A dual-stack capable router - in my case, I'm using a Cisco router. 
Setting Up the Tunnel Broker Service
There are a few steps involved in setting up the tunnel broker service.
  1. Create an account at
    Enter a username and password in the login box and click the "Register" button. Fill in your information to complete the process.

  2. Create a new tunnel
    Click the "Create Regular Tunnel" link in the User Functions section. You'll need to enter the IPv4 address of your local router's WAN interface, which must be a publicly routable Internet address (not a private RFC 1918 address). Then select a tunnel server from the list below. This will be the tunnel destination router that Hurricane Electric provides to terminate your tunnel service. I recommend selecting the closest server to your location for lowest latency performance. Click the "Create Tunnel" button on the bottom of the form.

    Hurricane Electric Regular Tunnel Creation
  3. View your tunnel details
    You will need to take note of a few items that will be used when configuring your local router:
    - Server IPv4 Address - will be used as the IPv4 tunnel destination.
    - Server IPv6 Address - for reference only as the IPv6 tunnel endpoint.
    - Client IPv4 Address - will be used on your local router's WAN interface as the tunnel source.
    - Client IPv6 Address - will be used on your local router's tunnel interface to establish a neighbor relationship with the server's IPv6 address on the other end of the tunnel.
    - Routed /64 - this is the /64 network prefix that you can use internally on your local network for IPv6 capable hosts.
    - Available DNS Resolvers - you can use these ISP provided IPv6 DNS capable servers to lookup IPv6 resources on the Internet (such as web servers, mail servers, etc.). Or you could alternatively use any public IPv6 DNS servers (such as OpenDNS or Google).

    Hurricane Electric Tunnel Details
  4. Optionally - assign a /48 prefix to your local network
    If you need more than one IPv6 routed prefix on your local network, Hurricane Electric can assign you an entire /48 prefix, which will be routed across the tunnel. You can then break into smaller network prefixes for use on multiple links in your local network. To assign a /48 prefix, click the "Assign /48" link.
Setting Up Your Cisco Router for IPv6
Next, we'll need to configure your local Cisco router.

First, enable IPv6 routing and Cisco Express Forwarding (CEF):

ipv6 unicast-routing
ipv6 cef

Second, you'll want to create a tunnel interface for the link to the Hurricane Electric tunnel broker service.

interface Tunnel0
 description Hurricane Electric IPv6 Tunnel Broker

 # No IPv4 address will be on the tunnel interface
 no ip address

 # Enable IPv6 on the interface
 ipv6 enable

 # Assign a Global Unicast Address to the Tunnel interface.
 # Use the Client IPv6 Address assigned to you by Hurricane
 # Electric. This will allow your router to establish a neighbor
 # relationship with the other tunnel endpoint router,
 # referenced as Server IPv6 Address.
 ipv6 address 2001:470:XXXX:XXXX::2/64

 # Set an IPv6 MTU that adjusts for the 20-byte IPv4
 # encapsulation caused by the tunnel. This prevents
 # dropping packets and sending back an ICMP 
 # Packet-too-Big error. I have a PPPoE link and reduce
 # the MTU another 8-bytes. 1500-20(IPv4)-8(PPPoE) = 1472.
 ipv6 mtu 1472

 # You may want to secure your local network using an
 # IPv6 ACL and traffic inspection. I'll cover these in 
 # a subsequent post.
 ipv6 inspect v6firewall in
 ipv6 inspect v6firewall out
 ipv6 traffic-filter v6Outside_ACL in

 # Configure the tunnel mode as a manual IPv6-in-IPv4 tunnel.
 tunnel mode ipv6ip

 # Configure the tunnel source and destination IPv4 endpoints.
 # The tunnel source is the IPv4 address on your local router's
 # WAN interface. The tunnel destination is Server IPv4 Address
 # provided by Hurricane Electric.
 tunnel source 63.224.XXX.XXX
 tunnel destination

Next, install a default route for all IPv6 traffic originating from your local network to traverse the tunnel.

ipv6 route ::/0 Tunnel0

Configure a stateless DHCPv6 server to assign IPv6 DNS servers and a domain suffix to clients so they can resolve hostnames to IP addresses. A stateless DHCPv6 server does not hand out IPv6 addresses to clients or maintain a binding database. In my setup, I'll be using SLAAC to allow clients to autoconfigure addresses on the local link based on the prefix(es) advertised by the router in ICMP Router Advertisements. You can use the ISP provided DNS servers or any public server as mentioned previously.

ipv6 dhcp pool DHCPv6
 dns-server 2001:470:20::2

Configure a local LAN interface with the routed IPv6 network assigned to you by Hurricane Electric. This may be the /64 prefix originally assigned to your network or a smaller portion of a /48 if you requested one (break the /48 into smaller /64 prefixes for multiple internal network links). This interface is typically a dual-stack interface, meaning it will support both IPv4 and IPv6 clients. This is important to allow clients to continue to use IPv4 to access services which are not yet available over IPv6.

interface FastEthernet0/0
 ip address
 ip nat inside
 ip virtual-reassembly in

 # Enable IPv6 on the interface
 ipv6 enable

 # Configure the assigned /64 prefix from Hurricane Electric
 # on the local LAN interface.
 ipv6 address 2001:470:XXXX:XXXX::1/64

 # Advertise a smaller IPv6 MTU than the default 1500 bytes
 # in order to account for tunnel overhead. The minimum IPv6
 # MTU is 1280 bytes and is a safe bet. This prevents dropping
 # packets due to IPv6 tunneling mechanisms.
 ipv6 mtu 1280

 # Advertise the ability for clients to configure other
 # parameters such as DNS by setting the other-config-flag
 # in Router Advertisements.
 ipv6 nd other-config-flag

 # Assign the previously defined DHCPv6 server to this interface.
 ipv6 dhcp server DHCPv6

The configuration of the IPv6 MTU on the local LAN interface is important because Path MTU discovery often does not work across the Internet when stateful security devices block ICMP Packet-too-Big error messages. Even if your tunnel supports a higher MTU than the minimum 1280 bytes, such as 1472 bytes, you may run into situations where some IPv6 Internet resources still require a smaller MTU because tunneling occurs elsewhere along the route.

Testing It All Out
Once you've got your tunnel established and local LAN configured, let's test it out.

Ping from your WAN interface across the tunnel. This will verify IPv6 reachability across the tunnel between the two tunnel endpoints.

cisco-router#ping 2001:470:XXXX:XXXX::1   
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:470:XXXX:XXXX::1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms

Connect a client to your local LAN. This will verify that a client is properly receiving an IPv6 address from your router. Here is an example using an Apple MacBook Pro connected to an IPv6 network over Wi-Fi:

Apple MacBook Pro IPv6 Network Connection
You will notice that the Cisco router sends Router Advertisements (RA) using it's link-local address in the fe80::/16 address block. Embedded in the RA is information about the network prefixes configured for the link, whether or not clients should use auto-configuration (SLAAC) to obtain an address, and the other-config-flag related to stateless DHCPv6 for DNS and domain suffix assignment. Most modern clients will auto-configure two global IPv6 addresses: one using the EUI-64 format based on the Ethernet MAC address on their interface, and one using the auto-generated random method for security and privacy. Hosts will typically prefer the random address when initiating sessions with other hosts.

vonNagyMBP13:~ andrewvonnagy$ ifconfig en1
en1: flags=8863 mtu 1500
ether 68:xx:xx:xx:1b:f0 
inet6 fe80::6axx:xxff:fexx:1bf0%en1 prefixlen 64 scopeid 0x5 
inet6 2001:470:XXXX:XXXX:6axx:xxff:fexx:1bf0 prefixlen 64 autoconf 
inet6 2001:470:XXXX:XXXX:4d2f:7cb8:221c:f6a1 prefixlen 64 autoconf temporary 
inet netmask 0xffffff00 broadcast
media: autoselect
status: active

You can also check the DNS settings on the host to ensure stateless DHCPv6 worked properly.

Apple MacBook Pro IPv6 DNS Server(s) and Domain Suffix

Next, ping the remote tunnel endpoint from the local LAN host across the tunnel. This will verify the routing for your assigned network prefix is working properly across the tunnel. Tip: be sure to use the correct ping6 command on Mac OS X!

vonNagyMBP13:~ andrewvonnagy$ ping6 2001:470:XXXX:XXXX::1
PING6(56=40+8+8 bytes) 2001:470:XXXX:XXXX:4d2f:7cb8:221c:f6a1 --> 2001:470:XXXX:XXXX::1
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=0 hlim=63 time=35.977 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=1 hlim=63 time=33.656 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=2 hlim=63 time=32.902 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=3 hlim=63 time=35.838 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=4 hlim=63 time=35.926 ms
--- 2001:470:1F10:36::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 32.902/34.860/35.977/1.313 ms

You might want to try resolving a AAAA DNS record:

vonNagyMBP13:~ andrewvonnagy$ dig @2001:470:20::2 AAAA

; <<>> DiG 9.8.1-P1 <<>> @2001:470:20::2 AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 14297="" font="" id:="" noerror="" opcode:="" query="" status:="">
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0


;; ANSWER SECTION: 52 IN AAAA 2607:f8b0:4009:802::1010

;; Query time: 38 msec
;; SERVER: 2001:470:20::2#53(2001:470:20::2)
;; WHEN: Tue Aug 13 15:24:33 2013
;; MSG SIZE  rcvd: 60

Finally, try hitting an IPv6 test website. A good one for North America is the North American IPv6 Task Force website. Look for the image of a turtle in the right sidebar along with detection of the IPv6 address being used by your host. You can also try hitting the Google IPv6 test webpage or


Additional IPv6 posts you might be interested in:

Friday, May 31, 2013

Apple iOS Fast Roaming with Aerohive Wi-Fi APs

Well folks, after what seems like an eternity, true standards-based Wi-Fi fast roaming is really here! I blogged back in December that Apple iOS version 6.01 added support for fast roaming with 802.11r and 802.11k. And WLAN infrastructure vendors have added support as well, with Aerohive 6.0 and Cisco 7.2 code releases.

Recently, I had the opportunity to test this functionality out on an iPhone 5 and an iPad mini with an Aerohive WLAN. I'd like to share my results with you... and I can tell you that you won't be disappointed! How do 8.5ms roams sound?!

Apple iPad Fast Roaming (1) and Aerohive AP Neighbor Report (2)
As you can see, the iPad completes the roam in 8.5ms, the time it takes to complete the 802.11 authentication and reassociation; no full 802.1X authentication, RADIUS TLS session resumption, or even 4-way handshake are required! This is the result of support for the Wi-Fi Alliance Voice-Enterprise certification on both the WLAN and client. In the tests that were captured, the WLAN was configured for WPA2-Enterprise with 802.1X authentication and dynamic keying. The initial client association resulted in a full 802.1X authentication with the RADIUS server, followed by fast roams as shown above.

Roaming with 802.11r (Fast BSS Transition) is noticeably faster than other proprietary fast-roaming methods (OKC/PKC) and it's also faster than roaming on a Pre-Shared Key (PSK) WLAN. This is because the 4-Way Handshake exchange can be eliminated by embedding the key derivation material (ANonce, SNonce, MIC, and GTK) within the Fast Transition Information Element inside the 802.11 Authentication and Reassociation frames. There is also a Mobility Domain IE that comes into play to distinguish boundaries between different WLANs (since key material must be exchanged between APs on the backend, two separate WLANs cannot facilitate fast roaming).

Here's a look at the Fast Transition IE inside the Reassociation Response (frame 18) from the AP to the iPad:

802.11r Fast Transition Information Element

You may want to review my previous post on The Many Variations of Wi-Fi Roaming to compare the frame exchanges required with each roaming method, CWNP's whitepaper on Fast BSS Transition [PDF] and blogs (here and here) to understand the key hierarchy and exchange between the initial AP authenticator (PMK-R0) and subsequent APs (PMK-R1).

Immediately after the fast roam completes, the Apple iPad submits a Neighbor Report Request within a Management Action frame. In essence, the client is requesting a list of all the neighbors from the AP in order to build a list for future roaming events. This report can be requested on-demand by the client and can help improve roam times by reducing or eliminating the need for the client station to actively scan off-channel. This way, the client has a list of nearby APs that is always up-to-date and can quickly move to another channel where it knows another AP is waiting.

Here is a look inside the Neighbor Report sent back to the iPad from the Aerohive AP (frame 21):

802.11k Neighbor Report
Unfortunately, Wireshark does not yet have a protocol dissector for 802.11k neighbor reports, so manual decoding must be performed. You can see that the Category Code is 5 (Radio Measurement) is used. Inside the tagged parameters lies the neighbor report details, which contains an element for each neighboring AP in the same WLAN and details about the AP such as it's BSSID and channel number which I have highlighted above. In this case, there is one neighboring AP with BSSID "08:ea:44:78:14:28" and it is operating on channel 161 (0xA1 in hexadecimal). Other information in the report includes AP's reachability, security policy (similar or different), and capabilities for spectrum management, quality of service, power save, block acknowledgements, and PHY type (802.11a/b/g/n).

There are three IEEE 802.11 amendments that come into play which are all bundled up in the Wi-Fi Alliance Voice-Enterprise certification.

Standards and Certification Recap
The core of fast roaming was drafted in the IEEE 802.11r amendment, defining "Fast BSS Transition"  or just Fast Transition (FT) for short. The name is derived because every individual AP radio cell is defined as a "Basic Service Set (BSS)" in the standard, and the amendment defines a method for client stations to transition (also called roaming) very fast between AP radios. It accomplishes this by defining a Mobility Domain comprised of a set of BSSs (APs) within the same Extended Service Set (ESS, otherwise known as an SSID) which have been validated. Validated APs must coordinate with each other to exchange client station details, including pairwise master key (PMK) encryption material, and perform pre-authentication of the client prior to the roam. This speeds the client roam by eliminating the need to re-authenticate the client through 802.1X/RADIUS or having to perform the 4-Way Handshake to derive pairwise transient key (PTK) encryption key material even in the case of a simple PSK network. The 802.11r amendement was ratified in 2008.

The IEEE 802.11k amendment on "Radio Resource Measurement" defines methods for information exchange about the RF environment between APs and client stations. The goal is to enable the client stations to understand the radio environment in which they exist so that they have more information to make correct decisions about roaming and performance. Stations can take radio measurements locally, request measurement by other stations, or have measurement requested of them and return the results. One interesting aspect for fast roaming is the Neighbor Report, where a client can request an AP to measure and report the neighboring APs which are available within the same Mobility Domain, including several pieces of operational information about each neighbor such as: BSSID, channel, security policy, and capabilities for QoS, APSD (power-save), BlockAck, spectrum management, and PHY type (802.11a/b/g/n). Some other reports available with 802.11k include: channel load, noise histogram, location configuration information, link measurement, and traffic stream measurements. The 802.11k amendment was ratified in 2008 as well.

The IEEE 802.11v amendment on "Wireless Network Management (WNM)" defines methods for stations to exchange information for the purpose of improving overall performance of the wireless network. Where 802.11k is concerned only with the radio environment, 802.11v expands it to include broader operational data surrounding existing network conditions allowing stations to be more cognizant of the topology and state of the network. There are a multitude of WNM services, the most interesting (for me, at least) is the BSS Transition Management capability, whereby an AP can request a client to roam to another AP for better performance or capacity. Some other services include: co-located interference, diagnostic reporting, directed multicast services, location services, multiple BSSID capability, proxy ARP, QoS traffic capability, and traffic filtering service, to name only a few. The 802.11v amendment was ratified in 2011.

Each of these amendments define numerous capabilities, of which I will only scratch the surface in this post to highlight a few. If you are interested in learning more about the services defined in each of the amendments, visit the IEEE Get Program website to download the 802.11-2012 standard, or search the web for PDF versions of each amendment.

Aerohive WLAN Configuration
Prior to being able to test and execute a fast transition (FT) roam, you need to configure the WLAN infrastructure to support the 11r/k/v features. In Aerohive HiveManager, navigate into the Configuration section and edit the SSID on which FT roaming should be supported. In the Advanced section of the SSID configuration you will see two sections, one for WMM and one for Voice Enterprise.

Aerohive Voice-Enterprise Configuration (IEEE 802.11r, k, v)

Upon checking the first check box for Voice Enterprise, you will be presented with the following notice, informing you that Voice-Enterprise requires 802.11rkv and WMM AC-Voice which will all be enabled automatically.

You may have also noticed the note which states 802.11r requires WPA2 key management. This is because 802.11r advertises FT support in-part through the Authentication and Key Management (AKM) suites in the Robust Security Network (RSN) Information Element, which was included in the 802.11i amendment and WPA2 certification program. Pre-standard WPA did not include the RSN IE and therefore cannot support fast transition. So make sure you're using WPA2 (with either 802.1X or PSK) on the SSID as well.

Save and upload this configuration to at-least two APs, which will then begin including the Mobility Domain IE, Fast Transition IE, and Radio Management capabilities in beacons and probe responses to advertise these capabilities to clients.

Note - no explicit configuration is required to enable Voice-Enterprise on Apple iOS devices. Simply run iOS 6.01 or later and join a Voice-Enterprise enabled WLAN.

Client Limitations
In addition, the RSN IE which advertises encryption ciphers and authentication and key management (AKM) methods in-use on the WLAN to clients now includes a new AKM type to advertise Fast Transition key management. Some existing client drivers have issues parsing the RSN IE with additional AKM and will fail to association to the WLAN - in fact, they won't even try. Until client drivers are updated by manufacturers to support this addition AKM type, they will be unable to join any SSID that has Voice-Enterprise (specifically 802.11r) enabled.

Therefore, it is recommended to create a separate SSID specifically for Fast Transition capable clients and migrate them over to the new SSID.

Final Thoughts
Wi-Fi roaming performance has been a painful sore spot on the industry for many years. Problems were initially obscured through the use of open or WEP encrypted networks where roaming was relatively fast due to the simple security models implemented. However, as security improved with 802.11i and WPA2-Enterprise, roaming performance became a glaring issue, often taking >500ms or worse! This impacted the usability of real-time applications on an enterprise WLAN, forcing many network administrators to rely on less-secure PSK security methods.

Some vendors responded with proprietary fast roaming methods such as CCKM, OKC, and PKC. However, this served to fragment the industry and support for these methods were spotty at best. The IEEE thankfully stepped in and ratified the 802.11r amendment in 2008, yet it has taken nearly 5 years since then for enough momentum to build to finally implement standards-based testing and certification of fast roaming through the Wi-Fi Alliance Voice-Enterprise certification program.

However, now that standards-based fast roaming is here, IT IS GLORIOUS! I applaud Apple for being an advocate for fast roaming and implementing it into their iOS platform, likely because their devices get blamed for poor performance all the time. I encourage other mobile device manufacturers to follow suit, especially if their devices are used with real-time voice or video applications.