Juniper Mist Konfigurationsobjekte

1. Lernziele

Organisation, Site und Gerät als Geltungsbereiche unterscheiden
Templates, Profiles, Policies, Shared Elements und Variablen fachlich einordnen
WLAN Template, RF Template und Device Profile voneinander abgrenzen
Switch Templates, Networks und Port Profiles korrekt verwenden
WAN Edge Templates und Hub Profiles nach Topologierolle unterscheiden
Konfigurationsvererbung und Overrides nachvollziehen
den effektiven Gerätezustand statt nur eines Einzelobjekts prüfen

2. Die Mist-Grundhierarchie

MSP optional→Organisation→Site→Gerät

Juniper Mist beschreibt für normale Organisationen drei Konfigurationsebenen. MSP-Umgebungen besitzen zusätzlich eine übergeordnete Ebene.

Ebene	Scope	Typische Objekte und Einstellungen
MSP	mehrere Kundenorganisationen	MSP-Templates, Organisationserstellung, übergreifende Verwaltung
Organisation	gesamte Mist-Organisation	Administratoren, Subscriptions, SSO, Zertifikate, Templates, Profiles, Inventory
Site	physischer Standort oder logische Unterteilung	Zeitzone, Standort, Site Variables, RF-Zuweisung, sitebezogene WLANs und Konfiguration
Gerät	ein AP, Switch oder WAN Edge	individuelle Parameter, Port-/Radioeinstellungen und Overrides

Grundregel: Breite Ebenen schaffen Standards. Engere Ebenen bilden begründete Ausnahmen. Eine engere Konfiguration kann geerbte Einstellungen überschreiben, aber die genaue Präzedenz ist objekt- und produktbereichsspezifisch zu prüfen.

3. Objektarten und ihre Beziehungen

Objektart	Funktion	Beziehungsart
Template	wiederverwendbare Sollkonfiguration für viele Sites oder Geräte	wird zugewiesen oder referenziert
Profile	gemeinsame Einstellungen für eine definierte Teilmenge oder Rolle	gilt für ausgewählte Geräte beziehungsweise Topologierollen
Policy	Regeln für Zugriff, Anwendung oder Verkehrspfad	referenziert Quell-, Ziel- und Aktionsobjekte
Shared Element	wiederverwendbarer Baustein innerhalb eines Konfigurationsmodells	wird von Profilen oder Regeln verwendet
Variable	Platzhalter für einen kontextabhängigen Wert	wird beim Rendern durch einen konkreten Wert ersetzt
Assignment	verbindet Template/Profile mit Site oder Gerät	bestimmt den tatsächlichen Geltungsbereich
Override	abweichender Wert auf engerer Ebene	überlagert einen geerbten Wert

Objekt definieren→referenzieren→Scope zuweisen→Variablen auflösen→Overrides anwenden→Gerätekonfiguration rendern

Wichtig: Die Existenz eines Templates bewirkt noch nichts. Erst Zuweisung, Referenz und gültige Variablen erzeugen eine effektive Konfiguration.

4. Wireless-Konfigurationsobjekte

Objekt	Aufgabe	Typischer Scope
WLAN	SSID, Security, VLAN, Bänder, Rate Limits, Portal und Zugriffsoptionen	Site oder Bestandteil eines WLAN Templates
WLAN Template	Sammlung von WLAN-, Tunneling- und WxLAN-Konfigurationen	Organisation; Zuweisung an Sites oder Nutzung über Device Profiles
RF Template	Rahmen für RRM, Kanäle, Leistung, Band- und Radioverhalten	Organisation; wird Sites zugewiesen
Device Profile	gemeinsame AP-Hardware-, Radio-, Ethernet-, VLAN- und WLAN-Einstellungen für ausgewählte APs	Organisation; Applies To bestimmt konkrete APs
AP-Konfiguration	individuelle Einstellungen eines einzelnen Access Points	Gerät
WxLAN Policy	labelbasierte Regeln zwischen Nutzern, Geräten, WLANs, Netzen und Anwendungen	Organisation oder Site
AP Variables	gerätespezifische Werte für unterstützte Templatefelder	einzelner AP

WLAN Template oder sitebezogenes WLAN?

WLAN Template

Geeignet für wiederkehrende SSIDs und Policies über mehrere Sites. Änderungen besitzen einen entsprechend großen Wirkungsbereich.

Site-WLAN

