The Shift to Smart APs is on the Horizon

In my last two posts, I detailed Cisco's Hybrid REAP mode of operation.

H-REAP is a feature attempting to fill a critical gap in the controller based wireless architecture. Due to the high expense of deploying controllers at all locations, many organizations are unwilling to make the shift to controller architectures. H-REAP attempts to reduce this reliance on distributed controllers by pushing more functionality back into the access points. Unfortunately, this feature as it stands today is too complex and too limited to be truly scalable and provide the availability many organizations now require for wireless network operation and SLAs.

The industry moved from “Fat APs” which provided minimal or no coordinated services among each other, to controller-based models with “Thin APs” that pushed both management and data plan operations to the controller with a Split-MAC architecture. The downfall of the controller-based model is the reliance on increasingly larger and larger hardware controllers, with specific AP licensing and support limits. This only serves to drive costs astronomically high for large enterprises, especially organizations with a large quantity of distributed remote offices, such as in the Retail industry.

The move to limit the reliance on the controller for network operation is required by these customers, and the wireless industry is being forced to migrate back towards what I call a “Smart AP” model. This will be a hybrid approach where controllers perform centralized management, configuration deployment, monitoring, statistics collection, reporting and alerting on the environment. The Smart APs will perform all 802.11 network functions (no more Split-MAC), client authentications, and all functionality required for the network to operate. Controllers will be placed in centralized data centers or NOCs, the network will function with high availability even if the controller is not reachable, and the required hardware investment in controllers will be dramatically reduced.

Only then will truly viable remote office solutions be practical when deploying controller-based architectures. If this doesn’t happen soon, there will be tremendous opportunity for smaller market vendors with traditionally strong vertical industry presence to gain market share. Aerohive offers a completely controller-less architecture, as Devin Akin eloquently rants. He’s absolutely right, the time has come for either controller-less networks or at-least “less-controllers”!

Along that same line, Motorola recently gave an excellent preview for my organization on their Adaptive AP roadmap. I have to give them credit, I liked what I saw and will be anxiously awaiting beta code for evaluation in our lab.

Andrew

H-REAP Deployment Guidelines and Feature Limitations

Updated on 2011/04/17 based on 7.0 J-MR1 code release enhancements (7.0.116.0)

In my last post, I detailed the business case for the Hybrid REAP mode of operation on Cisco wireless access points, and provided an overview of H-REAP operation. In this post, I will build on those basic fundamentals and provide more depth on the recommended deployment guidelines if you're thinking about deploying H-REAP for remote sites. Additionally, feature limitations when using this mode of operation need to be clearly understood by network administrators prior to evaluating and deploying an H-REAP solution.

H-REAP Deployment Guidelines

First, several guidelines are recommended for successful deployment. Administrators should design a solution around these requirements as best as possible.

§  WAN bandwidth must be at minimum 128kbps

o   CAPWAP utilization overhead is 400-500 bps

o   CAPWAP utilization with rogue detection and client location could be 2-3 kbps

o   Code upgrades put largest strain on WAN bandwidth when pushing a ~4MB code image to each AP

§  WAN latency must not exceed 100ms roundtrip (version 5.2 and prior), 300ms (version 6.0) and 2 seconds (version 7.0.116.0 and later when using H-REAP Local Authentication of clients).

§  WAN MTU must be larger than 500 bytes because H-REAP APs only support up to 4 IP fragments

§  If H-REAP APs are in the same H-REAP Group but connected to different controllers, all controllers should be in the same mobility group

H-REAP Failover Operation

Failover

When entering standalone mode, the H-REAP access point maintains client connectivity without interruption for all locally switched WLANs. If H-REAP groups with backup RADIUS servers or local authentication is enabled, new and roaming clients can be authenticated and join the network. CCKM clients can use cached keys if established prior to the APs going into standalone mode, since the controller is required to distribute key IDs to all the H-REAP APs in a group. Clients on web-auth WLANs maintain connectivity as well, but the WLAN cannot accept new connections.

Fallback

In versions prior to 7.0.116.0, when re-establishing a connection with a controller using the primary discovery timer (30 sec. in 4.2 and earlier, 120 sec. default in 5.0 and later), the H-REAP access point disassociates all clients, reboots, re-joins the controller, re-applies the configuration from the controller, and re-allows client sessions in connected mode.

