Arbeitsablauf zur Einbindung eines EX-Switches in Wired Assurance

1. Lernziele

den Einbindungsprozess als Folge prüfbarer Zustände durchführen
Claim und Adoption korrekt auswählen
Rollen, Subscription, Hardware und Junos vorab prüfen
Site-Template und Konfigurationshoheit vor dem Push bewerten
Greenfield-ZTP und Brownfield-Cutover unterscheiden
Cloudsession und Configstatus unabhängig validieren
Virtual-Chassis-Sonderweg berücksichtigen
Netzwerkdienst bis zum Testclient abnehmen
Stop-, Rollback- und Eskalationskriterien anwenden
die Übergabe mit Baseline und Nachweisen abschließen

Leitfrage: Welcher Zustand ist erreicht, wodurch ist er bewiesen und darf der nächste Schritt freigegeben werden?

2. Zustandsmodell

Zustand	Beweis	Nächster Schritt
S0 · vorbereitet	Design, Rechte, Subscription, Hardware und Netzwerk geprüft	Claim/Adopt
S1 · im Inventory	Seriennummer/MAC in richtiger Organisation	Cloudverbindung/Site
S2 · connected	Portalstatus oder etablierte Gerätesession	Managemententscheidung
S3 · Site assigned	korrekte Site und Templatebezug sichtbar	Intent rendern
S4 · managed	Configuration Management aktiv	Push/Commit
S5 · configured	erwartete effektive Junos-Konfiguration committed	Serviceabnahme
S6 · accepted	Uplinks, Ports, Clients und SLEs im Ziel	Übergabe

Kein Zustandswechsel ohne Eingangsvoraussetzung, Beweis und Stop-Kriterium.

3. Gesamtworkflow

Planen→Vorprüfen→Claim/Adopt→Connect→Site→Manage→Commit→Test

Greenfield

Cloud-ready Gerät, Claim-/Activation-Code und ZTP. Zielkonfiguration liegt vor dem Einschalten bereit.

Brownfield

Produktiver Bestand, Adoption per Junos CLI, Konfigurationsvergleich und kontrollierter Ownership-Wechsel.

Onboarding, Cloudverbindung, Site Assignment und Configuration Management sind eigenständige Schritte. Ihre Reihenfolge und Wirkung müssen explizit geprüft werden.

4. Scope und Changeauftrag

Frage	Dokumentierter Wert
Welches Gerät?	Modell, Variante, Seriennummer, MAC, Asset-ID
Welche Rolle?	Standalone, Access, Distribution, VC Member, Fabric Node
Welche Site?	Organisation, Site, Gebäude, Raum, Rack, Höheneinheit
Welches Ziel?	unmanaged Telemetrie oder vollständiges Mist-Management
Welcher Impact?	betroffene Uplinks, VLANs, APs, Telefone und Clients
Welches Fenster?	Start, Ende, Kommunikations- und Eskalationsweg
Welcher Rollback?	Console/OOB, Rescue Config, Altgerät und Abbruchzeit

Ohne geklärten Zielzustand darf insbesondere bei Brownfield „Manage configuration with Mist“ nicht aktiviert werden.

5. Administratorrollen

Die Berechtigungen unterscheiden sich nach Aufgabe. Laut aktueller Juniper-Rollenmatrix ist Claim auf Super User begrenzt; Konfigurationsmanagement kann auch durch geeignete Network-Admin-Rollen aktiviert oder deaktiviert werden.

Aufgabe	Typische Mindestfreigabe laut Rollenmatrix
Claim Switch	Super User
Adopt Switch	in mehreren Rollen sichtbar; organisatorische Freigabe trotzdem erforderlich
Template bearbeiten	Super User
Switch/Site Config bearbeiten	Super User oder entsprechend berechtigter Network Admin
Configuration Management schalten	Super User oder berechtigter Network Admin
Remote Shell/Utilities	Super User oder berechtigter Network Admin
Release	Super User

Technische Portalberechtigung ist nicht gleich Changefreigabe. Hochwirksame Aktionen benötigen zusätzlich den betrieblichen Auftrag.

6. Technische Voraussetzungen

