Floods and Broadcasts

It doesn’t have to be reality TV to be bad…

By Steve Harrison



This is the fourth in a series of blog posts that focus on wireless security and technology at Cisco Meraki.

Wireless networks underpin most of our day-to-day activities, all while sharing the same relatively small frequency spectrum. As such, the protocols that dictate how these networks work are exceptionally polite by design, and for good reason.  This is because wireless networks, like humans, are half-duplex, meaning only one station or person can talk at anyone time.

However, this politeness can also be used against such networks by potential “bad actors.” This post will detail how Cisco Meraki access points help our users’ networks from being excessively impacted by such malicious (intentional or otherwise) devices.

How can broadcasting be bad?

You may be asking “why would a network broadcast be a bad thing? On my wired network, protocols use broadcasts all the time,” and you would be correct that broadcasts are seldom a problem on the wired side of network (but not always). However, as we have previously discussed, wireless is a shared access medium, so if someone was continually talking (packet flood discussed below), we would have to wait for them to stop. More importantly, when an access point transmits to a client on a wireless network, it has to transmit at a speed that the client can understand. For a broadcast frame, this speed is actually the slowest supported data rate of the BSSID and is often a basic data rate.

This means that when transmitting broadcast (and management) traffic, the access point can only talk as fast as the slowest data rate at which the BSSID will accept a client association. If the default settings for minimum bit rate have not been changed, then an access point will send the broadcast frames out at up to 150 times slower than it could do (though this isn’t something Meraki recommends).

This can render the 802.11 network unusable, as the access points are always busy transmitting or waiting for the malicious broadcast traffic (if another AP or client is broadcasting). This behavior is often weaponized by bad actors into a DoS attack against wireless networks.

Meraki APs help minimize excessive broadcast traffic from entering the wireless medium from the wired network by enabling Proxy ARP.  This means that an access point currently serving a wireless client responds to an ARP request from the wired portion of a network on behalf of the wireless client, which would have otherwise been sent as a broadcast.

Additionally, Air Marshal can alert Meraki network administrators to malicious broadcast traffic that has been seen by the access points in their network, as shown below:

Then, the administrator can investigate the local environment to ascertain and mitigate the source of the malicious broadcasts.

What is a packet flood?

In a similar manner to misusing broadcast traffic, a client or AP could send out large amounts of 802.11 management (beacon, association, and authentication) frames, knowing that an access point is bound by protocol to process and, where appropriate, respond to them. This is akin to an inquisitive toddler peppering their parent with questions, without waiting for a response, over and over again.

As any teacher or parent will know, working in this kind of environment requires either the patience of a saint or the unconditional love of a parent. Alas, for 802.11 networks, access points, whilst being very polite, lack both of these things! As such, when a client behaves in this manner, it is detrimental to the performance of the overall wireless network in much the same way as excessive broadcast traffic.

As with malicious broadcast traffic, Air Marshal will alert the administrator that the access points within their network are seeing this potentially nasty behavior and display the frame type, as shown below:

Then, the administrator can investigate the local environment to ascertain and mitigate the source of the malicious broadcasts.

Other things to consider…

Finally, one other type of network-level transmission that can cause issues in 802.11 networks is multicast traffic. Unlike wired networks, wireless networks typically send multicast traffic flows over the wireless medium as broadcast traffic. In order to alleviate this potential issue, Meraki access points enable IGMP by default. This has the effect of converting the multicast stream into (potentially multiple) unicast transmissions that are likely to be transmitted at much higher speeds.

This is essential in classroom environments, where students could be watching a multicast HD video stream as illustrated above.


Similar to the “evil twin” attack discussed in the previous blog post, there is nothing that can be done to mitigate these risks while still complying with the 802.11 network standard.  However, the power of the Meraki dashboard and access points provide instant visibility into threats in an organization.  


For more information on Air Marshal and spoofs please see the following additional references: