¿Por qué el WiFi de tu estadio se detiene (y cómo solucionarlo)?

Esta guía técnica autorizada examina la causa raíz de la congestión del WiFi en estadios — el ruido de fondo simultáneo de 50,000 dispositivos cargando anuncios programáticos y telemetría — y proporciona un plan arquitectónico detallado para implementar el filtrado DNS de borde como estrategia de mitigación principal. Diseñada para Directores de TI, CTOs y Arquitectos de Red, ofrece orientación de implementación práctica, estudios de caso reales y marcos de ROI medibles para ayudar a los operadores de recintos a recuperar ancho de banda y ofrecer conectividad de alto rendimiento a escala.

📖 9 min de lectura📝 2,015 palabras🔧 2 ejemplos resueltos❓ 3 preguntas de práctica📚 9 definiciones clave

Escucha esta guía

Ver transcripción del 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.

Puntos clave

✓Stadium WiFi congestion is almost never caused by insufficient hardware; the root cause is background application chatter from ad networks, analytics SDKs, and telemetry services consuming up to 60% of available bandwidth.
✓State table exhaustion — not bandwidth saturation — is the primary failure mode: 50,000 devices each maintaining 20-30 background connections can exhaust enterprise firewall capacity before a single user actively browses.
✓You cannot out-provision bad traffic. Adding more APs or a larger WAN circuit will not fix a problem caused by millions of micro-transactions exhausting connection state resources.
✓Edge DNS Filtering is the primary mitigation: intercepting and null-routing DNS queries to known ad networks prevents TCP connections from being established, reclaiming up to 40% of WAN bandwidth and reducing latency by 40-70ms.
✓Blocking DoH is mandatory: without explicitly blocking DNS over HTTPS provider IP addresses at the firewall, modern browsers will bypass local DNS filtering entirely, rendering the strategy ineffective.
✓Always deploy in monitor-only mode first: a minimum two-week baseline is required to build an accurate allowlist of mission-critical domains before enforcement mode is activated.
✓The ROI is measurable and significant: a typical stadium deployment sees WAN cost reductions of 30-40%, deferred hardware refresh cycles, and measurable improvements in user satisfaction scores.

Resumen Ejecutivo

Para los CTOs y Directores de TI que gestionan recintos de alta densidad, el fenómeno de la lentitud del WiFi en estadios es un riesgo operativo persistente y costoso. A pesar de la importante inversión de capital en backhaul multigigabit, puntos de acceso de alta densidad y una planificación RF meticulosa, las redes con frecuencia se detienen cuando la capacidad del recinto supera el 80%. La causa raíz rara vez es una limitación de hardware. Es la avalancha invisible de tráfico de fondo. Cuando 50,000 dispositivos se conectan simultáneamente a una red Guest WiFi , inician millones de microtransacciones — cargando anuncios programáticos, sincronizando telemetría y ejecutando llamadas de SDK en segundo plano. Este "ruido" puede consumir hasta el 60% del ancho de banda disponible antes de que un solo usuario navegue activamente por la web, agotando los grupos NAT y saturando el tiempo de aire. Esta guía detalla la mecánica técnica de esta congestión, proporciona un plan arquitectónico neutral en cuanto a proveedores para implementar el filtrado DNS de borde y cuantifica el ROI de hacerlo.

Análisis Técnico Detallado: La Anatomía de la Congestión de Alta Densidad

La Avalancha de Tráfico de Fondo

Cuando un dispositivo se asocia con una red WiFi de invitados, inmediatamente comienza una cascada de actividad en segundo plano que no tiene nada que ver con lo que el usuario está haciendo activamente. Las aplicaciones móviles modernas están integradas con numerosos SDK de terceros — para plataformas de análisis, servicios de informes de fallos y redes de anuncios programáticos. Cada SDK opera de forma independiente, consultando sus propios servidores según su propio horario. En un entorno de estadio, 50,000 dispositivos realizando estas acciones simultáneamente crean un perfil de tráfico fundamentalmente diferente a cualquier otro escenario de implementación.

Este tráfico se caracteriza por solicitudes de alto volumen y baja carga útil: handshakes TCP de paquetes pequeños, consultas DNS y solicitudes HTTP GET para píxeles de seguimiento y creatividades publicitarias. Si bien el total de datos transferidos por dispositivo puede parecer insignificante de forma aislada, el efecto agregado en la eficiencia espectral de la red es devastador. El estándar IEEE 802.11 dicta que el WiFi es un medio compartido; cada paquete transmitido por cualquier dispositivo debe competir por el tiempo de aire. Millones de microtransacciones en segundo plano saturan este medio compartido, dejando un tiempo de aire insuficiente para sesiones de usuario legítimas.

