Zum Hauptinhalt springen
Deutsch

Warum Ihr Stadion WiFi zum Stillstand kommt (und wie man es behebt)

Dieser maßgebliche technische Leitfaden untersucht die Ursache der Überlastung von Stadion-WiFi – das gleichzeitige Hintergrundrauschen von 50.000 Geräten, die programmatische Werbung und Telemetriedaten laden – und bietet einen detaillierten architektonischen Entwurf für die Implementierung von Edge DNS Filtering als primäre Minderungsstrategie. Entwickelt für IT-Direktoren, CTOs und Netzwerkarchitekten, liefert er umsetzbare Implementierungsanleitungen, Fallstudien aus der Praxis und messbare ROI-Frameworks, um Veranstaltungsortbetreibern zu helfen, Bandbreite zurückzugewinnen und Hochleistungs-Konnektivität in großem Maßstab bereitzustellen.

📖 9 Min. Lesezeit📝 2,015 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 9 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen
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

Zusammenfassung für die Geschäftsleitung

Für CTOs und IT-Direktoren, die Veranstaltungsorte mit hoher Dichte verwalten, ist das Phänomen des langsamen Stadion-WiFi ein anhaltendes und kostspieliges Betriebsrisiko. Trotz erheblicher Investitionen in Multi-Gigabit-Backhaul, hochdichte Access Points und sorgfältige HF-Planung kommen Netzwerke häufig zum Erliegen, wenn die Kapazität des Veranstaltungsortes 80 % übersteigt. Die Ursache ist selten eine Hardware-Einschränkung. Es ist die unsichtbare Lawine des Hintergrundverkehrs. Wenn 50.000 Geräte gleichzeitig eine Guest WiFi -Netzwerkverbindung herstellen, initiieren sie Millionen von Mikrotransaktionen – das Laden programmatischer Werbung, das Synchronisieren von Telemetriedaten und das Ausführen von Hintergrund-SDK-Aufrufen. Dieses „Rauschen“ kann bis zu 60 % der verfügbaren Bandbreite verbrauchen, bevor ein einzelner Benutzer aktiv im Web surft, wodurch NAT-Pools erschöpft und die Sendezeit gesättigt werden. Dieser Leitfaden beschreibt die technischen Mechanismen dieser Überlastung, bietet einen herstellerneutralen architektonischen Entwurf für die Implementierung von Edge DNS Filtering und quantifiziert den ROI davon.

Technischer Deep-Dive: Die Anatomie der Hochdichte-Überlastung

Die Hintergrundverkehrs-Lawine

Wenn sich ein Gerät mit einem Gast-WiFi-Netzwerk verbindet, beginnt es sofort eine Kaskade von Hintergrundaktivitäten, die nichts mit dem zu tun haben, was der Benutzer aktiv tut. Moderne mobile Anwendungen sind mit zahlreichen Drittanbieter-SDKs ausgestattet – für Analyseplattformen, Absturzberichtsdienste und programmatische Werbenetzwerke. Jedes SDK arbeitet unabhängig und fragt seine eigenen Server nach seinem eigenen Zeitplan ab. In einer Stadionumgebung erzeugen 50.000 Geräte, die diese Aktionen gleichzeitig ausführen, ein Verkehrsprofil, das sich grundlegend von jedem anderen Bereitstellungsszenario unterscheidet.

Dieser Verkehr zeichnet sich durch hohe Volumen, geringe Nutzlastanfragen aus: Small-Packet-TCP-Handshakes, DNS-Abfragen und HTTP-GET-Anfragen für Tracking-Pixel und Werbemittel. Während die pro Gerät übertragene Gesamtmenge an Daten isoliert betrachtet vernachlässigbar erscheinen mag, ist der kumulative Effekt auf die spektrale Effizienz des Netzwerks verheerend. Der IEEE 802.11 Standard schreibt vor, dass WiFi ein geteiltes Medium ist; jedes von einem Gerät übertragene Paket muss um Sendezeit konkurrieren. Millionen von Hintergrund-Mikrotransaktionen sättigen dieses gemeinsame Medium und lassen unzureichende Sendezeit für legitime Benutzersitzungen.

congestion_explainer.png