Bereich	Prüfung	Stop bei
Wired Assurance	Subscription aktiv	fehlender Lizenz-/Org-Zuordnung
EX Hardware	Modell/Variante unterstützt	nicht gelisteter Plattform
Junos	Standard-Junos, geeignete unterstützte Release	Flex Image, FIPS-Modus oder ungeklärter Version
Management	DHCP oder geplante statische IP, Gateway	kein belastbarer Rückweg
Services	DNS; NTP empfohlen	fehlender DNS-Auflösung oder unplausibler Zeit
Firewall	CloudX/klassischer Mistpfad gemäß Region	unbestätigter Egress
Recovery	Console/OOB und Backup	Brownfield ohne Wiederherstellungsweg

Versionsbewertung: Die dokumentierte generelle Mindestversion ist keine Empfehlung für Produktion. Plattform und Features werden gegen eine aktuelle JTAC Suggested Release geprüft.

7. Ziel-Intent vor dem Gerät

Site existiert mit richtiger Zeitzone und Adresse
Switch Template ist der Site korrekt zugewiesen
Networks/VLANs und Subnetze sind vollständig
Port Profiles für Uplink, AP, Client, Voice, IoT und Disabled existieren
Switchregeln treffen nur die beabsichtigten Modelle/Rollen
Site Variables sind befüllt und nicht mit Beispielwerten belegt
RADIUS, NTP, DNS, Syslog und SNMP sind fachlich geprüft
Switchspezifische Management-IP, Name und Rolle sind vorbereitet
Additional CLI ist minimal, syntaktisch geprüft und ownershipklar
Firmware-Autoupgrade und Rebootwirkung sind bekannt

Das Site-Template kann bei Zuordnung eines managed Switches unmittelbar wirksam werden. Deshalb gehört die Review vor und nicht nach den Claim.

8. Greenfield: Claim-Workflow

1. Identität
Claim-Code am Gerät oder Activation Code der Bestellung erfassen; MAC/Seriennummer abgleichen.

2. Portal
Organization → Admin → Inventory → Switches → Claim Switches.

3. Optionen
Site Assignment, Subscription, Configuration Management, Gerätename und Firmwareziel prüfen.

4. Root Password
Beim Web-Workflow sicher setzen und geschützt verwalten. Die Mobile App erlaubt laut Quick Start beim Claim keine Root-Passwortsetzung.

5. Claim
Ergebnisliste abwarten und jedes Gerät anhand MAC/Seriennummer kontrollieren.

6. Physisch
Uplink anschließen, einschalten und ZTP beobachten.

Gate	Beweis
Inventory Gate	richtiges Gerät in richtiger Organisation
Site Gate	richtige Site und erwartetes Template
Connection Gate	Status Connected/Cloud-ready LED gemäß Modell
Config Gate	kein Push-/Commitfehler

9. Brownfield: Adopt-Workflow

1. Bestand sichern
Junos-Konfiguration exportieren und bei geplanter Mist-Verwaltung request system configuration rescue save ausführen.

2. Ziel abgleichen
Alle produktiven Features in Template, Site, Switch oder Additional CLI abbilden.

3. Adopt-Befehle
Organization → Inventory → Switches → Adopt Switch; Befehle sicher kopieren.

4. Junos CLI
In edit wechseln, auf Top-Level stehen, Befehle einfügen, mit show kontrollieren und committen.

5. Session prüfen
show system connections auf etablierte Mist-Verbindung kontrollieren.

6. Inventory/Site
Gerät identifizieren, Site auswählen und Managemententscheidung bewusst treffen.

7. Cutover
Management nur mit vollständigem Ziel-Intent, Wartungsfenster und Rollback aktivieren.

Managed Brownfield: Juniper weist darauf hin, dass die bestehende Konfiguration durch den in Mist definierten Zustand ersetzt wird. Die Aktivierung ist daher der eigentliche Migrations-Cutover.

10. Cloudsession validieren

Modell	Transport	Prüfung
CloudX	HTTPS 443 und JTI	Portalstatus, CloudX-/Proxylogs, unterstützte Junos-Version
klassisch	Outbound SSH/NETCONF TCP 2200	`show system connections`, Outbound-SSH-Konfiguration
CloudX via Proxy	HTTPS über statischen/dynamischen Proxy	DHCP Option 43 oder statische Proxykonfiguration