Tres Modos de Fallo a Escala

La congestión de alta densidad se manifiesta típicamente a través de tres modos de fallo distintos, que a menudo ocurren simultáneamente:

Modo de Fallo	Causa Técnica	Síntoma Percibido por el Usuario
Agotamiento de la Tabla de Estados	El firewall/gateway NAT se queda sin memoria de seguimiento de conexiones	Paquetes perdidos, tiempos de espera de conexión, fallos del Captive Portal
Saturación del Tiempo de Aire	Medio RF compartido abrumado por microtransacciones en segundo plano	Alta latencia, bajo rendimiento a pesar del bajo número de clientes AP
Sobrecarga del Resolutor DNS	Resolutores locales abrumados por consultas de redes de anuncios y telemetría	Carga lenta de páginas, fallos de aplicaciones, retrasos en la autenticación

El Agotamiento de la Tabla de Estados es el más insidioso de estos. Un firewall empresarial típico puede estar dimensionado para manejar entre 500,000 y 1,000,000 de estados de conexión concurrentes. En un estadio de 50,000 dispositivos, con cada dispositivo manteniendo entre 20 y 30 conexiones en segundo plano, el recuento teórico de estados de conexión supera el millón antes de contabilizar cualquier tráfico de usuario activo. El resultado son paquetes perdidos y conexiones fallidas en general, afectando a cada usuario independientemente de su propio comportamiento.

La Saturación del Tiempo de Aire se agrava por el mecanismo de contención 802.11 (CSMA/CA). Cada dispositivo debe escuchar antes de transmitir, y la probabilidad de colisión aumenta exponencialmente con la densidad de dispositivos. El tráfico de fondo de las redes de anuncios y los servicios de telemetría obliga al tráfico de usuario legítimo a hacer cola, aumentando la latencia y reduciendo el rendimiento efectivo muy por debajo de la capacidad teórica de los puntos de acceso.

La Sobrecarga del Resolutor DNS a menudo se pasa por alto. En una implementación típica de estadio, WiFi Analytics revela que los dominios de redes de anuncios — como los operados por las principales plataformas de publicidad programática — aparecen consistentemente entre las cinco entradas DNS más consultadas. Cada consulta, aunque individualmente pequeña, contribuye a la carga agregada en los resolutores locales y desencadena intentos de conexión TCP posteriores que sobrecargan aún más la tabla de estados.

Guía de Implementación: Arquitectura de Filtrado DNS de Borde

La respuesta estratégica a este patrón de fallo no es aprovisionar más hardware, sino eliminar la fuente del ruido. El Filtrado DNS de Borde es la estrategia de mitigación principal, y cuando se implementa correctamente, puede recuperar hasta el 40% del ancho de banda WAN y reducir la latencia promedio en 60ms o más.

Plan Arquitectónico

El filtrado DNS de borde opera interceptando las consultas DNS en el perímetro de la red. Cuando un dispositivo solicita la dirección IP de una red de anuncios conocida, un servidor de telemetría o un dominio de malware, el filtro responde con una ruta nula — ya sea devolviendo 0.0.0.0 o una respuesta NXDOMAIN. Esto evita que el dispositivo establezca una conexión TCP, eliminando la sobrecarga asociada de la tabla de estados, el consumo de tiempo de aire y la utilización del ancho de banda WAN.

Pasos de Implementación

Paso 1: Implementar Resolutores DNS Locales Implemente resolutores DNS locales de alta disponibilidad en el borde del recinto. Estos deben ser capaces de manejar la carga completa de consultas de la población de dispositivos conectados. No dependa únicamente de los resolutores ISP ascendentes, ya que esto introduce latencia y remmejora su capacidad de filtrado.

Paso 2: Integrar fuentes de inteligencia de amenazas y bloqueo de anuncios Suscríbase a fuentes de inteligencia de amenazas de nivel empresarial que incluyan dominios conocidos de redes de anuncios, servidores de telemetría e infraestructura de malware. Estas fuentes deben actualizarse dinámicamente —idealmente cada pocas horas— para detectar dominios recién registrados utilizados por las redes de anuncios para evadir el bloqueo.

Paso 3: Configurar la política DHCP Configure los servidores DHCP para distribuir las direcciones IP de los resolvedores locales y filtrados a todos los dispositivos de invitados. Este es el mecanismo de aplicación principal para dirigir el tráfico DNS del cliente a través del filtro.

Paso 4: Implementar reglas de firewall de salida Este paso es crítico y frecuentemente omitido. Implemente reglas estrictas de firewall de salida para bloquear todo el tráfico DNS saliente (puerto TCP/UDP 53) a cualquier destino que no sean los resolvedores locales aprobados. Esto evita que los dispositivos con configuraciones DNS codificadas eviten el filtro.