Geeignet für eine tatsächlich standortspezifische SSID oder einen begrenzten Sonderfall. Zu viele lokale WLANs erhöhen Drift und Betriebsaufwand.

Device Profile

Device Profiles gelten für ausgewählte APs und können beispielsweise Bluetooth, Default VLAN, Ethernetports, Radiooptionen und eingebundene WLAN Templates definieren. Sie eignen sich für Teilmengen wie Außen-APs, Lagerhallen oder bestimmte Modelle innerhalb einer Site.

Modellierungsregel: Ein Device Profile sollte eine dauerhafte technische Rolle beschreiben – nicht als kurzfristiger Sammelplatz für beliebige Ausnahmen dienen.

5. RF-Konfiguration und Präzedenz

Für RRM beschreibt Juniper ausdrücklich folgende Reihenfolge:

RF Template
breitester Scope

Device Profile
überschreibt RF Template

Direkte AP-Konfiguration
höchste Priorität

Ebene	Verwendung	Risiko
RF Template	gemeinsame RF-Leitplanken für alle APs einer Site	ungeeignete globale Vorgaben wirken auf viele Radios
Device Profile	abweichende RF-Vorgaben für ausgewählte AP-Gruppen	Überlagerung ist in der Siteansicht weniger offensichtlich
AP direkt	einzelne technisch begründete Ausnahme oder Test	höchste Driftgefahr und schwerste Skalierbarkeit

Ein RF Template kann modellbezogene Einstellungen je Band enthalten. Device Profiles können Einstellungen bandbezogen überschreiben. Bestimmte Wahlmöglichkeiten auf engeren Ebenen hängen davon ab, welche Optionen das RF Template zulässt.

Nicht pauschalisieren: Diese konkrete Reihenfolge ist für die RRM-/RF-Konfiguration dokumentiert. Andere Objektfamilien besitzen eigene Vererbungs- und Konfliktregeln.

6. Wired-Konfigurationsobjekte

Objekt	Funktion	Beispiel
Switch Template	gemeinsame Konfiguration über mehrere Sites	NTP, AAA, VLANs, Portregeln, Systemparameter
Site Switch Configuration	siteweite Anpassung der geerbten Switchkonfiguration	standortspezifische Gateway- oder Infrastrukturwerte
Switch Configuration	gerätespezifische Parameter und Overrides	Hostname, Rolle, IRB oder einzelner Port
Network	wiederverwendbares VLAN-/Subnetzobjekt	Corporate VLAN 20
Port Profile	standardisiertes Interfaceverhalten	AP-Trunk, 802.1X-Client, Voice, Kamera
Port Configuration Rule	weist Profile anhand von Portbereich, Modell oder Rolle zu	Ports 1–24 als Clientports
Dynamic Port Configuration	dynamische Profilauswahl nach erkannten Merkmalen	IoT- oder AP-Erkennung auf colorless ports
Additional CLI	Set-Kommandos für nicht über GUI abgebildete Funktionen	spezielle Junos-Option

Wired-Präzedenz

Organisationstemplate → Site-Konfiguration → Gerätekonfiguration

Bei Konflikten überschreibt der engere Scope den breiteren. Juniper empfiehlt, standortspezifische Werte möglichst über Site Variables statt durch unnötige Site-Overrides zu modellieren.

CLI-Warnung: Änderungen direkt über die Geräte-CLI erscheinen nicht vollständig als Mist-Konfigurationsobjekt. Mist-Dashboard-Konfiguration kann CLI-Konfiguration überschreiben. Der gewünschte Source of Truth muss daher organisatorisch eindeutig sein.

7. WAN-Konfigurationsobjekte

Objekt	Rolle	Typischer Einsatz
WAN Edge Template	gemeinsame Eigenschaften von Spoke-Geräten	WAN-Interfaces, Networks, Steering und Policies für Filialen
Hub Profile	Konfiguration eines Hub-Geräts und seiner Overlaypfade	Headend, Rechenzentrum oder zentraler Hub
Network	Quellnetz beziehungsweise Benutzer-/Tenant-Kontext	Branch-LAN, Corporate oder Guest
Application	Zielanwendung oder Adressdefinition	SaaS, Rechenzentrumsdienst oder Internetziel
Traffic Steering	gewünschter Pfad oder Pfadgruppe	Internet, MPLS, Overlay oder Hub
Application Policy	verknüpft Quelle, Aktion, Ziel und gegebenenfalls Steering/Security	Branch-to-Hub, Direct Internet Access
IDP/Security Profile	optionale Sicherheitsprüfung für unterstützte Plattformen und Lizenzen	Client-, Server- oder benutzerdefinierter Schutz

