Passer au contenu principal
Français

Pourquoi le WiFi de votre stade s'arrête (et comment y remédier)

Ce guide technique faisant autorité examine la cause profonde de la congestion du WiFi dans les stades — le bruit de fond simultané de 50 000 appareils chargeant des publicités programmatiques et de la télémétrie — et fournit un plan architectural détaillé pour le déploiement du filtrage DNS en périphérie comme stratégie d'atténuation principale. Conçu pour les directeurs informatiques, les CTO et les architectes réseau, il offre des conseils de mise en œuvre exploitables, des études de cas réels et des cadres de ROI mesurables pour aider les opérateurs de sites à récupérer de la bande passante et à offrir une connectivité haute performance à grande échelle.

📖 9 min de lecture📝 2,015 mots🔧 2 exemples concrets❓ 3 questions d'entraînement📚 9 définitions clés

Écouter ce guide

Voir la transcription du podcast
Welcome to the Purple Enterprise Networking Briefing. I'm your host, and today we're addressing a catastrophic failure mode that plagues high-density venues globally: the stadium WiFi grind. You've provisioned a multi-gigabit backhaul. You've deployed high-density access points under every third seat. Your RF planning is flawless. Yet, when the stadium hits 80% capacity, the network chokes. Throughput plummets, latency spikes, and your captive portal times out. Why? It's not your hardware. It's the background noise. Today, we're unpacking how 50,000 devices simultaneously loading background advertisements cause catastrophic network congestion, and how edge filtering is the strategic mitigation you need. Let's look at the telemetry. When a fan connects to your network, they aren't just sending the traffic they actively request — like posting a photo or checking scores. Their device is a beacon for background processes. Applications are constantly polling servers for updates, syncing data, and most aggressively, loading programmatic advertisements and tracking pixels. Consider a typical mobile app. It might contain a dozen different SDKs for analytics, crash reporting, and ad networks. Now, multiply that by 50,000 devices. The sheer volume of DNS requests and small-packet TCP handshakes creates a massive state-table burden on your firewalls and gateways. We're not talking about large, sustained payloads like video streaming; we're talking about millions of micro-transactions. This is what we call chatter. This chatter consumes up to 60% of your available bandwidth before a single user actively browses a webpage. It exhausts NAT pools, spikes CPU utilisation on edge routers, and saturates the airtime with management frames and small data payloads, reducing the overall spectral efficiency of your WiFi deployment. The standard response from IT is often to buy more bandwidth or upgrade the access points. But you cannot out-provision bad traffic. You have to filter it. Now, let's get into the architecture. When we talk about state-table exhaustion, we're referring to the memory your firewall uses to track every active connection. In a stadium, you might have 50,000 devices each generating 20 to 30 background connections simultaneously. That's potentially over a million concurrent connection states. Most enterprise firewalls are not sized for this. The result is dropped packets, failed connections, and a network that appears broken even when the WAN circuit is barely utilised. The airtime problem is equally severe. WiFi is a shared medium governed by the 802.11 standard. Every device that transmits — even a small background packet — must contend for airtime. In a high-density deployment, the overhead from millions of background micro-transactions means that legitimate user traffic is constantly waiting for its turn. This manifests as high latency and poor throughput, even when the access points are technically operating within specification. The DNS layer is particularly revealing. In a typical stadium deployment, we see ad network domains appearing in the top five most-requested DNS entries. Domains like doubleclick.net, googlesyndication.com, and various third-party analytics platforms receive millions of queries per event. Each query, while small, contributes to the aggregate load on your DNS resolvers and the downstream connection attempts. This brings us to the mitigation strategy: Edge DNS Filtering. By deploying a DNS filter at the edge of your network, you can intercept and null-route requests to known ad networks, telemetry servers, and malware domains before they establish a TCP connection. Implementation requires precision. You don't want to break legitimate application functionality. The best practice is to integrate filtering with your identity provider and captive portal. When a user authenticates, the policy is applied dynamically. This allows you to offer differentiated experiences — stricter filtering for general admission, more permissive policies for corporate suites or press areas. A common pitfall here is ignoring DNS over HTTPS, or DoH. Modern browsers and operating systems try to bypass local DNS to use encrypted external resolvers. If you don't block known DoH providers at the IP level, your DNS filtering strategy is bypassed entirely. You must force DNS traffic to use your local, filtered resolvers to reclaim that bandwidth. This means blocking outbound port 53 to all external destinations, and explicitly blocking the IP addresses of major DoH providers like Cloudflare's 1.1.1.1 and Google's 8.8.8.8 at the firewall level. Another pitfall is the walled garden configuration. Before a user authenticates through the captive portal, their device is in an unauthenticated state. If your walled garden is too permissive, background traffic will flow freely, exhausting your state table before users even log in. Tighten the walled garden to allow only the minimum required for DHCP, DNS, and portal access. Let's hit a few common questions from CTOs. Question one: Will blocking ads upset users? No. Users generally prefer faster load times and less battery drain. The only complaints come if you block a core service, which is why policy tuning is critical. A monitor-only phase before enforcement is essential. Question two: What's the ROI on this? We typically see a 30 to 40 percent reduction in WAN bandwidth utilisation. That extends the lifecycle of your current infrastructure and drastically improves the user experience, driving higher engagement with your own venue applications. For a stadium spending 50,000 pounds per year on WAN connectivity, that's a potential saving of 15,000 to 20,000 pounds annually, before you factor in the avoided hardware refresh costs. To summarise: High-density WiFi fails not because of hardware limits, but because of background app chatter and ad networks. The fix is aggressive, intelligent Edge DNS filtering coupled with strict DoH blocking. If you're managing a stadium, a retail chain, or a large public sector deployment, audit your DNS traffic today. Look at the top requested domains. You'll likely find ad networks dominating the list. Implement filtering, reclaim your bandwidth, and deliver the high-performance network your users expect. For further reading, Purple's guides on DNS over HTTPS implications for public WiFi and profile-based authentication are essential reading for any network architect working in high-density environments. Thank you for joining this technical briefing. I'll see you next time.