Paso 5: Abordar DNS sobre HTTPS (DoH) Como se detalla en nuestra guía sobre DNS Over HTTPS (DoH): Implicaciones para el filtrado de WiFi público , los sistemas operativos y navegadores modernos utilizan cada vez más DoH para cifrar las consultas DNS, dirigiéndolas a resolvedores externos y eludiendo por completo el filtrado local. Los administradores de red deben bloquear explícitamente las direcciones IP de los proveedores de DoH conocidos a nivel de firewall. Esto obliga al cliente a recurrir al DNS estándar no cifrado, que luego puede ser filtrado. El equivalente en portugués de esta guía está disponible en DNS Over HTTPS (DoH): Implicações para a Filtragem de WiFi Público para implementaciones internacionales.

Paso 6: Integrar con la gestión de identidad y acceso Para una máxima eficacia, vincule las políticas de filtrado DNS a la autenticación de usuarios. Aprovechar la autenticación basada en perfiles —como se explora en nuestra guía de 2026 sobre acceso sin contraseña— permite a los recintos aplicar políticas de filtrado diferenciadas basadas en los roles de los usuarios. Los usuarios de admisión general reciben un filtrado agresivo; los usuarios de prensa, corporativos o VIP pueden recibir políticas más permisivas que permitan aplicaciones empresariales específicas.

Casos de estudio

Caso de estudio 1: Estadio de fútbol de 60,000 asientos, Reino Unido

Un club de fútbol de la Premier League estaba experimentando una grave degradación de la red durante el medio tiempo, con el captive portal agotando el tiempo de espera y el uso compartido de redes sociales fallando en los momentos de mayor afluencia. El circuito WAN era una conexión dedicada de 10 Gbps, operando a solo el 28% de utilización durante el incidente. Sin embargo, la tabla de estados del firewall estaba al 97% de su capacidad.

Tras una auditoría de tráfico utilizando WiFi Analytics , el equipo identificó que los dominios de redes de anuncios representaban el 61% de todas las consultas DNS. Los cinco dominios principales eran toda infraestructura de publicidad programática. Se implementó el filtrado DNS de borde con una lista de bloqueo de 1.2 millones de dominios, combinado con reglas estrictas de salida que bloqueaban el puerto 53 y las IP de los proveedores de DoH.

El resultado: la utilización de la tabla de estados se redujo al 34% en la capacidad máxima, la latencia promedio disminuyó de 280 ms a 95 ms, y la utilización del ancho de banda WAN en el pico bajó del 28% al 17% —una reducción del 39% en el ancho de banda consumido a pesar de no haber cambios en el número de dispositivos conectados.

Caso de estudio 2: Centro de conferencias internacional, sector de Hostelería

Un importante centro de conferencias que albergaba una cumbre tecnológica de 15,000 delegados estaba recibiendo quejas de los asistentes sobre la lentitud del WiFi a pesar de una infraestructura recientemente actualizada. El recinto había desplegado 400 puntos de acceso de nivel empresarial y un circuito WAN de 5 Gbps.

El análisis de tráfico reveló que los dispositivos de los delegados —predominantemente laptops corporativas con múltiples aplicaciones empresariales en ejecución— estaban generando un promedio de 45 conexiones en segundo plano por dispositivo. El resolvedor DNS estaba procesando 2.3 millones de consultas por hora, con el 68% destinado a redes de anuncios y plataformas de análisis.

Tras la implementación del filtrado DNS de borde con la integración de políticas vinculadas al sistema de registro de la conferencia, el recinto experimentó una reducción del 52% en el volumen de consultas DNS, una reducción del 41% en la utilización de la tabla de estados del firewall y una mejora medida en el tiempo promedio de establecimiento de conexión TCP de 180 ms a 62 ms. Las puntuaciones de satisfacción de los delegados por la calidad del WiFi aumentaron de 3.1 a 4.6 sobre 5.

Mejores prácticas y estándares

Las siguientes mejores prácticas neutrales en cuanto a proveedores reflejan los estándares actuales de la industria para implementaciones de WiFi de alta densidad:

