Bereitstellungsmodell für Switches der EX-Serie

1. Lernziele

Greenfield, Brownfield, Claim und Adoption eindeutig unterscheiden
Onboarding und Konfigurationsmanagement als getrennte Entscheidungen behandeln
Managed und unmanaged Brownfield fachlich bewerten
Day-0-Netzwerkvoraussetzungen und Cloudpfade erklären
Site-, Template- und Gerätevererbung vor Aktivierung prüfen
Bestandskonfiguration in einen belastbaren Mist-Intent überführen
Virtual Chassis modellgerecht bereitstellen
Switch Replacement, Reassignment und Release sicher durchführen
Abnahme- und Rollbackkriterien definieren
Cloudverbindungsfehler systematisch isolieren

Leitfrage: Wie gelangt der Switch in die Organisation – und wer besitzt danach die autoritative Konfiguration?

2. Drei getrennte Entscheidungen

1 · Aufnahme

Claim für cloud-ready Geräte oder Adopt für bestehende, virtuelle oder ältere unterstützte Geräte.

2 · Zuordnung

Organisation, Subscription, Site, Rolle und Template bestimmen den fachlichen Kontext.

3 · Management

Mit oder ohne Manage configuration with Mist entscheidet über die Konfigurationshoheit.

Onboarded ≠ Site-assigned ≠ Configuration-managed

Diese Zustände können zeitlich getrennt eintreten. Ein Gerät kann im Inventory liegen, einer Site zugeordnet sein und dennoch kein aktives Mist-Konfigurationsmanagement besitzen.

3. Entscheidungsmatrix

Ausgangslage	Aufnahme	Management	Geeigneter Weg
neuer cloud-ready EX	Claim-/Activation-Code	typisch aktiv	Greenfield ZTP
bestehender produktiver EX	Adopt CLI	zunächst optional aus	Brownfield Staging und Migration
bestehender EX, vollständig modelliert	Adopt	kontrolliert aktivieren	Brownfield Cutover
vJunos-switch/Legacy ohne Claim-Code	Adopt	nach Zielsetzung	Adoption statt Claim
nicht angebundener Fremd-/Juniper-Switch	keine Cloudaufnahme	keine	LLDP-basierte Visibility only
RMA-Ersatzgerät	Claim/Adopt, unassigned	über Replacement	Konfiguration gezielt übertragen

„Visibility only“ für nicht verbundene Geräte ist kein Deployment des Switches in Mist: Mist erkennt nur begrenzte Topologie- und Kontextdaten über LLDP/AP-Beobachtung und pusht keine Konfiguration.

4. Day 0, Day 1, Day 2 und Day 2+

Phase	Aufgabe	Erfolg
Day 0	Rack, Strom, Uplink, DHCP, DNS, NTP, Gateway, Firewall	Switch erreicht Cloudbootstrap
Day 1	Claim/Adopt, Site, Template, Initialkonfiguration	Intent committed, Basisdienste aktiv
Day 2	Clients, Ports, SLEs, Insights, Firmware, Änderungen	stabiler produktiver Betrieb
Day 2+	Automatisierung, API, Lifecycle, RMA, Kapazität	skalierbarer und auditierbarer Betrieb

Physisch bereit→Cloud verbunden→Inventory→Site→Intent→Abnahme

5. Voraussetzungen

Bereich	Prüfpunkt
Subscription	Wired Assurance aktiv und der Organisation korrekt zugeordnet
Rollen	erforderliche Switch-Administratorrechte im Mist-Portal
Hardware	EX-Modell und konkrete Variante aktuell unterstützt
Junos	unterstütztes Standard-Junos; kein Junos Flex
Netzwerk	Management-IP, Default Route, DNS und Internetpfad
Zeit	NTP empfohlen; korrekte Zeit für TLS, Logs und Korrelation
Firewall/Proxy	ausgehende Mist-Kommunikation passend zum Verbindungsmodell
Ownership	Gerät nicht an andere Mist-Organisation oder Cloudinstanz gebunden

Die allgemeine Mindestversion 18.2R3 ist nicht automatisch die sinnvolle Produktionsversion. Juniper weist auf das Supportende hin und empfiehlt eine aktuelle, für die Plattform geeignete JTAC Suggested Release.

6. Greenfield-Bereitstellung

Cloud-ready EX-Switches besitzen QR- beziehungsweise Claim-Code. Mehrere Geräte einer Bestellung können über einen Activation Code gemeinsam ins Inventory aufgenommen werden.

