¿Qué es un WLC (Controlador de LAN Inalámbrica) y aún lo necesita?

Esta guía completa explora la evolución de los Controladores de LAN Inalámbrica (WLC) y proporciona un marco técnico para determinar la arquitectura adecuada en 2026. Cubre modelos de hardware tradicionales, gestionados en la nube y sin controlador, detallando su impacto en el cumplimiento, la escalabilidad y la experiencia del huésped.

📖 7 min de lectura📝 1,623 palabras🔧 2 ejemplos resueltos❓ 3 preguntas de práctica📚 8 definiciones clave

Escucha esta guía

Ver transcripción del podcast

What is a WLC — Wireless LAN Controller — and Do You Still Need One?
A Purple Technical Briefing

[INTRODUCTION & CONTEXT — approximately 1 minute]

Welcome to the Purple Technical Briefing series. I'm your host, and today we're tackling a question that lands on the desk of almost every network architect and IT manager working in a multi-AP environment: what exactly is a Wireless LAN Controller, and in 2026, do you actually still need one?

This isn't an academic exercise. If you're managing WiFi across a hotel, a retail estate, a stadium, or a public-sector campus, the answer to this question has real budget implications, real compliance implications, and real consequences for the guest experience you can deliver. So let's get into it.

[TECHNICAL DEEP-DIVE — approximately 5 minutes]

Let's start with the fundamentals. A Wireless LAN Controller — or WLC — is a network device that centralises the management, configuration, and control of multiple wireless access points. Before WLCs became mainstream in the mid-2000s, every access point on your network was autonomous. Each one had its own configuration, its own firmware, its own security policy. Managing fifty of them meant logging into fifty devices individually. That was fine when WiFi was a convenience amenity. It became completely unworkable as WiFi became critical infrastructure.

The WLC solved that by introducing what the industry calls the split-MAC architecture. In this model, the access point handles the time-sensitive, real-time radio functions — things like beacon transmission, probe responses, and the physical layer processing defined under IEEE 802.11. The controller handles everything that requires coordination across the estate: RF management, roaming decisions, QoS policy enforcement, security policy, and VLAN assignment. The access points become what we call "lightweight" or "thin" APs — they're essentially radio heads that tunnel all their traffic back to the controller using a protocol called CAPWAP: Control and Provisioning of Wireless Access Points.

Now, why does that matter in practice? Consider seamless roaming. In a hotel with two hundred rooms and forty access points, a guest walking from the lobby to their room needs to hand off between multiple APs without dropping their VoIP call or losing their streaming session. The WLC orchestrates that handoff. It knows the client's authentication state, it pre-stages the next AP, and it executes the roam in milliseconds. Without a controller, each AP makes its own roaming decision independently, and you get what engineers call "sticky client" syndrome — devices that cling to a distant AP long after a closer one is available, degrading throughput and experience.

Security is the other major driver. Enterprise WiFi deployments operating under PCI DSS — the Payment Card Industry Data Security Standard — or under GDPR require consistent, auditable security policy across every access point. IEEE 802.1X authentication, WPA3 Enterprise encryption, rogue AP detection, and client isolation policies all need to be enforced uniformly. A hardware WLC gives you a single enforcement point. You define the policy once, and it propagates to every AP in the estate. That's not just operationally convenient — it's often a compliance requirement.

Now, here's where the conversation gets more nuanced. The WLC has evolved significantly. In 2026, you have three distinct deployment models to choose from.

The first is the traditional on-premises hardware WLC — a physical appliance in your server room or data centre. Vendors like Cisco, with their Catalyst Wireless Controllers, and HPE Aruba, with their Mobility Controllers, have been the dominant players here. These give you full control, local data processing, and offline resilience. If your WAN link goes down, the network keeps running. The trade-off is CAPEX: you're buying hardware with a finite capacity ceiling, and you're responsible for maintenance, redundancy, and eventual refresh cycles.