Drei Ausfallmodi im großen Maßstab

Hochdichte-Überlastung äußert sich typischerweise in drei verschiedenen Ausfallmodi, die oft gleichzeitig auftreten:

Ausfallmodus Technische Ursache Vom Benutzer wahrgenommenes Symptom
Erschöpfung der Zustandstabelle Firewall/NAT-Gateway läuft der Speicher für die Verbindungsverfolgung aus Verlorene Pakete, Verbindungs-Timeouts, Captive Portal-Fehler
Sendezeit-Sättigung Gemeinsames HF-Medium überlastet durch Hintergrund-Mikrotransaktionen Hohe Latenz, geringer Durchsatz trotz geringer AP-Client-Anzahl
DNS-Resolver-Überlastung Lokale Resolver überlastet durch Werbenetzwerk- und Telemetrieabfragen Langsame Seitenladevorgänge, App-Fehler, Authentifizierungsverzögerungen

Erschöpfung der Zustandstabelle ist die heimtückischste davon. Eine typische Unternehmens-Firewall kann für 500.000 bis 1.000.000 gleichzeitige Verbindungszustände ausgelegt sein. In einem Stadion mit 50.000 Geräten, wobei jedes Gerät 20 bis 30 Hintergrundverbindungen aufrechterhält, übersteigt die theoretische Anzahl der Verbindungszustände eine Million, noch bevor aktiver Benutzerverkehr berücksichtigt wird. Das Ergebnis sind verlorene Pakete und fehlgeschlagene Verbindungen auf breiter Front, die jeden Benutzer unabhängig von seinem eigenen Verhalten betreffen.

Sendezeit-Sättigung wird durch den 802.11-Zugriffsmechanismus (CSMA/CA) noch verstärkt. Jedes Gerät muss vor dem Senden lauschen, und die Wahrscheinlichkeit einer Kollision steigt exponentiell mit der Gerätedichte. Hintergrundverkehr von Werbenetzwerken und Telemetriediensten zwingt legitimen Benutzerverkehr in die Warteschlange, was die Latenz erhöht und den effektiven Durchsatz weit unter die theoretische Kapazität der Access Points reduziert.

DNS-Resolver-Überlastung wird oft übersehen. In einer typischen Stadionbereitstellung zeigt WiFi Analytics , dass Werbenetzwerk-Domains – wie die von großen programmatischen Werbeplattformen betriebenen – durchweg unter den Top fünf der am häufigsten abgefragten DNS-Einträge erscheinen. Jede Abfrage, obwohl einzeln klein, trägt zur Gesamtlast der lokalen Resolver bei und löst nachgeschaltete TCP-Verbindungsversuche aus, die die Zustandstabelle zusätzlich belasten.

Implementierungsleitfaden: Edge DNS Filtering Architektur

Die strategische Antwort auf dieses Fehlerbild ist nicht, mehr Hardware bereitzustellen, sondern die Quelle des Rauschens zu eliminieren. Edge DNS Filtering ist die primäre Minderungsstrategie, und bei korrekter Bereitstellung kann sie bis zu 40 % der WAN-Bandbreite zurückgewinnen und die durchschnittliche Latenz um 60 ms oder mehr reduzieren.

Architektonischer Entwurf

Edge DNS Filtering funktioniert, indem es DNS-Abfragen am Netzwerkrand abfängt. Wenn ein Gerät die IP-Adresse eines bekannten Werbenetzwerks, Telemetrieservers oder einer Malware-Domain anfordert, antwortet der Filter mit einer Nullroute – entweder durch Rückgabe von 0.0.0.0 oder einer NXDOMAIN-Antwort. Dies verhindert, dass das Gerät eine TCP-Verbindung herstellt, wodurch der damit verbundene Zustandstabellen-Overhead, der Sendezeitverbrauch und die WAN-Bandbreitennutzung eliminiert werden.

edge_filtering_architecture.png

Bereitstellungsschritte

Schritt 1: Lokale DNS-Resolver bereitstellen Implementieren Sie hochverfügbare lokale DNS-Resolver am Netzwerkrand des Veranstaltungsortes. Diese müssen in der Lage sein, die volle Abfragelast der verbundenen Gerätepopulation zu bewältigen. Verlassen Sie sich nicht ausschließlich auf Upstream-ISP-Resolver, da dies Latenz einführt und remverbessert Ihre Filterfähigkeit.