1. Vorbereiten
Site, Template, Networks, Portprofile, Rollen und Firmwareziel prüfen.

2. Claim
Claim-Code je Gerät oder Activation Code der Bestellung eingeben.

3. Optionen
Subscription, Site Assignment und Configuration Management bewusst wählen.

4. Verkabeln
DHCP-fähigen Managementpfad, Uplink und Strom bereitstellen.

5. ZTP
Switch verbindet sich, erhält Intent und gegebenenfalls automatisches Upgrade.

6. Validieren
Cloudstatus, Config, Uplinks, Ports, Clients und SLEs prüfen.

Reihenfolge: Ein bereits verknüpftes Site-Template kann nach der Site-Zuordnung automatisch wirksam werden. Darum wird das Template vor dem produktiven Anschluss geprüft.

7. Cloud-ready ZTP-Prozess

Boot→DHCP/IP→DNS/NTP/Route→Redirect/PHS→Secure Session→Config

Juniper beschreibt einen Phone-Home-Client, der beim ersten Start einen Redirect- und anschließend einen Phone-Home-Service erreicht. Mit CloudX erfolgt das Management standardmäßig über HTTPS/JTI; ältere beziehungsweise anders angebundene Geräte können eine ausgehende SSH/NETCONF-Verbindung verwenden.

DHCP-/Netzparameter	Zweck
IP/Mask	lokale Managementerreichbarkeit
Default Gateway	Pfad zur Mist Cloud
DNS Server	Auflösung der Mist-Endpunkte
NTP Server	korrekte Zeitbasis
Local Domain	von der Quick-Start-Dokumentation als DHCP-Information genannt
Proxy Option 43	optional dynamische CloudX-Proxyinformation

8. Brownfield-Adoption

Ein bestehender, unterstützter Switch ohne Cloud-ready Claim-Code wird über Adopt Switch aufgenommen. Das Portal erzeugt Junos-CLI-Befehle, die lokal auf dem Gerät committed werden.

Bestand sichern→Adopt CLI→Cloudsession→Site→Managed?

Die Adoption ergänzt unter anderem einen Mist-Benutzer und die Cloudkommunikation. Danach wird getrennt entschieden, ob Mist die vollständige Konfiguration verwalten soll.

Entscheidender Risikopunkt: Wird „Manage configuration with Mist“ aktiviert, kann die bestehende Konfiguration durch den im Portal erzeugten Intent ersetzt werden. Das ist ein Cutover und keine harmlose Monitoring-Option.

9. Brownfield mit Mist-Konfigurationsmanagement

Eigenschaft	Folge
Cloud Intent autoritativ	Template-, Site- und Switchkonfiguration werden auf Junos gerendert
Templates/Variablen	skalierbare Standards und standortspezifische Werte nutzbar
Portaländerung	wird auf den Switch gepusht und committed
lokale CLI	nicht automatisch im Dashboard sichtbar; kann von Mist überschrieben werden
Additional CLI	für nicht nativ modellierte Funktionen, aber weiterhin im Mist-Intent
Sync Configuration	Cloudzustand bei fehlgeschlagenem Push erneut synchronisieren

Vor Aktivierung müssen alle servicekritischen Elemente modelliert sein: Management, Uplinks, VLANs, IRBs, Routing, LAG, STP, 802.1X, PoE, Firewallfilter, Services und Sonderfunktionen.

10. Brownfield ohne Konfigurationsmanagement

Ohne „Manage configuration with Mist“ bleibt die bestehende Gerätekonfiguration grundsätzlich erhalten. Mist ergänzt dennoch Komponenten für Cloudkommunikation und Telemetrie, darunter laut Juniper Systemskripte/-erweiterungen, Syslog-Einstellungen und den Benutzer mist.

Verfügbar	Nicht verfügbar beziehungsweise begrenzt
Cloudanbindung und Telemetrie	keine Konfigurationsänderungen aus dem Portal
Visibility und Insights nach Datenlage	keine Template- und Site-Variablen-Nutzung
schrittweise Brownfield-Beobachtung	Gerät bleibt individueller lokaler Konfigurationsfall
Basis für geplante Migration	keine automatische Normalisierung des Bestands

Unmanaged ist als Übergangs- oder bewusstes Betriebsmodell möglich. Es ist aber kein vollwertiges Cloud-Configuration-Management.