DNS-Auflösung, Default Route, Quellinterface, NAT, Firewall, Proxy und Zeit werden getrennt geprüft. Ein lokaler Ping ins Internet beweist nicht, dass der benötigte Mist-Endpunkt und Transport erreichbar sind.

11. Site Assignment

Inventory→Switch wählen→More→Assign to Site→Site prüfen

Vor Bestätigung	Kontrollfrage
Organisation/Site	Ist das Ziel fachlich und regional korrekt?
Template	Welches Template ist mit dieser Site verknüpft?
Variablen	Sind alle Sitewerte gesetzt?
Management	Soll der Switch jetzt wirklich verwaltet werden?
Rolle	Welche rollenbasierten Regeln treffen das Gerät?
Reassignment	Retain oder Do not retain configuration?

Beim Reassignment behält „Retain configuration“ die vorhandene managed Konfiguration. „Do not retain“ setzt sie laut Juniper auf Defaultwerte zurück und behält den Hostnamen.

12. Configuration Management Gate

Aktiv

Mist Template, Site-, Switch- und Additional-CLI-Intent werden autoritativ auf das Gerät angewendet.

Inaktiv

Bestandskonfiguration bleibt primär lokal; Mist ergänzt dennoch Cloud- und Telemetriekomponenten.

Freigabekriterium	Muss erfüllt sein
Coverage	alle servicekritischen Bestandsfunktionen im Ziel abgebildet
Diff	erwartete Löschungen und Ergänzungen reviewed
Reachability	Managementpfad bleibt unter Zielkonfiguration erhalten
Recovery	Console/OOB, Backup und Abbruchzeit vorhanden
Approval	Change und Impact freigegeben

13. Render, Push und Commit

Template+Site+Switch+CLI→Junos Config→Commit

Stufe	Beweis	Fehlerklasse
Intent	Portal-/API-Werte korrekt	fachlicher Modellfehler
Rendering	effektive Konfiguration plausibel	Variable, Regel, Override
Transport	Switch erhält Push	Cloudsession/Erreichbarkeit
Commit	Junos akzeptiert Konfiguration	Syntax, Plattform, Konflikt
Operational	Protokolle und Ports im Soll	Design, Gegenstelle, Verkabelung

Bei fehlgeschlagenem Push kann Sync Configuration den Cloudzustand erneut synchronisieren. Das Werkzeug ersetzt nicht die Ursachenprüfung eines reproduzierbaren Commitfehlers.

14. Virtual-Chassis-Sonderweg

Plattformtyp	Workflow
mit dedizierten VCPs	Member verbinden, VC bilden, Cloud anbinden, anschließend preprovisionieren
EX2300 ohne dedizierte VCPs	Member einzeln onboarden, gleiche Site/Junos, Management aktiv, dann Form Virtual Chassis

unterstützte Modellkombination und Memberzahl
alle Mitglieder derselben Site zugewiesen
kompatible beziehungsweise gleiche Junos-Version
VCP-Portwahl und Verkabelung dokumentiert
Primary/Backup-Rollen bewusst festgelegt
Mist unterstützt nur preprovisioned VC
VC-Konfiguration nicht per Additional CLI verwalten

Ein VC erscheint nach erfolgreicher Bildung als ein logisches Gerät. Statistiken aller Mitglieder können zeitverzögert eintreffen.

15. Physische und Geräteabnahme

Prüfung	Soll
Identität	Modell, Seriennummer und MAC entsprechen Auftrag
Standort	Rack, HE, Foto/Label und Verkabelung dokumentiert
Strom	Netzteile, Redundanz, Alarm und PoE-Budget korrekt
Junos	freigegebene Zielversion und erwartetes Bootmedium
Ressourcen	CPU, Speicher, Temperatur ohne Auffälligkeit
Cloud	Connected und stabile Telemetrie
Config	kein offener Push-/Commitfehler

16. Netzwerkabnahme Layer 1 bis 3

