Erste Schritte mit Juniper Mist

1. Lernziele

Organisation, Site, Site Group, Inventory und Gerät fachlich unterscheiden
Rollen und Berechtigungsumfang nach dem Least-Privilege-Prinzip zuweisen
Cloud-Erreichbarkeit und lokale Netzdienste vor dem Rollout prüfen
Geräte claimen beziehungsweise adoptieren und einer Site zuweisen
Templates und sitebezogene Konfiguration sinnvoll voneinander abgrenzen
ein erstes WLAN sicher erstellen und mit echten Clients validieren
Insights, SLEs und Marvis als Diagnosehilfen einordnen

2. Was ist Juniper Mist?

Juniper Mist ist eine cloudverwaltete Plattform für Wireless, Wired, WAN und standortbezogene Dienste. Die Plattform stellt Management, Konfiguration und Telemetrie bereit. Je nach Lösung und Architektur können zusätzliche Assurance-, Access-, Marvis- oder Edge-Funktionen eingesetzt werden.

Wireless Assurance

Verwaltung und Bewertung von APs, Funkumgebung, Clients, WLANs und Benutzererlebnis.

Wired Assurance

Cloudgestützte Verwaltung und Telemetrie geeigneter Juniper-Switches.

WAN Assurance

Verwaltung und Analyse geeigneter WAN-Edge-Plattformen und Pfade.

Architekturhinweis: Cloudverwaltung bedeutet nicht automatisch, dass der Clientdatenverkehr durch die Mist Cloud läuft. Management-, Steuerungs- und Datenpfad müssen getrennt betrachtet werden.

3. Hierarchie und Konfigurationsumfang

Organisation→Site / Site Group→Gerät

Ebene	Zweck	Typische Inhalte
Organisation	administrative und technische Obergrenze	Administratoren, Subscriptions, Inventory, Templates, globale Einstellungen
Site Group	logische Gruppierung mehrerer Sites	gemeinsame Zuweisungen, Rollen- oder Template-Scope
Site	physischer Standort oder logische Unterteilung	Zeitzone, Adresse, RF-Einstellungen, WLANs, Geräte, Firmwareplanung
Gerät	einzelner AP, Switch, WAN Edge oder Mist Edge	Name, Standort, Status, individuelle Overrides und Insights

Juniper Mist erzeugt bei der Erstellung einer Organisation zunächst eine Primary Site. Diese hat keine Sonderstellung und kann umbenannt oder entfernt werden. Jede Site besitzt eine unveränderliche Site ID.

Konfigurationsprinzip: Standards möglichst auf Organisationsebene über Templates definieren. Abweichungen nur dort anlegen, wo ein nachweisbarer standort- oder gerätespezifischer Grund besteht.

4. Technische Voraussetzungen

Netzdienste für Access Points

Dienst	Anforderung	Bedeutung
DHCP	initial UDP 67/68	Der AP benötigt eine IP-Konfiguration; später ist auch eine statische Konfiguration möglich.
DNS	UDP 53 beziehungsweise passende DNS-Erreichbarkeit	Cloud-FQDNs müssen aufgelöst werden können.
Mist Cloud	primär ausgehend TCP 443	Onboarding, Konfiguration und Telemetrie; Juniper empfiehlt zusätzlich UDP 443 und TCP 80.
NTP	gegebenenfalls UDP 123 oder DHCP Option 42	Korrekte Zeit unterstützt Zertifikate, Ereigniskorrelation und Betrieb.
Lokale Dienste	abhängig vom WLAN	Default Gateway, DHCP, DNS, RADIUS, PKI und Anwendungsziele.

Juniper empfiehlt FQDN-basierte Firewallregeln, weil sich Cloud-IP-Adressen ändern können. Die konkret benötigten Ziele hängen von Cloud-Region und aktivierten Diensten ab.

Vor dem Anschließen prüfen

PoE-Leistung und Switchportkonfiguration passen zum AP-Modell
Management-VLAN, native/untagged VLAN-Behandlung und Trunks sind festgelegt
DHCP, DNS, NTP und Internetpfad funktionieren vom AP-Netz aus
Client-VLANs und Gateways existieren Ende-zu-Ende
RADIUS-, Zertifikats- und Firewallregeln sind vorbereitet
Seriennummern, Claim Codes und physische AP-Positionen sind dokumentiert

5. Konten, Rollen und Zugriff

Administratoren werden in der Organisation verwaltet. Rechte sollten nach Scope und Aufgabe vergeben werden.