The second model is the cloud-managed controller. This is where the industry has shifted significantly. Cisco's Catalyst Centre, Aruba Central, and Juniper Mist have all moved the management plane to the cloud while keeping the data plane distributed at the edge. Your APs still process traffic locally — there's no hairpinning everything back to a cloud data centre — but your configuration, monitoring, telemetry, and policy management all happen through a SaaS dashboard. This is an OPEX model, and it scales beautifully for multi-site retail or hospitality chains where you need consistent policy across hundreds of locations without deploying hardware at each one.

The third model is controller-less, using what vendors call autonomous or mesh APs. These are access points that communicate peer-to-peer and elect a virtual controller amongst themselves. Ubiquiti's UniFi platform is probably the most widely deployed example. For small sites — a boutique hotel, a single retail unit, a community centre — this can be entirely appropriate. But the moment you need enterprise-grade roaming, 802.1X authentication, or granular QoS, the limitations become apparent quickly.

So where does a platform like Purple fit into this picture? Purple operates as a hardware-agnostic layer above the controller. Whether you're running a Cisco WLC, an Aruba Central deployment, or a Ubiquiti controller-less setup, Purple's guest WiFi and analytics platform integrates via the controller's API or captive portal framework. The controller handles the RF and security layer; Purple handles the guest identity, the data capture, the marketing automation, and the analytics. They're complementary, not competing. Purple's WiFi analytics platform gives you the behavioural intelligence — dwell time, footfall patterns, repeat visit rates — that no WLC dashboard was ever designed to surface.

[IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes]

Let me give you the practical guidance that actually makes a difference in deployment.

First: size your WLC for peak concurrent clients, not average load. A stadium with fifty thousand seats might have an average of ten thousand concurrent WiFi users on a typical event day, but on a sold-out final, you're looking at thirty-five thousand. WLC capacity is measured in concurrent associations and concurrent sessions. Under-specifying here is the single most common cause of event-day WiFi failures.

Second: plan your CAPWAP tunnelling carefully. In a centralised data plane deployment, all client traffic flows through the WLC. At scale, that creates a bottleneck. For high-density venues, consider a split-tunnel or local switching configuration where guest traffic breaks out locally at the AP or the local switch, and only management traffic traverses the CAPWAP tunnel back to the controller. This dramatically reduces WLC processing load and improves throughput.

Third: redundancy is non-negotiable. A WLC is a single point of failure for your entire wireless estate. Deploy in an N+1 or active-standby configuration. Most enterprise WLC platforms support stateful switchover — meaning client sessions survive a controller failover without re-authentication. Test this. Don't assume it works until you've verified it under load.

Fourth: if you're deploying cloud-managed controllers across multiple sites, pay close attention to data residency. Under GDPR, the location of your cloud controller's data processing matters. Ensure your vendor's data centres are in compliant jurisdictions and that your data processing agreements are in place before you go live.

The most common pitfall I see? Organisations that buy a WLC sized for today's AP count without accounting for growth. WLC licences are typically per-AP. A 50-AP licence on a Cisco 3504 controller looks fine today, but when you add the new conference wing and need 80 APs, you're either buying a new controller or an expensive licence upgrade. Build in at least 30% headroom.

[RAPID-FIRE Q&A — approximately 1 minute]

Right, let's do some rapid-fire questions.

"Can I run Purple without a WLC?" — Yes. Purple integrates with controller-less deployments. You'll lose some enterprise roaming and policy features at the network layer, but Purple's guest WiFi and analytics capabilities are fully functional.

"Is a virtual WLC the same as a cloud WLC?" — No. A virtual WLC runs as a VM on your own infrastructure — on-premises or in your private cloud. A cloud WLC is hosted and managed by the vendor. Very different security and compliance profiles.

"Do WLCs support WPA3?" — All current-generation enterprise WLCs support WPA3 Personal and WPA3 Enterprise. If your WLC doesn't, it's end-of-life and you should be planning a refresh.