Ebene	Test
Layer 1	Link, Speed, Duplex, Optik/Kabel, Errors, Discards
Layer 2	Native/Tagged VLANs, MAC Learning, STP, LLDP
Aggregation	LACP Member, Actor/Partner, Forwarding im Bundle
Layer 3	IRB, ARP/ND, Routen, Default Route und Rückweg
Services	DHCP Relay/Server, DNS, NTP, RADIUS, Syslog
Redundanz	definierter Link-/Memberausfall ohne unzulässigen Impact

Jeder kritische Porttyp wird mindestens einmal real getestet. Ein korrekt gerenderter Port Profile Name beweist noch keine funktionierende Gegenstelle.

17. Client- und Access-Abnahme

Link→802.1X/MAB→RADIUS→VLAN→DHCP→Traffic

Portrolle	Abnahme
Corporate Client	802.1X, dynamisches VLAN, DHCP, DNS und Zielzugriff
IP Phone	PoE, LLDP-MED, Voice VLAN, Registrierung und Sprache
Access Point	PoE, Native Management, Tagged WLAN VLANs, Cloudverbindung
IoT/Kamera	MAB/Profil, PoE, restriktives VLAN und erlaubte Ziele
Uplink	LACP/STP/Routing, erlaubte VLANs und MTU
Unused	Disabled beziehungsweise sicherer Defaultzustand

18. Assurance-Baseline

Datenquelle	Baseline
Switch Insights	Config-, Reboot-, Link-, PoE- und Systemevents
Wired SLEs	Successful Connect, Auth/DHCP und Durchsatzkontext
Client Insights	Port, VLAN, Auth, IP und Timeline
Front Panel	Portstatus, Profile, Speed und PoE
Topology	LLDP-Nachbarn und erwarteter Pfad
Metrics	CPU, Memory, Errors, Discards und Power

Die Baseline wird erst nach einer repräsentativen Betriebsphase finalisiert. Direkt nach dem Boot fehlende Langzeitdaten sind kein Fehler.

19. Sicherheit im Workflow

Claim-/Activation- und Adopt-Informationen vertraulich behandeln
Root-Passwort sicher erzeugen, übertragen und verwahren
MFA/SSO und Least Privilege für Portalzugriff
Cloud-Egress nur zu dokumentierten Zielen/Ports
Adopt-Befehle nicht in Tickets oder Chats offen ablegen
OOB-Zugang und Rescue-Konfiguration testen
Configdownloads, Logs und PCAPs geschützt speichern
lokale CLI nach Ownership-Wechsel organisatorisch begrenzen
jede Änderung mit Person, Zeit, Ziel und Ergebnis protokollieren

Besonderheit: Die Mist AI Mobile App kann laut Juniper Quick Start beim Claim kein Root-Passwort setzen. Das muss im gewählten Betriebsablauf berücksichtigt werden.

20. Stop- und Rollbackkriterien

Befund	Aktion
falsche Organisation/Site	nicht weiter provisionieren; Zuordnung korrigieren
Template oder Variable unklar	Management nicht aktivieren
kein Console/OOB bei Brownfield	Cutover verschieben
Cloudsession instabil	Transportproblem vor Configpush lösen
Commitfehler	Ursache sichern; nicht blind wiederholen
Managementpfad verloren	Rollback über OOB/Console/Rescue
kritische Portrolle fehlerhaft	Go-live stoppen oder gezielt zurückrollen
Sicherheitskontrolle fehlt	keine fachliche Abnahme

Rollback beginnt vor dem ersten produktionswirksamen Schritt – nicht erst nach dem Ausfall.

21. Systematische Fehlerbehebung

1. Identity
Richtige Organisation, MAC, Seriennummer und Site?

2. Interface
show interfaces terse: Admin/Link und Management-IP?

3. Route
Default Route und Quellinterface zum Cloudziel?

4. DNS/Time
Namensauflösung und Zeitbasis funktionsfähig?

5. Firewall/Proxy
443/CloudX oder 2200/Outbound SSH passend?

6. Session
show system connections und relevante Logs?

7. Portal State
Inventory, Site, Management und Subscription korrekt?

8. Config State
Render, Push, Commit und Insights-Ereignis?