11. Konfigurationshoheit und Drift

Quelle	Managed Switch	Unmanaged Switch
Mist Template/UI/API	autoritativ	nicht auf Gerätekonfiguration angewendet
Site Variables	werden gerendert	nicht als Gerätekonfiguration wirksam
Additional CLI in Mist	Teil des Cloud-Intent	nicht als normaler Configpush nutzbar
lokale Junos CLI	Drift-/Überschreibungsrisiko	primäre Konfigurationsquelle

Eine Funktion braucht genau eine autoritative Konfigurationsquelle.

Geteilte Ownership pro Feature ist möglich, aber nur mit dokumentierter Grenze. Dieselbe Hierarchie gleichzeitig lokal und in Mist zu pflegen ist kein Redundanzkonzept, sondern Drift.

12. Site, Template und Rollen

Ein einer Site zugewiesener managed Switch erbt das mit der Site verknüpfte Organisationstemplate. Switchrollen können Regeln zielgerichtet auf Access-, Distribution- oder andere Gerätegruppen anwenden.

Ebene	Beispiel	Risiko
Organisationstemplate	NTP, RADIUS, Networks, Port Profiles	fehlerhafte Regel wirkt auf viele Sites
Site Variable	lokales Gateway oder Serveradresse	falscher Wert bei ansonsten gleichem Template
Site Override	standortweite Ausnahme	Abweichung vom Standard
Switch Override	einzigartige Geräteanforderung	Sonderfall und spätere Migration
Port Config	konkretes Portprofil	Modell-/Portanzahl beachten

Juniper empfiehlt, Site Overrides nur bei Bedarf zu verwenden und ansonsten Site Variables zu bevorzugen.

13. Cloudkonnektivität

Verbindungsmodell	Transport	Hinweis
CloudX	HTTPS 443 und JTI	modernes Standardmodell auf unterstützten Plattformen/Releases
klassische Anbindung	ausgehendes SSH/NETCONF, TCP 2200	Brownfield-Adoption, Telemetrie, Remote Shell, Additional CLI
Proxy	CloudX über HTTP-Proxy	statisch oder dynamisch über DHCP Option 43

Firewallregeln werden anhand der aktuellen Mist-Cloudregion und Dokumentation erstellt. Pauschales Internet-Freigeben ist weder erforderlich noch sicher. Die Switchsession wird ausgehend aufgebaut; NAT muss Rückverkehr zulassen.

14. CloudX-Migration

CloudX ist nativ in Junos integriert. Unterstützte bestehende Switches können laut Juniper von TCP 2200 auf CloudX über TCP 443 wechseln, ohne die Data Plane zu beeinflussen.

Management

Sichere HTTPS-Verbindung zur Mist Cloud, Proxyunterstützung und Cloudsteuerung.

Telemetry

Junos Telemetry Interface für zeitnahe Events und Statistiken.

„Kein Data-Plane-Impact“ beschreibt den vorgesehenen Wechsel des Cloudtransportes. Ein produktiver Rollout benötigt dennoch Modell-/Junosprüfung, Firewallfreigabe und Verifikation der Wiederverbindung.

15. Virtual-Chassis-Bereitstellung

Gerätegruppe	Bereitstellungsweg
EX3400, EX4000, EX4100/F/H, EX4300, EX4400	dedizierte VCPs verbinden, VC bilden, Cloud anbinden und preprovisionieren
EX2300	einzeln onboarden, gleiche Site/Junos, Configuration Management aktiv, dann „Form Virtual Chassis“

Mist unterstützt nur preprovisioned Virtual Chassis. Member ID, Seriennummer und Rolle werden deterministisch festgelegt. VC-Einstellungen sollen laut Juniper über den Mist-Workflow und nicht per CLI oder Additional CLI verwaltet werden.

Modellkombination und maximale Memberzahl prüfen
gleiche Site und kompatible Junos-Version
VCP-Verkabelung möglichst als Ring
Primary und Backup auf getrennte Fehlerdomänen
Uplink und Cloudpfad während Formation sicherstellen
Statistikverzögerung nach Bildung berücksichtigen

16. Brownfield-Migrationsverfahren

1. Discovery
Hardware, Junos, VC, Ports, VLANs, IRBs, Routing, Auth, Services und lokale Sonder-CLI erfassen.

