HREAP in a LAN environment

Unanswered Question
Mar 29th, 2012

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
Amjad Abdullah Thu, 03/29/2012 - 10:25

Luis:

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.

Amjad

Sent from Cisco Technical Support iPad App

George Stefanick Thu, 03/29/2012 - 10:55

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 ..

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080736123.shtml#Design

H REAP Design and Functional Limitations

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.

  • 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.

Hybrid REAP groups

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.

HREAP-Table.gif

Controller software releases 5.0.148.0 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 7.0.116.0 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.

lperez.megasupply Thu, 03/29/2012 - 11:21

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.

George Stefanick Thu, 03/29/2012 - 11:40

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.

grabonlee Thu, 03/29/2012 - 12:09

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.

Amjad Abdullah Thu, 03/29/2012 - 17:27

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.

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080b3690b.shtml

Amjad

Actions

Login or Register to take actions

This Discussion

Posted March 29, 2012 at 7:12 AM
Stats:
Replies:7 Avg. Rating:
Views:679 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard