Wednesday, June 16, 2010

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


3 comments:

  1. Great Review!

    thanks
    Jose Luis

    ReplyDelete
  2. Hi Andrew,

    Would you know the max number of WLANS allowed on HREAPs?

    My WLC is failing when using WLAN ID 17 onwards.

    Cheers,
    Adrian

    ReplyDelete
  3. Hi Adrian,
    All Cisco APs support a maximum of 16 BSSIDs per radio. This is because each radio is assigned 16 unique MAC addresses for use by SSIDs, based off the Base Radio MAC address and changing the last hex character 0-F.

    Only the first 16 WLAN IDs get pushed to APs in the default AP Goup. You cannot change this. If you need to use a WLAN ID higher than 16, you must create a different AP Group and assign WLANs to the group. These can be any WLAN ID, but is still limited to 16 or fewer total WLANs.

    One nice application of this behavior is that if you have a WLAN that you only want pushed to specific APs, you can give it a WLAN ID above 16 and it won't get pushed to all the APs in the default group. It makes it very easy to scope specific WLANs to a unique AP Goup while leaving all other APs in the default group for ease of administration.

    Cheers,
    Andrew

    ReplyDelete