Scope von Application Policies

Organisationsebenen-Policies lassen sich in mehreren WAN Edge Templates oder Hub Profiles wiederverwenden. Eine direkt im Template, Hub Profile oder Gerät definierte Policy besitzt nur diesen engeren Scope und ist nicht als allgemeines Objekt wiederverwendbar.

Topologieregel: In Hub-and-Spoke-Designs konfigurieren WAN Edge Templates üblicherweise Spokes, während Hub Profiles die Hub-Geräte und Overlay-Endpunkte beschreiben.

8. Site- und Device-Variablen

Variablen erlauben ein gemeinsames Template, obwohl konkrete Werte je Site oder AP variieren.

Template: VLAN {{corp_vlan}} → Site A: 120 → Site B: 220

Syntax

doppelte geschweifte Klammern verwenden,
Buchstaben, Zahlen und Unterstriche sind zulässig,
keine Leerzeichen oder sonstigen Sonderzeichen,
nur Felder mit entsprechender Variablenunterstützung verwenden,
aufgelösten Wert vor dem Rollout kontrollieren.

Wireless-Variablenpräzedenz

Für Device-Profile-Variablen dokumentiert Juniper: direkte AP-Variable vor Device Profile vor Site-Variable.

Site Variable

Device Profile Variable

AP Variable

Nutzen und Risiko

Nutzen	Risiko
weniger Templates trotz unterschiedlicher Sites	fehlende oder falsch typisierte Werte erzeugen fehlerhafte Konfiguration
standardisierte Namen und Strukturen	gleicher Variablenname kann organisatorisch unterschiedlich verstanden werden
API- und Automatisierungsfähigkeit	indirekte Werte erschweren spontane Sichtprüfung

Best Practice: Variablenkatalog mit Name, Datentyp, erlaubtem Wertebereich, Bedeutung, Eigentümer und Beispielwert führen.

9. Policies, Labels und referenzierte Objekte

WxLAN

WxLAN Policies nutzen Labels für Objekte wie Nutzer, WLANs, APs, IP-Adressen, Subnetze und Anwendungen. Regeln verknüpfen diese Labels zu verständlichen Zugriffsaussagen.

WAN Application Policy

WAN Policies verknüpfen Networks/Users als Quelle, eine Aktion, Applications/Destinations als Ziel und bei engerem Scope gegebenenfalls Traffic Steering oder Security Services.

Quelle/Label→Policy Rule→Aktion→Ziel/Application→Pfad/Security

Objektabhängigkeiten

Objekte vor referenzierenden Regeln anlegen
Namen eindeutig und fachlich stabil wählen
Scope von Objekt und Policy vergleichen
Löschung oder Umbenennung auf Referenzen prüfen
spezifische Regeln vor allgemeinen Regeln anordnen, sofern Reihenfolge relevant ist
Hit Counts und tatsächliche Verkehrsflüsse zur Validierung nutzen

Policy ist ein Beziehungsobjekt: Eine Policy wirkt nur so korrekt wie die von ihr referenzierten Quellen, Ziele, Labels, Pfade und Sicherheitsprofile.

10. Vererbung und Overrides beherrschen

Overrides bieten notwendige Flexibilität, erhöhen aber die Zahl möglicher Sollzustände. Deshalb muss jede Ausnahme begründet, sichtbar und befristet beziehungsweise überprüfbar sein.

Frage	Prüfung
Wo ist der Wert definiert?	Template, Profile, Site, Variable, Gerät oder Additional CLI?
Wie gelangt er zum Gerät?	Zuweisung, Applies To, Site-Bezug oder Referenz?
Gibt es einen engeren Wert?	Site-, Device-, Port-, AP- oder Policy-Override prüfen.
Ist die Variable aufgelöst?	konkreten Renderwert statt Platzhalter bewerten.
Welcher Scope ist betroffen?	alle Sites, eine Site, Gerätegruppe oder Einzelgerät?
Ist die Ausnahme noch nötig?	Owner, Ticket, Ablaufdatum und technische Begründung prüfen.

Override Debt

Viele Einzelabweichungen bilden eine technische Schuld: Änderungen werden schwer vorhersehbar, Geräte verhalten sich unterschiedlich und die Fehlersuche benötigt mehr Zeit.

Skalierbarkeit steigt mit Standards – Betriebsrisiko steigt mit unkontrollierten Ausnahmen