In version 7.0.116.0 and later, when re-establishing a connection with a controller using the discovery timer, the H-REAP access point is able to maintain seamless client connectivity during the re-join process.

H-REAP Feature Limitations

Unfortunately, H-REAP does not provide feature parity with full Local mode AP operation. The following features are not supported when running APs in H-REAP mode, whether the AP is connected or standalone. Administrators should understand these limitations when architecting a wireless network for remote offices, and may preclude the use of H-REAP if one or more of these features are critical to wireless network service in your organization.

§  AAA Override is not supported with H-REAP

§  Static PMK caching (per-AP) is not supported for fast roaming with H-REAP

§  Workgroup Bridges are not supported for use with H-REAP access points

§  H-REAP Groups limited to 20 groups per controller

o   Increased to 100 groups in WLC version 7.0 J-MR1 and later with a 5500 controller

§  H-REAP Groups can only contain 25 APs each

§  Multicast traffic forwarding requires the Unicast mode of operation

§  Peer-to-Peer Blocking is not supported with H-REAP locally switched WLANs

§  IPv6 Bridging is not supported with H-REAP locally switched WLANs

§  VideoStream (MediaStream multicast direct) is not supported with H-REAP

§  CCKM/OKC roaming between H-REAP and non-H-REAP APs is not supported

§  NAC out-of-band integration is not supported with locally switched WLANs

§  Passive client feature (version 7.0 code) is not supported with AP Group VLANs

§  Cisco Integrated Security Features have limited support with H-REAP.

o   MAC Flooding attack prevention is fully supported

o   DHCP Rogue Server attack prevention is supported for wired clients when DHCP snooping is enabled on the switch, but is not supported for H-REAP wireless clients.

o   DHCP Starvation attack prevention is supported with DHCP snooping with MAC address verification is enabled on the switch.

o   ARP Spoofing attack prevention is supported for wired clients when DHCP snooping and Dynamic ARP Inspection are enabled on the switch, but is not supported for H-REAP wireless clients.

§  Fortress Layer 2 encryption on a locally switched WLAN requires the “Learn Client IP Address” box to be un-checked, otherwise the controller periodically drops the client connection because it cannot learn the client IP address

H-REAP Standalone Mode Limitations

In addition to feature limitations that apply to all H-REAP operational states, the following limitations also apply when the AP goes into standalone mode after losing connection to the controller.

§  CCKM/OKC fast roaming is only performed for existing keys that were created when the AP was in connected mode to the controller.

o   New keys created once in standalone mode cannot be distributed between the APs in an H-REAP Group without a controller.

§  H-REAP Groups only support local authentication using LEAP and EAP-FAST for up to 100 users when in standalone mode (PEAP and EAP-TLS are not supported)

§  NAC and IDS integration are not supported when in standalone mode

§  RRM features are disabled when in standalone mode (DFS/TPC is still supported, however)

§  CCX layer 2 roaming features for clients are not supported in standalone mode (AP assisted roaming, enhanced neighbor list request (Intel E2E), roam reason report, directed roam request)

§  Bandselect will not function if an H-REAP AP is rebooted while in standalone mode

§  Multicast traffic forwarding is not supported in standalone mode

§  Error reports cannot be forwarded to the controller when in standalone mode

§  Peer-to-Peer Blocking is not supported in standalone mode

§  RLDP rogue connections are not supported in standalone mode

§  Rogue containment is not supported in standalone mode

§  Infrastructure MFP validation is not supported in standalone mode (Client MFP is supported)

§  IPv6 bridging is not supported in standalone mode

§  Link Latency Troubleshooting is not supported in standalone mode

§  Location services are not supported in standalone mode

§  CleanAir features are not supported in standalone mode

§  L3 seamless roaming is not supported in standalone mode (requires mobility tunneling)

§  WLC ACLs are not supported in standalone mode

§  TSPEC bandwidth reservation (part of WMM QoS) is not supported in standalone mode

Andrew

Hybrid REAP Overview

H-REAP (hybrid remote edge access point) is useful for corporations with many small remote sites requiring wireless networks. Since the industry shifted to controller-based architectures, solutions for remote offices have been difficult for many customers, including retail corporations such as the one I currently am employed with. Many customers have found it difficult to justify the large (even enormous) additional expense of distributed controllers at each and every remote site.