"What's the typical refresh cycle for a hardware WLC?" — Five to seven years for enterprise-grade hardware, though software support timelines vary by vendor. Cisco's EOL notices are worth tracking closely.

[SUMMARY AND NEXT STEPS — approximately 1 minute]

So, to bring this together. A WLC remains relevant and, in many cases, essential for enterprise WiFi deployments in 2026. The question isn't whether you need controller functionality — you almost certainly do if you're managing more than a handful of APs. The question is which deployment model fits your scale, your compliance requirements, your budget model, and your operational capability.

Hardware WLC for large single-site venues with strict compliance requirements and offline resilience needs. Cloud-managed for multi-site estates where operational consistency and OPEX flexibility matter. Controller-less only for genuinely small, low-complexity deployments.

And whatever controller architecture you choose, layer Purple's guest WiFi and analytics platform on top to unlock the business intelligence that turns your network from a cost centre into a revenue-generating asset.

If you want to go deeper on any of this — AP density planning, CAPWAP optimisation, or integrating Purple with your specific controller platform — the full technical guide is linked in the show notes. Thanks for listening.

Resumen Ejecutivo

Para los gerentes de TI y arquitectos de red que implementan redes inalámbricas empresariales, el Controlador de LAN Inalámbrica (WLC) ha sido históricamente el sistema nervioso central de la infraestructura inalámbrica. Sin embargo, el panorama arquitectónico ha cambiado significativamente. Con el auge de las arquitecturas gestionadas en la nube y los planos de datos distribuidos, la pregunta fundamental para cualquier nueva implementación o ciclo de actualización ya no es simplemente "¿qué controlador debemos comprar?", sino más bien "¿todavía necesitamos un controlador de hardware?".

Esta guía proporciona un desglose técnico completo de las arquitecturas de WLC en 2026. Examinamos la evolución desde el hardware centralizado tradicional hasta las topologías modernas gestionadas en la nube y sin controlador. Al mapear estas arquitecturas técnicas con los requisitos de cumplimiento del mundo real (como PCI DSS y GDPR), las necesidades de escalabilidad y los resultados de la experiencia del huésped, esta referencia capacita a los tomadores de decisiones técnicos para seleccionar la estrategia de plano de control adecuada.

Además, exploramos cómo plataformas como Purple operan de forma agnóstica por encima de esta capa de infraestructura, transformando la conectividad bruta en inteligencia procesable, independientemente del proveedor de hardware subyacente.

Análisis Técnico Detallado: Comprendiendo el WLC

La Evolución del Plano de Control

Un Controlador de LAN Inalámbrica (WLC) es un dispositivo de red responsable de la gestión centralizada, la configuración y la aplicación de políticas de seguridad en múltiples puntos de acceso inalámbricos (AP). En las primeras implementaciones inalámbricas, los AP operaban de forma autónoma, requiriendo configuración individual y careciendo de la capacidad de coordinar entornos de RF o traspasos de roaming. A medida que la tecnología inalámbrica pasó de ser una red de conveniencia a una infraestructura de misión crítica, la sobrecarga administrativa de los AP autónomos se volvió insostenible.

El WLC resolvió esto mediante la introducción de la arquitectura split-MAC. En este modelo, el AP (a menudo denominado AP "ligero") maneja las funciones de la capa física 802.11 en tiempo real y sensibles al tiempo, como la transmisión de balizas y las respuestas de sondeo. El controlador asume la responsabilidad de las funciones de la capa MAC no en tiempo real, incluida la gestión de RF, la aplicación de políticas de seguridad y la autenticación de clientes. La comunicación entre el AP ligero y el controlador se encapsula típicamente dentro de un túnel CAPWAP (Control and Provisioning of Wireless Access Points).

El Rol de CAPWAP

CAPWAP es fundamental para las operaciones tradicionales de WLC. Establece un túnel seguro entre el AP y el controlador, transportando tanto el tráfico de control (gestión y configuración) como el tráfico de datos (cargas útiles del cliente).

