This article will explain what broadcast traffic is and why it's important to manage it in your UniFi-managed network.
Table of Contents
- What is Broadcast Traffic?
- Effects of Excessive Broadcast Traffic
- Managing Broadcast/Multicast Traffic
- How-to Enable Port Isolation in UniFi Controller
- How Broadcast Blocking Works
- Related Articles
Broadcast traffic is a topic of critical importance for network administrators, especially in larger networks. Without managing broadcast and multicast traffic, most networks will likely suffer the consequences sooner or later which can be detrimental to network health.
With UniFi, administrators have a number of methods of both monitoring broadcast/multicast traffic and taking action to prevent the network issues that can come from too much of it. In this article, we'll explain why broadcast/multicast traffic is an important consideration for network administrators and suggest some methods of managing this traffic.
First let's define the three fundamentally different ways communication occurs over a network- unicast, broadcast and multicast.
Unicast is the most common method used for network transmissions. Unicast involves one device sending info to another single network address. This is the method used most often on networks when users browse the internet or download files from a file server.
Broadcast involves sending a single packet on a network to every possible recipient on the network. This method has its own advantages/disadvantages over unicast and is very efficient. It can, however, only extend so far as the broadcast domain—which is usually defined by subnet. Common uses of broadcast transmissions include UniFi device discovery, ARP (Address Resolution Protocol) requests, DHCP, etc.
Multicast functions in a sort of mix between broadcast/unicast. With multicast one device sends data only to systems that are set to receive this data but unlike unicast can send to multiple devices. This means it's more efficient than unicast while consuming fewer resources than broadcast. This most commonly occurs on local networks. An example of a common function that uses multicast transmissions is media streaming like a live stream of a sporting event.
Since unicast communication is the most common and essential on most networks—and the least intensive of the three, special precautions will usually need to be taken to ensure that broadcast/multicast requests do not consume so much network resources that they adversely impact network performance. Let's explore how this happens and how you can identify the symptoms.
Chances are most of us have been on a network when someone plugged in a router or IP phone incorrectly and basically took down the network. The cause of these network outages is most often broadcast/multicast traffic. When a router plugs into the local network incorrectly and starts broadcasting ARP requests in a loop- this consumes such a large amount of bandwidth that there are is quickly no room for normal network operations. This is what is called a broadcast storm.
While many networks can experience problems from time to time, the less obvious consequences of unmanaged broadcast/multicast traffic often go unnoticed while still severely impacting the network. In such cases, dropped packets, intermittent connectivity issues with APs and slower network speed can tip administrators off.
This diagram will give a closer look at how this happens. This is what 400 packets/second of broadcast traffic looks like on a WLAN network with 5 APs:
While 393 kbps isn't a particularly large amount of data, when sent via broadcast it can consume 80% of airtime. This takes roughly the same amount of airtime as trying to send 639 Mbps (500 packets/second * 123 bytes * 8bytes/bit * 1300 unicast frames/multicast frame) through the AP at full PHY rate.
In the above example, both AP1 and AP4 will likely experience intermittent connectivity issues and dropped packets, which will adversely further affect the performance of other APs. These conditions would result in APs having intermittent connectivity with a maximum of 17 Mbps of actual user throughput (unicast data). This would drastically limit the number of users that could connect to each access point—and make the wireless network particularly slow.
As broadcast transmissions increase, this will continue to choke out network function with cascading failures.
For these reasons, it is critical to manage the broadcast/multicast traffic. Let's take a look at how beneficial this can be through another example:
As you can see, with proper control of broadcast/multicast traffic, the same APs can handle over four-fold the user throughput without experiencing any intermittent connectivity. This means the same number of users will all have four times the amount of throughput, or for the same throughput, the system will be able to handle four times the number of users.
In the next section, we’ll explain how this traffic can be managed.
Depending on what tools are available to you in your network, there are a number of ways to manage broadcast/multicast traffic. With UniFi Switches/hardware, the currently recommended method is using "port isolation". This method both ensures that broadcast/multicast data is kept to a minimum while allowing critical services that rely on broadcast/multicast transmissions. Let’s look at an overview of what this would look like:
ATTENTION: Port isolation between access points is generally not recommended, since it breaks communication between the UAPs.
Here’s how to set this up as shown in the above example in the UniFi controller:
- First, open the UniFi Controller that manages the network.
- Click the Devices tab on the left to see the devices.
- Click on the switch to enable port isolation, and go to the Ports tab.
- Either select the ports individually or click the box to select all.
- Click Edit Selected at the bottom.
- Go to Advanced.
- Expand Advanced Options.
- Under Isolation, select Enable port isolation.
- Click Apply to finalize changes.
How Broadcast Blocking Works
It's important to note that the LAN-WLAN Broadcast blocking feature under Wireless Network Settings does not actually block stations from sending broadcast frames to the AP for forwarding onto the wired network. Instead, it blocks broadcast frames that are destined to the athX interface and avoids them from being transmitted.
The frames are dropped at a wireless driver level. Therefore, if you run a
tcpdump on the athX interface of the AP itself, traffic that will wind up being blocked later will appear. The bridge to Ethernet/VLAN forwards everything to the athX interface, which is what
tcpdump picks up, completely unaware of which frames the wireless driver will drop afterwards.
This is why verifying the blockage via
tcpdump won't work. You will however, be able to observe by listening on their wireless interface, that once this feature is enabled, broadcast traffic will not be received by any computer connected to that AP, even though you would still be able to see that traffic when running
tcpdump -i athX on the AP.