Schritt 2: Bedrohungsanalyse- und Werbeblocker-Feeds integrieren Abonnieren Sie unternehmenstaugliche Bedrohungsanalyse-Feeds, die bekannte Ad-Netzwerk-Domains, Telemetrie-Server und Malware-Infrastruktur umfassen. Diese Feeds müssen dynamisch – idealerweise alle paar Stunden – aktualisiert werden, um neu registrierte Domains zu erfassen, die von Ad-Netzwerken zur Umgehung von Blockierungen verwendet werden.

Schritt 3: DHCP-Richtlinie konfigurieren Konfigurieren Sie DHCP-Server so, dass sie die IP-Adressen der lokalen, gefilterten Resolver an alle Gastgeräte verteilen. Dies ist der primäre Durchsetzungsmechanismus, um den DNS-Verkehr der Clients durch den Filter zu leiten.

Schritt 4: Egress-Firewall-Regeln implementieren Dieser Schritt ist entscheidend und wird häufig ausgelassen. Implementieren Sie strenge Egress-Firewall-Regeln, um den gesamten ausgehenden DNS-Verkehr (TCP/UDP Port 53) zu allen Zielen außer den genehmigten lokalen Resolvern zu blockieren. Dies verhindert, dass Geräte mit fest codierten DNS-Einstellungen den Filter umgehen.

Schritt 5: DNS over HTTPS (DoH) adressieren Wie in unserem Leitfaden zu DNS Over HTTPS (DoH): Auswirkungen auf die öffentliche WiFi-Filterung beschrieben, verwenden moderne Betriebssysteme und Browser zunehmend DoH, um DNS-Anfragen zu verschlüsseln, sie an externe Resolver weiterzuleiten und die lokale Filterung vollständig zu umgehen. Netzwerkadministratoren müssen die IP-Adressen bekannter DoH-Anbieter auf Firewall-Ebene explizit blockieren. Dies zwingt den Client, auf standardmäßiges, unverschlüsseltes DNS zurückzugreifen, das dann gefiltert werden kann. Die portugiesische Version dieser Anleitung ist unter DNS Over HTTPS (DoH): Implicações para a Filtragem de WiFi Público für internationale Implementierungen verfügbar.

Schritt 6: Integration mit Identitäts- und Zugriffsmanagement Für maximale Effektivität verknüpfen Sie DNS-Filterrichtlinien mit der Benutzerauthentifizierung. Die Nutzung der profilbasierten Authentifizierung – wie in unserem Leitfaden von 2026 zum passwortlosen Zugriff erläutert – ermöglicht es Veranstaltungsorten, differenzierte Filterrichtlinien basierend auf Benutzerrollen anzuwenden. Benutzer mit allgemeinem Zugang erhalten eine aggressive Filterung; Presse-, Unternehmens- oder VIP-Benutzer können permissivere Richtlinien erhalten, die spezifische Geschäftsanwendungen zulassen.

Fallstudien

Fallstudie 1: Fußballstadion mit 60.000 Plätzen, UK

Ein Premier League Fußballverein erlebte während der Halbzeit eine starke Netzwerkverschlechterung, wobei das captive portal ablief und das Teilen in sozialen Medien in Spitzenmomenten fehlschlug. Die WAN-Leitung war eine dedizierte 10-Gbit/s-Verbindung, die während des Vorfalls nur zu 28 % ausgelastet war. Die Firewall-Statustabelle war jedoch zu 97 % ausgelastet.

Nach einer Traffic-Analyse mittels WiFi Analytics stellte das Team fest, dass Ad-Netzwerk-Domains 61 % aller DNS-Anfragen ausmachten. Die Top-Fünf-Domains waren alle programmatische Werbeinfrastrukturen. Edge DNS-Filterung wurde mit einer Blockliste von 1,2 Millionen Domains implementiert, kombiniert mit strengen Egress-Regeln, die Port 53 und DoH-Anbieter-IPs blockierten.