header_image.png

Résumé Exécutif

Pour les CTO et les directeurs informatiques gérant des sites à haute densité, le phénomène de la lenteur du WiFi dans les stades est un risque opérationnel persistant et coûteux. Malgré des dépenses d'investissement importantes pour des liaisons dorsales multi-gigabit, des points d'accès haute densité et une planification RF méticuleuse, les réseaux s'arrêtent fréquemment lorsque la capacité du site dépasse 80 %. La cause profonde est rarement une limitation matérielle. Il s'agit de l'avalanche invisible de trafic de fond. Lorsque 50 000 appareils se connectent simultanément à un réseau Guest WiFi , ils initient des millions de micro-transactions — chargement de publicités programmatiques, synchronisation de la télémétrie et exécution d'appels SDK en arrière-plan. Ce « bavardage » peut consommer jusqu'à 60 % de la bande passante disponible avant même qu'un seul utilisateur ne navigue activement sur le web, épuisant les pools NAT et saturant le temps d'antenne. Ce guide détaille les mécanismes techniques de cette congestion, fournit un plan architectural indépendant des fournisseurs pour la mise en œuvre du filtrage DNS en périphérie, et quantifie le ROI de cette démarche.

Approfondissement Technique : L'Anatomie de la Congestion à Haute Densité

L'Avalanche de Trafic de Fond

Lorsqu'un appareil s'associe à un réseau WiFi invité, il commence immédiatement une cascade d'activités en arrière-plan qui n'ont rien à voir avec ce que l'utilisateur fait activement. Les applications mobiles modernes sont intégrées avec de nombreux SDK tiers — pour les plateformes d'analyse, les services de rapport d'erreurs et les réseaux publicitaires programmatiques. Chaque SDK fonctionne indépendamment, interrogeant ses propres serveurs selon son propre calendrier. Dans un environnement de stade, 50 000 appareils effectuant ces actions simultanément créent un profil de trafic fondamentalement différent de tout autre scénario de déploiement.