En una implementación de plano de datos centralizado, todo el tráfico del cliente se reenvía al controlador antes de ser enrutado a la red cableada. Esto permite la aplicación centralizada de políticas, la inspección profunda de paquetes y una gestión de VLAN simplificada. Sin embargo, puede crear un cuello de botella significativo en entornos de alta densidad.

Para mitigar esto, muchas implementaciones modernas utilizan FlexConnect (Cisco) o arquitecturas de conmutación local similares. Aquí, el plano de control permanece centralizado en el WLC, pero el plano de datos se distribuye, permitiendo que el tráfico del cliente salga localmente en el switch de borde. Esto reduce drásticamente la carga de procesamiento en el WLC y mejora el rendimiento, particularmente a través de enlaces WAN.

Roaming Sin Interrupciones y Gestión de Clientes

Uno de los principales impulsores técnicos para implementar un WLC es el roaming de clientes sin interrupciones. En un entorno multi-AP, un cliente que se mueve a través del área de cobertura debe pasar de un AP a otro. Sin un controlador, el cliente toma esta decisión de forma totalmente independiente, lo que a menudo resulta en el síndrome de "cliente pegajoso", donde el dispositivo mantiene una conexión débil con un AP distante, degradando la capacidad general del canal.

Un WLC orquesta este proceso. Al mantener una vista centralizada del entorno de RF y el estado de autenticación del cliente (particularmente crítico para implementaciones 802.1X), el controlador puede preestablecer el evento de roaming. Facilita la transferencia del caché PMK (Pairwise Master Key) del cliente al AP de destino, permitiendo una transición sin interrupciones en milisegundos, asegurando que las llamadas VoIP y las sesiones de streaming permanezcan ininterrumpidas. Esto es vital para mantener una alta satisfacción del huésped en lugares como Hospitalidad y Comercio Minorista .

Guía de Implementación: Eligiendo la Arquitectura Correcta

En 2026, los arquitectos de red deben evaluar tres modelos de implementación distintos. La decisión depende de la escala, el cumplimiento, la tolerancia a la latencia y las estructuras presupuestarias CAPEX vs. OPEX.

1. WLC de Hardware Tradicional (Local)

El modelo tradicional implica un dispositivo físico implementado en un centro de datos local o sala de servidores.

Arquitectura: Planos de control y datos centralizados (típicamente).
Ventajas: Control completo sobre la residencia de datos, resiliencia sin conexión (sobrevive a interrupciones de WAN) y aplicación de políticas altamente granular.
Desventajas: Alto CAPEX inicial, límites de capacidad finitos que requieren reemplazo de hardware para una escalabilidad significativa, y configuraciones de redundancia complejas (N+1 o Activo/En espera).
Mejor Opción: Implementaciones grandes de un solo sitio (por ejemplo, estadios, hospitales importantes, campus universitarios) donde el procesamiento de datos local es obligatorio por cumplimiento o latency restricciones.

2. Controlador gestionado en la nube

El modelo gestionado en la nube abstrae el plano de control a una plataforma SaaS alojada por un proveedor, mientras que el plano de datos permanece distribuido en el borde.

Arquitectura: Plano de control centralizado en la nube, plano de datos local distribuido.
Ventajas: Escalabilidad rápida, modelo de suscripción OPEX, aprovisionamiento sin intervención y un panel de gestión unificado en sitios geográficamente dispersos.
Desventajas: Requiere conectividad WAN fiable para la gestión (aunque la conmutación de datos local sobrevive a las interrupciones) y posibles preocupaciones sobre la residencia de datos según la región de la nube del proveedor.
Mejor ajuste: Entornos multisitio como cadenas minoristas, sucursales empresariales distribuidas y operaciones franquiciadas.

3. Sin controlador (Autónomo/Malla)

En este modelo, los puntos de acceso se comunican entre sí (peer-to-peer), eligiendo un controlador virtual entre ellos para manejar la coordinación básica.

