¶ Introduction
A common issue in modern WiFi deployments is the presence of multicast/broadcast traffic from client devices. This traffic typically comes from devices which have some kind of automatic discovery (Chromecasts, Sonos, Apple TVs), or from Apple devices (Bonjour protocol). When a high number of these devices are connected to the same WLAN, you may find that they use a large amount of the available airtime. This is because many WiFi deployments handle this traffic inefficiently. This article will cover some methods that can be used to remediate this issue.
¶ Related Wyebot Signatures
Below is a screenshot of the signature that shows when a large amount of broadcast/multicast traffic is detected.
¶ Raise the minimum basic data rates
Broadcast/multicast traffic tends to be so inefficient because it is transmitted at one of the “basic data rates”. Basic data rates are the minimum required communication speed that a device must support to connect to an SSID. Oftentimes, the default configuration will have the 802.11b rates (1, 2, 5.5, 11mbps) selected as the basic data rates. As a best practice in general, we recommend raising the minimum basic rate to 12mbps. If your minimum basic rate is already at 12mbps, you can consider going as high as 24mbps to further optimize the speed of transmissions. Be wary of going higher than 24mbps, as setting your basic rate too high can cause connectivity issues for certain WiFi clients.
¶ Block client to client communication on your SSIDs
One of the most effective ways to mitigate high amounts of broadcast/multicast client traffic is to simply block any client to client communications on the SSID. This works effectively because the APs will no longer retransmit broadcast/multicast frames. If peer to peer communications for your WiFi connected devices is not critical, consider enabling this configuration. Typically, your WiFi vendor should allow you to block client to client traffic on some SSIDs (e.g. guest network), while leaving it enabled on others (e.g. admin network).
¶ Segment your network with VLANs and IP subnets
Another way that broadcast/multicast traffic becomes an issue is when the broadcast domain is too large. Devices on the same VLAN are typically in the same broadcast domain, and if the number of devices is too great the network can become congested with broadcast traffic. As a general best practice, you should isolate each SSID into different VLANs which are tied to a unique IP subnet (e.g. 192.168.10.0/24). It is also possible if you have the infrastructure for a RADIUS authenticated SSID, to assign clients within the same SSID to a different VLAN depending on their RADIUS attributes. This configuration is commonly known as “role based access control”.
¶ Vendor specific options
Many enterprise WiFi vendors offer some other methods to remediate broadcast/multicast traffic. These methods include Proxy ARP, where the controller/AP will respond to ARP requests on behalf of the client. This is a useful configuration, however it will not remediate all broadcast/multicast issues. Another method commonly called “bonjour gateway” is useful in deployments where a large number of Apple devices exist. This will have your WLAN controller act as a proxy for Bonjour traffic, and allow you to point it to a different subnet. This can be very effective, however the implementation differs between vendors. There are still other unique ways WiFi vendors can handle multicast/broadcast traffic, so we recommend you reach out to your vendor for advice specific to their product.
¶ Vendor specific articles:
Aruba, Cambium, Cisco, Extreme, Meraki, Ruckus, Ubiquiti, Mist