Das Ergebnis: Die Auslastung der Statustabelle sank bei Spitzenlast auf 34 %, die durchschnittliche Latenzzeit fiel von 280 ms auf 95 ms, und die WAN-Bandbreitenauslastung sank in Spitzenzeiten von 28 % auf 17 % – eine Reduzierung des verbrauchten Bandbreite um 39 %, obwohl sich die Anzahl der verbundenen Geräte nicht änderte.

Fallstudie 2: Internationales Konferenzzentrum, Gastgewerbe Sektor

Ein großes Konferenzzentrum, das einen Technologiegipfel mit 15.000 Delegierten veranstaltete, erhielt Beschwerden von Teilnehmern über langsames WiFi, trotz einer kürzlich aufgerüsteten Infrastruktur. Der Veranstaltungsort hatte 400 Access Points der Enterprise-Klasse und eine 5-Gbit/s-WAN-Leitung implementiert.

Die Traffic-Analyse ergab, dass die Geräte der Delegierten – überwiegend Firmenlaptops mit mehreren laufenden Unternehmensanwendungen – durchschnittlich 45 Hintergrundverbindungen pro Gerät erzeugten. Der DNS-Resolver verarbeitste 2,3 Millionen Anfragen pro Stunde, wobei 68 % für Ad-Netzwerke und Analyseplattformen bestimmt waren.

Nach der Implementierung der Edge DNS-Filterung mit Richtlinienintegration, die an das Konferenzregistrierungssystem gekoppelt war, verzeichnete der Veranstaltungsort eine Reduzierung des DNS-Anfragevolumens um 52 %, eine Reduzierung der Firewall-Statustabellen-Auslastung um 41 % und eine gemessene Verbesserung der durchschnittlichen TCP-Verbindungsaufbauzeit von 180 ms auf 62 ms. Die Zufriedenheitswerte der Delegierten für die WiFi-Qualität stiegen von 3,1 auf 4,6 von 5.

Best Practices & Standards

Die folgenden herstellerneutralen Best Practices spiegeln die aktuellen Industriestandards für WiFi-Implementierungen mit hoher Dichte wider:

  • IEEE 802.11ax (Wi-Fi 6/6E): Setzen Sie Wi-Fi 6 oder 6E Access Points ein. Die OFDMA- und BSS Colouring-Funktionen reduzieren die Airtime-Konflikte in Umgebungen mit hoher Dichte erheblich und ergänzen die durch DNS-Filterung erzielte Verkehrsreduzierung.
  • WPA3-Enterprise: Erzwingen Sie WPA3-Enterprise mit IEEE 802.1X-Authentifizierung für jede Implementierung, die sensible Daten verarbeitet. Dies ist eine Grundvoraussetzung für die PCI DSS-Konformität in Einzelhandelsumgebungen und entspricht den GDPR-Prinzipien der Datenminimierung.
  • GDPR Compliance: Kommunizieren Sie die Verwendung von Netzwerkoptimierungstools, einschließlich DNS-Filterung, transparent in den Nutzungsbedingungen des captive portal. Benutzer müssen darüber informiert werden, dass DNS-Anfragen als Teil der Netzwerkmanagementfunktion lokal verarbeitet werden.
  • Monitoring und Analytics: Überwachen Sie kontinuierlich die am häufigsten angefragten Domains mithilfe von WiFi Analytics und passen Sie die Filterrichtlinien entsprechend an. Ad-Netzwerke registrieren regelmäßig neue Domains, um Blockierungen zu umgehen; statische Blocklisten veralten innerhalb weniger Tage.
  • Implementierungen im öffentlichen Sektor: Für WiFi-Implementierungen im öffentlichen Sektor und in Smart Cities, wie im Kontext der Purple's public sector expansion erörtert, erfüllt die DNS-Filterung auch eine Schutzfunktion, indem sie den Zugriff auf schädliche Inhaltskategorien gemäß den Anforderungen der lokalen Behörden blockiert.

Fehlerbehebung & Risikominderung

Falsch positive Ergebnisse

Risiko: Eine übermäßig aggressive Filterung kann legitime Anwendungsfunktionen blockieren, wie z.B. Ticketing-Apps, Navigationsdienste für Veranstaltungsorte oder VPN-Endpunkte von Unternehmen.