Arquitectura: Planos de control y datos distribuidos.
Ventajas: Menor costo de entrada, implementación sencilla, no requiere hardware de controlador dedicado ni suscripción a la nube.
Desventajas: Escalabilidad limitada, capacidades de roaming básicas y falta de características de seguridad empresarial avanzadas.
Mejor ajuste: Implementaciones pequeñas de un solo sitio (por ejemplo, pequeñas unidades minoristas, cafeterías boutique) con baja densidad de clientes y requisitos de cumplimiento mínimos.

Mejores prácticas para la implementación

Independientemente de la arquitectura elegida, adherirse a las mejores prácticas estándar de la industria es fundamental para garantizar la estabilidad y el rendimiento de la red.

Dimensionar para el pico, no para el promedio: La capacidad del WLC está estrictamente licenciada y se aplica en función de los APs concurrentes y las sesiones de cliente concurrentes. Al diseñar para entornos de alta densidad como centros de Transporte o estadios, debe calcular la capacidad basándose en la carga máxima del evento, no en el uso diario promedio. No hacerlo resultará en que el WLC descarte las solicitudes de asociación de clientes durante períodos críticos.
Diseñar para la redundancia: Un WLC de hardware es un único punto de fallo. Las implementaciones deben incorporar alta disponibilidad (HA). Las plataformas modernas admiten Stateful Switchover (SSO), lo que garantiza que las sesiones de cliente y las asociaciones de AP se transfieran sin problemas a un controlador en espera sin requerir reautenticación.
Implementar salida local para alto ancho de banda: En arquitecturas WLC centralizadas, evite el transporte de tráfico de invitados de alto ancho de banda (por ejemplo, transmisión de video) a través del túnel CAPWAP a la red central. Utilice la conmutación local en el borde para descargar este tráfico directamente a internet, preservando la capacidad de procesamiento del WLC para funciones del plano de control y tráfico corporativo seguro.
Aplicar políticas de seguridad estrictas: Utilice el WLC como punto de aplicación central para la seguridad. Asegúrese de que WPA3 Enterprise esté implementado donde sea compatible y aplique un aislamiento robusto de clientes en las redes Guest WiFi para evitar la comunicación peer-to-peer entre dispositivos no confiables.

Solución de problemas y mitigación de riesgos

Cuando las implementaciones de WLC fallan, el impacto suele ser sistémico. Comprender los modos de fallo comunes es esencial para una mitigación rápida.

Enrutamiento asimétrico y fragmentación CAPWAP

Riesgo: Al implementar un WLC centralizado a través de una WAN compleja, las discrepancias de MTU (Maximum Transmission Unit) pueden causar la fragmentación de los paquetes CAPWAP. Esto degrada significativamente el rendimiento del AP y puede provocar desconexiones intermitentes del AP. Mitigación: Asegúrese de que la MTU sea consistente en toda la ruta entre el AP y el WLC. Si la fragmentación es inevitable, configure el WLC para ajustar el TCP MSS (Maximum Segment Size) y evitar la pérdida de paquetes.

Densidad de AP vs. Interferencia de canal

Riesgo: Añadir más APs a un WLC no aumenta linealmente la capacidad si se ignora la planificación de canales. La gestión de RF automatizada del WLC (por ejemplo, RRM de Cisco o ARM de Aruba) puede volverse inestable en implementaciones excesivamente densas, cambiando constantemente los canales y los niveles de potencia, lo que lleva a una experiencia de cliente degradada. Mitigación: Realice encuestas de sitio predictivas y activas exhaustivas. Ajuste manualmente los algoritmos de RF del WLC, definiendo umbrales estrictos de potencia de transmisión mínima y máxima para evitar la interferencia de cocanal.

Cumplimiento y residencia de datos

Riesgo: Implementar un controlador gestionado en la nube sin verificar las ubicaciones de los centros de datos del proveedor puede llevar a violaciones inmediatas de GDPR o PCI DSS, particularmente si las direcciones MAC de invitados o los registros de autenticación se procesan fuera de jurisdicciones conformes. Mitigación: Verifique la arquitectura de residencia de datos del proveedor de WLC en la nube. Asegúrese de que existan Acuerdos de Procesamiento de Datos (DPAs) y de que el proveedor admita el almacenamiento de datos localizado para implementaciones europeas.