Ce trafic est caractérisé par des requêtes à volume élevé et à faible charge utile : poignées de main TCP de petits paquets, requêtes DNS et requêtes HTTP GET pour les pixels de suivi et les créations publicitaires. Bien que le total des données transférées par appareil puisse sembler négligeable isolément, l'effet agrégé sur l'efficacité spectrale du réseau est dévastateur. La norme IEEE 802.11 stipule que le WiFi est un médium partagé ; chaque paquet transmis par n'importe quel appareil doit concourir pour le temps d'antenne. Des millions de micro-transactions en arrière-plan saturent ce médium partagé, laissant un temps d'antenne insuffisant pour les sessions utilisateur légitimes.

congestion_explainer.png

Trois Modes de Défaillance à Grande Échelle

La congestion à haute densité se manifeste généralement par trois modes de défaillance distincts, qui se produisent souvent simultanément :

Mode de Défaillance Cause Technique Symptôme Perçu par l'Utilisateur
Épuisement de la Table d'État Le pare-feu/passerelle NAT manque de mémoire de suivi des connexions Paquets perdus, délais d'attente de connexion, échecs du portail captif
Saturation du Temps d'Antenne Le médium RF partagé est submergé par les micro-transactions en arrière-plan Latence élevée, faible débit malgré un faible nombre de clients AP
Surcharge du Résolveur DNS Les résolveurs locaux sont submergés par les requêtes des réseaux publicitaires et de télémétrie Chargement lent des pages, échecs d'applications, retards d'authentification

L'Épuisement de la Table d'État est le plus insidieux de ces modes. Un pare-feu d'entreprise typique peut être dimensionné pour gérer 500 000 à 1 000 000 d'états de connexion simultanés. Dans un stade de 50 000 appareils, chaque appareil maintenant 20 à 30 connexions en arrière-plan, le nombre théorique d'états de connexion dépasse un million avant de prendre en compte tout trafic utilisateur actif. Le résultat est la perte de paquets et l'échec des connexions à tous les niveaux, affectant chaque utilisateur quel que soit son propre comportement.

La Saturation du Temps d'Antenne est aggravée par le mécanisme de contention 802.11 (CSMA/CA). Chaque appareil doit écouter avant de transmettre, et la probabilité de collision augmente exponentiellement avec la densité des appareils. Le trafic de fond des réseaux publicitaires et des services de télémétrie force le trafic utilisateur légitime à faire la queue, augmentant la latence et réduisant le débit effectif bien en dessous de la capacité théorique des points d'accès.

La Surcharge du Résolveur DNS est souvent négligée. Dans un déploiement de stade typique, WiFi Analytics révèle que les domaines des réseaux publicitaires — tels que ceux exploités par les principales plateformes de publicité programmatique — apparaissent constamment parmi les cinq entrées DNS les plus interrogées. Chaque requête, bien qu'individuellement petite, contribue à la charge agrégée sur les résolveurs locaux et déclenche des tentatives de connexion TCP en aval qui alourdissent davantage la table d'état.

Guide d'Implémentation : Architecture de Filtrage DNS en Périphérie

La réponse stratégique à ce modèle de défaillance n'est pas de provisionner plus de matériel, mais d'éliminer la source du bruit. Le Filtrage DNS en Périphérie est la principale stratégie d'atténuation, et lorsqu'il est correctement déployé, il peut récupérer jusqu'à 40 % de la bande passante WAN et réduire la latence moyenne de 60 ms ou plus.

Plan Architectural

Le filtrage DNS en périphérie fonctionne en interceptant les requêtes DNS à la périphérie du réseau. Lorsqu'un appareil demande l'adresse IP d'un réseau publicitaire connu, d'un serveur de télémétrie ou d'un domaine malveillant, le filtre répond avec une route nulle — soit en renvoyant 0.0.0.0 soit une réponse NXDOMAIN. Cela empêche l'appareil d'établir une connexion TCP, éliminant ainsi la surcharge de la table d'état associée, la consommation de temps d'antenne et l'utilisation de la bande passante WAN.

