Qu'est-ce qu'un WLC (Wireless LAN Controller) et en avez-vous encore besoin ?

Ce guide complet explore l'évolution des Wireless LAN Controllers (WLC) et fournit un cadre technique pour déterminer la bonne architecture en 2026. Il couvre les modèles matériels traditionnels, gérés dans le cloud et sans contrôleur, détaillant leur impact sur la conformité, l'évolutivité et l'expérience client.

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

Écouter ce guide

Voir la transcription du 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.

Résumé Exécutif

Pour les responsables informatiques et les architectes réseau déployant des réseaux sans fil d'entreprise, le Wireless LAN Controller (WLC) a toujours été le système nerveux central de l'infrastructure sans fil. Cependant, le paysage architectural a considérablement évolué. Avec l'essor des architectures gérées dans le cloud et des plans de données distribués, la question fondamentale pour tout nouveau déploiement ou cycle de rafraîchissement n'est plus simplement « quel contrôleur devrions-nous acheter », mais plutôt « avons-nous encore besoin d'un contrôleur matériel ? »

Ce guide fournit une analyse technique complète des architectures WLC en 2026. Nous examinons l'évolution des matériels centralisés traditionnels vers les topologies modernes gérées dans le cloud et sans contrôleur. En comparant ces architectures techniques aux exigences de conformité réelles (telles que PCI DSS et GDPR), aux besoins d'évolutivité et aux résultats en matière d'expérience client, cette référence permet aux décideurs techniques de choisir la stratégie de plan de contrôle appropriée.

De plus, nous explorons comment des plateformes comme Purple fonctionnent de manière agnostique au-dessus de cette couche d'infrastructure, transformant la connectivité brute en intelligence exploitable, quel que soit le fournisseur de matériel sous-jacent.

Plongée Technique : Comprendre le WLC

L'Évolution du Plan de Contrôle

Un Wireless LAN Controller (WLC) est un périphérique réseau responsable de la gestion centralisée, de la configuration et de l'application des politiques de sécurité sur plusieurs points d'accès sans fil (AP). Dans les premiers déploiements sans fil, les AP fonctionnaient de manière autonome, nécessitant une configuration individuelle et manquant de la capacité à coordonner les environnements RF ou les transferts d'itinérance. À mesure que le sans fil est passé d'un réseau de commodité à une infrastructure critique, la surcharge administrative des AP autonomes est devenue intenable.

Le WLC a résolu ce problème grâce à l'introduction de l'architecture split-MAC. Dans ce modèle, l'AP (souvent appelé AP « léger ») gère les fonctions de la couche physique 802.11 en temps réel et sensibles au temps, telles que la transmission de balises et les réponses de sonde. Le contrôleur assume la responsabilité des fonctions de la couche MAC non en temps réel, y compris la gestion RF, l'application des politiques de sécurité et l'authentification client. La communication entre l'AP léger et le contrôleur est généralement encapsulée dans un tunnel CAPWAP (Control and Provisioning of Wireless Access Points).

Le Rôle de CAPWAP

CAPWAP est fondamental pour les opérations WLC traditionnelles. Il établit un tunnel sécurisé entre l'AP et le contrôleur, transportant à la fois le trafic de contrôle (gestion et configuration) et le trafic de données (charges utiles client).

Dans un déploiement de plan de données centralisé, tout le trafic client est acheminé vers le contrôleur avant d'être routé vers le réseau filaire. Cela permet une application centralisée des politiques, une inspection approfondie des paquets et une gestion simplifiée des VLAN. Cependant, cela peut créer un goulot d'étranglement important dans les environnements à haute densité.

Pour atténuer cela, de nombreux déploiements modernes utilisent FlexConnect (Cisco) ou des architectures de commutation locale similaires. Ici, le plan de contrôle reste centralisé au niveau du WLC, mais le plan de données est distribué, permettant au trafic client de sortir localement au niveau du commutateur de périphérie. Cela réduit considérablement la charge de traitement sur le WLC et améliore le débit, en particulier sur les liaisons WAN.

Itinérance Transparente et Gestion des Clients

L'un des principaux moteurs techniques du déploiement d'un WLC est l'itinérance transparente des clients. Dans un environnement multi-AP, un client se déplaçant dans la zone de couverture doit passer d'un AP à un autre. Sans contrôleur, le client prend cette décision de manière entièrement indépendante, ce qui entraîne souvent le syndrome du « client collant », où l'appareil maintient une connexion faible à un AP distant, dégradant la capacité globale du canal.

