Cos'è un WLC (Wireless LAN Controller) e ne hai ancora bisogno?

Questa guida completa esplora l'evoluzione dei Wireless LAN Controller (WLC) e fornisce un quadro tecnico per determinare l'architettura giusta nel 2026. Copre i modelli hardware tradizionali, gestiti in cloud e senza controller, dettagliando il loro impatto su conformità, scalabilità ed esperienza degli ospiti.

📖 7 minuti di lettura📝 1,623 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 8 definizioni chiave

Ascolta questa guida

Visualizza trascrizione 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.

Riepilogo Esecutivo

Per i responsabili IT e gli architetti di rete che implementano reti wireless aziendali, il Wireless LAN Controller (WLC) è stato storicamente il sistema nervoso centrale dell'infrastruttura wireless. Tuttavia, il panorama architettonico è cambiato in modo significativo. Con l'ascesa delle architetture gestite in cloud e dei piani dati distribuiti, la domanda fondamentale per qualsiasi nuova implementazione o ciclo di aggiornamento non è più semplicemente "quale controller dovremmo acquistare", ma piuttosto "abbiamo ancora bisogno di un controller hardware?"

Questa guida fornisce un'analisi tecnica completa delle architetture WLC nel 2026. Esaminiamo l'evoluzione dall'hardware centralizzato tradizionale alle moderne topologie gestite in cloud e senza controller. Mappando queste architetture tecniche rispetto ai requisiti di conformità del mondo reale (come PCI DSS e GDPR), alle esigenze di scalabilità e ai risultati dell'esperienza degli ospiti, questo riferimento consente ai decisori tecnici di selezionare la strategia appropriata per il piano di controllo.

Inoltre, esploriamo come piattaforme come Purple operano in modo agnostico al di sopra di questo livello infrastrutturale, trasformando la connettività grezza in intelligenza utilizzabile indipendentemente dal fornitore hardware sottostante.

Approfondimento Tecnico: Comprendere il WLC

L'Evoluzione del Piano di Controllo

Un Wireless LAN Controller (WLC) è un dispositivo di rete responsabile della gestione centralizzata, della configurazione e dell'applicazione delle politiche di sicurezza su più access point (AP) wireless. Nelle prime implementazioni wireless, gli AP operavano autonomamente, richiedendo una configurazione individuale e mancando la capacità di coordinare gli ambienti RF o i trasferimenti di roaming. Man mano che il wireless è passato da una rete di convenienza a un'infrastruttura mission-critical, il sovraccarico amministrativo degli AP autonomi è diventato insostenibile.

Il WLC ha risolto questo problema introducendo l'architettura split-MAC. In questo modello, l'AP (spesso definito AP "leggero") gestisce le funzioni del livello fisico 802.11 in tempo reale e sensibili al tempo, come la trasmissione di beacon e le risposte alle probe. Il controller si assume la responsabilità delle funzioni del livello MAC non in tempo reale, inclusa la gestione RF, l'applicazione delle politiche di sicurezza e l'autenticazione dei client. La comunicazione tra l'AP leggero e il controller è tipicamente incapsulata all'interno di un tunnel CAPWAP (Control and Provisioning of Wireless Access Points).

Il Ruolo di CAPWAP

CAPWAP è fondamentale per le operazioni tradizionali del WLC. Stabilisce un tunnel sicuro tra l'AP e il controller, trasportando sia il traffico di controllo (gestione e configurazione) che il traffico dati (payload dei client).

In un'implementazione con piano dati centralizzato, tutto il traffico client viene instradato al controller prima di essere inoltrato alla rete cablata. Ciò consente l'applicazione centralizzata delle politiche, l'ispezione approfondita dei pacchetti e una gestione VLAN semplificata. Tuttavia, può creare un significativo collo di bottiglia in ambienti ad alta densità.

Per mitigare ciò, molte implementazioni moderne utilizzano FlexConnect (Cisco) o architetture di switching locale simili. Qui, il piano di controllo rimane centralizzato sul WLC, ma il piano dati è distribuito, consentendo al traffico client di uscire localmente allo switch di bordo. Ciò riduce drasticamente il carico di elaborazione sul WLC e migliora il throughput, in particolare attraverso i collegamenti WAN.

Roaming Senza Interruzioni e Gestione Client

Uno dei principali fattori tecnici per l'implementazione di un WLC è il roaming client senza interruzioni. In un ambiente multi-AP, un client che si sposta nell'area di copertura deve passare da un AP all'altro. Senza un controller, il client prende questa decisione in modo completamente indipendente, spesso con conseguente sindrome del "client appiccicoso", in cui il dispositivo mantiene una connessione debole a un AP distante, degradando la capacità complessiva del canale.