2. Klassifikation
Jede Konfigurationszeile als nativ modellierbar, Additional CLI, veraltet oder unklar einordnen.

3. Intent bauen
Networks, Profile, Templates, Variablen, Rollen und gerätespezifische Werte erstellen.

4. Unmanaged adoptieren
Telemetrie und Sichtbarkeit gewinnen, ohne sofortige Konfigurationsablösung.

5. Diff/Review
Bestands- und gerenderte Zielkonfiguration fachlich vergleichen.

6. Cutover
Wartungsfenster, Console/OOB, Rollback und Abnahmetests bereitstellen; Management aktivieren.

7. Validieren
Commit, Uplink, VLAN, Routing, Auth, DHCP, PoE, Clients und SLEs prüfen.

8. Normalisieren
temporäre Overrides abbauen und Dokumentation aktualisieren.

Kein Blind-Cutover: Die Aussage „Mist ersetzt die bestehende Konfiguration“ bedeutet, dass die Zielkonfiguration vor Aktivierung vollständig servicefähig sein muss.

17. Technische Abnahme

Ebene	Nachweis
Cloud	Connected, richtige Org/Site, Subscription, Configuration Status
Device	Hostname, Junos, Zeit, CPU/Memory, Alarmzustand
Configuration	Commit erfolgreich, erwartete Junos Config, keine unbeabsichtigte Drift
Physical	Link, Speed, Duplex, Optik/Kabel, PoE, Fehlercounter
Layer 2	VLANs, MAC Learning, STP, LACP, LLDP
Layer 3	IRB, ARP/ND, Routen, Gateway, DNS/NTP
Access	802.1X/MAB, RADIUS-VLAN, DHCP Bound
Experience	Testclients, Wired SLEs, Timeline und Verkehr

Die Abnahme erfolgt mit mindestens einem Test pro kritischer Portrolle. „Switch ist grün“ ist nur der Nachweis der Cloudverbindung.

18. Standalone Switch Replacement

Für einen Austausch muss der alte Switch claimed/adopted und einer Site zugewiesen sein. Das Ersatzgerät befindet sich im Inventory als Unassigned.

Ersatz claimen→Unassigned→Replace Switch→Config kopieren→Validieren

Mist kopiert standardmäßig die Konfiguration; bestimmte Attribute können ausgeschlossen werden. Bei unterschiedlicher Portanzahl wird Portkonfiguration laut Juniper automatisch verworfen. Bei Wechsel zwischen mge- und ge-Ports wird sie ebenfalls nicht übertragen.

Abgrenzung: Für Virtual-Chassis-Member gelten eigene Replacement-Verfahren. Der Standalone-Workflow darf nicht ungeprüft auf ein VC angewendet werden.

19. Site-Reassignment und Release

Aktion	Wirkung	Prüfung
Reassign + Retain Configuration	bestehende managed Konfiguration bleibt erhalten	neues Site-Template und künftige Ownership
Reassign + Do not retain	Reset auf Defaultwerte unter Beibehaltung des Hostnamens	Serviceimpact und Wiederprovisionierung
Disable Switch Configuration	Gerät nicht mehr durch Mist konfigurierbar	lokale Betriebsverantwortung übernehmen
Release	aus Inventory/Organisation entfernen	vorher Fabric entfernen und Ownership klären

Ein Fabric-Mitglied muss vor Release aus der Campus-Fabric-Topologie entfernt werden. Ein Release ist eine Bestands- und Managementänderung, nicht nur das Ausblenden einer Anzeige.

20. Firmware im Bereitstellungsmodell

Zeitpunkt	Strategie
vor Onboarding	Mindest-/ZTP-Kompatibilität sicherstellen, besonders Brownfield
beim Claim	automatisches Firmwareziel kann organisationsweit greifen
vor Cutover	Zielrelease im Lab/Staging gegen Features prüfen
nach Onboarding	manuell, geplant oder automatisiert über Mist
Virtual Chassis	Memberkompatibilität und besonderen Upgradeablauf beachten

Ein automatisches Upgrade beim Claim kann die Bereitstellungszeit und Reboots beeinflussen. Zielrelease und Wartungsfenster werden daher vor dem Claim geprüft.

21. Sicherheit und Governance