edge_filtering_architecture.png

Étapes de Déploiement

Étape 1 : Déployer des Résolveurs DNS Locaux Implémentez des résolveurs DNS locaux hautement disponibles à la périphérie du site. Ceux-ci doivent être capables de gérer la charge complète des requêtes de la population d'appareils connectés. Ne vous fiez pas uniquement aux résolveurs FAI en amont, car cela introduit de la latence et remaméliore votre capacité de filtrage.

Étape 2 : Intégrer les flux de renseignements sur les menaces et de blocage des publicités Abonnez-vous à des flux de renseignements sur les menaces de niveau entreprise qui incluent les domaines de réseaux publicitaires connus, les serveurs de télémétrie et l'infrastructure de logiciels malveillants. Ces flux doivent être mis à jour dynamiquement — idéalement toutes les quelques heures — pour détecter les domaines nouvellement enregistrés utilisés par les réseaux publicitaires pour échapper au blocage.

Étape 3 : Configurer la politique DHCP Configurez les serveurs DHCP pour distribuer les adresses IP des résolveurs locaux filtrés à tous les appareils invités. C'est le mécanisme d'application principal pour diriger le trafic DNS client à travers le filtre.

Étape 4 : Implémenter les règles de pare-feu de sortie (Egress) Cette étape est critique et souvent omise. Implémentez des règles de pare-feu de sortie strictes pour bloquer tout le trafic DNS sortant (port TCP/UDP 53) vers toute destination autre que les résolveurs locaux approuvés. Cela empêche les appareils avec des paramètres DNS codés en dur de contourner le filtre.

Étape 5 : Gérer le DNS over HTTPS (DoH) Comme détaillé dans notre guide sur DNS Over HTTPS (DoH) : Implications pour le filtrage du WiFi public , les systèmes d'exploitation et les navigateurs modernes utilisent de plus en plus le DoH pour chiffrer les requêtes DNS, les acheminant vers des résolveurs externes et contournant entièrement le filtrage local. Les administrateurs réseau doivent explicitement bloquer les adresses IP des fournisseurs DoH connus au niveau du pare-feu. Cela force le client à revenir au DNS standard non chiffré, qui peut alors être filtré. L'équivalent en portugais de ce guide est disponible à l'adresse DNS Over HTTPS (DoH): Implicações para a Filtragem de WiFi Público pour les déploiements internationaux.

Étape 6 : Intégrer avec la gestion des identités et des accès Pour une efficacité maximale, liez les politiques de filtrage DNS à l'authentification des utilisateurs. L'exploitation de l' authentification basée sur le profil — telle qu'explorée dans notre guide 2026 sur l'accès sans mot de passe — permet aux lieux d'appliquer des politiques de filtrage différenciées basées sur les rôles des utilisateurs. Les utilisateurs en admission générale reçoivent un filtrage agressif ; les utilisateurs de la presse, d'entreprise ou VIP peuvent recevoir des politiques plus permissives qui autorisent des applications métier spécifiques.

Études de cas

Étude de cas 1 : Stade de football de 60 000 places, Royaume-Uni

Un club de football de Premier League connaissait une grave dégradation du réseau à la mi-temps, avec le Captive Portal expirant et le partage sur les réseaux sociaux échouant aux moments de pointe. Le circuit WAN était une connexion dédiée de 10 Gbit/s, fonctionnant à seulement 28 % d'utilisation pendant l'incident. La table d'état du pare-feu, cependant, était à 97 % de sa capacité.

Suite à un audit de trafic utilisant WiFi Analytics , l'équipe a identifié que les domaines de réseaux publicitaires représentaient 61 % de toutes les requêtes DNS. Les cinq premiers domaines étaient tous des infrastructures de publicité programmatique. Le filtrage DNS en périphérie a été déployé avec une liste de blocage de 1,2 million de domaines, combiné à des règles de sortie strictes bloquant le port 53 et les adresses IP des fournisseurs DoH.

