H-REAP limitations

[Roman Rodichev]

40 locations, around 20-30 APs per location, 1 gig back from each site to the main site, minimizing cost. Client wants support of remote site survivability and reducing network loading. This implies H-REAP. We can't put controllers at each location due to cost. I'm thinking two 6506's with dual sups and three WISMs in each. My concern is HREAP. Here are some thoughts, let me know if you can think of some other limitations/issues.

* Enterprise SSID central auth / local switching, Guest SSID central switching / central auth

* If WAN goes down, Guest SSID will not be available.

* If WAN goes down, limited local authentication for Enterprise SSID will be available.

* With local switching L3 roaming is not supported, so if some location is using Layer 3 to the closet, this solution will not work.

* Location services? Design guide states "H-REAP is not designed to provide location services, so Cisco will not support location accuracy claims in H-REAP deployments." Have anyone implemented H-REAP with location services?

* RRM is fully supported in H-REAP (have anyone found it to be otherwise?)

* L2 CCKM fast-roaming is supported

* 20 H-REAP groups per controller with up to 25 in each group. Is this limitation still in place on latest 6.x code? If a site has more than 25 APs, I would create two or more H-REAP groups per site.

* Regarding 20 H-REAP groups per controller limitation, I believe this will create a problem for N+1 controller redundancy. If, let's say, one controller is used for redundancy for all APs, that controller would need all H-REAP groups configured on it which would exceed the 20 H-REAP group limitation. Am I correct to assume that with H-REAP support you need 2*N redundancy?

* Any other limitations?

[rahdeshp]

You pretty much covered everything. Here are just a few updates:

1. You can now do local authentication by creating users on the AP itself or using an external RADIUS server o n the local site. The local RADIUS server will be used if the WAN link is down.

2. When you enable multicast in H-REAP mode, only the unicast delivery of the packets is supported. This means that the controller makes a unicast delivery of the packets to the APs as opposed to the APs subscribing to the mcast group to receive packets from the controller.

[scott.stapleton]

I have looked at a similar (although larger) centralised H-REAP deployment and found the controllers unable to support such a deployment. The limitations show that H-REAP has not been designed for such large deployments and as per the Cisco H-REAP guide, has been designed for a small number of branch offices.

SPOF: As you mentioned, the controllers are a single point of failure as you would want all of the controllers to contain all of the H-REAP groups which does not appear possible.

RRM: You cannot adjust DCA & TPC per H-REAP group - the settings are controller-wide.

RADIUS: Maximum of 17 RADIUS servers. Not an issue if you have centralised authentication - we do not however.

Model of controller: We would either require a rack of 5508s or utilise 4400 WiSMs in 6500s. I would obviously prefer modules but I do not wish to utilise 4400s with the 5500s out. Hopefully a 5500 module for the controller comes out in the near future. A capacity of >250 on the 5500 would be good also.

QoS: Cisco recommends QoS over the WAN to prioritise controller packets and sub 100ms from H-REAP to controller. Possibly not an issue for yourself.

Roaming: Does not support Proactive Key Caching and presumably also Opportunistic Key Caching.

I really wish this sort of deployment was feasible however I have my fingers crossed that it will be in the future.