9. Service State
Uplink, VLAN, Routing, Auth, DHCP und Client getrennt testen.

Symptom	Prüfpunkt
Claim erfolgreich, Gerät rot	Boot, DHCP, DNS, Route, Firewall, Proxy
Connected, aber unmanaged	Configuration Management nicht aktiviert
Connected, falsche Config	Site, Template, Rolle, Variable, Override
Brownfield-Dienst fällt aus	fehlende Zielkonfiguration/zu früher Ownership-Wechsel
Push wiederholt fehlerhaft	Junos-Syntax, Plattformunterstützung, Konflikt
Switch grün, Client ohne IP	Auth, VLAN, DHCP und Uplink – nicht Cloudsession

22. Übergabe in den Betrieb

Artefakt	Inhalt
Inventory Record	Modell, Seriennummer, MAC, Standort, Rolle, Junos
Configuration Record	Template, Variablen, Overrides, Additional CLI
Physical Record	Rack, Strom, VCP/Uplink, Patchfelder, Fotos
Acceptance Record	Portrollen, Clients, Redundanz und SLE-Nachweise
Operations Record	Upgradegruppe, Alerts, Ansprechpartner, Wartungsfenster
Recovery Record	OOB/Console, Rescue, Ersatzgerät und Eskalation

Erst mit dokumentierter Baseline, offenen Restpunkten und verantwortlichem Betriebsteam ist die Einbindung abgeschlossen.

23. Kompaktes Runbook

Change, Gerät, Site und Zielzustand bestätigen.
Rollen, Subscription, Modell und Junos prüfen.
DHCP/IP, DNS, NTP, Route, Firewall und Proxy testen.
Site, Template, Variablen, Rollen und Firmwareziel reviewen.
Greenfield claimen oder Brownfield-Konfiguration sichern und adoptieren.
Inventory-Identität und Cloudsession bestätigen.
Site Assignment und Managemententscheidung kontrollieren.
Render, Push und Commit überwachen.
Gerät, Uplinks, VLANs, Routing, Auth und DHCP abnehmen.
kritische Portrollen mit realen Endpunkten testen.
Insights, SLEs, Timeline und Metrics als Baseline sichern.
Dokumentation, Rollback und Übergabe abschließen.

Häufige Fehlannahmen

Behauptung	Bewertung	Einordnung
„Claim beendet die Einbindung.“	Falsch	Cloudverbindung, Site, Management, Config und Abnahme folgen.
„Connected bedeutet konfiguriert.“	Falsch	Cloudsession und Konfigurationszustand sind getrennt.
„Brownfield Adopt ist ohne Servicewirkung.“	Falsch	Spätestens Managementaktivierung ist ein Cutover.
„Ein erfolgreicher Commit beweist den Dienst.“	Falsch	Operational State und Testclient müssen stimmen.
„Sync Configuration repariert jeden Fehler.“	Falsch	Ein fachlicher oder syntaktischer Fehler bleibt bestehen.
„VC wird wie ein Standalone-Switch behandelt.“	Falsch	Formation, VCPs, Memberrollen und Preprovisionierung sind separat.

Merksätze

Claim oder Adopt ist nur der Anfang.
Connected, managed und configured sind verschiedene Zustände.
Der Ziel-Intent entsteht vor dem produktiven Push.
Brownfield Management ist ein Ownership-Cutover.
Ein Commit beweist Syntax, nicht Service.
Cloudstatus und Clientstatus werden getrennt geprüft.
Virtual Chassis besitzt einen eigenen Workflow.
Stop-Kriterien verhindern, dass Unsicherheit zum Ausfall wird.
Assurance beginnt mit einer dokumentierten Baseline.
Ohne Übergabenachweis ist der Workflow nicht abgeschlossen.

Offizielle Grundlagen

Stand der fachlichen Prüfung: August 2026. Portalabläufe, Rollen, Cloudtransport, Junos-Anforderungen und Modellunterstützung können sich ändern. Für Produktiveinbindungen gelten die aktuelle Juniper-Dokumentation, die konkrete Mist-Cloudregion, das EX-Modell und der freigegebene Change.