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