H-REAP attempts to fill this gap by allowing corporations to deploy centralized controllers and distribute more brains of system back into the access points. However, the controller typically still performs some level of data-plane operations and is not solely limited to management plane functionality. Some vendors have bucked this trend and have designed solutions that are fully distributed with no controller required. Cisco's approach to this problem has continued to evolve since their Airespace acquisition and jump into the controller architecture.

H-REAP enables customers to configure and control access points in a branch or remote office from the corporate office through a wide area network (WAN) link without deploying a controller in each office. The hybrid-REAP access points can switch client data traffic locally and perform client authentication locally when their connection to the controller is lost. When they are connected to the controller, they can also send traffic back to the controller.

However, this feature still has a significant amount of limitations compared to their current controller-based architecture with Local mode APs. Additionally, many different authentication and traffic forwarding scenarios exist which make H-REAP deployment somewhat complex. Here is a rundown of some of the basics.

Authentication and Traffic Forwarding

WLANs can be locally switched from the AP or tunneled back to the controller. This setting is global for each WLAN. Clients are authenticated centrally through the controller. If the controller connection is lost, clients can also be authenticated locally by the AP, either through backup RADIUS servers if they are configured for the H-REAP group, or through Local EAP on the AP (limited to LEAP and EAP-FAST). 

Note that client authentication is ALWAYS performed by the controller if the AP can establish a connection to the controller.

H-REAP Operational Modes

     1. Connected Mode – the AP can reach a controller

     2. Standalone Mode – the AP cannot reach a controller

H-REAP Operational States

1.       Central Authentication, Central Switching (Connected Mode)

a.       Controller handles client authentication

b.       Client data is tunneled back to the controller

2.       Central Authentication, Local Switching (Connected Mode)

a.       Controller handles client authentication

b.       Client data is switched locally by the AP into trunked VLANs on the access layer switch

3.       Local Authentication, Local Switching (Standalone Mode)

a.       AP handles client authentication using backup RADIUS servers

b.       Client data is switched locally by the AP into trunked VLANs on the access layer switch

c.        Valid for Open, Static WEP, and WPA/WPA2-PSK

d.       Valid for 802.1x and CCKM if backup RADIUS servers are defined on the H-REAP group or on an individual AP

e.        Never valid for web authentication, which is always performed at the controller

4.       Authentication Down, Switching Down (Standalone Mode)

a.       AP disassociates existing clients and stops sending beacons and probe responses

b.       Valid for centrally switched WLANs when the AP goes into standalone mode, including web-auth WLANs

5.       Authentication Down, Local Switching (Standalone Mode)

a.       AP rejects new client authentications, but continues sending beacons and probe responses to keep existing clients alive. Once client count reaches zero, the AP stops sending beacons.

b.       Valid for locally switched WLANs when the AP goes into standalone mode, including web-auth WLANs, and when no backup RADIUS servers are defined

H-REAP Groups

In order to better organize and manage your hybrid-REAP access points, you can create hybrid-REAP groups and assign specific access points to them.

All of the hybrid-REAP access points in a group share the same backup RADIUS servers, CCKM, and local authentication configuration information. This feature is required for CCKM to work on H-REAP access points. Backup RADIUS servers can also be configured on individual APs, which override the group configuration if present.

Whew! It takes a few passes to understand all of that, doesn't it. Now, try designing a remote site solution to take into account all the possibilities and architect a stable solution. Easier said than done.

In my next post, I'll detail H-REAP deployment guidelines and some of the H-REAP feature limitations you should be aware of.

Andrew

It's Time for 802.11r

It's been just shy of 2 years now since the IEEE ratification of the 802.11r amendment in July 2008, and there is little sign of vendors, either infrastructure or client, moving to implement it.

Perhaps this is a testament to the value of pre-standard fast roaming techniques such as CCKM and Opportunistic Key Caching (OKC). OKC has been available on Windows platforms since Windows XP, albeit administrators were required to install a special package (KB917021). Funk Odyssey has also included support for OKC for quite some time prior to their purchase by Juniper. CCKM, meanwhile has only been implemented by a marginal subset of client vendors due to the more proprietary nature of the protocol, and usually only when pushed by large customers with Cisco infrastructures.

