Using Policy to Improve Wi-Fi Performance

By ozerdo posted Feb 03, 2012 01:36 PM


Back to the future: Airheads Online article from April 27th 2009


The other day I was meeting with one of my customers, having one of our quarterly "update" lunches, and we got to talking about the Aruba Policy Enforcement Firewall (PEF) module for ArubaOS. This customer happens to be a higher education institution, and I mentioned to him that a lot of prospective college/university customers question the value of PEF because security is not overly important to them. He looked at me like I’m an idiot (and maybe I am) and said, “You don’t get it. PEF is not just a security tool – it’s how we control performance on our network.”


We had an enlightening discussion, after which he ordered the most expensive dessert on the menu (that’s what vendors are for, right?) Essentially, his point was that because WLANs are shared media, they require more control than wired networks in order to maintain their performance at acceptable levels. Just a handful of “power users” on a WLAN can take bandwidth away from other users, and PEF provides them a way to control how the available resources can be used.


For example:

- Large amounts of multicast and broadcast traffic can really slow down a WLAN. Many organizations create wireless VLANs with large IP subnets in order to improve handling of mobility, but the more client devices on a VLAN, the higher the potential multicast and broadcast traffic goes. PEF lets you set limits on this type of traffic so that it doesn’t consume a disproportionate amount of airtime.
- Peer to peer traffic might serve a legitimate purpose, but it can also cause resource constraints. I’ve seen some universities restrict peer to peer traffic over wireless only on campus, but in the dorms it is wide open. I’ve seen other universities who do the exact opposite. Each have their reasons, but PEF provides the flexibility to handle both situations.
- Dual-stack systems with IPv4 and IPv6 at the same time are increasingly common. Left unchecked, IPv6 will do all sorts of fun things on a network. If you don’t have an IPv6 infrastructure on campus, you might use PEF to block IPv6 traffic from clients. And if you do have IPv6, PEF lets you control how IPv6 clients communicate.
- Streaming media can be a network-killer. Do you want to let students run streaming media servers from their dorm rooms over wireless LAN? PEF lets you have control, whether you outright block the traffic or whether you just rate-limit it.


None of these are really security issues, but they show how PEF can be used to control performance. That led me to think about the Wireless Intrusion Prevention (WIP) module as well – we tend to think of that as a security tool too. Turns out it can be used for some performance controls too – for example, with users running their own access points. Any time you have an interfering RF signal, it’s going to reduce total channel capacity by some amount. Using the WIP module, you can set up policies to prevent clients from connecting to non-approved APs – hopefully this will prompt users to eventually shut down those APs. We’ve also seen cases of misconfigured clients causing network outages when they connect to the wired network and the wireless network at the same time and bridge the two together – this is another situation that the WIP module can detect and prevent.


Conclusion? I really got my money’s worth out of this lunch because it opened my eyes to a new way of thinking about the tools we can provide to our customers. If you have similar stories, add them to the thread below and I promise I’ll buy you dessert too someday. Oh, and the chocolate lava cake? Totally worth it.



Subsequent notes within the discussion forums below. 


In addition, how many times have we had to troubleshoot an issue where a rogue DHCP server has caused many hours to tracking and troubleshooting. The policy below will prevent DHCP server response coming from the wireless side. It will allow DHCP server response to come from the wired side. Certainly, one can tighten this down by identifying the DHCP server instance.


ip access-list session

user any udp 68 deny

any any svc-dhcp permit



Using PEF to stop things that would otherwise harm the reliability of your network. Here's another example....if a wired user bridges his/her interface to the wireless NIC, what ramification could there be? Well, spanning-tree convergence, HSRP/VRRP conflicts, routing issues, a whole host of things.....using PEF, you could essentially disconnect a client's wireless NIC if you see these type of frames coming from know their wired, so why not get them off of the wireless.


To do this, using PEF, create a policy that get's applied in the user role that looks for these common "router-based" protocols coming from wireless "clients. Things in this list should include OSPF, EIGRP, RIP, HSRP, VRRP, PIM, etc.....if any hits against this, use the blacklist tag to knock them off the wlan for 60 seconds or so.....once they disconnect from wired, they'll be able to connect once that timer expires. Here is an example policy:


netdestination HSRP



netdestination VRRP



netdestination RIP



netdestination OSPF




netdestination PIM



netdestination EIGRP



ip access-list session Detect_Bridge

any alias HSRP any deny log blacklist

any alias VRRP any deny log blacklist

any alias RIP any deny log blacklist

any alias OSPF any deny log blacklist

any alias PIM any deny log blacklist

any alias EIGRP any deny log blacklist

1 comment


Feb 03, 2012 02:56 PM

Very good read.  Useful tips for any environment.