Le résultat : l'utilisation de la table d'état est tombée à 34 % à la capacité maximale, la latence moyenne est passée de 280 ms à 95 ms, et l'utilisation de la bande passante WAN au pic est passée de 28 % à 17 % — une réduction de 39 % de la bande passante consommée malgré aucun changement dans le nombre d'appareils connectés.

Étude de cas 2 : Centre de conférence international, secteur de l' hôtellerie

Un grand centre de conférence accueillant un sommet technologique de 15 000 délégués recevait des plaintes des participants concernant la lenteur du WiFi malgré une infrastructure récemment mise à niveau. Le lieu avait déployé 400 points d'accès de niveau entreprise et un circuit WAN de 5 Gbit/s.

L'analyse du trafic a révélé que les appareils des délégués — principalement des ordinateurs portables d'entreprise avec plusieurs applications d'entreprise en cours d'exécution — généraient en moyenne 45 connexions en arrière-plan par appareil. Le résolveur DNS traitait 2,3 millions de requêtes par heure, dont 68 % étaient destinées aux réseaux publicitaires et aux plateformes d'analyse.

Suite au déploiement du filtrage DNS en périphérie avec intégration de la politique liée au système d'inscription à la conférence, le lieu a constaté une réduction de 52 % du volume de requêtes DNS, une réduction de 41 % de l'utilisation de la table d'état du pare-feu, et une amélioration mesurée du temps moyen d'établissement de connexion TCP de 180 ms à 62 ms. Les scores de satisfaction des délégués pour la qualité du WiFi sont passés de 3,1 à 4,6 sur 5.

Bonnes pratiques et normes

Les bonnes pratiques neutres vis-à-vis des fournisseurs suivantes reflètent les normes industrielles actuelles pour les déploiements WiFi à haute densité :

  • IEEE 802.11ax (Wi-Fi 6/6E) : Déployez des points d'accès Wi-Fi 6 ou 6E. Les fonctionnalités OFDMA et BSS Colouring réduisent considérablement la contention du temps d'antenne dans les environnements à haute densité, complétant la réduction de trafic obtenue par le filtrage DNS.
  • WPA3-Enterprise : Appliquez WPA3-Enterprise avec l'authentification IEEE 802.1X pour tout déploiement traitant des données sensibles. Il s'agit d'une exigence de base pour la conformité PCI DSS dans les environnements de vente au détail et s'aligne sur les principes de minimisation des données du GDPR.
  • Conformité GDPR : Communiquez de manière transparente l'utilisation des outils d'optimisation réseau, y compris le filtrage DNS, dans les conditions de service du Captive Portal. Les utilisateurs doivent être informés que les requêtes DNS sont traitées localement dans le cadre de la fonction de gestion du réseau.
  • Surveillance et analyse : Surveillez en permanence les domaines les plus demandés à l'aide de WiFi Analytics et ajustez les politiques de filtrage en conséquence. Les réseaux publicitaires enregistrent régulièrement de nouveaux domaines pour échapper au blocage ; les listes de blocage statiques deviennent obsolètes en quelques jours.
  • Déploiements dans le secteur public : Pour les déploiements WiFi du secteur public et des villes intelligentes, comme discuté dans le contexte de l' expansion de Purple dans le secteur public , le filtrage DNS remplit également une fonction de protection, bloquant l'accès aux catégories de contenu nuisible conformément aux exigences des autorités locales.

Dépannage et atténuation des risques

Faux positifs

Risque : Un filtrage trop agressif peut bloquer les fonctionnalités légitimes des applications, telles que les applications de billetterie, les services de navigation de site ou les points d'accès VPN d'entreprise.

Atténuation : Mettez en œuvre une liste blanche stricte pour les domaines critiques identifiés lors d'une phase de référence en mode surveillance uniquement. Ne passez jamais directement en mode d'application dans un environnement de production. Une période de surveillance de deux semaines est la référence minimale recommandée avant l'application.