Un WLC orchestre ce processus. En maintenant une vue centralisée de l'environnement RF et de l'état d'authentification du client (particulièrement critique pour les déploiements 802.1X), le contrôleur peut pré-organiser l'événement d'itinérance. Il facilite le transfert du cache PMK (Pairwise Master Key) du client vers l'AP cible, permettant une transition transparente en quelques millisecondes, garantissant que les appels VoIP et les sessions de streaming restent ininterrompus. Ceci est vital pour maintenir une satisfaction client élevée dans des lieux comme l'Hôtellerie et le Commerce de Détail .

Guide d'Implémentation : Choisir la Bonne Architecture

En 2026, les architectes réseau doivent évaluer trois modèles de déploiement distincts. La décision dépend de l'échelle, de la conformité, de la tolérance à la latence et des structures budgétaires CAPEX vs. OPEX.

1. WLC Matériel Traditionnel (Sur Site)

Le modèle traditionnel implique un appareil physique déployé dans un centre de données local ou une salle de serveurs.

Architecture : Plans de contrôle et de données centralisés (généralement).
Avantages : Contrôle total sur la résidence des données, résilience hors ligne (survit aux pannes WAN) et application de politiques très granulaires.
Inconvénients : CAPEX initial élevé, limites de capacité finies nécessitant le remplacement du matériel pour une mise à l'échelle significative, et configurations de redondance complexes (N+1 ou Actif/Veille).
Meilleure Adéquation : Déploiements importants sur un seul site (par exemple, stades, grands hôpitaux, campus universitaires) où le traitement des données locales est imposé par la conformité ou la latency contraintes.

2. Contrôleur géré dans le cloud

Le modèle géré dans le cloud abstrait le plan de contrôle vers une plateforme SaaS hébergée par un fournisseur, tandis que le plan de données reste distribué en périphérie.

Architecture : Plan de contrôle cloud centralisé, plan de données local distribué.
Avantages : Évolutivité rapide, modèle d'abonnement OPEX, provisionnement sans intervention, et tableau de bord de gestion unifié pour les sites géographiquement dispersés.
Inconvénients : Nécessite une connectivité WAN fiable pour la gestion (bien que la commutation de données locale survive aux pannes), et des préoccupations potentielles concernant la résidence des données en fonction de la région cloud du fournisseur.
Idéal pour : Environnements multi-sites tels que les chaînes de magasins, les succursales d'entreprise distribuées et les opérations franchisées.

3. Sans contrôleur (Autonome/Mesh)

Dans ce modèle, les points d'accès communiquent de pair à pair, élisant un contrôleur virtuel parmi eux pour gérer la coordination de base.

Architecture : Plans de contrôle et de données distribués.
Avantages : Coût d'entrée le plus bas, déploiement simple, aucun matériel de contrôleur dédié ni abonnement cloud requis.
Inconvénients : Évolutivité limitée, capacités d'itinérance de base et manque de fonctionnalités de sécurité d'entreprise avancées.
Idéal pour : Petits déploiements sur un seul site (par exemple, petites unités de vente au détail, cafés-boutiques) avec une faible densité de clients et des exigences de conformité minimales.

Bonnes pratiques de déploiement

Quelle que soit l'architecture choisie, l'adhésion aux meilleures pratiques standard de l'industrie est essentielle pour garantir la stabilité et les performances du réseau.

Dimensionner pour le pic, pas la moyenne : La capacité du WLC est strictement sous licence et appliquée en fonction des points d'accès et des sessions client simultanés. Lors de la conception pour des environnements à haute densité comme les pôles de Transport ou les stades, vous devez calculer la capacité en fonction de la charge maximale de l'événement, et non de l'utilisation quotidienne moyenne. Ne pas le faire entraînera le rejet des demandes d'association client par le WLC pendant les périodes critiques.
Concevoir pour la redondance : Un WLC matériel est un point de défaillance unique. Les déploiements doivent intégrer une haute disponibilité (HA). Les plateformes modernes prennent en charge le Stateful Switchover (SSO), garantissant que les sessions client et les associations de points d'accès basculent de manière transparente vers un contrôleur de secours sans nécessiter de réauthentification.
Mettre en œuvre le breakout local pour la haute bande passante : Dans les architectures WLC centralisées, évitez de renvoyer le trafic invité à haute bande passante (par exemple, le streaming vidéo) via le tunnel CAPWAP vers le réseau central. Utilisez la commutation locale en périphérie pour décharger ce trafic directement vers Internet, préservant ainsi la capacité de traitement du WLC pour les fonctions du plan de contrôle et le trafic d'entreprise sécurisé.
Appliquer des politiques de sécurité strictes : Utilisez le WLC comme point d'application central de la sécurité. Assurez-vous que WPA3 Enterprise est déployé là où il est pris en charge, et appliquez une isolation client robuste sur les réseaux Guest WiFi pour empêcher la communication de pair à pair entre les appareils non fiables.