However, the value of a standards-based fast roaming method cannot be underscored. It's value will be tremendous with the growth and adoption of voice of wireless technologies, especially as ABI Research and Gartner have released studies predicting large adoption of VoWiFi and Fixed Mobile Convergence (FMC) in the enterprise by 2014. Smartphone adoption of WiFi is set to explode as well.

http://www.abiresearch.com/press/1465-Enterprise+FMC+Will+Grow+at+a+CAGR+of+27%25,+Reaching+Over+27+Million+by+2014

http://www.wi-fi.org/news_articles.php?f=media_news&news_id=795

http://www.abiresearch.com/press/1579-802.11n+To+Feature+in+87%25+of+Wi-Fi-Enabled+Smartphones+in+2014

Also, I am disappointed by the slow progress of the WiFi Alliance in developing interoperability certifications for fast roaming. They have been talking about releasing the Voice-Enterprise certification for some time, but have been slow to act in developing this program. They have released the Voice-Personal certification, but that only includes testing of voice quality on single access point, and does not include enterprise-grade equipment with multiple access point deployments requiring client roaming. What's the deal WiFi Alliance, let's get this program moving!

I am encouraged by some recent developments by the largest wireless vendor, Cisco. In their latest release of controller code just last week, version 7.0 includes the ability to enable 802.11r fast BSS transition on a per-WLAN basis. Kudos to Cisco for stepping out in front and putting a stake in the ground saying "let's get this technology moving people." Now it's time for other vendors to follow (I'm talking to you client vendors!!!).

Here are the commands to view and configure the 802.11r fast roaming in WLC 7.0 code:

(Cisco Controller) >show wlan 6


Security
802.11 Authentication:........................ Open System
Static WEP Keys............................... Disabled
802.1X........................................ Disabled
Wi-Fi Protected Access (WPA/WPA2)............. Enabled
WPA (SSN IE)............................... Enabled
TKIP Cipher............................. Enabled
AES Cipher.............................. Disabled
WPA2 (RSN IE).............................. Enabled
TKIP Cipher............................. Disabled
AES Cipher.............................. Enabled
Auth Key Management
802.1x.................................. Enabled
PSK..................................... Disabled
CCKM.................................... Enabled
FT(802.11r)............................. Disabled
FT-PSK(802.11r)......................... Disabled
FT Reassociation Timeout......................... 20
FT Over-The-Air mode............................. Enabled
FT Over-The-Ds mode.............................. Enabled


(Cisco Controller) >config wlan security wpa akm ?


802.1x Configures 802.1x support
cckm Configures CCKM support
psk Configures PSK support
ft Configures 802.11r fast transition 802.1x support


Now, everyone, let's get moving on this! The business need is upon us, let's not let WiFi be the barrier to new and exciting service opportunities.

Andrew

P.S. - For an overview of 802.11r Fast BSS Transition, see the excellent CWNP whitepaper of the same title (free account registration required).

http://www.cwnp.com/index/training/freeresources/whitepapers

802.11 Medium Contention

I highly recommend that wireless professionals, new or seasoned to the field, watch this video about 802.11 medium contention by Meru's CTO. Bharghavan goes through the basics of medium contention in random access networks (versus controlled access networks such as token ring/bus, TDM, etc.). He does a great job of explaining in simple terminology how the standards define the protocol operation, and then goes further to relate the importance and advantage of some of Meru's proprietary enhancements that work within the standard.

I've had the pleasure of getting an in-person presentation by the Meru staff and they definitely have innovative technology. 


Much of the content in this video is equivalent to a Master's degree level course I took in Data Communications and Computer Networks. I encourage individuals to learn and develop the protocols of the future to investigate graduate degree programs in these types of fields.


Graduate Lectures on Data Communications and Computer Networks (lectures 5-6 cover IEEE 802.3 and 802.11 medium contention):
http://www-users.cselabs.umn.edu/classes/Fall-2012/csci5211/index.php?page=lecture%20slides

Wi-Fi Toolkit Suggestions?

I work for a large corporation, and so have little need or use for a
dedicated wireless toolkit. Sure, I use most wireless tools on an
regular basis, but have nothing packed into a toolkit. By toolkit, I'm
speaking about a grab-bag of essential Wi-Fi tools, software, and
accessories that consultants and contractors have packed at all times,
ready to pickup and go on an assignment at a moments notice without
foreknowledge of the situation they're being called into.

I've started a list, but would like tips from engineers using such a
toolkit in their everyday routine.

