H-Reap factoids as of 11/2010

Taken from the H-REAP deployment guide:


The CAPWAP, on which Cisco's Unified Wireless Network architecture is based, specifies two different primary modes of wireless access point operation:


Split-MAC—In Split-MAC mode, the system shares key functions of the 802.11 specification between the access point and the controller. In such a configuration, the controller is not only responsible for much of the processing of things such as 802.11 authentications and associations, it also acts as the single point of ingress and egress for all user traffic. Split-MAC access points tunnel all client traffic to the controller via an CAPWAP data tunnel (CAPWAP control also follows the same path.).


Local MAC—Local MAC, in implementing full 802.11 functionality at the access point, allows for the decoupling of the data plane from the control path by terminating all client traffic at the wired port of the access point. This allows not only for direct wireless access to resources local to the access point, but it provides link resiliency by allowing the CAPWAP control path (the link between AP and controller) to be down while wireless service persists. This functionality is particularly useful in small remote and branch offices across WAN links where only a handful of access points are needed and the cost of a local controller is not justified.


H REAP WAN Considerations
Because the H REAP has been designed specifically to operate across WAN links, it has been optimized for such installations. Though H REAP is flexible when it comes to these remote network design scenarios, there are still a few guidelines that need to be honored when architecting a network with H REAP functionality.


Hybrid REAP supports up to four fragmented packets or a minimum 500-byte maximum transmission unit (MTU) WAN link.


Roundtrip latency must not exceed 300 milliseconds (ms) for data and 100 ms for voice and data between the access point and the controller, and CAPWAP control packets must be prioritized over all other traffic.


The controller can send multicast packets in the form of unicast or multicast packets to the access point. In hybrid-REAP mode, the access point can receive multicast packets only in unicast form.


In order to use CCKM fast roaming with hybrid-REAP access points, you need to configure hybrid-REAP groups.


Hybrid-REAP access points support multiple SSIDs.


NAC out-of-band integration is supported only on WLANs configured for hybrid-REAP central switching. It is not supported for use on WLANs configured for hybrid-REAP local switching.


Note: During an upgrade, each AP needs to retrieve a 4 MB code update across the WAN link. Plan upgrades and change windows accordingly.


In order to ensure that support for this stated latency limitation is in place, it is strongly recommended that between the access point and controller, priority be configured in the intermediary infrastructure to elevate CAPWAP (UDP port 5246) to the highest priority queue available. Without priority placed on CAPWAP control, spikes in other network traffic can very likely cause H REAP access points to frequently shift from connected to Standalone modes as WAN link congestion prevents access point/controller messages (and keep-alives) from being delivered. It is highly recommended to Network designers, who plan to deploy HREAP AP over WAN links, to test all their applications.


Frequent H REAP flapping causes serious connectivity issues. Without proper network prioritization in place, it is prudent to place controllers at remote sites to ensure consistent and stable wireless access.


Note: Whether H REAP is configured to tunnel client traffic back to the controller or not, the CAPWAP data path is used to forward all 802.11 client probes and authentication/association requests, RRM neighbor messages, and EAP and web authentication requests back to the controller. As such, ensure that CAPWAP data (UDP port 5247) is not blocked anywhere between the access point and controller.


Hybrid 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 CCKM, WLAN, and backup RADIUS server configuration information. This feature is helpful if you have multiple hybrid REAP access points in a remote office or on the floor of a building and you want to configure them all at once. For example, you can configure a backup RADIUS server for a hybrid REAP group rather than having to configure the same server on each access point. For each controller, you can configure up to 20 hybrid REAP groups with up to 25 access points per group.


To Trunk or not to Trunk
H REAP access points may be connected to 802.1Q trunk links or untagged access links. When connected to a trunk link, H REAP access points send their CAPWAP control and data traffic back to the controller via the native VLAN. Locally switched WLANs may then have their traffic dropped on any available VLANs (native, or otherwise). When set to operate on an access link (with no 802.1Q visibility), H REAP s forward all CAPWAP messages and locally switched user data out to the single, untagged subnet to which it is connected.


General guidelines for the selection of the switchport mode for H REAPs are as follows:
Use a trunk link if more than one WLAN is configured for local switching and if traffic on these SSIDs needs to be dropped on different subnets. Both the access point and the upstream switchport need to be configured for 802.1Q trunking. The configuration of H REAPs for 802.1Q trunking is the most common configuration and provides the most flexibility. Native VLAN also needs to be configured on the switchport that the H REAP is connected to as all CAPWAP communication between the AP and the WLC is on the native VLAN.


Use an access link when H REAPs either do not have more than a single locally switched WLAN or have multiple locally switched WLANs that do not require wired-side separation. Be aware that a trunk link can still be desirable under these conditions if separation between CAPWAP messaging and user data is desired. But, this is neither a configuration requirement, nor a security risk.


Note: H REAP access points default to operate on untagged, access link interfaces.


Radio Resource Management (RRM)
Transmit Power Control (TPC) algorithms in RRM are not triggered until four or more access points are within range of each other. So, some H REAP installations might never power their radios down. As such, without ever being able to power down their radios in the first place, H REAPs do not adjust transmit power upward to compensate in the event of a coverage hole detection.


In Standalone mode, RRM functions on H REAPs that require controller processing are not supported.


Note: H REAP was not designed to provide location services. Therefore Cisco cannot support stated location accuracy claims in H REAP deployments.


L2 and L3 Mobility
Roaming events between H REAPs on locally switched WLANs may take between 50 ms and 1500 ms, which depend on WAN latency, RF designs and environmental characteristics, as well as security types and client-specific roaming implementations.


Layer 3 roaming is not supported for locally switched WLANs but is supported for centrally switched WLANs.


Other H REAP Limitations
H REAPs do not support WGB.


If you have configured a locally switched WLAN, then Access Control Lists (ACLs) do not work and is not supported. On a centrally switched WLAN, ACLs is supported.


Any changes to a locally switched WLAN configuration on the Controller cause a temporary loss in connectivity as the new configuration is applied to the H REAP. As such any clients on these locally switched WLAN get temporarily disconnected. The WLAN is enabled right away and the clients re-associate back.


The controller can send multicast packets in the form of unicast or multicast packets to the access point. In hybrid-REAP mode, the access point can receive multicast packets only in unicast form.


Per @samuel_clements there is no limit to the number of H-REAP APs that are supported in newer versions of controller code.  Seconded by @revolutionwifi & link to a good discussion on H-REAP provided by @IndTechTalk

The H-REAP feature matrix document is also quite useful.