Rolle	Grundcharakter	Typischer Einsatz
Super User	vollständiger Lese-/Schreibzugriff einschließlich Administratoren und Login-Einstellungen	sehr kleiner Kreis verantwortlicher Plattformadministratoren
Org Admin	Schreibzugriff auf Organisation und Sites, jedoch ohne bestimmte administrative Funktionen	organisationsweite Netzwerkadministration
Network Admin	auf Sites, Site Groups oder alle Sites begrenzter Netzwerkzugriff	regionaler oder standortbezogener Betrieb
Observer/Helpdesk-orientiert	reduzierter oder lesender Zugriff gemäß zugewiesenem Scope	Monitoring und First-Level-Support

Sicherheitsregel: Mindestens zwei kontrollierte Notfallzugänge vorsehen, MFA beziehungsweise SSO nach Organisationsvorgabe aktivieren und Administratoränderungen über Audit Logs nachvollziehen.

6. Organisation und Sites vorbereiten

Die offizielle Navigation kann sich durch Portalupdates verändern. In der aktuellen Dokumentation erfolgt die Site-Verwaltung unter Organization → Admin → Site Configuration.

1. Organisation prüfen
Name, Zeitzone, Cloud-Region, Login-/SSO-Einstellungen, Org ID und Verantwortlichkeiten dokumentieren.

2. Sites anlegen
Mindestens Name, Zeitzone und Standort eintragen. Sites nach echten Betriebs- und Failure-Domain-Grenzen strukturieren.

3. Site Groups planen
Nur verwenden, wenn mehrere Sites eine nachvollziehbare gemeinsame Policy oder Zuständigkeit besitzen.

4. Maps vorbereiten
Grundrisse maßstabsgerecht einpflegen und AP-Position, Höhe sowie Orientierung dokumentieren.

5. Namenskonzept festlegen
APs, Switches, WLANs, Templates und Sites konsistent und maschinenlesbar benennen.

Designhinweis: Eine Site ist keine bloße Ordnerstruktur. Sie beeinflusst unter anderem Konfiguration, RF-Kontext, Firmwareplanung, Auswertung und Berechtigungsscope.

7. Geräte claimen, adoptieren und zuweisen

Ein Gerät muss zunächst Eigentum beziehungsweise Verwaltungsobjekt der Organisation werden. Danach wird es einer Site zugewiesen.

Claim/Adopt→Inventory→Site Assignment→Konfiguration→Connected

Claim

Neue Geräte werden über Claim Code, Aktivierungscode oder QR-Code in die Organisation übernommen. Die Mist AI Mobile App kann Geräte scannen und direkt einer Site zuweisen.

Adopt

Geeignete vorhandene Juniper-Geräte können abhängig von Plattform und Installed Base in die Mist-Verwaltung übernommen werden.

Portalablauf für APs

Organization → Inventory öffnen.
Access Points auswählen und Geräte claimen beziehungsweise vorhandene Geräte anzeigen.
Unassigned APs markieren.
More → Assign to Site auswählen.
Ziel-Site wählen und Zuweisung bestätigen.
AP anschließen und Status, Firmware, LLDP-Nachbar sowie Cloud-Konnektivität prüfen.

Nicht verwechseln: Claimed bedeutet, dass das Gerät zur Organisation gehört. Assigned bedeutet, dass es einer konkreten Site zugeordnet ist. Connected bedeutet, dass die Cloud-Kommunikation tatsächlich funktioniert.

8. Templates und Vererbung

Templates reduzieren Konfigurationsdrift und wiederholte Arbeit. Sie sollten jedoch bewusst versioniert, getestet und einem klaren Scope zugewiesen werden.

Objekt	Zweck	Beispiel
WLAN Template	Sammlung von WLAN-, Tunneling- und WxLAN-Einstellungen	einheitliche Corporate- und Guest-SSIDs
RF Template	gemeinsame Radio- und RRM-Vorgaben	Kanäle, Leistungen, Bandparameter
Device Profile	Konfiguration für definierte AP-Gruppen innerhalb einer Site	Außen-APs, Lagerbereiche, Sondermodelle
Switch Template	gemeinsame Switchkonfiguration	Portprofile, VLANs und Campusstandards
WAN Edge Template	standardisierte WAN-Edge-Konfiguration	Filialen mit einheitlichem WAN-Design

Empfohlene Reihenfolge

organisationsweiten Standard definieren,
Template einem kontrollierten Pilot-Scope zuweisen,
Resultat an echten Geräten validieren,
erst danach auf weitere Sites ausrollen,
Overrides dokumentieren und regelmäßig auf Notwendigkeit prüfen.

