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.
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.
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
Andrew, thanks for your excellent post !
ReplyDeletethis a way perfect, do you have the same analysis For Aruba Networks ?
ReplyDeleteThat is a great post. Did you test the throughput of hreap AP?
ReplyDeleteHi Keith,
ReplyDeleteYes, I have tested TCP throughput on a 1252 H-REAP around 144 Mbps, versus about 130 Mbps in Local mode. So there does seem to be a bump in performance with H-REAP.
Andrew
Hi,
ReplyDeleteIt is true that the cisco can supports dynamic vlan assignment with hreap configured in local-switching mode?
I can be reached at samuel.yip@live.com
No, H-REAP access points do not support dynamic VLAN assignment (also called AAA Override). This is a current limitation once the AP is put into H-REAP mode, no matter how the WLAN traffic is forwarded.
ReplyDeleteI have an outstanding feature request open with Cisco WNBU to add this capability. No timelines yet.
Andrew
Great post. Curious about your thoughts on the controller-less solution from Aerohive? Other vendors are beginning to downplay the controller I've noticed (Cisco HREAP, Aruba RemoteAP, Motorola WING), but according to my research, Aerohive is the only WLAN vendor to provide AP coordination without a controller at all. Am I right about that? Seems like a refreshing approach.
ReplyDeleteI have not yet evaluated the Aerohive solution, but have some gear that I will be looking at soon. I'll be sure to post my thoughts on their product.
ReplyDeleteAerohive has an advantage because they were able to develop their product without existing product roadmaps and feature sets to support and upgrade along the way. It does seem like a refreshing approach, and I am curious to see how their system scales to large environments.
Xirrus does something similar, with a controller in every AP and coordination among multiple APs. Motorola is trying to get their with their WiNG product but will take some time.
Look for Cisco and Aruba to make some headway in this area in 2011 as well. I think we'll see some big announcements from those two in 1H2011.
Cheers,
Andrew
Really good info.
ReplyDeleteWhy must the latency not exceed 2 seconds (v. 7.0.1160.0 & later) when using H-REAP Local Authentication? Does that refer to H-REAP Standalone or H-REAP Local Switching?
ReplyDeleteHi Andrew
ReplyDeleteAny feedback on your outstanding feature request open with Cisco WNBU to add this capability?
We're about to roll out wi-fi throughout our campus including remote sites and would like to use central authentication with local switching.
Please reply. I can be reached at cbagley@nmmu.ac.za
The WAN latency between an H-REAP AP and the controller comes into play for two reasons.
ReplyDeleteFirst, authentication timers on clients; they expect to have authentication complete within a reasonable amount of time, and if not then they will assume it has failed and try to reconnect and start the authentication process over. 300ms is the guideline for central authentication through the WLC, since most EAP types take several round-trip packet exchanges. PEAP can be 8 round-trips for full auth, and 4 round-trips for TLS session resumption, for instance. When the H-REAP AP performs local auth, then it is also acting as the RADIUS server and WAN latency does not come into play.
Second, the AP and WLC maintain a heartbeat timer every 30 seconds. The AP expects a response from the controller within 2 seconds, otherwise it sends up to 5 more hearbeat packets at 1 sec. intervals. The WAN latency can affect the responsiveness of the heartbeat communications and can cause the AP to disconnect from the controller and go into standalone mode.
Cheers,
Andrew
Hi Cheslin,
ReplyDeleteCisco WNBU has still not added AAA Override support within H-REAP (now FlexConnect). This is still an open feature gap.
Andrew
Hi Andrew,
ReplyDeleteYou have stated that the "CAPWAP utilization overhead is 400-500 bps". Could you kindly point me to a Cisco doco that specifies the same pls?.Searching high and low for this but could not still get my hands on one.
Thanks,
Hi,
ReplyDeleteThis Cisco LWAPP Traffic Study has the WAN bandwidth utilization that you are looking for.
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a0080901caa.shtml
Regards,
Andrew
Hi Andrew,
ReplyDeleteThanks for the post.
I am having issues here in my network where all 500 APs in H-REAP mode. And we are noticing the loop in to the network?
I understand as per CISOC guidlines there should no more then 25.
Would you able to advise me,by having 500 APs in one group, what effects it would have on network?
Cheers,
N
Hi,
ReplyDeleteIf you are violating Cisco deployment guidelines and placing more than 25 H-REAP APs into a single H-REAP Group, then you should be prepared to experience problems.
You should contact Cisco TAC for support and recommendations to remediate your issue.
Regards,
Andrew
Hi Andrew,
ReplyDeleteWe have a controller located at remote site where WAN latency 300ms or more. All remote sites have APs running in HREAP mode.
Local controller at remote site is primary controller for the APs at remote site and centrally located controller is secondary controller for the APs at remote site.
When we initiate fail-over from primary controller (local) to secondary controller (central with 300ms or more WAN latency) AP fail-over works fine however when AP gets associated to central controller the clients connected to the AP gets disconnectes and re-authetication takes place. So fail-over is not seamless.
Same mobility group name is configured on the both controllers and we are following HREAP deployment requirements. Should we be expecting seamless fail-over in this scenario?
Thank you.
If you have code version 7.0 or later, and both controllers are configured exactly the same, then failover between local and remote should not cause a client re-authentication. Be sure that the APs are running in H-REAP mode even when connected to the local controller at the site. If they are running in Local mode and failover the central WLC and have to switch to H-REAP mode, then it will result in a service outage.
ReplyDeleteAlso, the H-REAP APs must have the secondary controller already discovered and maintained in its backup controller list. Ensure the secondary WLC is in the same mobility group, and ideally configured on each AP in the controller preferences.
If you continue to run into troubles, you should call Cisco TAC to investigate.
Cheers,
Andrew
Hi Andrew
ReplyDeleteThank you for useful info and I really enjoy reading it. We have deployed H-reap with two centralized controllers at two different locations. We have tried to do load sharing by dividing groups to both controller. Do we need to all H-reap groups on both controllers even there are no APs on other controller in that group? In case of fail over if they go from group of one controller to default group of other, what will be impact?
Yes, you should make the configurations identical on both controllers, except for things that must be different like interface IP addresses. All H-REAP Groups should be configured on both controllers, so that when an AP fails over to the backup controller, it will still function as desired. You will also need to ensure that all APs are added to the H-REAP Groups on both controllers as well. It is easy to add them to the group on their currently connected controller, just select each AP from the drop-down list within the H-REAP Group to add them. On the backup controller, you will have to add each AP manually by entering the AP MAC address.
DeleteCheers,
Andrew
Are you sure it is neccesary to add the APs manually to the secondary controller ?
DeleteI would asume that it just joins the seondary WLC and brings in its own AP configuration. (show derevied config on HREAP-AP) shows that there is local config even though it is in HREAP connected mode. I know asumptions is the root for all "#$"#$ups :D
I also Wonder if you just configure the HREAP-group name on the primary controller The AP would tell the secondary controller what group it belongs to when it has joined. Because it should already know as it is configured this way before its primary WLC goes offline for some reason.
I have seen however that not only the SSID configuration needs to be the exact same (same SSID,security and ID) but also the profile name. Agree with that ?
regards. Kristjan
Kristjan,
DeleteNo configuration is replicated between controllers. You would have to manually configure the information on both. A central network managements system like Prime NCS could be used to configure templates that include the MAC addresses of all APs in each group and related H-REAP group settings and push it out to multiple controllers. But it's still fairly manual.
Andrew
Maybe this is obvious, but the "vlan select" feature is not supported with H-REAP.
ReplyDeleteHi Andrew,
ReplyDeleteGreat post with an awesome summary! H-REAP/FlexConnect features change pretty quickly. Here is a link from cisco.com which does a pretty good job summarizing the feature support and limitations for H-REAP/FlexConnect in Central/Local Switching or Standalone mode.
http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080b3690b.shtml
Kindest regards,
Troy
Hi Troy,
DeleteYes, the H-REAP / FlexConnect solution continues to evolve. You may be interested in reading my post on that feature matrix as well:
http://revolutionwifi.blogspot.com/2010/09/h-reap-feature-matrix.html
I find it best to review the release notes for each Cisco software release to remain up to date on the changes. Not exactly all of the changes make it into the release notes, but most of the major ones do. That way it's easier to remain on top of the changes in an incremental fashion, rather than trying to figure out what changed from a year ago and three releases ago :)
Cheers,
Andrew
Hi Andrew,
DeleteSorry, I missed that post....and certainly agree with you. I must admit though, I prefer your summaries to the matrix and release notes.
Kindest regards,
Troy