Abhilfe: Implementieren Sie eine strikte Positivliste für geschäftskritische Domains, die während einer reinen Überwachungs-Baseline-Phase identifiziert wurden. Gehen Sie niemals direkt in den Erzwingungsmodus in einer Produktionsumgebung. Eine zweiwöchige Überwachungsperiode ist die minimal empfohlene Baseline vor der Erzwingung.

Captive Portal Umgehung über Hintergrundverkehr

Risiko: Geräte können das Captive Portal möglicherweise nicht auslösen, wenn Hintergrundverkehr den Captive Portal-Erkennungsmechanismus des Betriebssystems (z.B. Apples captive.apple.com-Prüfung) erfüllt, bevor der Benutzer einen Browser öffnet.

Abhilfe: Straffen Sie den Walled Garden, um nur die spezifischen Domains zuzulassen, die für die Captive Portal-Erkennung und -Authentifizierung erforderlich sind. Der gesamte andere Datenverkehr muss blockiert werden, bis der Benutzer vollständig authentifiziert ist und die Filterrichtlinie auf seine Sitzung angewendet wird.

DoH Umgehung

Risiko: Geräte, die DoH verwenden, umgehen die lokale DNS-Filterung, wodurch die gesamte Strategie für diese Clients unwirksam wird.

Abhilfe: Pflegen Sie eine aktuelle Sperrliste von DoH-Anbieter-IP-Adressen und blockieren Sie diese an der Firewall. Dies ist keine einmalige Konfiguration; neue DoH-Anbieter tauchen regelmäßig auf und müssen verfolgt werden.

Offline-Karten- und Navigationsdienste

Für Veranstaltungsorte, die Indoor-Navigation zusammen mit WiFi einsetzen – wie z.B. solche, die Purple's Offline Maps Mode verwenden – stellen Sie sicher, dass die Kartenserver und Navigations-APIs explizit auf die Positivliste gesetzt werden. Diese Dienste sind entscheidend für die Benutzererfahrung und dürfen nicht von allgemeinen Werbenetzwerk-Filterregeln erfasst werden.

ROI & Geschäftsauswirkungen

Das Geschäftsmodell für Edge-DNS-Filterung ist in mehrfacher Hinsicht überzeugend:

Metrik Typisches Ergebnis Geschäftsauswirkungen
WAN-Bandbreitenreduzierung 30–40% Aufgeschobene Kosten für Schaltungs-Upgrades; verlängerter Infrastruktur-Lebenszyklus
Latenzreduzierung 40–70ms durchschnittlich Höhere Benutzerinteraktion mit Venue-Apps und digitalen Diensten
Auslastung der Zustandstabelle 50–65% Reduzierung in Spitzenzeiten Aufgeschobene Firewall-Hardware-Erneuerung; reduziertes Vorfallrisiko
DNS-Abfragevolumen 40–60% Reduzierung Reduzierte Resolver-Last; verbesserte Authentifizierungsgeschwindigkeit
Benutzerzufriedenheit Messbare NPS-Verbesserung Längere Verweildauer, erhöhte Ausgaben für Speisen und Getränke, verbesserte Markenwahrnehmung

Für ein Stadion, das jährlich 80.000 £ für WAN-Konnektivität ausgibt und vor einem Hardware-Erneuerungszyklus von 200.000 £ steht, bedeutet eine Bandbreitenreduzierung von 35 % jährliche WAN-Einsparungen von etwa 28.000 £ und eine potenzielle Verlängerung des Hardware-Erneuerungszyklus um 18 Monate – eine kombinierte Dreijahresersparnis von über 100.000 £, gegenüber Implementierungskosten, die für einen Veranstaltungsort dieser Größenordnung typischerweise zwischen 15.000 £ und 30.000 £ liegen.

Hören Sie sich das technische Briefing an

Schlüsseldefinitionen

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.

Ausgearbeitete Beispiele

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.

Kommentar des Prüfers: 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.

Kommentar des Prüfers: 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.

Übungsfragen

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?

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

Musterlösung anzeigen

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?

Hinweis: 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.

Musterlösung anzeigen

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?

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

Musterlösung anzeigen

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.