ROI e impacto empresarial

La decisión de implementar, actualizar o migrar una arquitectura WLC debe justificarse con resultados empresariales medibles. El ROI se evalúa típicamente en tres vectores:

Eficiencia operativa: Los WLCs gestionados en la nube reducen significativamente la sobrecarga operativa de la gestión de redes distribuidas. El aprovisionamiento sin intervención permite que los APs se envíen directamente a sitios remotos, descargando automáticamente la configuración desde la nube al conectarse. Esto elimina la necesidad de costosas visitas de ingeniería in situ.
Reducción de riesgos: Un WLC de hardware centralizado con HA robusta proporciona la resiliencia fuera de línea necesaria para operaciones de misión crítica, como entornos de Salud . El costo de un WLC redundante es a menudo insignificante en comparación con el daño financiero y reputacional de una interrupción sistémica de la red.
Habilitación de análisis avanzados: El WLC proporciona la conectividad fundamental, pero el verdadero valor empresarial se desbloquea en la capa de aplicación. Al integrar un WLC con una plataforma como Purple's WiFi Analytics , los datos de conexión sin procesar se transforman en inteligencia procesable. Purple actúa como un proveedor de identidad (IdP) gratuito para servicios como OpenRoaming, capturando valiosos datos de primera mano. Esto permite a los recintos medir el tiempo de permanencia, comprender los patrones de afluencia y lanzar campañas de marketing dirigidas, contribuyendo directamente a la generación de ingresos.

Como se discutió en nuestro reciente anuncio, Purple Nombra a Iain Fox como VP de Crecimiento , el enfoque está cada vez más en la inclusión digital y la innovación de ciudades inteligentes. Una arquitectura WLC robusta, combinada con los analytics de Purple, constituye la base de estas iniciativas, permitiendo una conectividad fluida, segura y perspicaz en vastos espacios públicos. Además, la adopción de métodos de autenticación modernos, como los detallados en Cómo un wi fi assistant Habilita el Acceso sin Contraseña en 2026 , depende completamente de la aplicación de políticas segura y centralizada proporcionada por la infraestructura WLC.

Definiciones clave

CAPWAP

Control and Provisioning of Wireless Access Points. The standard protocol used to encapsulate communication between a lightweight AP and a WLC.

Understanding CAPWAP is crucial for troubleshooting connectivity issues between APs and the controller across WAN links.

Split-MAC Architecture

A design where the functions of the 802.11 MAC layer are divided between the access point (real-time functions) and the WLC (management functions).

This is the foundational concept that enables centralized control of a large wireless estate.

Local Switching (FlexConnect)

A configuration where the control plane remains at the WLC, but client data traffic is routed directly onto the local wired network at the AP or edge switch.

Essential for reducing bandwidth bottlenecks on the WLC and WAN links in distributed environments.

Stateful Switchover (SSO)

A high-availability feature where a standby WLC maintains the state of all client sessions, allowing for seamless failover without client re-authentication.

Critical for mission-critical deployments where dropped VoIP calls or streaming sessions are unacceptable during a hardware failure.

Sticky Client

A wireless device that remains connected to a distant AP with a weak signal, rather than roaming to a closer AP with a stronger signal.

WLCs mitigate this by orchestrating roaming decisions based on a centralized view of the RF environment.

802.1X

An IEEE standard for port-based network access control, providing an authentication mechanism to devices wishing to attach to a LAN or WLAN.

The standard for enterprise wireless security, requiring a WLC to act as the centralized authenticator.

Zero-Touch Provisioning (ZTP)

The ability to deploy network devices (like APs) without manual configuration on-site; the device automatically connects to a cloud controller to download its configuration.

The primary operational advantage of cloud-managed WLC architectures for multi-site deployments.

