🤯Broadcast Filtering on Network Switches – Preventing a Networking Brainfart💥


Listen here, boet. If you’ve ever been in the trenches of network engineering, you’ll know that when a switch starts spamming broadcast traffic like an overenthusiastic radio DJ, it’s only a matter of time before everything falls over. ISPs, FNOs, big corporates – we’ve all seen it. A single misconfigured switch can cause a broadcast storm that brings an entire network to its knees.
And the worst part? These things don’t just happen in obscure, badly managed networks. Even the big boys have suffered outages because someone forgot to apply proper broadcast filtering. Ja, even your favourite ISP or fibre provider has been caught with their pants down because of this.
So, let’s talk about how to stop this madness before it turns your network into a dumpster fire. 🔥
Why Broadcast Filtering Is Required
A switch is supposed to be intelligent – it learns MAC addresses and forwards traffic only where it’s needed. But sometimes, thanks to bad configurations or the joys of legacy devices, a switch can flood the entire network with unnecessary broadcast traffic. Here’s why this is a massive problem:
1. Broadcast Storms Will Wreck Your Network
A broadcast storm happens when there’s an uncontrolled flood of broadcast frames (like ARP requests, DHCP requests, or network loops). The switch doesn’t know what to do with it, so it just keeps forwarding the traffic, chewing up bandwidth and switch CPU.
2. Everything Slows to a Crawl
Broadcast traffic doesn’t just vanish. Every single device on the network has to process it. Now imagine hundreds or thousands of endpoints trying to handle a broadcast storm. Even your beefiest core switches will start crying for their mother.
3. Loops Are a Silent Killer
One incorrectly connected cable, and boom – you’ve got a loop. STP (Spanning Tree Protocol) should catch this, but do you trust everyone in your team to configure STP properly? Ja, exactly. Broadcast filtering is your extra safety net.
How to Implement Broadcast Filtering
Now that you know why you need it, let’s talk about how to apply it in a way that makes sure your network stays lekker.
1. Use Broadcast Storm Control
Most decent managed switches have a setting to limit the amount of broadcast, multicast, and unknown unicast traffic allowed on an interface. This is called Storm Control.
Example Configurations:
On Cisco switches:
interface GigabitEthernet0/1
storm-control broadcast level 5.00
storm-control multicast level 10.00
storm-control action shutdown
This limits broadcast traffic to 5% of the port’s bandwidth and multicast to 10%. If traffic exceeds this, the port will be shut down (or you can set it to just log an alert).
On MikroTik:
/interface ethernet set ether1 storm-rate=1000000
Limits broadcast packets to 1 Mbps on that port.
On Juniper:
set interfaces ge-0/0/1 unit 0 family ethernet-switching storm-control broadcast level 5
set interfaces ge-0/0/1 unit 0 family ethernet-switching storm-control action discard
This will drop excess broadcast packets beyond 5% of the port’s bandwidth.
2. Enable Port Security
Another way to limit damage is to use port security, so rogue devices or loops don’t flood the network.
On Cisco:
interface GigabitEthernet0/1
switchport port-security
switchport port-security maximum 2
switchport port-security violation restrict
This allows only two MAC addresses on that port. Anything else? Sorry, bud – it gets blocked.
3. Implement VLAN Segmentation
If your broadcast domain is too big, your network is going to be slow and unmanageable. VLANs ensure that devices are only communicating within their relevant segment, reducing unnecessary broadcast traffic.
Example VLAN setup:
vlan 10
name "Finance"
vlan 20
name "IT-Support"
Then assign interfaces to those VLANs. This prevents broadcasts from jumping across departments.
4. Use DHCP Snooping to Prevent Rogue DHCP Servers
A classic mistake: Someone plugs in a rogue router, and suddenly the whole office gets dodgy IP addresses. DHCP snooping ensures that only authorised DHCP servers can send offers.
On Cisco:
ip dhcp snooping
ip dhcp snooping vlan 10
interface GigabitEthernet0/1
ip dhcp snooping trust
This stops random devices from handing out IPs like a dodgy car guard at the mall.
Recommended Settings for Broadcast Filtering
For a stable network, you should aim for:
Broadcast limit: 1-5% of port bandwidth
Multicast limit: 5-10% of port bandwidth
Unknown unicast traffic limit: 5-10% of port bandwidth
Port security: Limit to a reasonable number of devices
VLANs: Keep broadcast domains small
DHCP Snooping: Always enabled
Wrap – Don’t Let a Brainfart Take Down the Network
Every ISP and FNO in SA has experienced a broadcast storm meltdown at some point. Sometimes it’s due to an innocent mistake, sometimes it's pure negligence. But the solution is simple – implement broadcast filtering properly, and these disasters can be avoided.
If your networking team isn’t taking this seriously, just remind them that one bad broadcast storm could be the next headline on MyBroadband. 😬
So, do yourself a favour and configure storm control before your switch decides to pull a disappearing act on your business. And if you’re running SD-WAN? Even better. Fusion’s SD-WAN solution ensures traffic flows smoothly, without getting caught in these common network issues.
Stay sharp, and keep your network lekker! 💻🔥🚀
More read about related topics:
Subscribe to my newsletter
Read articles from Ronald Bartels directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Ronald Bartels
Ronald Bartels
Driving SD-WAN Adoption in South Africa