Contournement du Captive Portal via le trafic en arrière-plan

Risque : Les appareils peuvent ne pas déclencher le Captive Portal si le trafic en arrière-plan satisfait le mécanisme de détection du Captive Portal du système d'exploitation (par exemple, la vérification captive.apple.com d'Apple) avant que l'utilisateur n'ouvre un navigateur.

Atténuation : Renforcez le « jardin clos » pour n'autoriser que les domaines spécifiques requis pour la détection et l'authentification du Captive Portal. Tout autre trafic doit être bloqué jusqu'à ce que l'utilisateur soit entièrement authentifié et que la politique de filtrage soit appliquée à sa session.

Contournement DoH

Risque : Les appareils utilisant DoH contourneront le filtrage DNS local, rendant l'ensemble de la stratégie inefficace pour ces clients.

Atténuation : Maintenez une liste noire à jour des adresses IP des fournisseurs DoH et bloquez-les au niveau du pare-feu. Il ne s'agit pas d'une configuration unique ; de nouveaux fournisseurs DoH apparaissent régulièrement et doivent être suivis.

Services de cartes et de navigation hors ligne

Pour les sites déployant la navigation intérieure en parallèle du WiFi — comme ceux utilisant le mode Cartes hors ligne de Purple — assurez-vous que les serveurs de tuiles cartographiques et les API de navigation sont explicitement autorisés. Ces services sont essentiels à l'expérience utilisateur et ne doivent pas être bloqués par des règles de filtrage de réseau publicitaire trop larges.

ROI et impact commercial

L'analyse de rentabilisation du filtrage DNS en périphérie est convaincante à plusieurs égards :

Métrique Résultat typique Impact commercial
Réduction de la bande passante WAN 30–40% Coûts de mise à niveau des circuits reportés ; cycle de vie de l'infrastructure prolongé
Réduction de la latence 40–70ms en moyenne Engagement accru des utilisateurs avec les applications du site et les services numériques
Utilisation de la table d'état Réduction de 50 à 65 % au pic Renouvellement du matériel de pare-feu reporté ; risque d'incident réduit
Volume de requêtes DNS Réduction de 40 à 60 % Charge du résolveur réduite ; vitesse d'authentification améliorée
Satisfaction de l'utilisateur Amélioration mesurable du NPS Temps de séjour plus long, augmentation des dépenses F&B, amélioration de la perception de la marque

Pour un stade dépensant 80 000 £ par an en connectivité WAN et faisant face à un cycle de renouvellement matériel de 200 000 £, une réduction de 35 % de la bande passante se traduit par environ 28 000 £ d'économies annuelles sur le WAN et une prolongation potentielle de 18 mois du cycle de renouvellement matériel — soit une économie combinée sur trois ans dépassant 100 000 £, pour un coût de mise en œuvre généralement compris entre 15 000 £ et 30 000 £ pour un site de cette envergure.

Écoutez le briefing technique

Définitions clés

State Table Exhaustion

A condition where a firewall or NAT gateway runs out of memory allocated for tracking active network connections, causing it to drop new connection requests.

Occurs in high-density venues when tens of thousands of devices simultaneously initiate micro-connections to ad networks and telemetry servers. The primary cause of the 'stadium WiFi slow' paradox where the WAN circuit appears underutilised but the network is effectively broken.

Airtime Utilisation

The percentage of time the RF spectrum on a given WiFi channel is actively being used to transmit data or management frames.

High airtime utilisation from background chatter reduces the capacity available for active user sessions. In a high-density stadium, background traffic can drive airtime utilisation above 80%, leaving insufficient capacity for legitimate user traffic.

Edge DNS Filtering

The practice of intercepting DNS queries at the network perimeter and blocking resolution for known malicious, high-overhead, or policy-violating domains by returning a null route or NXDOMAIN response.

The primary architectural mitigation for background traffic congestion in high-density venues. Prevents devices from establishing connections to ad networks and telemetry servers, reclaiming bandwidth and reducing state table load.

DNS over HTTPS (DoH)