Please post your favorite items in the comments section. I'll post my
compiled list once finalized.

Thanks,
Andrew

AP Image Pre-Download

Starting in WLC code version 6.0, new unified code images can be pre-downloaded to wireless access points to reduce network impact during the upgrade process. The current primary or backup boot images on the controller can be selected to pre-download to the access points.

In addition, each access point now holds a primary and backup image in flash to facilitate failover in the event of a corrupt image and for easier image swapping between multiple versions.

Currently, these features are only available through the controller CLI.

To configure AP image pre-download, perform the following from the controller CLI:

1. View the current controller images
   
   show boot
   
   (cciewlc) >show boot
   Primary Boot Image............................... Code 6.0.188.0 (active)
   Backup Boot Image................................ Code 6.0.182.0  
   
   
2. View the current AP images:
   
   show ap image { all | ap-name }
   
   (cciewlc) >show ap image all
   
   Total number of APs.............................. 1
   Number of APs
           Initiated....................................... 0
           Predownloading.................................. 0
           Completed predownloading........................ 0
           Not Supported................................... 0
           Failed to Predownload........................... 0
   
                                           Predownload   Predownload
   AP Name     Primary Image  Backup Image Status        Version      Next Retry Time  Retry Count
   ----------- -------------- ------------ ------------- ------------ ---------------- ------
   CCIELWAP001 6.0.188.0      0.0.0.0      None          None         NA               NA
   
   
3. Pre-download a new primary or backup image to an AP. Specify the controller’s current primary or backup image to pre-download to the AP:
   
    config ap image predownload { primary | backup }{ all | ap-name }
   
    Note – If the selected image is already present on the AP as its primary or backup image, the image will not be downloaded to the AP.
   
   
4. View the progress of the image pre-download:
   
   show ap image { all | ap-name }
   
    (cciewlc) >show ap image all
   
   Total number of APs.............................. 10
   Number of APs
           Initiated....................................... 4
           Predownloading.................................. 5
           Completed predownloading........................ 1
           Not Supported................................... 0
           Failed to Predownload........................... 0
   
                                              Predownload     Predownload
   AP Name      Primary Image  Backup Image   Status          Version     Next Retry Time  Retry Count
   ------------ -------------- -------------- --------------- ----------- ---------------- ------
   CCIELWAP001  6.0.188.0      6.0.182.0      Complete        6.0.182.0   NA               NA         
   CCIELWAP002  6.0.188.0      0.0.0.0        Predownloading  6.0.182.0   NA               NA         
   CCIELWAP003  6.0.188.0      0.0.0.0        Predownloading  6.0.182.0   NA               NA         
   CCIELWAP004  6.0.188.0      0.0.0.0        Predownloading  6.0.182.0   NA               NA         
   CCIELWAP005  6.0.188.0      0.0.0.0        Predownloading  6.0.182.0   NA               NA         
   CCIELWAP006  6.0.188.0      0.0.0.0        Predownloading  6.0.182.0   NA               NA         
   CCIELWAP007  6.0.188.0      0.0.0.0        Initiated       6.0.182.0   NA               0          
   CCIELWAP008  6.0.188.0      0.0.0.0        Initiated       6.0.182.0   NA               0          
   CCIELWAP009  6.0.188.0      0.0.0.0        Initiated       6.0.182.0   NA               0          
   CCIELWAP010  6.0.188.0      0.0.0.0        Initiated       6.0.182.0   NA               0      
   
   
5. Swap primary and backup images on an AP. The AP must be rebooted after swapping images for the new primary image to be used during runtime.
   
   config ap image swap { all | ap-name } 

Also, watch for future enhancements to allow image staging off an existing access point or other local TFTP/FTP server. This can reduce image download times to access points by locally staging an image on an AP or server rather than traversing a low-bandwidth, high-latency WAN connection to download the image from a centralized controller.


Andrew

Wi-Fi Tip: Server Validation

In order to ensure that an attacker cannot impersonate the approved
network infrastructure AAA server, enable client-side server validation.

This setting instructs the client to compare the presented server
certificate credentials during EAP phase 1 to the list of approved
servers, and to only continue the authentication process if connecting
to a valid server.

This can prevent RADIUS server impersonation by tools such as
FreeRadius-WPE.

Support for this feature varies between vendors.