A WLC orchestra questo processo. Mantenendo una visione centralizzata dell'ambiente RF e dello stato di autenticazione del client (particolarmente critico per le implementazioni 802.1X), il controller può pre-organizzare l'evento di roaming. Facilita il trasferimento della cache PMK (Pairwise Master Key) del client all'AP di destinazione, consentendo una transizione senza interruzioni in millisecondi, garantendo che le chiamate VoIP e le sessioni di streaming rimangano ininterrotte. Questo è vitale per mantenere un'elevata soddisfazione degli ospiti in luoghi come Hospitality e Retail .

Guida all'Implementazione: Scegliere l'Architettura Giusta

Nel 2026, gli architetti di rete devono valutare tre distinti modelli di implementazione. La decisione dipende da scala, conformità, tolleranza alla latenza e strutture di budget CAPEX vs. OPEX.

1. WLC Hardware Tradizionale (On-Premises)

Il modello tradizionale prevede un'appliance fisica implementata in un data center locale o in una sala server.

Architettura: Piani di controllo e dati centralizzati (tipicamente).
Vantaggi: Controllo completo sulla residenza dei dati, resilienza offline (sopravvive alle interruzioni WAN) e applicazione delle politiche altamente granulare.
Svantaggi: Elevato CAPEX iniziale, limiti di capacità finiti che richiedono la sostituzione dell'hardware per una scalabilità significativa e configurazioni di ridondanza complesse (N+1 o Attivo/Standby).
Ideale per: Implementazioni su larga scala in un'unica sede (es. stadi, grandi ospedali, campus universitari) dove l'elaborazione locale dei dati è imposta dalla conformità o dalla latenzvincoli.

2. Controller gestito in cloud

Il modello gestito in cloud astrae il piano di controllo a una piattaforma SaaS ospitata dal fornitore, mentre il piano dati rimane distribuito all'edge.

Architettura: Piano di controllo cloud centralizzato, piano dati locale distribuito.
Vantaggi: Scalabilità rapida, modello di abbonamento OPEX, provisioning zero-touch e dashboard di gestione unificata su siti geograficamente dispersi.
Svantaggi: Richiede connettività WAN affidabile per la gestione (anche se lo switching dati locale sopravvive alle interruzioni) e potenziali preoccupazioni sulla residenza dei dati a seconda della regione cloud del fornitore.
Ideale per: Ambienti multi-sito come catene di vendita al dettaglio, filiali aziendali distribuite e operazioni in franchising.

3. Senza controller (Autonomo/Mesh)

In questo modello, gli access point comunicano peer-to-peer, eleggendo un controller virtuale tra loro per gestire la coordinazione di base.

Architettura: Piani di controllo e dati distribuiti.
Vantaggi: Costo di ingresso più basso, implementazione semplice, nessun hardware controller dedicato o abbonamento cloud richiesto.
Svantaggi: Scalabilità limitata, capacità di roaming di base e mancanza di funzionalità di sicurezza aziendali avanzate.
Ideale per: Implementazioni piccole, a sito singolo (es. piccole unità di vendita al dettaglio, caffè boutique) con bassa densità di client e requisiti minimi di conformità.

Migliori Pratiche per l'Implementazione

Indipendentemente dall'architettura scelta, l'adesione alle migliori pratiche standard del settore è fondamentale per garantire la stabilità e le prestazioni della rete.

Dimensionamento per il picco, non per la media: La capacità del WLC è strettamente licenziata e applicata in base agli AP e alle sessioni client concorrenti. Quando si progetta per ambienti ad alta densità come gli hub di Trasporto o gli stadi, è necessario calcolare la capacità in base al carico di picco dell'evento, non all'utilizzo medio giornaliero. La mancata osservanza di ciò comporterà il rifiuto delle richieste di associazione client da parte del WLC durante i periodi critici.
Progettazione per la ridondanza: Un WLC hardware è un singolo punto di guasto. Le implementazioni devono incorporare l'alta disponibilità (HA). Le piattaforme moderne supportano lo Stateful Switchover (SSO), garantendo che le sessioni client e le associazioni AP passino senza interruzioni a un controller di standby senza richiedere la riautenticazione.
Implementare il Local Breakout per l'alta larghezza di banda: Nelle architetture WLC centralizzate, evitare di reindirizzare il traffico guest ad alta larghezza di banda (es. streaming video) attraverso il tunnel CAPWAP alla rete core. Utilizzare lo switching locale all'edge per scaricare questo traffico direttamente su internet, preservando la capacità di elaborazione del WLC per le funzioni del piano di controllo e il traffico aziendale sicuro.
Applicare politiche di sicurezza rigorose: Utilizzare il WLC come punto di applicazione centrale per la sicurezza. Assicurarsi che WPA3 Enterprise sia implementato dove supportato e applicare un robusto isolamento client sulle reti Guest WiFi per prevenire la comunicazione peer-to-peer tra dispositivi non attendibili.

