Can somebody help me with explanations about why is not recommended HREAP in a LAN environment???
Im sure about the use of HREAP in a branch office, but one of my customers now is asking me about HREAP for use in a LAN in case of failure of the WLC. Im not very sure this is a good idea but im finding help and tips about that. I think for faiolver purposes in a LAN environment is better to have a secondary WLC.
You better check limitations of HREAP. There are some limitations you will face. You better check HREAP documents for that. I am only remembering that WGB use is not supported with HREAP. and CCKM limitation when clients roam among HREAP & local APs.
U cd find many useful answers to ur question if u search this forum.Gd luck.
Sent from Cisco Technical Support iPad App
Amjad is on target with the HREAP limitations. Although some of the past limitations (hurdles) have be improved on in newer controller releases. Roaming being one of them ..
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.
An H REAP access point can be deployed with either a static IP address or a DHCP address. In the case of DHCP, a DHCP server must be available locally and must be able to provide the IP address for the access point at bootup.
H 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 H REAP mode, the access point can receive multicast packets only in unicast form.
In order to use CCKM fast roaming with H REAP access points, you need to configure H REAP groups.
H REAP access points support multiple SSIDs.
NAC out-of-band integration is supported only on WLANs configured for H REAP central switching. It is not supported for use on WLANs configured for H 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 H REAP 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.
In order to better organize and manage your H REAP access points, you can create H REAP groups and assign specific access points to them. All of the H 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 H 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 an H REAP group rather than having to configure the same server on each access point.
Controller software releases 220.127.116.11 and later contain two new H REAP group features:
Backup RADIUS server—You can configure the controller to allow an H REAP access point in standalone mode to perform full 802.1X authentication to a backup RADIUS server. You can configure a primary RADIUS server or both a primary and secondary RADIUS server.
Local authentication—You can configure the controller to allow a H REAP access point in standalone mode to perform LEAP or EAP FAST authentication up to 20 statically configured users. With Controller software release 5.0 onwards, this has been increased to 100 statically configured users. The controller sends the static list of usernames and passwords to each H REAP access point when it joins the controller. Each access point in the group authenticates only its own associated clients. This feature is ideal for customers who migrate from an autonomous access point network to a CAPWAP H REAP access point network and do not need to maintain a large user database nor add another hardware device to replace the RADIUS server functionality available in the autonomous access point.
Controller software releases 18.104.22.168 and later contain these new H REAP group features:
Local authentication—This feature is now supported even when H REAP access points are in Connected Mode.
OKC Fast Roaming—H REAP Groups are required for CCKM/OKC fast roaming to work with H REAP access points. Fast roaming is achieved by caching a derivative of the master key from a full EAP authentication so that a simple and secure key exchange can occur when a wireless client roams to a different access point. This feature prevents the need to perform a full RADIUS EAP authentication as the client roams from one access point to another. The H REAP access points need to obtain the CCKM/OKC cache information for all the clients that might associate so they can process it quickly instead of sending it back to the controller. If, for example, you have a controller with 300 access points and 100 clients that might associate, sending the CCKM/OKC cache for all 100 clients is not practical. If you create an H REAP Group comprising a limited number of access points (for example, you create a group for four access points in a remote office), the clients roam only among those four access points, and the CCKM/OKC cache is distributed among those four access points only when the clients associate to one of them. This feature, along with Backup Radius and Local Authentication (Local-EAP), ensures no operational downtime for your branch sites.
Note: CCKM fast roaming among H REAP and non-H REAP access points is not supported.
Refer to the Configuring Hybrid-REAP Groups section of Cisco Wireless LAN Controller Configuration Guide, Release 7.0 for more information on how to configure H REAP groups.
Thanks George the knowledge abouth the hreap limitations is a great tip, but making a personal question for you and Amjad. Do you recommend to configure the APs in HREAP mode if i have only a LAN environment???
I have a LAN environment with 24 APs with a WLC 5508 now the APs are configured normally but my customer is asking about the HREAP configuration like failover method for WLC fail posibility.
Its a good question.
I wouldn't consider it and here is why.
1) You have more control with access points connected to your WLC rather than HREAP local.
2) It allows for easier trouble shooting and design -- shaping of your traffic at the WLC -- great for policy shaping
3) Simple switch port configs at the edge. HREAP requires trunks
4) The possible roaming hurdles if you go HREAP
You may want to open a ticket with TAC and asked them as well. I bet they could also point some other challenges as well.
George and All,
A point of correction. You don't need to trunk for HREAP. Trunk is only required if the wireless clients will be on different VLAN from the AP. If you use a single VLAN, Access mode on the switch port will not affect HREAP on the AP.
In a deployment with more then 1 ssid you would want to map them to different vlans.
I wrote a long reply and it is lost due forum in maintenance when I tried to post it.
To summarize what I wrote:
If ur network is critical then do no t use HREAP to avoid any future unexpected issues.
If it not that critical then you may give it a try on few access points and monitor the situation. If it works correctly for enough period then it is good.
But imagine for some reason ur WLC goes faulty and needs RMA, then during the period without WLC U will not be able to do any modification on ur config.
The below link is useful to decide what is supported and what is not with HREAP.