Wireless Access

Currently we have about 640 802.11G clients (all atheros wifi, yuck...) and a handful of g/n clients and 100 a/n clients.  But we are moving to a BYOD option at our school so our environment will be changing quite a lot next year,  We will have guaranteed 450 a/n devices and then 300 or so of what people bring on campus.  This is another reason for us to turn of HT.  In our tiny bit of testing (we obviously can not test a ton of devices for connectivity) we have found that SOME device manufactures put really crappy wifi cards in their computers :)

Would there be any reason to have HT on?  If most of our data is moving to the internet (all of our students are using Google drive, no files services, etc...) then why would I need the extra throughput, air time should be identical, as their throughput still exceeds what we even give them to begin with.

Danstl,

You have a great deal of clients.  I hear you about the crappy wifi cards.

The reason you would have HT on is based on two terms used by my colleagues Chuck and Clark called "associated client capacity" and "active client capacity".  Even if you are limited by your internet connection,  you want as many clients to be able to associate.  Not all clients will be active at one time, but he right 802.11n access point will allow more clients to be able to associate so that when they are ready they can pass traffic.  The reason to turn on HT is if you could not add any more access points for any reason, you would want the clients that are capable of associating and passing traffic at HT rates to be able to.  That would definitely increase your capacity.  You could also enable the Airtime Fairness feature so that the effect of non-HT clients dragging down the performance of HT clients is not so severe.  

You can take a look at the High Density VRD here http://www.arubanetworks.com/wp-content/uploads/DG_HighDensity_VRD.pdf  to see a number of things you could do to manage your increasing clients.  You  might not want to or be able to do all of them, but it is good to know what your real options are.

Thanks for the information.  Looks like I will add some more ACLs :)

Something else to note that I not well noted, you should always add ACLs to block clients from using any IPs of any core services on your network, so all gateways, routers, switches, etc.  We have all our core servers on a single subnet so we restrict our clients from using that entire subnet.  But it is very important if you are using Vlans with discrete gateways that you add those gateway IPs to the client ACL blacklist as well.

We have a fairly dense deployment of 64 APs, and usually see no more than 12-15 clients on an AP at any time.  I think we may re-evaluate HT for next year, but seeing what we have already seen, it seems removing HT means your lowest denominator clients will still be able to connect without problems.  I think I would rather add APs then deal with BYOD connectivity/reliability issues.  

I find it interesting how you have all these wifi vendors all stating (to schools) how their technology will fix everything wrong with wifi, but in reality you are dealing with limitations of the wireless spec, and not so much the hardware.  Having a quality ARM platform seems to be key with any deployment especially a dense one...

Going back to the original subject (sorry for the hijack), should we just drop broadcast/multicast :) I know this is what our local aruba engineer sugests, and we have seen no issues since...

Yup.  Drop Bcast/Mcast.

You can use "Enforce DHCP" in the AAA profile to prevent clients from using static ip addresses.

There are quite a few factors that go into deploying reliable wifi.  The Aruba VRDs go into alot of those and give a sense of what are the considerations for deploying indoor 802.11n for example.  That gives a good starting point on how to deploy wireless.  A certain X-factor, however is client behavior which changes all the time.  That is something that cannot be controlled by the infrastructure--just influenced by it.  That by far is the majority of issues faced and no wifi manufacturer is in control of it...they just have to deal with it.

Enforce DHCP does not work as we have found out the hard way.  The client will get a deny access, but will still show in the controller, and anyone trying to access said resource would also get denied access as the arp would point to the denied client.

After talking with support they did confirm that this is working as designed, and though enforcing DHCP will keep a client from gaining access, it does not keep the IP from showing in the arp cache on the controller.