A protocol for performing DNS resolution via the HTTPS protocol, encrypting the DNS query and routing it to an external resolver, bypassing local DNS infrastructure.

The primary bypass mechanism for edge DNS filtering. Must be explicitly blocked at the IP level to ensure all DNS traffic passes through the local, filtered resolver.

Null Route

A network route that discards traffic destined for a specific IP address or domain, effectively dropping it without forwarding.

Used by DNS filters to respond to blocked domains — returning 0.0.0.0 or NXDOMAIN — preventing the client from initiating a TCP connection and eliminating the associated network overhead.

Walled Garden

A restricted network environment that limits device access to a predefined set of resources, typically used to enforce captive portal authentication before granting full internet access.

Must be strictly configured to prevent background traffic from satisfying OS captive portal detection mechanisms before the user authenticates, which would allow unrestricted background traffic to flow without a filtering policy being applied.

Profile-Based Authentication

An authentication method that dynamically applies specific network policies — including DNS filtering rules, bandwidth limits, and access controls — based on the authenticated user's identity or role.

Enables venues to offer differentiated network experiences, applying aggressive filtering to general admission users while providing more permissive policies to VIPs, press, or corporate guests.

OFDMA (Orthogonal Frequency Division Multiple Access)

A multi-user version of OFDM that allows a single WiFi 6 (802.11ax) transmission to be split across multiple users simultaneously, reducing contention and improving spectral efficiency.

A key feature of Wi-Fi 6 that directly addresses airtime contention in high-density deployments. Works in conjunction with DNS filtering to maximise the usable capacity of each access point.

Spectral Efficiency

The amount of useful data that can be transmitted over a given bandwidth in a specific communication system.

Reduced by background micro-transactions that consume airtime without delivering value to end users. Edge filtering and Wi-Fi 6 features like OFDMA work together to maximise spectral efficiency.

Exemples concrets

A 50,000-seat stadium is experiencing severe network degradation during halftime. The IT team has verified that the 10Gbps WAN circuit is only at 30% utilisation, but APs are reporting high airtime utilisation and the firewall state table is at 95% capacity. Adding more APs has not improved performance.

The issue is not raw bandwidth or AP density, but connection state exhaustion caused by background application chatter. The solution requires deploying an Edge DNS Filter in a phased approach. Phase 1: Deploy local DNS resolvers and configure them in monitor-only mode for two weeks. Analyse the top 100 queried domains. Phase 2: Configure DHCP to point all guest clients to the local resolvers. Implement egress firewall rules blocking outbound TCP/UDP Port 53 to all external IPs. Phase 3: Block the IP addresses of known DoH providers (Cloudflare 1.1.1.1, Google 8.8.8.8, etc.) at the firewall. Phase 4: Activate enforcement mode on the DNS filter with a blocklist targeting the identified ad network and telemetry domains. Phase 5: Monitor state table utilisation and airtime metrics over the next three events to validate the improvement.

Commentaire de l'examinateur : This scenario highlights the classic stadium WiFi paradox: plenty of bandwidth, but exhausted state tables. The phased approach is critical — going directly to enforcement without a monitoring baseline risks false positives that break ticketing or venue apps. The DoH blocking step is non-negotiable; without it, modern browsers will bypass the filter entirely, and the intervention will appear to have failed.

A major transport hub wants to implement DNS filtering across 12 terminal buildings to improve network performance for 80,000 daily passengers. They are concerned about breaking legitimate airline ticketing applications and airport operations systems.

Implement a centralised, cloud-managed DNS filtering platform with local forwarders at each terminal. Phase 1: Deploy local forwarders in all 12 terminals, pointing to a centralised management plane. Phase 2: Run in monitor-only mode for 30 days across all terminals simultaneously. Use the analytics to build a comprehensive allowlist of airline ticketing domains, airport operations APIs, and ground handling system endpoints. Phase 3: Segment the network into guest WiFi and operational technology (OT) VLANs. Apply aggressive filtering to guest WiFi; apply a strict allowlist-only policy to OT VLANs. Phase 4: Enforce filtering on guest WiFi. Phase 5: Implement automated allowlist management — when a new airline begins operations at the terminal, their domain requirements are added to the allowlist via a change management process.