Vorsicht bei Vererbung: Vor jeder Änderung prüfen, welche Sites und Geräte das Template verwenden. Eine kleine organisationsweite Änderung kann einen großen operativen Radius besitzen.

9. Das erste WLAN erstellen

Ein WLAN kann sitebezogen oder in einem WLAN Template angelegt werden:

Site: Site → Wireless → WLANs → Add WLAN
Organisationstemplate: Organization → Wireless → WLAN Templates → Add WLAN

Mindestkonfiguration

Bereich	Prüffrage
SSID	Ist der Name eindeutig, dokumentiert und für den Einsatzzweck geeignet?
Security Type	WPA3, WPA2/WPA3, 802.1X/EAP, PSK, PPSK oder Gastverfahren?
VLAN	Ist das Client-VLAN auf AP-Uplink, Switching, Gateway und DHCP vollständig vorhanden?
Bänder	2,4, 5 und/oder 6 GHz passend zu Clients und Design?
IP-Zugriff	Welche internen und externen Ziele dürfen Clients erreichen?
QoS/Rate Limits	Sind Anwendungsklassen und Begrenzungen fachlich begründet?
Client Isolation	Dürfen Clients untereinander kommunizieren?

Seit einer Mist-Aktualisierung im November 2025 ist WPA3 im Portal der Standard-Sicherheitstyp für neu erstellte WLANs. Bestehende WLANs werden dadurch nicht automatisch geändert. Für 6 GHz und Wi-Fi 7 sind die jeweiligen Sicherheitsanforderungen zu berücksichtigen.

Keine Blindkonfiguration: Vor dem Erstellen müssen Clientkompatibilität, Authentifizierungsverfahren, VLAN-Pfad, DHCP, DNS und Zugriffsregeln feststehen. Ein sichtbares SSID ist noch kein funktionsfähiger Dienst.

10. AP online bringen und prüfen

1. Strom und Link
PoE-Klasse, Portzustand, Geschwindigkeit, Duplex und LLDP-Nachbar prüfen.

2. IP-Konfiguration
Adresse, Maske, Gateway, DHCP-Optionen und DNS-Verhalten verifizieren.

3. Cloud-Verbindung
Status Connected, Zeitstempel, Ereignisse und gegebenenfalls Firewalllogs prüfen.

4. Firmware
freigegebene Version und Upgradefenster festlegen; nicht unkontrolliert während des Geschäftsbetriebs aktualisieren.

5. Konfiguration
Template-Zuweisungen, Overrides, WLANs, VLANs und Radios kontrollieren.

6. Map Placement
AP am tatsächlichen Montagepunkt mit korrekter Höhe und Orientierung platzieren.

Was bei Cloud-Ausfall zu klären ist

Das genaue Verhalten hängt von Gerät, Funktion und Konfiguration ab. Vor Produktivsetzung ist zu testen:

Bleiben bestehende WLANs und lokale Datenpfade aktiv?
Können sich neue Clients weiterhin authentifizieren?
Welche Funktionen benötigen laufende Cloud- oder Mist-Edge-Konnektivität?
Wie werden Konfigurationsänderungen, Telemetrie und Alarme beeinflusst?

11. Validierung mit Insights und Service Levels

Mist bewertet nicht nur den Gerätestatus, sondern stellt Client-, AP- und Serviceperspektiven bereit. Die genaue Sicht hängt von Subscriptions, Gerätetyp und aktivierten Diensten ab.

AP Insights

Cloud-Verbindung, Ereignisse, Radioverhalten, Firmware und angeschlossene Infrastruktur.

Client Insights

Association, Authentifizierung, DHCP, DNS, Roaming, Datenraten und Verbindungshistorie.

SLEs

Service Level Expectations fassen Benutzererlebnis nach Metriken und Fehlerursachen zusammen.

Erste Abnahmetests

Client findet SSID auf den vorgesehenen Bändern
Association und Authentifizierung sind erfolgreich
DHCP liefert korrekte Adresse, Gateway und DNS-Server
DNS-Auflösung und vorgesehene Anwendungen funktionieren
Policy und Segmentierung erlauben nur den definierten Zugriff
Roaming wird mit geeignetem Client und laufendem Verkehr getestet
Client- und AP-Insights zeigen den Ablauf vollständig und zeitlich korrekt
RF-Werte, Retries, Kanalnutzung und verwendete Datenraten sind plausibel

