Ethan, We are currently testing the HP MSM (formerly Colubris) wireless controllers and access points. We have 27 MSM422 access points deployed in a production environment attached to a couple of MSM765 controllers.
As Patrick points out, the HP solution does allow both centralized and decentralized approaches. Given what we have observed at this time, I would recommend a decentralized approach using WPA2 or WPA enterprise. There is a bandwidth penalty for tunneling traffic back to the controller rather than bridging it at the AP. HP is working on improving this. Unlike previously suggested, it will *not* take a lot of controllers to meet your requirements. A single MSM765 controller can be licensed to support 200 APs (which is roughly what you are looking at). There is no N+1 controller configuration at this time (I anticipate that this will be coming shortly), but you can configure your APs to act in a similar manner by giving them a list of controllers in order of preference. You could get by with three MSM765's. That will give you a redundant controller and two production controllers capable of support up to 200 APs each. Until an N+1 strategy comes out, you will be stuck paying for licenses that sit unused on your backup controller. The MSM765 form-factor is a module that fits into your existing HP switches. The HP solution does not support IPv6, and I suspect it will not for quite awhile. This seems to me a serious drawback in the R&E community. If you bridge wireless traffic local at the AP, then you can easily pass IPv6 traffic. However, you will need to look at placing filters at the switch uplink to the AP or at your router, as the wireless system is not IPv6 aware. We have run into wireless client density issues. There is no load balancing nor band steering capabilities built into the product, so you are completely at the mercy of the wireless client with respect to which AP the client lands on. We have not had success in simply limiting the number of clients that can join radios. At this time, the production code only allows you to limit this at an SSID level (i.e., the same number is applied to both a/n and b/g radios, and it is done so uniformly across all APs on a controller), but there should be a huge improvement on this in the near future. We have had issues with basic channel selection on the product, but we are hoping to have a short-term fix for that built into the product soon. Functions related to RF are not centrally coordinated. The CLI on the controller is definitely not the shining star of this product line. The GUI is okay, but it sometimes takes multiple steps to get information you would think should appear on a summary screen (i.e., when looking at a list of wireless clients, the info does not include the username... you have to drill down to get that info, which is time consuming when troubleshooting a problem that effects many users). There are several other quirks with the GUI (like forms canceling instead of being submitted when you hit "return") that make it annoying, but for the most part you can do what you need to do. There are also some legacy constructs and terminology that will take some getting used to, which are leftovers from the product's early days. I think with only ~200 APs, this is a usable system. We are trying to support >4000 APs, and we are still working with HP to make the product scale a little better to that number of APs and the number of users we have. HP engineers have added several features for us (not in production code yet). If you want any more details or have some specific questions, feel free to contact me (on or off list). Thanks. -Jason On Apr 2, 2010, at 7:09 PM, Patrick Goggins wrote: > HP can be decentralized (depending on the model) or controller-based but > requires a large number of controllers to scale well. While Aruba does have > extra licensing fees some of them can be skipped with the newer licensing > model and others passed on if you have an existing NAC/NPS solution which > works well for you environment. How is your organization with regards to > cloud services in general? If per policy other services were turned down by > the organization Meraki might not be an option as wireless configuration is > "in the cloud". What features are you looking to implement on the access > points? For example, we are using ethertype filters at the AP level to block > IPv6 which during tests earlier this year HP would not offer but Cisco and > 3Com did. When running encryption on your network if certain encrypted SSID's > are available campus-wide is this installation a forklift replaced? If not, > the new equipment may need to support whatever the existing encryption > settings are as different vendors have slight variation on implementation of > the standards. If using 802.1x and it is a mixed vendor environment > thoroughly test the functionality, we have seen some limitation when running > cross-vendor with multiple MAC addresses on a single switch port or access > points tying in correctly with different NAC solutions. > > > ~Patrick > > ________________________________ > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [wireless-...@listserv.educause.edu] On Behalf Of Mike Hydra > [mhy...@2fast4wireless.com] > Sent: Friday, April 02, 2010 4:01 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Aruba vs HP vs Meraki > > What I personally find interesting is the wide choice not from a > manufacturing point of view but more from a Wi-Fi technology point of view. > > Aruba – Controller based (aka controller based) > All data goes through the controller, centralized architecture. > > HP – decentralized (Controller in not directly essential) > Data path is separated from the management path. > > Meraki – Cloud computing > Centralized Cloud, not having to own controller hardware inside your own > network. > > All three very different solutions. > > I’m looking forward to follow this email threat with the comments, thanks for > sharing. > I would recommend writing down a proof of concept and invite the vendors of > your choice. > In this way you’ve tested your requirement (out of your proof on concept) > therefore convinced around the solution you buy is the right one. > Good luck... > > > Mike Hydra > > Cell: +31 6 29 07 18 96 > Tel: +31 252 62 61 20 > Fax: +31 252 68 88 37 > E-mail: mhy...@2fast4wireless.com<UrlBlockedError.aspx> > Skype: Flying-Wireless-Dutchman > Web: www.2fast4wireless.com > > > > ________________________________ > From: Peter P Morrissey <ppmor...@syr.edu<UrlBlockedError.aspx>> > Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<UrlBlockedError.aspx>> > Date: Fri, 2 Apr 2010 22:47:26 +0200 > To: <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<UrlBlockedError.aspx>> > Subject: Re: Aruba vs HP vs Meraki > > OK, so I'll ask. Why did you eliminate Cisco already? > Pete M. > > -----Original Message----- > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:wireless-...@listserv.educause.edu] On Behalf Of Ethan Sommer > Sent: Friday, April 02, 2010 2:21 PM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<UrlBlockedError.aspx> > Subject: [WIRELESS-LAN] Aruba vs HP vs Meraki > > We are considering replacing our 200+ AP wireless infrastructure with a > controller based 802.11n system. > > I believe we have narrowed it down to Aruba, HP Procurve (we use HP > switch gear), and Meraki. > > I have two questions: > > 1. Are there any hidden costs we should watch out for with any of these > (particularly Aruba.) Will we hit major costs other than the up front > cost for the APs and the controllers? > > 2. I know a lot of schools are very happily using Aruba, but I haven't > heard of any schools using HP and very few using Meraki. > > Are there any schools who have gone with Aruba and regretted it? If so, why? > > Are there any schools out there using HP Procurve (formerly Colubrius) > or Merkai? What do you think of them? Did you have any surprises after > you deployed? > > > Ethan > > -- > Ethan Sommer > Associate Director of Core Services > 507-933-7042 > somm...@gustavus.edu<UrlBlockedError.aspx> > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > > > ________________________________ > The information in this e-mail is confidential and may be legally privileged. > If you have received this e-mail in error, please reply to its sender > indicating "received in error" in the subject line, then delete the e-mail > and destroy any copies of it. If you are not its intended recipient, any > disclosure, copying, distribution or any action taken or omitted to be taken > in reliance on this e-mail, is prohibited and may be unlawful. Internet > communications are not considered secure. Information might be intercepted, > amended, lost, destroyed, arrive late or incomplete, or might contain > viruses. 2 Fast 4 Wireless and/or 2 Fast 4 Wireless Corporation (USA) will > not accept any liability with respect to the contents of this email and its > attachments. > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
