Some notable items include:
- No PMK/OKC/PKC fast roaming support.
This is a big disappointment, especially considering H-REAP does support Cisco's proprietary CCKM fast roaming. Hopefully they're working on this as well as 802.11r Fast BSS Transition support.
- No Spectrum Intelligence on 3500 series APs.
Considering this is built into the AP and is not a controller function, lack of support is surprising. I can see why reporting and trending through the WLC and WCS would be interrupted in standalone mode, but I would think spectrum intelligence base functionality should be available for admins to connect remotely to the AP and analyse the airspace.
Update: Just to clarify, CleanAir spectrum intelligence does work in H-REAP connected mode, but does not work in H-REAP standalone mode since the WLC aggregates and reports on the interference data.
- No Workgroup Bridge support
I was not aware of limitation previously! If you support autonomous WGBs, then H-REAP is NOT the solution for you at this point.
- Supports DFS/TPC (802.11h) even in standalone mode
This is critical to maintain compliance with FCC regulations to avoid radar in the 5GHz band. Kudos to Cisco for being one of the few vendors with support for DFS channels, allowing administrators greater spectrum to work with to increase client and network capacity.
Overall, a few interesting new findings in this document. It is definitely not comprehensive though, so don't use this as your only source for H-REAP feature support. Check our my previous blog post for a more thorough listing compiled from multiple Cisco document sources as well as real-world testing.
-Andrew
Great post!
ReplyDeleteIt's a real shame about the WGB limitation (and no AAA override) as I'm currently evaluating a large scale h-reap retail deployment however it can't go ahead without WGB support.
PS This blog is a great source of useful relevant info for this industry. Keep it up!
Cheers
Pete
Thanks Peter!
ReplyDeleteHi,
ReplyDeleteLove your articles about H-REAP since Im looking at a design scenario where Id like to use HREAP in a remote office with a central controler at HQ, but I will pretty much require some sort of OKC/fast roaming in the remote office.
According to your article H-REAP Deployment Guidelines and Feature Limitation from june 22 '10 under H-REAP Standalone Mode Limitations you mentioned:
"OKC and CCKM fast roaming is only performed for existing PMKIDs that were created when the AP was in connected mode to the controller." whereas here you say that no PMK/OKC/PKC fast roaming is supported in H-REAP mode at all.
Ive searched around ciscos website and found pretty inconsistent information about wheter or not OKC fast roaming is actually supported in H-REAP mode but cant seem to get a clear answer.
Do you happend to know what the exact status of this is?
Hi Fredrik,
ReplyDeleteSorry for the confusion. As of 7.0.98.0 code only CCKM fast roaming is supported with H-REAP access points. I was mistaken when including PMK/OKC/PKC fast roaming with my previous H-REAP post.
Thanks for catching that. I have updated my post to reflect that correction.
Andrew
As far as I understand, PMK caching does in fact work in 7.0.98.0, but it's not officially listed as a supported feature until the next upcoming release of 7.0.xxx (aka J-MR1, due out tentatively April 4th); as such, it hasn't been updated in the feature matrix document yet.
ReplyDeleteUnfortunately it took a TAC case to understand that it does in fact work in 7.0.98.0, but my loss is your gain!
It's interesting that you mention PMK caching. I have had similar experience with static PMK caching actually working with the Cisco UWN solution on 4.2.205.0 code, despite TAC adamantly telling me it does not. After proving it to them with several capture traces we were told that it may work, but is not officially supported.
ReplyDeleteSo, it's worked for a while. It will be curious to see if they officially add support for PMK caching in 7.0 J-MR1 or not.
Andrew
Very informative stuff thanks for sharing this..
ReplyDelete