Komponenten
APs, Controller, Cloud-Dienste, Switches, Gateways, AAA, DHCP, DNS und Managementsysteme.
1. Lernziele
- autonome, controllerbasierte und cloudverwaltete WLAN-Architekturen unterscheiden
- Management-, Control- und Data Plane fachlich trennen
- lokales und zentralisiertes Forwarding bewerten
- Ausfallszenarien und Abhängigkeiten einer Architektur erkennen
- den WLAN-Lebenszyklus von Strategie bis Außerbetriebnahme erklären
- technische, organisatorische und wirtschaftliche Lebenszyklen gemeinsam planen
2. Was bedeutet Wi-Fi-Architektur?
Eine Wi-Fi-Architektur beschreibt nicht nur Access Points und Funkzellen. Sie legt fest, wo Konfiguration, Steuerungsentscheidungen, Sicherheitsfunktionen, Datenweiterleitung, Telemetrie und Betriebsverantwortung angesiedelt sind.
Beziehungen
Managementkanäle, Tunnel, VLANs, Routing, Zertifikate, APIs und Abhängigkeiten.
Betriebsmodell
Zuständigkeiten, Änderungen, Überwachung, Updates, Support und Lebenszyklusentscheidungen.
Grundsatz: Die Funkplanung ist ein Teil der Architektur. Ein gutes RF-Design kann durch einen ungeeigneten Datenpfad, instabile Abhängigkeiten oder fehlende Betriebsprozesse dennoch scheitern.
3. Grundlegende Architekturtypen
| Architektur | Kennzeichen | Stärken | Herausforderungen |
|---|---|---|---|
| Autonome APs | Konfiguration und Steuerung liegen weitgehend auf jedem AP. | geringe zentrale Abhängigkeit, einfache Kleinstumgebungen | Konfigurationskonsistenz, Skalierung, Übersicht und Änderungen |
| Controllerbasiert | Eine zentrale oder redundante Instanz koordiniert APs und Richtlinien. | zentrale Steuerung, einheitliche Policies, Mobility-Funktionen | Controllerkapazität, Redundanz, Tunnel- und Ausfalldesign |
| Cloudverwaltet | Management und häufig Control-Funktionen werden als Dienst bereitgestellt. | standortübergreifende Sicht, Automatisierung, geringer lokaler Managementaufwand | WAN-, DNS-, Zeit- und Cloud-Abhängigkeit sowie Lizenzmodell |
| Virtueller Controller | Controllerfunktion läuft als VM, Softwareinstanz oder AP-integrierte Funktion. | flexible Bereitstellung, weniger Spezialhardware | Ressourcen, Plattformabhängigkeit und Failure Domain |
| Hybrid | Lokale und zentrale beziehungsweise Cloud-Funktionen werden kombiniert. | Anpassung an Standorte und regulatorische Anforderungen | höhere Komplexität und klare Funktionsabgrenzung erforderlich |
Keine absolute Kategorie: „Cloud-managed“ sagt allein nicht, wo Nutzdaten weitergeleitet werden. Management kann in der Cloud liegen, während der Datenverkehr vollständig lokal verbleibt.
4. Management, Control und Data Plane
Management Plane
Control Plane
Data Plane
| Funktionsbereich | Aufgabe | Beispiele |
|---|---|---|
| Management Plane | Konfiguration, Monitoring, Inventar und Administration | GUI, API, Telemetrie, Logs, Firmwareverwaltung |
| Control Plane | Steuerungsinformationen und Entscheidungen | AP-Join, RF-Optimierung, Clientzustand, Mobility-Steuerung |
| Data Plane | Transport des eigentlichen Clientverkehrs | lokales Bridging, Controller-Tunnel, Routing, Policy Enforcement |
Die genaue Verteilung dieser Funktionen ist hersteller- und architekturspezifisch. Eine zentrale Managementoberfläche bedeutet daher nicht automatisch eine zentralisierte Control oder Data Plane.
Prüffrage: Für jede Funktion muss geklärt werden: Wo läuft sie, welche Verbindung benötigt sie, was geschieht bei deren Ausfall und wie lange kann der Dienst ohne sie weiterarbeiten?
5. Lokales und zentralisiertes Forwarding
Lokales Forwarding
Clientverkehr verlässt den AP am lokalen Standort, typischerweise über VLAN oder Routing. Das reduziert zentrale Datenpfadabhängigkeiten und kann WAN-Verkehr vermeiden.
Zentralisiertes Forwarding
Clientverkehr wird zum Controller oder Gateway getunnelt. Richtlinien und Übergänge lassen sich zentralisieren, der Datenpfad benötigt aber Kapazität und Redundanz.
| Kriterium | Lokal | Zentral |
|---|---|---|
| Latenz zum lokalen Dienst | meist direkter Pfad | möglicher Umweg über Tunnelendpunkt |
| Policy-Zentralisierung | Verteilung auf lokale Infrastruktur nötig | am zentralen Gateway gut bündelbar |
| WAN-Ausfall | lokaler Verkehr kann häufig fortbestehen | abhängig vom Tunnel- und Survivability-Konzept |
| Skalierung | verteilt sich auf Standorte | zentrale Tunnel-, Durchsatz- und Sessiongrenzen beachten |
| Fehlersuche | mehr lokale Pfade und VLANs | zentraler Einblick, aber zusätzliche Tunnelkomplexität |
6. Ergänzende Architekturformen
Mesh
APs verwenden drahtlose Backhaul-Verbindungen. Jeder Funk-Hop beansprucht Airtime; Pfadstabilität, Kanalnutzung und Stromversorgung bleiben kritische Faktoren.
Remote AP / Teleworker
Ein AP erweitert ein Unternehmensnetz an einen entfernten Standort. Tunnel, lokale Ausbruchspfade, Zertifikate und Verhalten bei WAN-Ausfall müssen definiert sein.
Campus
Viele überlappende Zellen, hohe Mobilität und zentrale Dienste verlangen konsistentes RF-, Switching-, Security- und Mobility-Design.
Distributed Branch
Viele kleine Standorte benötigen standardisierte Templates, Zero-Touch-Prozesse, lokale Überlebensfähigkeit und zentralen Überblick.
Guest Architecture
Gastverkehr benötigt Isolation, Onboarding, rechtlich abgestimmte Protokollierung sowie einen kontrollierten Internetübergang.
IoT/OT Architecture
Gerätefähigkeiten, lange Lebensdauer, eingeschränkte Security, feste Kommunikationsbeziehungen und Segmentierung prägen das Design.
7. Auswahl einer geeigneten Architektur
Die Architektur folgt den Anforderungen, nicht einer Produktbezeichnung. Eine belastbare Entscheidung bewertet mindestens folgende Bereiche:
| Kriterium | Leitfragen |
|---|---|
| Geschäftsanforderung | Welche Prozesse hängen vom WLAN ab? Welche Ausfallzeit ist tolerierbar? |
| Standortstruktur | Campus, Filialen, Lager, Außenbereiche oder temporäre Standorte? |
| Client- und Anwendungsmix | Voice, Video, Scanner, IoT, BYOD, Echtzeit oder hohe Datenmengen? |
| Sicherheit | 802.1X, Zertifikate, Segmentierung, Gastzugang, NAC und Compliance? |
| Verfügbarkeit | Welche Komponenten, Links und Dienste bilden Failure Domains? |
| Betriebsfähigkeit | Welche Kompetenzen, Prozesse und Bereitschaftszeiten sind vorhanden? |
| Skalierung | APs, Clients, Standorte, Tunnel, Telemetrie und API-Limits? |
| Wirtschaftlichkeit | Investition, Subskription, Betrieb, WAN, Schulung und Refresh? |
| Datenhoheit | Wo liegen Konfiguration, Telemetrie, Identitäten und Protokolle? |
Geeignete Architektur = Anforderungen + beherrschbare Abhängigkeiten + tragfähiger Betrieb
8. Der Wi-Fi-Lebenszyklus
Ein WLAN ist kein einmaliges Installationsprojekt. Es ist ein fortlaufend betriebener Dienst, dessen Anforderungen, Clients, Funkumgebung, Sicherheitslage und Herstellerplattform sich verändern.
Strategie→Anforderungen→Design→Beschaffung→Implementierung→Betrieb→Optimierung→Refresh
Geschäftsziele, Verantwortlichkeiten, Standorte, Budget und Serviceklassen festlegen.
Clients, Anwendungen, Kapazität, Mobilität, Sicherheit, Verfügbarkeit und Compliance erfassen.
Standortdaten, Spektrum, Verkabelung, Switching, RF, Security und Datenpfade planen.
Kritische Annahmen mit realen Clients, Anwendungen und Betriebsabläufen validieren.
Hardware, Lizenzen, Support, Adressierung, Zertifikate, Templates und Inventar vorbereiten.
kontrollierter Rollout, Migration, Abnahmetests, Dokumentation und Übergabe.
Monitoring, Incident-, Problem-, Change-, Security- und Kapazitätsmanagement.
EOL-Risiken, Ersatz, Migration, Datenlöschung, Lizenzbeendigung und Entsorgung steuern.
9. Anforderungen, Design und Validierung
Anforderungen müssen messbar sein
| Unpräzise | Prüfbare Form |
|---|---|
| „Überall gutes WLAN“ | definierte Mindestabdeckung, SNR, Kapazität und Anwendungsleistung in festgelegten Bereichen |
| „Roaming muss funktionieren“ | maximale Unterbrechungszeit, Paketverlust und getestete Client-/Anwendungskombination |
| „hohe Verfügbarkeit“ | Serviceziel, Failure Domains, Redundanz und überprüftes Ausfallverhalten |
| „sicheres WLAN“ | konkrete Identitäts-, Verschlüsselungs-, Segmentierungs- und Protokollierungsanforderungen |
Designartefakte
- Anforderungs- und Annahmenkatalog
- High-Level- und Low-Level-Design
- RF-Planung und Survey-Ergebnisse
- SSID-, VLAN-, Policy- und Authentifizierungsmatrix
- IP-, DNS-, DHCP-, NTP- und Zertifikatsabhängigkeiten
- Redundanz-, Ausfall- und Wiederherstellungskonzept
- Test-, Migrations-, Rollback- und Abnahmeplan
Validierungsgrundsatz: Ein prädiktives Design ist eine belastbare Planungshypothese. Die installierte Umgebung muss nach dem Rollout vor Ort und mit den maßgeblichen Anwendungen validiert werden.
10. Betrieb und kontinuierliche Verbesserung
Überwachen
Verfügbarkeit, Authentifizierung, RF, Kapazität, Clienterlebnis, Lizenzen und Abhängigkeiten.
Verändern
Änderungen kontrolliert planen, testen, dokumentieren, freigeben und bei Bedarf zurückrollen.
Verbessern
Trends, wiederkehrende Incidents, neue Clients und geänderte Nutzung in Designanpassungen überführen.
Wichtige Betriebsbereiche
| Bereich | Beispiele |
|---|---|
| Service Monitoring | Erreichbarkeit, Join-Status, Clientverbindungen, Authentifizierungserfolg |
| RF Monitoring | Kanalnutzung, Noise, Retries, MCS, Nachbarzellen und Interferenz |
| Capacity Management | aktive Clients, Airtime, Anwendungsbedarf und Wachstum |
| Security Management | Schwachstellen, Zertifikate, Adminzugriffe, Protokolle und Anomalien |
| Configuration Management | Templates, Versionen, Drift, Backups und dokumentierte Sollzustände |
| Knowledge Management | Runbooks, Topologien, Eskalationswege und Lessons Learned |
Messwerte brauchen Kontext: Ein Hersteller-Dashboard ersetzt keine Servicebewertung. Technische Telemetrie muss mit Zeit, Ort, Clienttyp, Anwendung und Nutzerwirkung korreliert werden.
11. Refresh, End of Life und Außerbetriebnahme
Mehrere Lebenszyklen laufen parallel und enden nicht zwangsläufig gleichzeitig.
| Lebenszyklus | Beispiele | Risiko bei Nichtbeachtung |
|---|---|---|
| Hardware | AP, Controller, Antenne, Switch, Stromversorgung | Ausfallrate, fehlende Ersatzteile, Leistungsgrenzen |
| Software/Firmware | unterstützte Releases, Security Fixes, Upgradepfade | Schwachstellen, Inkompatibilität, fehlender Support |
| Lizenz/Subscription | Management, Features, Support, Telemetrieaufbewahrung | Funktionsverlust oder fehlender Verwaltungszugriff |
| Standard und Spektrum | Clientfähigkeiten, regulatorische Änderungen, neue Frequenzbänder | ineffizienter Betrieb oder unzulässige Konfiguration |
| Zertifikate und Identitäten | PKI, RADIUS-Zertifikate, API- und Gerätezertifikate | plötzliche Authentifizierungs- oder Managementausfälle |
| Geschäftsanforderung | neue Anwendungen, Gebäudenutzung, Clientdichte | Architektur erfüllt den eigentlichen Zweck nicht mehr |
Begriffe sauber trennen
End of Sale
Produkt wird nicht mehr regulär verkauft. Bestehender Support kann weiterlaufen.
End of Support
Herstellerunterstützung und häufig sicherheitsrelevante Pflege enden. Das Datum ist für die Risikobewertung zentral.
Sichere Stilllegung
- Konfiguration, Schlüssel, Zertifikate und Zugangsdaten entfernen
- Geräte aus Management, NAC, Monitoring, DNS, DHCP und Inventar austragen
- Lizenzen und Subskriptionen korrekt beenden oder übertragen
- Logs und Dokumentation gemäß Aufbewahrungsregeln sichern
- Hardware datenschutz- und umweltgerecht verwerten
- Restabhängigkeiten und alte SSIDs nachweislich entfernen
12. Governance, Sicherheit und Dokumentation
Technische Architektur wird erst durch klare Verantwortlichkeiten dauerhaft beherrschbar.
| Rolle/Prozess | Verantwortung |
|---|---|
| Service Owner | Serviceziele, Budget, Risiko und Prioritäten |
| Architecture Owner | Prinzipien, Standards, Abhängigkeiten und Zielarchitektur |
| Operations | Überwachung, Incidentbehandlung und Regelbetrieb |
| Security | Risikovorgaben, Schwachstellen, Identitäten und Nachweise |
| Change Management | Bewertung, Freigabe, Kommunikation und Rollback |
| Asset/Lifecycle Management | Inventar, Verträge, EOL-Daten, Ersatz und Entsorgung |
Dokumentation als Betriebsbestandteil
Dokumentation muss versioniert, auffindbar und mit der realen Umgebung abgeglichen sein. Kritisch sind insbesondere:
TopologieRF-DesignSSID/PolicyAAA/PKIAbhängigkeitenRunbooksEOL-DatenRollback
Architekturentscheidung dokumentieren: Nicht nur festhalten, was gebaut wurde, sondern auch warum, unter welchen Annahmen und mit welchen bewusst akzeptierten Risiken.
Häufige Fehlannahmen
| Behauptung | Bewertung | Fachliche Einordnung |
|---|---|---|
| „Cloud-managed bedeutet, dass alle Nutzdaten durch die Cloud laufen.“ | Falsch | Managementort und Datenpfad sind getrennt zu prüfen. |
| „Ein redundanter Controller macht das WLAN vollständig hochverfügbar.“ | Falsch | Switching, Strom, WAN, DNS, DHCP, AAA, PKI und Datenpfad bleiben mögliche Failure Domains. |
| „Nach der Abnahme ist das WLAN fertig.“ | Falsch | Clients, Nutzung, Funkumgebung, Firmware und Risiken verändern sich kontinuierlich. |
| „Mehr neue APs lösen jedes Kapazitätsproblem.“ | Falsch | Ohne neues RF- und Kanaldesign kann zusätzliche Hardware die Konkurrenz erhöhen. |
| „EOL beginnt erst, wenn Hardware ausfällt.“ | Falsch | Support-, Firmware-, Lizenz- und Sicherheitsfristen müssen lange vorher geplant werden. |
| „Ein Backup der Konfiguration genügt als Notfallkonzept.“ | Falsch | Wiederherstellung braucht Plattform, Lizenzen, Schlüssel, Zertifikate, Abhängigkeiten, Verfahren und Tests. |
Merksätze
- Eine Wi-Fi-Architektur umfasst Funk, Steuerung, Datenpfad, Sicherheit und Betrieb.
- Cloud-Management und Cloud-Datenpfad sind nicht dasselbe.
- Jede zentrale Funktion benötigt eine bewertete Failure Domain und ein definiertes Ausfallverhalten.
- Architekturentscheidungen folgen Anforderungen und beherrschbaren Abhängigkeiten.
- Ein WLAN ist ein dauerhaft betriebener Service, kein einmaliges Installationsprojekt.
- Messbare Anforderungen bilden die Grundlage für Design und Abnahme.
- Hardware-, Software-, Lizenz-, Zertifikats- und Geschäftslebenszyklen laufen parallel.
- Eine sichere Außerbetriebnahme ist Teil des Architekturlebenszyklus.