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