Enterprise WLAN-Controller-Architektur: Cisco und Aruba WLAN-Design
Dieser Artikel ist Teil der Enterprise-WiFi-Serie.
Neu im Enterprise-Wireless-Bereich? Beginnen Sie mit der Übersicht: Enterprise WiFi-Architektur: Von Standards bis zur Deployment
Warum Controller-Architektur wichtig ist
Ein Access Point ist nur ein Radiosender. Was ihn zu einem Teil eines Unternehmensnetzwerks macht — mit konsistenter Richtlinie, nahtlosem Roaming, zentralisiertem Management und Sicherheitsintegration — ist die Controller-Architektur dahinter.
Wenn Sie die Controller-Architektur falsch gestalten, erhalten Sie:
- Roaming-Ausfälle zwischen Gebäuden oder Etagen
- Inkonsistente Sicherheitsrichtlinien über verschiedene AP-Gruppen
- Authentifizierungsengpässe, die Client-Verbindungen verlangsamen
- Verwaltungskomplexität, die Routineänderungen in mehrstufige Operationen verwandelt
Wenn Sie es richtig machen, verhält sich das WLAN wie eine Erweiterung der kabelgebundenen Infrastruktur — konsistent, verwaltbar und integriert mit Identitäts- und Sicherheitssystemen.
Die drei Architekturmodelle
Modell 1: Zentralisierter Controller (Traditionell)
Alle Intelligenz liegt im Controller. APs sind „dünn" — sie übertragen RF und leiten den gesamten Datenverkehr an den Controller:
[AP] ──CAPWAP-Datentunnel──→ [WLC] → Core-Switch → Netzwerk
[AP] ──CAPWAP-Datentunnel──→ [WLC]
[AP] ──CAPWAP-Datentunnel──→ [WLC]
CAPWAP (Control and Provisioning of Wireless Access Points) ist das Protokoll zwischen APs und dem Controller. Es transportiert:
- Steuerungsebene: AP-Registrierung, Konfiguration, RF-Management, Roaming-Entscheidungen
- Datenebene: Client-Datenverkehr (im zentralisierten Modus leitet der gesamte Client-Datenverkehr durch den Controller)
Vorteile:
- Zentralisierte Sichtbarkeit auf alle Clients und Datenverkehr
- Nahtloses Roaming innerhalb der Controller-Domäne — Client-Zustand bleibt auf dem Controller
- Konsistente Richtliniendurchsetzung — jeder Client durchläuft denselben Controller
Nachteile:
- WLC ist ein Single Point of Failure (erfordert HA-Paar)
- Datenverkehrs-Hairpin fügt Latenz und Controller-Bandbreitenverbrauch hinzu
- Skalierung erfordert das Hinzufügen von Controller-Kapazität
Verwendungsort: Große Campus-Deployments mit On-Premise-Infrastruktur, regulierte Umgebungen, die lokale Datenverkehrskontrolle erfordern.
Modell 2: Verteilt / FlexConnect
Ein Hybridmodell, bei dem der Controller Konfiguration und Richtlinie verwaltet, aber Client-Datenverkehr lokal am AP oder Branch-Switch vermittelt wird:
Zentraler Standort: Branch-Standort:
[WLC] [AP FlexConnect] ──lokaler Switch──→ LAN
│ │
└──WAN──────────nur CAPWAP-Steuerung──
Im FlexConnect-Modus übernimmt der AP lokales Switching für VLANs, die am Branch verfügbar sind. Wenn der WAN-Link ausfällt, können Clients weiterhin auf lokale Ressourcen zugreifen — der AP arbeitet im Standalone-Modus mit zwischengespeicherter Konfiguration.
Verwendungsort: Zweigstellen, die über WAN mit einem zentralen WLC verbunden sind, wo das Hairpinning des gesamten Datenverkehrs zur Zentrale unpraktisch wäre.
Modell 3: Cloud-verwaltet
Management und Konfiguration werden von einer Cloud-Plattform verwaltet. Datendatenverkehr geht direkt ins lokale Netzwerk — kein Hairpin:
[AP] ──Daten──→ Lokaler Switch → Netzwerk (direkt, kein Controller-Hairpin)
[AP] ──Verwaltungstunnel──→ Cloud-Dashboard (Konfiguration, Monitoring)
APs kommunizieren für Konfiguration und Telemetrie mit der Cloud, aber Client-Daten verlassen das lokale Netzwerk nie. Wenn die Cloud-Konnektivität verloren geht, arbeiten APs mit ihrer letzten bekannten Konfiguration weiter.
Verwendungsort: Multi-Site-Organisationen ohne dediziertes Netzwerkpersonal an jedem Standort, KMU-Umgebungen, Einzelhandelsketten, Gastgewerbe.
Cisco Wireless-Architektur
Traditionell: Cisco WLC + Lightweight APs
Die klassische Cisco Enterprise-Wireless-Architektur:
- Cisco WLC (Wireless LAN Controller): Hardware-Appliances (9800er-Serie, früher 5508, 8540) oder virtuell (C9800-CL). Verwaltet je nach Modell bis zu Tausenden von APs.
- Lightweight APs (LWAPP/CAPWAP): Cisco Catalyst und Aironet APs im CAPWAP-Modus.
HA-Konfiguration: WLC-Paare arbeiten in Aktiv-Standby mit Stateful Switchover (SSO). Client-Sessions werden auf den Standby-WLC gespiegelt — Failover ist für Clients transparent.
WLC-Primär (Aktiv) ←── HA-Link ──→ WLC-Sekundär (Standby)
│ │
[APs] [APs]
Mobilitätsgruppe: Mehrere WLCs im selben Campus bilden eine Mobilitätsgruppe — Clients können zwischen APs, die von verschiedenen WLCs verwaltet werden, mit nahtlosem Layer-2- oder Layer-3-Roaming wechseln.
Modern: Cisco DNA Center + Catalyst Center
Ciscos aktuelles Enterprise-Platform:
- Catalyst Center (früher DNA Center): Die Management-, Automatisierungs- und Assurance-Plattform. Läuft auf dedizierten Hardware-Appliances.
- SD-Access: Ciscos Campus-Fabric-Technologie — Wireless- und Wired-Ports nehmen an demselben Richtlinien-Fabric mit konsistenter VLAN- und SGT-Zuweisung (Security Group Tag) teil.
- KI-verbessertes RRM: Radio Resource Management mit maschinellem Lernen zur Optimierung der Kanal- und Leistungszuweisung basierend auf historischen RF-Daten.
ISE-Integration: Cisco Identity Services Engine bietet 802.1X-Authentifizierung und Richtlinien. Wenn ein Client verbindet, authentifiziert ISE ihn, weist eine Sicherheitsgruppe zu, und DNA Center setzt die entsprechende Netzwerkrichtlinie durch — konsistent ob der Client kabelgebunden oder drahtlos ist.
Cisco Meraki: Cloud-verwaltete Einfachheit
Meraki ist Ciscos Cloud-verwaltete Plattform — für operative Einfachheit über Enterprise-Flexibilität konzipiert:
- Dashboard: Gesamtes Management über ein einziges Cloud-Portal. Null On-Premise-Controller-Hardware.
- Auto-Provisionierung: Neue APs werden bei Verbindung automatisch provisioniert — keine manuelle Konfiguration.
- Integrierte Sicherheit: Meraki APs enthalten integriertes IDS/IPS, Content-Filterung und Traffic-Analytik.
- MX-Integration: Meraki Wireless integriert sich nativ mit Meraki MX Sicherheitsappliances — einheitliche Richtlinie über kabelgebunden und drahtlos.
Kompromisse: Weniger flexibel als Catalyst Center für komplexe Enterprise-Richtlinien. Gesamtes Management erfordert Cloud-Konnektivität (APs arbeiten offline weiter, können aber nicht konfiguriert werden). Abonnementbasierte Lizenzierung.
Wo Meraki glänzt: Multi-Site-Einzelhandel, Gastgewerbe, KMU, Zweigstellen — jedes Szenario, wo operative Einfachheit und schnelles Deployment wichtiger als tiefe Enterprise-Anpassung sind.
Aruba Wireless-Architektur
Traditionell: Aruba Mobility Master + Mobility Controller
Arubas On-Premise Enterprise-Architektur:
- Mobility Master (MM): Die Top-Level-Management- und Orchestrierungsplattform. Leitet keinen Datendatenverkehr weiter — reine Steuerungsebene.
- Mobility Controller (MC): Verteilte Controller, die AP-Management, Client-Authentifizierung und Datenweiterleitungen für ihre lokalen APs übernehmen.
- APs: Aruba Access Points im „Campus AP"-Modus, verbunden mit ihrem zugewiesenen Controller.
[Mobility Master]
│
┌────┴────┐
[MC-1] [MC-2] ← Verteilte Controller
│ │
[APs] [APs]
Die Mobility Master Hierarchie trennt Verwaltungskomplexität von der Datenebenenskalierung. Der MM verwaltet globale Richtlinien, Firmware-Management und RF-Planung. Controller verwalten lokales AP-Management und Client-Daten. Diese Architektur skaliert gut für große, gebäudeübergreifende Campusse.
Cluster-Mobilität: Controller im selben Cluster teilen den Client-Zustand. Roaming zwischen APs auf verschiedenen Controllern im selben Cluster ist nahtlos — Authentifizierung und Session des Clients bewegen sich mit ihm.
Modern: Aruba CX + AOS 10
Arubas aktuelle Architektur (AOS 10) bewegt sich in Richtung eines verteilten, fabric-integrierten Modells:
- APs haben mehr lokale Intelligenz — Authentifizierung und Richtliniendurchsetzung können am AP ohne Controller-Beteiligung für jedes Paket stattfinden
- Integration mit Aruba CX Switching Fabric für einheitliche kabelgebundene/drahtlose Richtlinien
- Aruba Central als Verwaltungsebene — Cloud-basiert, ersetzt On-Premise Mobility Master für viele Deployments
Aruba Central: Cloud-verwaltetes Enterprise
Anders als Cisco Meraki (für Einfachheit konzipiert), ist Aruba Central als Enterprise-Grade-Cloud-Management positioniert:
- Vollständige Enterprise-Richtlinienfähigkeiten über Cloud-Management verfügbar
- KI-gestützte Netzwerkeinblicke und Anomalieerkennung
- ClearPass-Integration für 802.1X-Authentifizierung (cloud-verbunden, nicht nur On-Premise)
- Unterstützung für sehr große Deployments (Tausende von APs, Hunderte von Standorten)
ClearPass-Integration ist Arubas stärkster Differenziator: eine dedizierte NAC-Plattform, die 802.1X, Geräteprofiling, Gastportal, Posture-Bewertung und dynamische VLAN-Zuweisung übernimmt. ClearPass integriert sich mit Active Directory, LDAP und Drittanbieter-MDM-Systemen für umfassenden identitätsbasierten Netzwerkzugang.
Roaming-Architektur: Die kritischen Designentscheidungen
Layer-2-Roaming
Der Client wechselt von AP-1 zu AP-2, beide im selben VLAN und vom selben Controller verwaltet. Die IP-Adresse des Clients ändert sich nicht. Roaming ist schnell und transparent.
AP-1 (VLAN 10) ──→ Client roamt ──→ AP-2 (VLAN 10)
Gleiches Subnetz, gleicher Controller, Client-IP unverändert
Layer-3-Roaming
Der Client wechselt zwischen Subnetzen — verschiedene VLANs auf verschiedenen Controllern oder Gebäuden. Ohne spezielle Behandlung würde der Client eine neue IP-Adresse benötigen, was aktive Sessions unterbricht.
Enterprise-Controller verwalten Layer-3-Roaming durch einen Mobilitätstunnel — der ursprüngliche Controller (der „Anchor") hält die ursprüngliche IP-Adresse des Clients und tunnelt den Datenverkehr zum/vom aktuellen Controller des Clients (dem „Foreign"):
Client verbindet sich mit AP-1 (Gebäude A, VLAN 10, Controller-1)
Client roamt zu AP-2 (Gebäude B, VLAN 20, Controller-2)
Controller-2 (Foreign) ──Mobilitätstunnel──→ Controller-1 (Anchor)
Client-IP: noch 192.168.10.x aus VLAN 10
Session: ununterbrochen
Das fügt Overhead hinzu — Datenverkehr für den roamenden Client muss den Inter-Controller-Tunnel durchqueren. Für die meisten Anwendungen ist das vernachlässigbar. Für latenzsensitive Anwendungen (VoIP, Echtzeit-Video) die Anchor-to-Foreign-Tunnellänge minimieren.
Schnelles Roaming: 802.11r/k/v
Wie im Standards-Artikel beschrieben, sollten Enterprise-Deployments alle drei Fast-Roaming-Protokolle aktivieren. Aus Controller-Perspektive:
- 802.11r: Der Controller vorauthentifiziert den Client mit dem Ziel-AP, bevor der Client die aktuelle Verbindung trennt. Erfordert Koordination auf Controller-Ebene.
- 802.11k: Der Controller stellt Clients Nachbar-AP-Informationen bereit. Clients nutzen dies für bessere Roaming-Entscheidungen.
- 802.11v: Der Controller kann vorschlagen oder anfordern, dass ein Client zu einem bestimmten AP roamt — nützlich für Lastausgleich und Sticky-Client-Management.
Opportunistic Key Caching (OKC): Für Netzwerke mit WPA2-Enterprise (802.1X) ermöglicht OKC dem Client, einen zwischengespeicherten PMK (Pairwise Master Key) beim Roaming zu einem neuen AP wiederzuverwenden und eine vollständige 802.1X-Reauthentifizierung zu vermeiden. Reduziert die Roaming-Zeit in 802.1X-Netzwerken erheblich.
Radio Resource Management
Enterprise-Controller optimieren die RF-Umgebung kontinuierlich durch Radio Resource Management (RRM):
Sendeleistungssteuerung
Der Controller überwacht RSSI (Signalstärke) zwischen APs. Wenn ein AP starke Signale von vielen Nachbarn erkennt, reduziert er seine Sendeleistung — Abdeckung aufrechterhalten und gleichzeitig Interferenz mit benachbarten Zellen reduzieren.
Abdeckungsloch-Erkennung: Wenn ein Client schlechten RSSI meldet, kann der Controller die Sendeleistung des APs erhöhen, um zu kompensieren.
Dynamische Kanalzuweisung
Der Controller scannt die RF-Umgebung und weist Kanäle zu, um Gleichkanal-Interferenz zu minimieren:
- APs melden Nachbar-AP-Signale und Client-Interferenz
- Der Controller erstellt eine RF-Topologiekarte
- Kanäle werden zugewiesen, um die Trennung zwischen gleichen Kanal-APs zu maximieren
Bei Cisco heißt das RRM (Radio Resource Management). Bei Aruba ist es ARM (Adaptive Radio Management). Beide arbeiten autonom, profitieren aber von manuellen Überschreibungen für bekannte RF-Herausforderungen.
Client-Lastausgleich
Wenn mehrere APs denselben Bereich abdecken (überlappende Zellen), kann der Controller Clients über APs verteilen:
- Neue Clients zum weniger belasteten AP lenken, wenn beide in Reichweite sind
- Clients von überlasteten APs zu weniger belasteten Nachbarn verschieben
Das erfordert sorgfältiges Tuning — aggressiver Lastausgleich führt dazu, dass Clients unnötig roamen.
HA und Redundanz in der Controller-Architektur
WLC HA (Cisco)
Cisco 9800 WLCs unterstützen High Availability SSO (Stateful Switchover):
WLC-Aktiv ──RP (Redundanzport)──→ WLC-Standby
│ │
Konfiguration gespiegelt Client-Sessions gespiegelt
Wenn der aktive WLC ausfällt, übernimmt der Standby mit vollständigem Client-Session-Zustand — Clients verbinden sich nicht neu. APs behalten ihre CAPWAP-Tunnel; der Übergang ist transparent.
Aruba Controller HA
Aruba unterstützt Aktiv-Aktiv-Cluster-Konfigurationen, wo mehrere Controller die AP- und Client-Last teilen:
[MC-1] ←─ Cluster ─→ [MC-2] ←─ Cluster ─→ [MC-3]
│ │ │
[APs] [APs] [APs]
Wenn MC-1 ausfällt, verteilen sich seine APs auf MC-2 und MC-3. Client-Sessions werden durch das Cluster-Zustandsteilen aufrechterhalten.
Cloud-Management-Ausfallsicherheit
Cloud-verwaltete APs (Meraki, Aruba Central) arbeiten während eines Cloud-Konnektivitätsverlusts weiter:
- APs behalten die letzte bekannte Konfiguration
- Clients können normal verbinden und roamen
- Verwaltungsoperationen (Konfigurationsänderungen, Monitoring) erfordern Cloud-Konnektivität
Für Umgebungen, die garantierten Verwaltungszugang unabhängig von der Internetkonnektivität erfordern, bleibt On-Premise-Controller-Architektur geeigneter.
Integration mit Identitätssystemen
Cisco ISE-Integration
Für Deployments mit Cisco ISE für 802.1X:
Client verbindet sich mit WiFi
↓
AP sendet RADIUS-Anfrage an ISE (über WLC)
↓
ISE authentifiziert gegen Active Directory
↓
ISE gibt zurück: VLAN-Zuweisung + Security Group Tag
↓
WLC wendet Richtlinie an: Client wird in korrektes VLAN platziert
↓
DNA Center setzt SGT-basierte Richtlinie Ende-zu-Ende durch
ISE Posture Assessment kann auch die Gerätekonformität prüfen (AV-Status, OS-Patch-Level) bevor vollständiger Netzwerkzugang gewährt wird — identisches Verhalten für kabelgebundene und drahtlose Clients.
Aruba ClearPass-Integration
ClearPass bietet äquivalente Fähigkeiten für Aruba-Deployments:
- 802.1X-Authentifizierung via RADIUS
- MAC Authentication Bypass (MAB) für Geräte ohne 802.1X-Supplicants
- Geräteprofiling — Gerätetyp identifizieren (Telefon, Laptop, Drucker, IoT) basierend auf DHCP, HTTP User-Agent und CDP/LLDP-Signalen
- Gastportal — Selbstregistrierung oder Sponsor-Genehmigungs-Workflows
- Dynamische VLAN- und Rollenzuweisung basierend auf Benutzeridentität, Gerätetyp und Posture
ClearPasss OnGuard-Agent führt Posture-Bewertung durch — überprüft, dass Unternehmens-Laptops aktuelles AV, erforderliche Patches und genehmigte Software haben, bevor Netzwerkzugang gewährt wird.
Wichtigste Erkenntnisse
- Controller-Architektur bestimmt Roaming-Qualität, Richtlinienkonsistenz und operative Komplexität — nicht nur Verwaltungskomfort.
- Zentralisierter WLC bietet nahtloses Roaming und konsistente Richtlinien auf Kosten von Datenverkehrs-Hairpin und Single-Point-of-Failure-Risiko (mit HA gemindert).
- Cloud-Management (Meraki, Aruba Central) bietet operative Einfachheit und Multi-Site-Skalierung ohne On-Premise-Hardware.
- Schnelles Roaming (802.11r/k/v + OKC) muss auf Controller-Ebene für Sprach- und Videoanwendungen aktiviert werden — die Standardkonfiguration ist selten optimal.
- ISE/ClearPass-Integration verwandelt Wireless von „einem Netzwerk" in „einen identitätsbewussten Richtliniendurchsetzungspunkt" — konsistentes Verhalten für kabelgebunden und drahtlos, alles basierend auf wer und was verbindet.
Diese Serie
- 📖 Enterprise WiFi-Architektur Übersicht ← Beginnen Sie hier
- 📡 802.11 Standards Deep Dive
- 🏨 WiFi-Design für KMU, Hotels und Arztpraxen
- 🔐 WiFi-Sicherheit: WPA3, 802.1X, Rogue AP, Site Survey
Verwandte Artikel
- 🔐 802.1X Identitätsbasierte Architektur im Praxiseinsatz — Deep Dive in 802.1X-Deployment
- 🏗️ IT-Infrastruktur ist keine Produktsammlung — Systemdenken für Wireless
- 📊 Monitoring richtig gemacht — Wireless-Infrastruktur proaktiv überwachen