Diagnosegrundsatz: Ein grüner AP-Status beweist nur einen Teil des Dienstes. Entscheidend ist der vollständige Clientpfad von RF über Authentifizierung und IP-Dienste bis zur Anwendung.

12. Marvis sinnvoll einsetzen

Marvis Actions bündelt von Mist erkannte, auswirkungsrelevante Probleme und stellt Ursachen sowie Handlungsempfehlungen bereit. Je nach Subscription und Funktion sind Driver-Assist- oder ausdrücklich freigegebene Self-Driving-Aktionen möglich.

Marvis Actions

Priorisiert erkannte Probleme aus Wireless, Wired und WAN und verweist auf betroffene Sites, Geräte oder Dienste.

Conversational Assistant

Ermöglicht Abfragen in natürlicher Sprache zu Sites, Geräten, Clients, Anwendungen und Fehlerbildern.

Verantwortungsvoller Start

zunächst Empfehlungen und Nachweise verstehen,
Ergebnisse mit Rohdaten und realem Nutzerproblem korrelieren,
automatische Aktionen nur nach Risiko- und Scope-Bewertung freigeben,
Änderungen über Audit- und Ereignisdaten nachvollziehen,
Wirkung und mögliche Nebenwirkungen nach der Aktion validieren.

Wichtig: Marvis unterstützt Diagnose und Automatisierung. Architekturwissen, Change-Verantwortung und unabhängige technische Validierung bleiben erforderlich.

13. Day-0-/Day-1-Checkliste

Phase	Ergebnis
Organisation	Org, Cloud-Region, Adminrollen, MFA/SSO, Audit und Verantwortlichkeiten dokumentiert
Subscriptions	Aktivierungscode angewendet, Laufzeiten und Site-Zuweisungen geprüft
Sites	Name, Zeitzone, Standort, Gruppen und Maps korrekt angelegt
Netzwerk	PoE, Management-VLAN, DHCP, DNS, NTP, Firewall und Client-VLANs getestet
Templates	WLAN-, RF- und Geräteprofile im Pilot-Scope validiert
Inventory	Geräte geclaimt/adoptiert, benannt, zugewiesen und physisch zugeordnet
WLAN	Security, VLAN, Bänder, Policies und Clientkompatibilität bestätigt
Firmware	Zielversion, Wartungsfenster und Rollback-/Supportverfahren festgelegt
Abnahme	Clientpfad, Anwendungen, Roaming, RF und Insights dokumentiert geprüft
Betrieb	Alarmierung, Runbooks, Eskalation, Backup/Dokumentation und Lifecycle-Prozess vorhanden

Häufige Fehlannahmen

Behauptung	Bewertung	Fachliche Einordnung
„Claimed und Assigned bedeuten dasselbe.“	Falsch	Claim ordnet ein Gerät der Organisation zu; Assignment ordnet es einer Site zu.
„Connected bedeutet, dass das WLAN für Benutzer funktioniert.“	Falsch	Cloud-Verbindung des AP beweist nicht den vollständigen Client-, VLAN-, AAA- und Anwendungspfad.
„Cloud-managed bedeutet Cloud-Datenverkehr.“	Falsch	Der Datenpfad ist separat zu konfigurieren und kann lokal verlaufen.
„Templates verhindern jede Fehlkonfiguration.“	Falsch	Templates skalieren sowohl korrekte als auch fehlerhafte Einstellungen.
„Auto-RF ersetzt RF-Design und Survey.“	Falsch	Automatisierung optimiert innerhalb physischer und konfigurierter Grenzen; Montage und Design bleiben entscheidend.
„Marvis ersetzt Paketanalyse und Fachwissen.“	Falsch	Marvis liefert Korrelation und Empfehlungen, muss aber im Kontext validiert werden.

Merksätze

Organisation, Site, Inventory und Gerät sind unterschiedliche Verwaltungsebenen.
Claimed, Assigned und Connected beschreiben verschiedene Zustände.
Templates schaffen Konsistenz, vergrößern aber den Änderungsradius.
Cloud-Erreichbarkeit ersetzt nicht die Prüfung lokaler Netzdienste.
Ein sichtbares SSID ist noch kein funktionsfähiger WLAN-Dienst.
Die Abnahme erfolgt aus Client- und Anwendungssicht.
SLEs und Marvis unterstützen die Diagnose, ersetzen aber keine technische Validierung.
Ein kontrollierter Pilot gehört vor den breiten Rollout.

Offizielle Grundlagen

Stand der inhaltlichen Prüfung: August 2026. Portalbezeichnungen und Funktionsumfang können durch laufende Cloud-Updates geändert werden.