Risoluzione dei Problemi e Mitigazione dei Rischi

Quando le implementazioni WLC falliscono, l'impatto è spesso sistemico. Comprendere le modalità di guasto comuni è essenziale per una rapida mitigazione.

Routing Asimmetrico e Frammentazione CAPWAP

Rischio: Quando si implementa un WLC centralizzato su una WAN complessa, le discrepanze MTU (Maximum Transmission Unit) possono causare la frammentazione dei pacchetti CAPWAP. Ciò degrada significativamente le prestazioni degli AP e può portare a disconnessioni intermittenti degli AP. Mitigazione: Assicurarsi che l'MTU sia coerente lungo l'intero percorso tra l'AP e il WLC. Se la frammentazione è inevitabile, configurare il WLC per regolare il TCP MSS (Maximum Segment Size) per prevenire la perdita di pacchetti.

Densità AP vs. Interferenza di Canale

Rischio: L'aggiunta di più AP a un WLC non aumenta linearmente la capacità se la pianificazione dei canali viene ignorata. La gestione RF automatizzata del WLC (es. RRM di Cisco o ARM di Aruba) può diventare instabile in implementazioni eccessivamente dense, cambiando costantemente canali e livelli di potenza, portando a un'esperienza client degradata. Mitigazione: Condurre indagini sul sito predittive e attive approfondite. Regolare manualmente gli algoritmi RF del WLC, definendo soglie minime e massime rigorose di potenza di trasmissione per prevenire l'interferenza co-canale.

Conformità e Residenza dei Dati

Rischio: L'implementazione di un controller gestito in cloud senza verificare le posizioni dei data center del fornitore può portare a violazioni immediate del GDPR o PCI DSS, in particolare se gli indirizzi MAC guest o i log di autenticazione vengono elaborati al di fuori delle giurisdizioni conformi. Mitigazione: Verificare l'architettura di residenza dei dati del fornitore WLC cloud. Assicurarsi che siano in atto accordi di elaborazione dei dati (DPA) e che il fornitore supporti l'archiviazione localizzata dei dati per le implementazioni europee.

ROI e Impatto Commerciale

La decisione di implementare, aggiornare o migrare un'architettura WLC deve essere giustificata da risultati aziendali misurabili. Il ROI viene tipicamente valutato su tre vettori:

Efficienza Operativa: I WLC gestiti in cloud riducono significativamente il sovraccarico operativo della gestione di reti distribuite. Il provisioning zero-touch consente di spedire gli AP direttamente a siti remoti, scaricando automaticamente la configurazione dal cloud al momento della connessione. Ciò elimina la necessità di costose visite ingegneristiche in loco.
Riduzione del Rischio: Un WLC hardware centralizzato con HA robusta fornisce la resilienza offline richiesta per operazioni mission-critical, come gli ambienti Sanitari . Il costo di un WLC ridondante è spesso trascurabile rispetto al danno finanziario e reputazionale di un'interruzione di rete sistemica.
Abilitazione di Analisi Avanzate: Il WLC fornisce la connettività fondamentale, ma il vero valore aziendale viene sbloccato a livello di applicazione. Integrando un WLC con una piattaforma come quella di Purple WiFi Analisi , i dati di connessione grezzi vengono trasformati in intelligence utilizzabile. Purple funge da provider di identità (IdP) gratuito per servizi come OpenRoaming, acquisendo preziosi dati di prima parte. Ciò consente alle strutture di misurare il tempo di permanenza, comprendere i modelli di affluenza e promuovere campagne di marketing mirate, contribuendo direttamente alla generazione di entrate.

Come discusso nel nostro recente annuncio, Purple nomina Iain Fox VP Growth , l'attenzione si concentra sempre più sull'inclusione digitale e sull'innovazione delle smart city. Un'architettura WLC robusta, abbinata all'analisi di Purple, costituisce la base di queste iniziative, consentendo una connettività fluida, sicura e intelligente in ampi spazi pubblici. Inoltre, l'adozione di metodi di autenticazione moderni, come quelli dettagliati in Come un assistente Wi-Fi abilita l'accesso senza password nel 2026 , si basa interamente sull'applicazione sicura e centralizzata delle policy fornita dall'infrastruttura WLC.

Definizioni chiave

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.

Esempi pratici

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.

Commento dell'esaminatore: 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.

Commento dell'esaminatore: 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.

Domande di esercitazione

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?

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

Visualizza risposta modello

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?

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

Visualizza risposta modello

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?

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

Visualizza risposta modello

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.