Overview
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
What is Broadcast Traffic?
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 fundamental 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 less 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.
Effects of Excessive Broadcast Traffic
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 we call a broadcast storm.
While many networks will unfortunately experience these 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.
Let’s take 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 broadcast/multicast traffic. Let’s take a look at how beneficial this can be through another example:
As you can see, with proper control on 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.
Managing Broadcast/Multicast Traffic
Depending on what tools you have 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:
How to Enable Port Isolation in UniFi Controller
Here’s how to set this up as shown in the above example in the UniFi controller:
- First, open the UniFi Controller that manages your network.
- Click the Devices tab on the left to see your devices.
- Click on the switch you want to enable port isolation on, and go to the Ports tab.
- Either select the ports individually you want to enable port isolation on, or click 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 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.
Related Articles
UniFi – Debugging Intermittent Connectivity Issues on your UAP