Kontrolle	Begründung
Least Privilege/MFA/SSO	Claim, Release und Configuration Management sind hochwirksame Aktionen
Gerätezuordnung prüfen	falsche Organisation oder Site kann falschen Intent auslösen
Cloudziele restriktiv freigeben	ausgehenden Managementpfad begrenzen
Adopt-CLI schützen	enthält managementrelevante Konfiguration
OOB/Console im Cutover	Recovery bei Verlust des In-band-Pfades
Template Review	Massenwirkung vor Aktivierung kontrollieren
Audit und Change Record	wer hat wann Ownership, Site oder Intent geändert?

22. Fehlerbehebung

1. Inventory
Claimed/adopted, richtige Organisation, nicht anderswo gebunden?

2. Link und IP
Management-/Revenue-Port, DHCP-Lease, Interface und Default Route?

3. DNS und Zeit
Mist-Ziele auflösbar, Uhrzeit plausibel?

4. Firewall/Proxy
CloudX 443 oder klassischer 2200-Pfad passend freigegeben?

5. Session
show system connections, Cloud-/Proxyverbindung established?

6. Site und Management
Site korrekt, Konfigurationsmanagement erwartungsgemäß an/aus?

7. Config
Push, Render, Commitfehler und Switch Insights prüfen; gegebenenfalls Sync Configuration.

8. Service
Uplink, VLAN, Routing, Auth und Clients separat vom Cloudstatus testen.

Symptom	Wahrscheinlicher Prüfbereich
im Inventory, aber offline	Uplink, DHCP, DNS, Route, Firewall, Cloudsession
connected, aber keine Config	Site Assignment und Configuration Management
Bestandsconfig verschwunden	Management zu früh aktiviert/Template wirksam
lokale Änderung verschwindet	Mist ist autoritative Quelle
Template wirkt falsch	Site, Regel, Rolle, Variable und Override
Ersatzgerät ohne Portconfig	Portanzahl oder ge/mge-Wechsel
VC kann nicht gebildet werden	Site, Version, Modell, VCP und Config Management

23. Bereitstellungschecklisten

Greenfield

unterstütztes Modell/Junos
Subscription und Adminrolle
Site/Template vorher geprüft
Claim-/Activation-Code
DHCP, DNS, NTP, Route
Firewall/Proxy
Firmwareziel
OOB/Console und Abnahme

Brownfield

vollständiger Configexport
Feature-/Portinventar
Adopt CLI und Cloudsession
zunächst unmanaged erwogen
gerenderter Intent geprüft
Rollback und Wartungsfenster
kritische Portrollen getestet
Drift nach Cutover entfernt

Häufige Fehlannahmen

Behauptung	Bewertung	Einordnung
„Claim und Adopt sind identisch.“	Falsch	Claim nutzt Geräte-/Activation-Code; Adoption lokale Junos-CLI.
„Onboarded heißt managed.“	Falsch	Konfigurationsmanagement ist eine zusätzliche Entscheidung.
„Brownfield Managed übernimmt automatisch alles.“	Falsch	Der Mist-Intent ersetzt den Bestand; er muss vorher vollständig modelliert sein.
„Unmanaged bedeutet keinerlei Mist-Konfiguration.“	Falsch	Cloud-/Telemetriekomponenten werden dennoch ergänzt.
„Connected beweist funktionierendes LAN.“	Falsch	Es beweist primär die Cloudverbindung.
„Replacement kopiert Ports immer.“	Falsch	Portanzahl und ge/mge-Unterschiede können die Übertragung verhindern.

Merksätze

Claim oder Adopt bringt das Gerät ins Inventory.
Site Assignment gibt dem Gerät seinen Kontext.
Configuration Management bestimmt die Konfigurationshoheit.
Greenfield ist ZTP; Brownfield ist Migration.
Unmanaged ist Cloudsichtbarkeit, nicht Cloudkonfiguration.
Templates werden vor dem Anschluss geprüft, nicht danach.
Ein Brownfield-Cutover braucht gerenderten Intent und Rollback.
Virtual Chassis wird in Mist preprovisioned verwaltet.
Replacement ist modell- und portabhängig.
Connected ist erst der Beginn der technischen Abnahme.

Offizielle Grundlagen

Stand der fachlichen Prüfung: August 2026. Modellunterstützung, Cloudtransport, Junos-Anforderungen, Portalworkflows und Subscriptions können sich ändern. Für produktive Bereitstellungen gelten die aktuelle Juniper-Dokumentation, das konkrete EX-Modell, die verwendete Mist-Cloudregion und eine geprüfte Zielkonfiguration.