Pablo,
Our experience with the HP MSM765 controller is mixed. It has a
conceptually different architecture than most of the other controller
models out there. One key difference is that the controller works much
better in an environment where you forward traffic from wireless users
directly at the AP rather than tunneling user traffic back to the
controller (distributed rather than centralized model). There are both
pros and cons to this approach. The HP support engineers have
encouraged us to use the distributed approach with this product for
our primary SSID (WPA2-enterprise/AES).
There is no *simple* association of an SSID to a VLAN, if you tunnel
traffic to the controller. You can assign VLANs to an SSID at the
controller, but there are two ways to do it and caveats that go along
with both. There are a couple of roadmap features that might be very
powerful in terms of fixing this issue, but nothing that has been
realized in current production code. An SSID <-> VLAN relationship is
easy to construct, if you bridge traffic at the AP rather than the
controller. In fact, if you are using a distributed model, you can set
the VLAN <-> SSID relationship for all APs, a group of APs, or
individually at a single AP (and you can have a mix based on simple
inheritance rules). In our testing case, we have a different VLAN for
our primary SSID per building.
We have had several issues with their web-based captive portal, but I
don't think there is a perfect captive portal in any controller-based
solution. You should note that you must forward traffic to the
controller, if you want to use the captive portal. We have also had
some performance issues when tunneling traffic to the controller.
We would really like to see user load balancing across both APs and
bands rolled into the product (no band steering and no active user
balancing across APs). You can set the maximum number of users you
want per radio, but that value is set across an entire SSID on a
controller rather than being applied per a group of APs (i.e., there
is no way to vary this setting by geographic region or AP type other
than adding an additional controller).
The RF management is fairly rudimentary, but I am sure this is being
worked on diligently.
There is currently no N+1 redundancy, but you might well imagine that
this is also an issue they are diligently working on. You can get some
redundancy now by simply assigning multiple controller addresses to
the APs.
The MSM422 itself has done well in our pilot and testing (~100 APs).
We have been supporting about 800 simultaneous users in our library
during the busiest two weeks of the year.
We have had a reasonable response on the engineering and support side.
I think this is a great fit for small to medium sized deployments. But
you will need to consider whether the product scales appropriately for
your environment. I encourage you to contact an HP sales
representative that might be able to give you more detailed
information about the product roadmap and future features.
If you want to know some more specifics about our experience, contact
me off-list.
-Jason
******************************
Jason Mueller
Network Design Engineer
Indiana University, UITS
812-856-5720
jasmu...@indiana.edu
******************************
On Dec 16, 2009, at 6:55 AM, Pablo J. Rebollo-Sosa wrote:
Hi,
We are looking for 802.11n solutions. I would like know more about
Enterasys and HP solutions experience.
Best regards,
Pablo J. Rebollo
**********
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/.
