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