Part 2: Network configuration recommendations
The previous post in this 3-part series covered technical challenges, operational challenges, and design recommendations. This part will cover network configuration recommendations. Part 3 covers tips for the event and real-world results.
These are more practical tips for the network, this time focusing on specific network configurations and settings we’ve found to be helpful in large event scenarios.
- Enable bandwidth limits
- Shape application traffic
- Enable NAT
- Limit splash page size
- Enable auto channel assignment
- Enable channel spreading
- Enable band steering
- Reduce AP transmit power
- Set 5 GHz channel width to 20 MHz instead of 40 MHz
- Avoid interference
- Use static IP addresses on APs
- Disable legacy 802.11b rates
This is probably the most important single consideration. If bandwidth limits are not enabled, a small number of clients can quickly saturate a channel. For most events, a per-client limit of 100-200 kbit/s is appropriate, and this will provide a snappy web browsing experience, reasonably fast email, and usable video. Higher limits (1-2 Mbit/s) will, of course, enable higher-bandwidth applications. However, this will require that there is enough local and wide area bandwidth available to support all users at this limit.
One simple and effective strategy is to start with low limits and, if no problems are encountered, then gradually increase the limit. It’s very easy to change the limit using the dashboard:
Make sure to disable SpeedBurst. SpeedBurst allows users to temporarily exceed the bandwidth limit for short periods while still keeping them under the bandwidth limit over time. For large events with many users, this is undesirable.
Consider blocking applications that might be considered abusive, such as file-sharing software. Also consider rate-limiting applications that may consume large amounts of bandwidth, or those that do so automatically or perhaps with little notice from the user, such as automatic backup software. For example, @cramforce recently noted: “One person at JSConf uploaded 9.6 GB in the first 30 minutes of the conference.” — Ouch! Using Meraki’s layer 7 application traffic shaping, you don’t have to worry about protocols, ports, or IP addresses. That goes for the end-user and the application as well.
Centralized DHCP servers often fail or become slow when hundreds or thousands of clients request an IP address in a short time. Imagine all those conference attendees attempting to join the network at the same time. Painful! We strongly recommend enabling Meraki NAT, which spreads the DHCP load among all the APs.
We recommend limiting the size of the splash page, if you use one. This reduces congestion during a time at which many clients are accessing the network for the first time. 10-50 KB is a reasonable target.
Auto channel assignment allows the Meraki Cloud Controller to assign channels to Meraki APs in the network using RF information that the APs constantly send up to the Cloud Controller. Unlike traditional wireless solutions, in which channel assignment decisions are made by each AP in a localized manner, the Meraki Cloud Controller ensures that channel assignments make sense locally as well as globally, relative to the rest of the network.
Channel spreading enables Meraki APs in the same vicinity (e.g. in the same auditorium) to broadcast on different channels so that channel utilization on each channel is minimized. This maximizes throughput and minimizes interference in the network. The Meraki Cloud Controller automatically assigns channels to achieve channel spreading.
Band steering forces 5 GHz-capable wireless devices (e.g. most 802.11n clients) to migrate away from the 2.4 GHz band. This opens up radio spectrum for legacy wireless devices (e.g. 802.11b/g clients). This is highly beneficial since there are many more 5 GHz channels than 2.4 GHz channels.
Reduced transmit power reduces the range of the AP, such that a user associates only with the nearest AP in a room containing multiple APs. This helps distribute the users across the APs deployed in a single physical space.
Normally, the 5 GHz band is used to support higher-bandwidth applications and users. In this case, this configuration allows for a greater number of individual channels, which is usually desired in a high-density setup. This change is only applied to 5 GHz radios since 2.4 GHz radios already use 20 MHz channels by default.
The Meraki Cloud Controller will automatically select the right channels to use for each AP based on channel spreading, interference, and other factors. You can use the channel planning report to view how the channels are occupied.
This setting reduces the APs’ dependency on an upstream DHCP server.
Slow rates (e.g. 1 or 2 Mbit/s) can enable a small number of clients to consume a disproportionate amount of “airtime.”
Proactively configuring these settings will go a long way towards ensuring your wireless network is prepared to handle the most demanding users and applications. Then, during the event, time can be spent troubleshooting specific issues as they arise, instead of trying to find the optimal network configuration settings on-the-fly. Don’t miss part 3 of this series – tips for the event and real-world results.