802.11 Wireless LANs vs. broadcast traffic

Like many engineers and network managers I’m finding more and more clients are connecting via our 802.11a/b/g wireless network than ever before. While some of the wireless clients are corporate devices which connect to the corporate network, a large number of wireless devices are connecting to the public guest network which connects to the public Internet. At our largest facility we have some 1,500 corporate devices connecting via wireless. However, we can have upwards of 2,000 public devices connecting to our public guest network at any one time. All those smartphones, tablets and computers put out an immense amount of broadcast and multicast traffic which can adversely impact a wireless network.

I originally calculated that the broadcast and multicast traffic was accounting for between 40Kbps and 60Kbps of traffic on our wireless network. However, looking at the traffic graphs right after the change I was shocked at the delta. I performed the change just before noon and you can see a delta of Mbps not Kbps. I would estimate that the changes are saving us 5Mbps of traffic to/from our wireless network.

That’s a lot of needless background noise that ultimately leads to airtime issues which eventually results in retransmissions, delayed packets, jitter and packet loss which can severely impact application performance.

Over the past few weeks I’ve been working to deploy some filters on our Motorola RFS 7000 Wireless LAN Switches  (v4.4.2) so I thought I would share them as a best practice in any medium to large scale wireless deployment. If you only have 10 APs then you probably don’t need to worry about filtering the broadcast and multicast traffic. If you have 500 APs then you definitely need to be paying attention to all the needless noise being generated on your wireless network. In the example below I also took the opportunity to block IPv6 frames since we’re still utilizing only IPv4 on our wireless networks.

enable
config t

firewall enable

no firewall stateful-packet-inspection l2

mac access-list extended ARP-ALLOW-ACL
deny any any type ipv6 rule-precedence 10
permit any any type arp rule-precedence 20
permit any any type ip rule-precedence 30

ip access-list extended WLAN-FILTER-BCMC-ACL
permit udp any any range 67 68 rule-precedence 10
deny udp any range 137 138 any range 137 138 rule-precedence 20
deny udp any eq 17500 any eq 17500 rule-precedence 40
deny ip any host 255.255.255.255 rule-precedence 50
deny ip any 224.0.0.0/4 rule-precedence 60
permit ip any any rule-precedence 70

wlan-acl <wlan idx> WLAN-FILTER-BCMC-ACL in
wlan-acl <wlan idx> ARP-ALLOW-ACL in
wlan-acl <wlan idx> WLAN-FILTER-BCMC-ACL out
wlan-acl <wlan idx> ARP-ALLOW-ACL out

You’ll notice that the firewall needs to be enabled. And you need to verify that Layer 2 inspection is disabled.

If you are utilizing VRRP you may need to enable ARP trust on the interfaces relieving the VRRP packets, if you don’t you may see errors such as the following;

sw-wireless.store.acme.org*#Sep 12 11:27:00 2013: %DATAPLANE-4-ARPPOISON: ARP CACHE POISONING: Conflicting ethernet header and inner arp header :Ethernet Src Mac: 00-21-62-E3-XX-XX, Ethernet Dst Mac: 00-15-70-82-XX-XX, ARP Src Mac: 00-00-5E-00-01-C8, ARP Dst Mac: 00-15-70-82-XX-XX, ARP Src IP: 10.1.255.1, ARP Target IP: 10.1.255.19

sw-wireless.store.acme.org*#Sep 12 11:27:25 2013: %DATAPLANE-4-ARPPOISON: ARP CACHE POISONING: Conflicting ethernet header and inner arp header :Ethernet Src Mac: 00-21-62-E3-XX-XX, Ethernet Dst Mac: 00-15-70-82-XX-XX, ARP Src Mac: 00-00-5E-00-01-C8, ARP Dst Mac: 00-15-70-82-XX-XX, ARP Src IP: 10.1.255.1, ARP Target IP: 10.1.255.19

sw-wireless.store.acme.org*#Sep 12 11:27:48 2013: %DATAPLANE-4-ARPPOISON: ARP CACHE POISONING: Conflicting ethernet header and inner arp header :Ethernet Src Mac: 00-21-62-E3-XX-XX, Ethernet Dst Mac: 00-15-70-82-XX-XX, ARP Src Mac: 00-00-5E-00-01-C8, ARP Dst Mac: 00-15-70-82-XX-XX, ARP Src IP: 10.1.255.1, ARP Target IP: 10.1.255.19

Just enable ARP trust on the interface connected to the routers/switches running VRRP;

enable
config t

interface ge1
ip arp trust
exit

Cheers!