11. Sicheres Änderungsmodell

Objekt und Scope identifizieren: Welches Objekt ist der echte Source of Truth?
Referenzen ermitteln: Welche Templates, Sites, Profiles und Geräte verwenden es?
Effective Configuration prüfen: Vererbung, Variablen und Overrides vollständig auflösen.
Diff bewerten: nicht nur Eingabeänderung, sondern resultierende Gerätekonfiguration betrachten.
Pilot bilden: kleine repräsentative Site- oder Gerätegruppe verwenden.
Validieren: Gerätestatus, Clientservice, Policies, Events und Telemetrie prüfen.
Ausrollen: gestaffelt und mit Wartungs-, Kommunikations- und Rollbackplan.
Dokumentieren: Grund, Scope, Ergebnis und verbleibende Overrides festhalten.

Änderungsradius: Ein organisationsweites Objekt kann Tausende Geräte beeinflussen. Die Einfachheit eines Portal-Klicks reduziert nicht die technische Tragweite.

12. Fehlersuche bei Konfigurationsobjekten

Symptom	Mögliche Ursache	Prüfung
AP übernimmt RF-Wert nicht	Device Profile oder direkter AP-Override	Applies To, Band-Override und AP-Konfiguration prüfen
WLAN fehlt an einzelnen APs	Template-/Profile-Scope, Site-Bezug oder WLAN-Einschränkung	WLAN Template, Site und AP-Zuweisung vergleichen
Switchport hat falsches VLAN	Port Profile, Site-/Device-Override oder dynamische Regel	effektives Portprofil und Switch Events prüfen
Templatewert ist je Site falsch	fehlende oder falsche Site Variable	Variablendefinition und aufgelösten Wert prüfen
WAN Policy zeigt keine Wirkung	falscher Scope, Objektbezug, Reihenfolge oder Steering	referenzierte Networks/Applications und Hit Count prüfen
CLI-Änderung verschwindet	Mist ist Source of Truth und pusht gerenderte Konfiguration	Dashboard-, Template- und Additional-CLI-Konfiguration prüfen

Diagnoseablauf

Gerät←direkte Config←Profile/Site←Template←Variable/Policy-Objekte

Vom Ergebnis rückwärts: Bei unerwartetem Verhalten zuerst das konkrete Gerät und die effektive Konfiguration untersuchen. Danach schrittweise zu Overrides, Profiles, Site und Organisationstemplates zurückgehen.

Häufige Fehlannahmen

Behauptung	Bewertung	Fachliche Einordnung
„Ein gespeichertes Template gilt automatisch für alle Geräte.“	Falsch	Es benötigt eine passende Zuweisung oder Referenz.
„Site Configuration ist immer die höchste Priorität.“	Falsch	Gerätespezifische Einstellungen können höhere Präzedenz besitzen.
„Alle Mist-Produkte haben exakt dieselbe Vererbungslogik.“	Falsch	Wireless, Wired und WAN besitzen eigene Objekt- und Konfliktregeln.
„Variablen sind nur Textabkürzungen.“	Falsch	Sie werden kontextbezogen aufgelöst und beeinflussen die gerenderte Konfiguration.
„Direkte Overrides sind die einfachste Dauerlösung.“	Falsch	Sie erhöhen Drift, Testaufwand und Fehlersuchkomplexität.
„CLI und Mist Dashboard sind gleichwertige Sources of Truth.“	Falsch	Bei Mist-verwalteten Geräten muss die gewünschte Quelle eindeutig definiert sein; Dashboardkonfiguration kann CLI-Werte überlagern.

Merksätze

Ein Objekt wirkt erst durch Zuweisung, Referenz und gültigen Scope.
Templates definieren Standards; Profiles bilden technische Teilmengen.
Variablen trennen gemeinsame Struktur von standortspezifischen Werten.
Für RF gilt: AP vor Device Profile vor RF Template.
Für Wired gilt bei Konflikten: Gerät vor Site vor Organisationstemplate.
Wireless, Wired und WAN dürfen nicht mit einer pauschalen Präzedenzregel bewertet werden.
Die effektive Gerätekonfiguration ist wichtiger als die isolierte Ansicht eines Templates.
Overrides benötigen technische Begründung, Owner und regelmäßige Überprüfung.

Offizielle Grundlagen

Stand der inhaltlichen Prüfung: August 2026. Portalpfade, Rollen und Funktionsumfang können durch laufende Cloud-Updates verändert werden.