Commentaire de l'examinateur : The transport sector presents unique challenges due to the mix of passenger-facing and operational systems on the same physical infrastructure. The critical insight here is VLAN segmentation before enforcement — applying guest WiFi filtering rules to operational systems would be catastrophic. The centralised management approach ensures policy consistency across all 12 terminals while the local forwarders provide resilience against WAN link degradation.

Questions d'entraînement

Q1. You have deployed an Edge DNS filter and configured DHCP to point all clients to the local resolver. After the first major event, you find that bandwidth utilisation has only dropped by 5%, and traffic analysis shows many devices are still successfully resolving ad network domains. What is the most likely architectural oversight, and what is the remediation?

Conseil : Consider how modern browsers and operating systems handle DNS resolution by default, and what happens when a device has a hardcoded DNS server configured.

Voir la réponse type

There are two likely causes. First, the network is failing to block DNS over HTTPS (DoH) traffic. Modern browsers will attempt to use DoH, routing encrypted DNS queries to external resolvers like Cloudflare or Google, bypassing the local filter entirely. The remediation is to implement egress firewall rules blocking the IP addresses of known DoH providers. Second, some devices may have hardcoded DNS server addresses (e.g., 8.8.8.8) in their network configuration, bypassing DHCP-assigned resolvers. The remediation is to implement egress firewall rules blocking all outbound TCP/UDP Port 53 traffic to any destination other than the local resolvers, forcing all DNS traffic through the filter regardless of client configuration.

Q2. During a major event, the captive portal is timing out for users attempting to connect, even though the APs show relatively low client counts (only 40% of capacity). The WAN circuit is at 15% utilisation. What is the likely cause, and what architectural changes would prevent this at the next event?

Conseil : Think about what happens to device traffic in the period between WiFi association and captive portal authentication, and what network resource is most likely to be exhausted.

Voir la réponse type

The firewall's state table is likely exhausted by background traffic from devices that have associated with the AP but not yet authenticated through the captive portal. In the unauthenticated state, if the walled garden is too permissive, background traffic flows freely, creating thousands of connection state entries per device. With 40% of 50,000 seats occupied (20,000 devices), even a brief window of unrestricted background traffic can exhaust the state table before users attempt to authenticate. The architectural remediation requires two changes: First, tighten the walled garden to permit only the minimum required traffic — DHCP (UDP 67/68), DNS to the local resolver only, and HTTP/HTTPS to the captive portal IP. Block all other traffic until authentication is complete. Second, consider deploying a dedicated stateless ACL at the AP or switch level to drop background traffic in the pre-authentication state, preventing it from even reaching the stateful firewall.

Q3. A retail chain with 500 locations wants to implement DNS filtering to improve POS system reliability and reduce WAN costs. They need uniform policy enforcement but also need to ensure that new point-of-sale software vendors can be onboarded without causing outages. What architectural approach should be taken, and what operational process should accompany it?

Conseil : Consider the tension between centralised policy management and the operational agility needed to support a dynamic retail technology stack.

Voir la réponse type

Deploy a cloud-managed DNS filtering solution with local forwarders at each site. The centralised management plane allows for uniform policy definition and threat feed updates across all 500 locations simultaneously, while the local forwarders ensure low-latency resolution and resilience against WAN link degradation. For operational agility, implement a tiered allowlist management process: a permanent allowlist for core POS and payment processing domains (which should be treated as change-controlled infrastructure), a temporary allowlist for new vendor onboarding (with a 90-day review cycle), and a self-service request process for store managers to flag false positives. Critically, the PCI DSS requirement for network segmentation means the POS VLAN must be isolated from the guest WiFi VLAN, with separate filtering policies applied to each. The guest WiFi policy can be aggressive; the POS policy should be allowlist-only, permitting only explicitly approved payment processor and software update domains.