Data Plane vs. Control Plane

The data plane carries user traffic (payloads), while the control plane carries management and routing information.

Modern WLC architectures often separate these, keeping the control plane in the cloud while distributing the data plane to the edge.

Ejemplos resueltos

A national retail chain with 400 locations is planning a network refresh. Each location averages 3 APs. The current infrastructure relies on aging, autonomous APs, leading to inconsistent security policies and zero visibility into network health from head office. They need a solution that minimizes CAPEX, requires no on-site IT staff for deployment, and provides centralized analytics.

The optimal solution is a Cloud-Managed Controller architecture. Deploying 400 hardware WLCs is financially unviable, and managing 1,200 autonomous APs is operationally impossible. The cloud model allows APs to be drop-shipped to stores (Zero-Touch Provisioning). Upon connection, they securely tunnel to the vendor's cloud dashboard to download their configuration. The data plane remains local (handling point-of-sale traffic directly), while the control plane is centralized in the cloud. Purple's analytics platform is integrated via the cloud controller's API to provide footfall and dwell time metrics across the entire estate.

Comentario del examinador: This scenario perfectly illustrates the OPEX advantage of cloud-managed WLCs. The critical technical decision here is ensuring the local data plane remains active even if the WAN link to the cloud controller drops, ensuring the store can still process local transactions.

A major teaching hospital is deploying a new wireless network across a sprawling campus to support critical VoIP communications for clinical staff and secure access to electronic health records (EHR). The environment is highly sensitive to latency, requires strict HIPAA/GDPR compliance, and must remain operational even if the external internet connection fails.

A Traditional Hardware WLC deployed on-premises in a High Availability (Active/Standby) pair is required. The strict requirement for offline resilience (surviving a WAN outage) eliminates cloud-managed controllers as the primary control plane. All clinical traffic should be locally switched at the edge to minimize latency, while management and authentication traffic is centralized at the WLC. The WLC enforces 802.1X authentication uniformly across the campus.

Comentario del examinador: In mission-critical environments, the CAPEX of redundant hardware WLCs is justified by the requirement for absolute control over data residency and offline survivability. The architecture prioritizes resilience and low latency over deployment simplicity.

Preguntas de práctica

Q1. A university campus is upgrading its wireless network. They require seamless roaming for students moving between lecture halls, robust 802.1X authentication, and all user traffic must be inspected by an on-premises firewall before reaching the internet. Which WLC architecture is most appropriate?

Sugerencia: Consider the requirement for all traffic to be inspected by an on-premises appliance.

Ver respuesta modelo

A Traditional Hardware WLC with a centralized data plane. The requirement to route all traffic through an on-premises firewall dictates that client traffic should be backhauled to a central point (the WLC) before being handed off to the core network and firewall. A cloud-managed controller with local breakout would bypass the central firewall.

Q2. A boutique hotel with 20 rooms needs a basic wireless network for guest internet access. They have no dedicated IT staff and a minimal budget. Compliance requirements are low. What is the most cost-effective approach?

Sugerencia: Focus on the lack of IT staff and minimal budget for a very small deployment.

Ver respuesta modelo

A Controller-Less (Autonomous/Mesh) architecture. For a small deployment of likely under 10 APs, the cost of a hardware WLC or the recurring subscription of a cloud controller is not justified. The APs can elect a virtual controller to handle basic configuration and roaming.

Q3. You are designing a network for a stadium with 60,000 seats. The design calls for 800 access points. The vendor's WLC datasheet states a maximum capacity of 1,000 APs and 10,000 concurrent clients. Is this WLC suitably sized?

Sugerencia: Look beyond the AP count and consider the density of the venue.

Ver respuesta modelo

No. While the WLC supports the 800 APs, the concurrent client limit of 10,000 is vastly insufficient for a 60,000-seat stadium. During an event, concurrent connections will likely exceed 30,000. The WLC must be sized based on peak concurrent clients, requiring a significantly larger controller or a cluster of controllers.