CommScope's COVID-19 Customer & Partner Hub Visit
If you’ve ever attended a large conference or exhibition, chances are everyone whined about the Wi-Fi. But the truth is, a lot of the time, it’s not Wi-Fi’s fault at all.
While there is a litany of Wi-Fi-specific deployment options that can cause problems in increasingly crowded Wi-Fi networks, such as: too many or too few APs, improper channel planning, haphazard AP placement, or too many SSIDs – even when all of these are handled perfectly, Wi-Fi still tends to get the blame when anything goes haywire.
Not an exhaustive list of every possible networking problem, here are some of the more common culprits that cause Wi-Fi to be everyone’s whipping boy, especially in highly dense wireless conditions.
More Broadband Please!
The most frequent and obvious problem for which Wi-Fi is castigated is lousy or slow broadband connectivity. The purpose of almost all Wi-Fi networks is to provide local connectivity for clients to get to the Internet. The fastest Wi-Fi networks on the planet that can now deliver local connection speeds at hundreds of megabits per second to clients, come to a crawl if there isn’t enough backhaul to the Internet. Even a 100Mbps Internet connection is too slow when you have thousands of clients served by dozens of APs capable of near gigabit speeds. This makes Wi-Fi appear slow or unreliable.
Another major problem, not directly related to Wi-Fi, is simply poor wired network design. Switching, routing and higher layer functions such as DHCP and DNS systems not configured correctly to support the explosion of Wi-Fi network connections can wreak havoc on the network but still appears to be a Wi-Fi problem.
Addressing Users
There are a number of ways that setting up DHCP improperly will cause problems that will look to most people like Wi-Fi is broken. The Dynamic Host Configuration Protocol (DHCP) is a method for automatically configuring TCP/IP network settings on computers, printers, and other network devices.
With DHCP, a common problem can be too long of a DHCP lease. This is the amount of time that a device is allowed to retain an IP address. In a standard network configuration, this period of time can be hours, or even days. Active devices will ask to renew their lease from the DHCP server when the lease is half up. An inactive device will simply lose its lease and the address will be released and available to be assigned to another device.
Over a long period of time in a high-density network it is possible to run out of IP addresses. It’s sort of like a train station where people come and go all day long. When the lease is too long, the DHCP server can run out of assignable addresses again giving the impression that Wi-Fi is broken. Shorter leases will generate a slight bit of additional traffic with the renewals but is worth the tradeoff versus depleting the available IP addresses.
Lost in Translation
A domain network service (DNS) is a vital part of any network. Whenever a device needs to know what address to use when passing traffic, the DNS server provides a translation from a name, or URL, to an actual IP address.
If a DNS server is underpowered, in a busy or dense Wi-Fi environment, it can fall way behind in its role by trying to provide address translation for more devices than it has processing power to complete. And If a DNS server crashes or clients can’t reach it, the users are effectively dead in the water. This causes devices to only sporadically be able to pass traffic and gives the impression of a Wi-Fi network that is overloaded even though every client is properly connected.
DNS redundancy in this case is a helpful fix, especially in highly dense Wi-Fi conditions. A properly devised network has redundancy built in, providing multiple DNS servers to support large numbers of users.
The Big MAC Attack
Every device has a unique media access control (MAC) address used by network switches to move traffic around. Different types of switches have different limitations on the number of MAC addresses of which they can keep track.
A core switch typically has a large MAC table that lets it track a lot of devices while an edge switch has more MAC table limitations. When that limit is reached, the switches lose the ability to properly pass traffic where it needs to go and end up flooding all ports in an attempt to find the correct path. When this happens there is already quite a large amount of traffic being passed, resulting in dropped packets, a lot of them.
If a large number of devices are attempting to access the network at the same time, DHCP requests and ARPs become affected and we once again see a problem that looks like the Wi-Fi is broken even though the problem has nothing to do with Wi-Fi.
A more devious limitation than the number of MAC addresses a switch can handle is the number that it can handle on any one virtual LAN or subnet. A guest WLAN is generally configured for a single VLAN. But edge switches are often limited to a smaller number of MAC addresses per VLAN than they are for the switch as a whole. At an event with a very large number of people attending, the guest network is generally configured for a single VLAN. In this case every edge switch ends up seeing every MAC address of every guest connected to the network, possibly exceeding the limit of those switches for a single VLAN. Correctly sizing the edge switches, controlling broadcast domains, using multiple VLANs where possible, or tunneling traffic to beefier core switches will help avoid this problem.
Now Broadcasting
When broadcast (UDP) packets are sent by a device over Wi-Fi, they are sent at much lower speeds than if they were sent directly the end receiving device (web server, VPN, etc.). Broadcast traffic has no expectation of an acknowledgement. This means the device doesn’t always know if the packet was received. Broadcast packets are typically sent multiple times because of this.
The effect is that broadcasts take up a lot more airtime than unicast (TCP) traffic. Because Wi-Fi is a shared medium where users contend for access and wait for the network to be available before they can transmit or receive traffic, too many broadcasts will bring a network to its knees. But certain types of broadcast, such as DHCP requests and ARPs (the address resolution protocol used to get the MAC addresses of devices on the network based on IP addresses) are necessary. Simply turning off broadcast traffic is not an option.
Good network design always accommodates broadcasts but limits them as much as possible. A large, flat, Layer 2 network, such as is typical for an event like a trade show or football game, is a perfect opportunity for broadcasts to kill the network. Every device sees every other devices broadcasts – whether they need to or not. Worse yet, while traffic is broadcast, no other devices can't send real data.
Too many broadcasts within a wired network will be just as deadly as too many broadcasts over the air. The result looks like the Wi-Fi network is overloaded when that is not the case at all. Packets will be dropped at the switches when a packets per second limitation is reached.
On the Wi-Fi side, client isolation can help to reduce the effect and also provide security to the wireless devices. It’s also necessary to control broadcasts within the switched side of the network too; using VLANs to reduce broadcast domains. Switches that allow VLANs to be dynamically assigned to a single or group of devices help solve this problem.
Got Perspective?
Ultimately, Wi-Fi often gets a bad rap when it is completely undeserved. Yes, Wi-Fi is not perfect, but at the end of the day, Wi-Fi is also dependent on the wired network that connects everything together and can never exceed its capabilities. Although only touching the surface of the many challenges that impact Wi-Fi that are not Wi-Fi-related, hopefully these common wired pitfalls will give Wi-Fi whiners some much needed perspective.