Dépannage et atténuation des risques

Lorsque les déploiements WLC échouent, l'impact est souvent systémique. Comprendre les modes de défaillance courants est essentiel pour une atténuation rapide.

Routage asymétrique et fragmentation CAPWAP

Risque : Lors du déploiement d'un WLC centralisé sur un WAN complexe, les incompatibilités de MTU (Maximum Transmission Unit) peuvent entraîner la fragmentation des paquets CAPWAP. Cela dégrade considérablement les performances des points d'accès et peut entraîner des déconnexions intermittentes des points d'accès. Atténuation : Assurez-vous que le MTU est cohérent sur l'ensemble du chemin entre le point d'accès et le WLC. Si la fragmentation est inévitable, configurez le WLC pour ajuster le TCP MSS (Maximum Segment Size) afin d'éviter les pertes de paquets.

Densité des points d'accès vs. interférence de canal

Risque : L'ajout de points d'accès à un WLC n'augmente pas linéairement la capacité si la planification des canaux est ignorée. La gestion RF automatisée du WLC (par exemple, RRM de Cisco ou ARM d'Aruba) peut devenir instable dans des déploiements trop denses, modifiant constamment les canaux et les niveaux de puissance, ce qui entraîne une expérience client dégradée. Atténuation : Menez des études de site prédictives et actives approfondies. Ajustez manuellement les algorithmes RF du WLC, en définissant des seuils de puissance de transmission minimum et maximum stricts pour éviter les interférences de co-canal.

Conformité et résidence des données

Risque : Le déploiement d'un contrôleur géré dans le cloud sans vérifier les emplacements des centres de données du fournisseur peut entraîner des violations immédiates du GDPR ou du PCI DSS, en particulier si les adresses MAC des invités ou les journaux d'authentification sont traités en dehors des juridictions conformes. Atténuation : Vérifiez l'architecture de résidence des données du fournisseur de WLC cloud. Assurez-vous que des accords de traitement des données (DPA) sont en place et que le fournisseur prend en charge le stockage de données localisé pour les déploiements européens.

ROI et impact commercial

La décision de déployer, de mettre à niveau ou de migrer une architecture WLC doit être justifiée par des résultats commerciaux mesurables. Le ROI est généralement évalué selon trois vecteurs :

Efficacité opérationnelle : Les WLC gérés dans le cloud réduisent considérablement la charge opérationnelle de la gestion des réseaux distribués. Le provisionnement sans intervention permet d'expédier les points d'accès directement vers des sites distants, téléchargeant automatiquement la configuration depuis le cloud lors de la connexion. Cela élimine le besoin de visites d'ingénierie coûteuses sur site.
Réduction des risques : Un WLC matériel centralisé avec une HA robuste offre la résilience hors ligne requise pour les opérations critiques, telles que les environnements de Santé . Le coût d'un WLC redondant est souvent négligeable par rapport aux dommages financiers et de réputation d'une panne réseau systémique.
Activation de l'analyse avancée : Le WLC fournit la connectivité fondamentale, mais la véritable valeur commerciale est débloquée au niveau de la couche application. En intégrant un WLC à une plateforme comme le WiFi Analyses , les données de connexion brutes sont transformées en informations exploitables. Purple agit comme un fournisseur d'identité (IdP) gratuit pour des services comme OpenRoaming, capturant des données de première partie précieuses. Cela permet aux lieux de mesurer le temps de présence, de comprendre les schémas de fréquentation et de mener des campagnes marketing ciblées, contribuant directement à la génération de revenus.

Comme indiqué dans notre récente annonce, Purple nomme Iain Fox au poste de VP Croissance , l'accent est de plus en plus mis sur l'inclusion numérique et l'innovation des villes intelligentes. Une architecture WLC robuste, associée aux analyses de Purple, constitue le fondement de ces initiatives, permettant une connectivité transparente, sécurisée et perspicace dans de vastes espaces publics. De plus, l'adoption de méthodes d'authentification modernes, telles que celles détaillées dans Comment un assistant Wi-Fi permet un accès sans mot de passe en 2026 , repose entièrement sur l'application sécurisée et centralisée des politiques fournie par l'infrastructure WLC.

Définitions clés

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.

Exemples concrets

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.

Commentaire de l'examinateur : 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.

Commentaire de l'examinateur : 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.

Questions d'entraînement

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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.