IEEE 802.11ax (Wi-Fi 6/6E): Implemente puntos de acceso Wi-Fi 6 o 6E. Las características OFDMA y BSS Colouring reducen significativamente la contención del tiempo de aire en entornos de alta densidad, complementando la reducción de tráfico lograda por el filtrado DNS.
WPA3-Enterprise: Aplique WPA3-Enterprise con autenticación IEEE 802.1X para cualquier implementación que maneje datos sensibles. Este es un requisito básico para el cumplimiento de PCI DSS en entornos de Retail y se alinea con los principios de minimización de datos de GDPR.
Cumplimiento de GDPR: Comunique de forma transparente el uso de herramientas de optimización de red, incluido el filtrado DNS, en los términos de servicio del captive portal. Los usuarios deben ser informados de que las consultas DNS se procesan localmente como parte de la función de gestión de red.
Monitoreo y análisis: Monitoree continuamente los dominios más solicitados utilizando WiFi Analytics y ajuste las políticas de filtrado en consecuencia. Las redes de anuncios registran regularmente nuevos dominios para evadir el bloqueo; las listas de bloqueo estáticas quedan obsoletas en cuestión de días.
Implementaciones en el sector público: Para implementaciones de WiFi en el sector público y ciudades inteligentes, como se discute en el contexto de la expansión de Purple en el sector público , el filtrado DNS también cumple una función de salvaguarda, bloqueando el acceso a categorías de contenido dañino en cumplimiento con los requisitos de las autoridades locales.

Solución de problemas y mitigación de riesgos

Falsos positivos

Riesgo: Un filtrado excesivamente agresivo puede bloquear la funcionalidad legítima de las aplicaciones, como aplicaciones de venta de entradas, servicios de navegación del recinto o puntos finales de VPN corporativas.

Mitigación: Implementar una lista de permitidos estricta para dominios de misión crítica identificados durante una fase de referencia de solo monitoreo. Nunca pasar directamente al modo de aplicación en un entorno de producción. Un período de monitoreo de dos semanas es la referencia mínima recomendada antes de la aplicación.

Omisión del Captive Portal a través del tráfico en segundo plano

Riesgo: Los dispositivos pueden no activar el Captive Portal si el tráfico en segundo plano satisface el mecanismo de detección de Captive Portal del OS (p. ej., la verificación captive.apple.com de Apple) antes de que el usuario abra un navegador.

Mitigación: Restringir el "walled garden" para permitir solo los dominios específicos requeridos para la detección y autenticación del Captive Portal. Todo otro tráfico debe ser bloqueado hasta que el usuario esté completamente autenticado y la política de filtrado se aplique a su sesión.

Omisión de DoH

Riesgo: Los dispositivos que usan DoH omitirán el filtrado DNS local, haciendo que toda la estrategia sea ineficaz para esos clientes.

Mitigación: Mantener una lista de bloqueo actualizada de direcciones IP de proveedores de DoH y bloquearlas en el firewall. Esta no es una configuración única; nuevos proveedores de DoH surgen regularmente y deben ser rastreados.

Servicios de mapas y navegación sin conexión

Para recintos que implementan navegación interior junto con WiFi — como los que usan el Modo de Mapas sin Conexión de Purple — asegúrese de que los servidores de mosaicos de mapas y las API de navegación estén explícitamente en la lista de permitidos. Estos servicios son críticos para la experiencia del usuario y no deben ser interceptados por reglas de filtrado amplias de redes publicitarias.

ROI e Impacto Comercial

El caso de negocio para el filtrado DNS en el borde es convincente en múltiples dimensiones:

Métrica	Resultado Típico	Impacto Comercial
Reducción de Ancho de Banda WAN	30–40%	Costos de actualización de circuitos diferidos; ciclo de vida de infraestructura extendido
Reducción de Latencia	40–70ms en promedio	Mayor interacción del usuario con las aplicaciones del recinto y servicios digitales
Utilización de la Tabla de Estado	Reducción del 50–65% en el pico	Actualización de hardware de firewall diferida; riesgo de incidentes reducido
Volumen de Consultas DNS	Reducción del 40–60%	Carga del resolvedor reducida; velocidad de autenticación mejorada
Satisfacción del Usuario	Mejora medible del NPS	Mayor tiempo de permanencia, aumento del gasto en F&B, mejora de la percepción de la marca

Para un estadio que gasta £80,000 al año en conectividad WAN y que enfrenta un ciclo de actualización de hardware de £200,000, una reducción del 35% del ancho de banda se traduce en aproximadamente £28,000 en ahorros anuales de WAN y una posible extensión de 18 meses del ciclo de actualización de hardware — un ahorro combinado de tres años que supera las £100,000, frente a un costo de implementación que suele oscilar entre £15,000 y £30,000 para un recinto de esta escala.

Escuche el Informe Técnico

Definiciones clave

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.

Ejemplos resueltos

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.

Comentario del examinador: 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.

Comentario del examinador: 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.

Preguntas de práctica

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?

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

Ver respuesta modelo

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?

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

Ver respuesta modelo

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?

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

Ver respuesta modelo

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.