funkymunky

As good? It's nowhere near; Ruckus have a far superior solution both in regards to RF management and other feature sets (802.1x dynamic VLAN support for example). That's not to say UniFi won't do what you require of it but taken purely on technical merit they're like apples and oranges. UniFi can be very cost effective and as long as you understand its limitations can work great. See http://www.wlanpros.com/wp-content/uploads/2013/02/Wi-Fi-Stress-Test-Report-Overview1.pdf for a comprehensive recent multi vendor test (for a single AP) which shows off some of the performance Ruckus' clever RF management can get you. Where it says Ruckus 7372 it was actually a 7363 they tested (7363 is older than the 7372).

Ruckus APs use Atheros silicon (as do Aruba and some (all?) Ubiquiti). A lot of the time things like that are driver issues rather than the silicon being fundamentally broken (that's not saying they've not released crap in the past, they may have).

What vendor are you using? Some of them now encrypt controller-AP control traffic and as such you shouldn't need a VPN, if there's NAT in front of the controller then put the relevant port forwarding rules in place. You can tell the AP(s) how to find the controller via DHCP, DNS or pre-configuring them with it. Again depends on the vendor.

Reality is that both Ruckus and Aerohive will do the job you want *if* the network is designed and installed correctly. 802.11 is very complex and although all the vendors have various features to try and simplify deployment, radio resource management etc. - if the APs are installed in the wrong place, they're in the wrong place no matter who the vendor (some will tell you otherwise though). A good Ruckus AP (7363, 7982 etc.) will give an excellent coverage area and you'll see a better download signal to a client than upload due to their dynamic beam-forming (which is fine in lots of networks as clients download more than they upload) however if you're network needs to be built for capacity rather than coverage (as you've got high concentrations of stations in the same areas requiring a lot of bandwidth each) then some of the Ruckus benefit is lost (that's not to say it won't work). Ruckus also have a feature called ChannelFly which uses statistical modelling of real world throughput to predict the best channel each AP should be on and will react to sudden throughput issues e.g. when someone/thing introduces a new source of interference. Again this can be very useful however one of the downsides is that each AP changes channel quite often, especially while it's in the initial learning stage (this problem can be mitigated if the clients support channel switch announcements). Build your list of requirements and take them to a recommended, reputable 802.11 network design company, they'll be able to then design you a sound system that will perform as required. As for the controller being a single point of failure, it is but you can have a redundant unit running alongside the primary. If cost of the second unit is an issue point this out to your reseller and tell them it's potentially a deal breaker for you going with a competitor, you'd be surprised how creative they can become with pricing (and this goes for all vendors, not just Ruckus). Although Meraki have a potentially good cloud management platform (depending on your needs) the radios don't perform particularly well in all the reputable testing I've seen. The MR24 was one of (if not) the first 3x3:3 enterprise AP on the market and it looks like they possibly rushed it and it's been slated in various reviews. Having said that some people are 'apparently' using them happily in high density scenarios.... (although that info came from someone trying to sell me Meraki kit!).

Already associated clients will stay connected however no new clients can connect. Also, the APs will reboot after not being able to speak to the ZD for 20 minutes as part of an attempted recovery process (and if the ZD is still down when it comes back up it won't provide any wireless service until it comes back or it finds another). The new ZD code (9.5) which came out this week lets you disable or change this timeout value. In this scenario though Ruckus will suggest you purchase a backup controller...

QoS is only needed if you have congestion on the network. If your devices forward at wirespeed (which is most things these days) and you're not hitting any interface limits then the frames aren't getting queued anyway so there's nothing to prioritise. If you do have congestion then yes look at QoS or even better increase your connectivity.

SAN can be done relatively cheap if you opt for AoE rather than Fibre Channel. Have a look at Coraid's excellent EtherDrive products and see if they'd be any good for you.

Glad it helped

The way that trunking works is that a frame arrives at a switch and a lookup is done to see which interface it needs to be sent out of. When the outgoing interface is a trunk then further processing needs to be done before the frame can be queued for transmission, this processing is to decide which port of the trunk the frame should be used to transmit the frame and the hashing algorithm used varies between manufacturers and switch models. The HP switches you're using only do a basic layer 2 hash, they take the SA and DA (source MAC address and destination MAC address) and perform a calculation on them that will output one of x values where x is the number of member ports in the trunk (in this case it will result in 1 of 2 values as there's 2 ports making up the trunk). This result then decides what outgoing port to transmit the frame on. This means that for any SA/DA pair the same transmit port will always be used (unless the make up of the trunk alters through a config change or hardware failure), what's happening in your case is that there's 2 SA/DA pairs and they both hash to the same value so both use the same outgoing port. Once you start introducing more devices to the network you'll find that SA/DA pairs hash to either value and you'll start seeing some load balancing. Trunking is more effective when you have more devices on the network, the basic layer 2 hash that HP use means it's next to pointless for networks with very small numbers of endpoints. On better switches you usually get a choice of algorithms to use and they're not restricted to layer 2, you can choose algorithms that take IP and TCP/UDP ports in to account as well which then means individual streams can be better load balanced. I'm not aware of any HP switches from the E range (Procurve stuff) that support anything other than layer 2 SA/DA though., not looked at the new A range stuff (H3C/3Com) enough to know either way. Even with these higher layer hash algorithm the max size of each individual stream will still be restricted to the size of the ports making up the trunk (100Mbit in your case) as each stream always hashes to the same value. Foundry/Brocade do offer a round robin algorithm on their MLX/XMR platforms which would in theory allow you to split a stream across multiple ports and thus get a transfer rate higher than the speed of a single member port however it's usually a good idea to try and keep frames in the correct order as there's no order correction at the MAC layer and various issues could occur.

We've got 3 of them powering the 3 screens in our NOC. Decent units for the price.

Go with learning the CLI, it's easy enough and more powerful for most things unless you need the sort of stuff the IDM plugin offers in which case you'll need Procurve Manager. Working with a CLI is an important skill to have if you want to further yourself in the world of networking... you don't generally configure BGP, OSPF, MPLS etc. via point and click! As for moving to using VLANs and STP you should find it quite easy if you plan properly, work out what subnets will be running over each VLAN and note down the security parameters required for each. The actual configuring on the switch is the easy bit.

To do what you want you'd probably need the Identity Driven Manager plugin for PCM (HP ProCurve Identity Driven Manager 3.0 J9438A, J9440A, J9439A) and a higher spec switch than the 2510s. Better to confirm with HP though....

Depends what switches you've got. If you have semi recent HP then enable loop protect, it'll save your arse on many occasion and the switch will be happy to tell you the last time it happened. It's a pain in the arse when it happens but if you can identify it then you're half way there

RouterOS is pretty simple to use, I wouldn't bother with the training... what is it you're wanting to do with it? It's jut Linux with a different frontend. The documentation is reasonable and the forums are quite active.

Just a note on the HP/Colubris MSM kit, you don't have to configure each access point, the APs provision themselves from the controller when in controlled mode (which is the default). It's decent enough kit, easy to use and the NAC stuff is good and pretty flexible although I'd like to trial some other kit against it if I ever get the time as there's a lot of much improved wireless kit coming out at the moment. I'm guessing the people that had to set each AP up are using the old zl kit (pre Colubris) or don't have a controller unit...?