Die grundlegenden Funktionen von Mist – LAN / Switching

1. Lernziele

Mist, Wired Assurance und Junos in ihrer jeweiligen Rolle erklären
Management-, Control- und Data Plane sauber trennen
Claim, Adoption, Site-Zuordnung und Konfigurationsübernahme beherrschen
Template-Vererbung und Overrides nachvollziehbar einsetzen
Networks, VLANs, Port Profiles und Port Config unterscheiden
klassisches Campus-LAN und EVPN-VXLAN-Fabric abgrenzen
802.1X, MAB, Dynamic Port Configuration und RADIUS-VLANs bewerten
Wired SLEs, Insights, Telemetrie und Marvis evidenzbasiert nutzen
Virtual Chassis und Junos-Upgrades sicher planen
eine Ende-zu-Ende-Fehlersuche ohne vorschnelle Ursachenzuweisung durchführen

Leitfrage: Ist ein Problem durch Intent, gerenderte Konfiguration, Gerätezustand, Protokollzustand oder Clientverhalten verursacht?

2. Das Systemmodell

Mist Cloud

Organisation, Sites, Templates, Intent, Rollen, Telemetrieauswertung, SLEs, Insights, APIs und Workflows.

Junos Switch

Lokale Control- und Data Plane, FIB, MAC-Tabelle, STP, LACP, Routing, PoE und Interfacezustände.

Wired Assurance

Cloud-Management und Experience-orientierte Auswertung der Switch- und Clienttelemetrie.

Mist definiert und beobachtet Intent – Junos setzt Protokolle und Paketweiterleitung lokal um.

Ein Verlust der Cloudverbindung ist daher nicht automatisch ein Ausfall des LAN-Datenverkehrs. Bestehende lokale Forwarding- und Protokollzustände können weiterarbeiten; Cloudänderungen, neue Telemetrie und Cloudwerkzeuge sind während der Trennung jedoch eingeschränkt.

3. Management, Control und Data Plane

Ebene	Beispiele	Fehlerbild
Management Plane	Mist-Verbindung, API, Konfigurationspush, SSH, Benutzer	Switch offline in Mist, Datenverkehr eventuell weiterhin aktiv
Control Plane	STP, LACP, LLDP, OSPF, BGP EVPN, ARP/ND	Topologie oder Erreichbarkeit instabil
Data Plane	MAC-/FIB-Lookup, ACL, CoS, VXLAN-Encapsulation	Pakete werden verworfen, fehlgeleitet oder gedrosselt

Die Ebenen sind gekoppelt, aber nicht identisch. „Switch connected“ beweist weder korrekte VLAN-Zuweisung noch erfolgreichen Clientverkehr.

4. LAN-Lebenszyklus in Mist

Design→Claim/Adopt→Site→Template→Deploy→Assure→Change

Phase	Ergebnis	Abnahmenachweis
Design	Topologie, VLAN-/IP-, PoE-, HA- und Securitymodell	Low-Level-Design
Onboarding	Gerät in korrekter Org/Site, Cloud erreichbar	Inventory und Connectivity
Provisionierung	Intent gerendert und committed	Config Status und Junos Config
Validierung	Client erhält Auth, VLAN, IP und Verkehr	SLE, Client-/Port-Timeline, Testprotokoll
Betrieb	Baseline, Alarmierung, Upgrade- und Changeprozess	KPIs, Events, Change Records

5. Claim, Adoption und ZTP

Greenfield

Cloud-ready Switch mit QR-/Claim-Code wird der Organisation hinzugefügt, einer Site zugeordnet und per ZTP provisioniert.

Brownfield

Bestehender unterstützter Switch wird adoptiert. Bestand, lokale Konfiguration, Erreichbarkeit und Migrationswirkung müssen vor Aktivierung des Konfigurationsmanagements geprüft werden.

Schritt	Prüfung
1. Voraussetzungen	unterstütztes Modell, Standard-Junos statt Flex, DNS/NTP/Internet, Proxy falls nötig
2. Eigentum	Gerät nicht mehr in anderer Organisation/Cloud gebunden
3. Claim/Adopt	Claim-/Activation-Code oder Adoption aus Installed Base
4. Site Assignment	richtige Site, Zeitzone und Templatezuordnung
5. Management	Konfigurationsmanagement bewusst aktivieren
6. Baseline	Portzustände, LLDP, Version, VC, Uplinks und Clients sichern

Brownfield-Regel: Vor der ersten autoritativen Mist-Konfiguration muss klar sein, welche lokale Konfiguration übernommen, ersetzt oder als zusätzliche CLI erhalten wird.

6. Organisation, Site und Switch

Ebene	Typische Verantwortung	Beispiel
Organisation	globale Standards und Templates	NTP, RADIUS, Portprofile, Switchregeln
Site	standortspezifische Werte und Overrides	lokale VLANs, Gateway, Standort-RADIUS
Switch	notwendige Geräteausnahme	ein Port, Management-IP, besondere Uplinkrolle
Port	konkrete Interfacezuweisung	AP-Trunk, Kamera-Access, 802.1X-Client

Je tiefer der Override, desto kleiner der Geltungsbereich – aber desto höher die Gefahr unsichtbarer Sonderfälle. Abweichungen gehören begründet, befristet und überprüfbar dokumentiert.

7. Intent, Render und Commit

Portal/API-Intent→Vererbung→Rendering→Junos Candidate→Commit

Zustand	Frage
beabsichtigt	Was wurde im Template oder Switchobjekt definiert?
gerendert	Welche effektive Konfiguration entsteht nach Regeln und Overrides?
übertragen	Hat das Gerät die Änderung erhalten?
committed	Hat Junos die Konfiguration syntaktisch und semantisch akzeptiert?
operativ	Ist der resultierende Protokoll-/Portzustand tatsächlich korrekt?

Konfiguration im Mist-Dashboard überschreibt laut Juniper die über lokale CLI vorgenommenen Einstellungen im verwalteten Bereich. Lokale CLI-Änderungen erscheinen nicht automatisch auf der Switch-Detailseite. Zusätzliche CLI ist deshalb gezielt und mit Ownership-Grenze einzusetzen.

8. Switch Templates und Regeln

Templates skalieren gemeinsame Konfiguration über Sites und Geräte. Regeln können nach Site, Modell oder anderen Auswahlkriterien auf Switches wirken.

Baustein	Aufgabe
Shared Elements	Networks, Port Profiles, Dynamic Port Configuration und VRFs wiederverwenden
All Switches Configuration	gemeinsame System-, Authentisierungs- und Serviceparameter
Switch Rules	Zielmenge bestimmen und Portkonfiguration anwenden
Site Override	geerbten Wert nur für eine Site abweichend definieren
Switch Override	kleinste notwendige Geräteausnahme

Designprinzip: Profile beschreiben Rollen; Regeln weisen Rollen Zielgeräten und Ports zu. Die physische Portnummer allein sollte nicht die fachliche Bedeutung tragen.

9. Networks, VLANs und Subnetze

Ein „Network“ ist in Mist das wiederverwendbare Objekt für ein VLAN. Typische Felder sind Name, VLAN-ID und optional IPv4-/IPv6-Subnetz.

Begriff	Bedeutung	Prüfung
VLAN ID	802.1Q-Kennung im lokalen L2-Domain	Ende-zu-Ende-Konsistenz
Port Network	untagged/native VLAN am Access- oder Trunkport	Native-VLAN-Mismatch vermeiden
Trunk Networks	zulässige getaggte VLANs	nur benötigte VLANs erlauben
VoIP Network	separates Voice-VLAN	LLDP-MED, Auth und QoS abstimmen
Subnet	IP-Kontext des Networks	überlappungsfrei; IRB/Gateway passend
VRF	getrennte Routingtabelle	Route-Leaking und Services planen

VLAN existiert nicht automatisch auf jedem Port. Erst Portprofile, L3-Interfaces oder Fabric-Zuordnungen machen das Network operativ nutzbar.

10. Statische Port Profiles

Profiltyp	Mode	Typische Parameter
Client	Access	Port Network, 802.1X/MAB, DHCP Snooping, Storm Control
IP Phone	Access + Voice	Data/Voice Network, LLDP-MED, PoE, QoS
Access Point	Trunk	Native Management-VLAN, erlaubte WLAN-VLANs, PoE
Kamera/IoT	Access	restriktives VLAN, PoE, MAC Limit, NAC
Uplink	Trunk/LAG	VLAN-Liste, LACP, MTU, keine Dynamic Port Config
Disabled	deaktiviert	administrativ down, PoE aus

Weitere Parameter können Speed, Duplex, MTU, PoE, STP, MAC Limit, CoS und Authentisierung umfassen. Systemprofile default und disabled sind besonders zu behandeln; unzugewiesene Ports können gezielt ein Standardprofil erhalten.

11. Dynamic Port Configuration

„Colorless Ports“ erhalten ein Profil anhand der erkannten Geräteidentität, zum Beispiel LLDP Chassis ID oder RADIUS Name.

Default/Restricted→Gerät erkannt→Regelmatch→Dynamic Profile

Juniper-Hinweis	Begründung
LLDP vor MAC Matching bevorzugen	stabilere semantische Geräteerkennung
nicht auf Uplinks verwenden	für Endpunkte, APs und IoT – nicht Switch/Router/Firewall-Verbindungen
nicht mit MAC-Matching auf 802.1X-Ports	Authentisierung und dynamische Klassifikation nicht vermischen
bei MAB/RADIUS nicht empfohlen	VLAN-Zuweisung soll durch RADIUS erfolgen
Restricted VLAN ohne aktiven DHCP	stale IP bei Legacy-Geräten vermeiden

Kein Match muss in ein sicheres, definiertes Fallback führen. „Dynamic“ ohne sichere Defaultrolle ist keine Automatisierung, sondern ein unkontrollierter Ausnahmeweg.

12. Layer-2-Funktionen

Funktion	Zweck	Fehlersignal
802.1Q	VLAN-Tagging	Native-/Allowed-VLAN-Mismatch
RSTP/MSTP	Schleifenvermeidung	Topology Changes, blockierter falscher Port
BPDU Guard	Edge-Port gegen fremde Bridges schützen	Port nach BPDU gesperrt
Root Guard	unerwünschte Root-Wahl verhindern	inkonsistenter Port
Storm Control	Broadcast/Multicast/Unknown-Unicast begrenzen	Drops bei falscher Schwelle
MAC Limit	gelernte MACs pro Port begrenzen	Frames oberhalb des Limits verworfen
DHCP Snooping	Bindings und Rogue-DHCP-Schutz	Client erreicht Bound State nicht
LLDP/LLDP-MED	Nachbarschaft, Voice und Topologie	falsches Profil oder fehlende Telefonparameter

Edge-Port ist eine Vertrauensentscheidung: STP-Schutz, DHCP-Snooping-Trust und Uplinkrollen dürfen nicht pauschal auf Portbereiche kopiert werden.

13. LAG, LACP und Uplinks

Baustein	Aussage
AE Interface	logische Aggregation mehrerer physischer Links
LACP	verhandelt Mitgliedschaft und erkennt Fehlverkabelung
Active/Passive	mindestens eine Seite sollte aktiv initiieren
Hashing	verteilt Flows, nicht einzelne Pakete beliebig
MC-LAG/EVPN-MH/VC	unterschiedliche Verfahren für geräteübergreifende Redundanz

Alle Member brauchen kompatible Speed-, MTU-, VLAN- und LACP-Parameter. Ein grüner physischer Link beweist nicht, dass er im Bundle forwarding ist.

14. Layer 3, IRB und VRF

Objekt	Funktion
IRB/RVI	Layer-3-Gateway eines VLANs/Bridge Domains
Routed Port	direkte L3-Verbindung ohne Switching
Static Route	expliziter Next Hop für Präfix
OSPF	dynamisches IGP und Underlay-Option
BGP	Routing und EVPN-Control-Plane
VRF	separate Routing-/Forwarding-Domäne

Default Gateway, DHCP Relay, MTU, Routingprotokoll, Summarization und Fehlerdomäne werden als Architektur entschieden. Das bloße Anlegen eines Network-Objekts erzeugt nicht zwingend ein Gateway.

15. 802.1X, MAB und NAC

Link Up→EAPOL/MAB→RADIUS→Accept/Reject→VLAN/Policy→DHCP

Element	Aufgabe	Prüfung
Supplicant	liefert Benutzer-/Gerätecredentials	EAP-Methode und Zertifikate
Authenticator	Switchport kontrolliert Zugang	Portmodus, Timer, Host Mode
RADIUS/Mist Access Assurance	entscheidet Auth und Attribute	Shared Secret, NAS, Policies, Erreichbarkeit
MAB	Fallback/IoT anhand MAC	Spoofingrisiko und Profil
Dynamic VLAN	RADIUS weist VLAN nach Erfolg zu	VLAN existiert Ende-zu-Ende
Accounting	Sitzungsdaten	UDP 1813 standardmäßig

Juniper nennt standardmäßig UDP 1812 für Authentisierung und 1813 für Accounting. Ein RADIUS-Server allein aktiviert kein 802.1X: Authentisierungsserver, dot1x-Portprofil und Portzuweisung müssen zusammenpassen.

16. PoE als Betriebsfunktion

Variable	Bedeutung
Administrative PoE	Stromversorgung pro Port erlaubt oder gesperrt
Negotiated Class	ausgehandelte Leistungsklasse des Powered Device
Draw	tatsächliche Leistungsaufnahme
Budget	verfügbare Chassis-/Netzteilkapazität
Priority	Abschaltreihenfolge bei Mangel
Power Cycle	gezielter Neustart eines APs/Telefons – servicewirksam

PoE-Probleme werden anhand Portstatus, Klasse, Budget, Kabel, Netzteilredundanz und Endgerät getrennt. „Link down“ und „kein Strom“ sind verschiedene Zustände.

17. Virtual Chassis

Mehrere physische Switches arbeiten als ein logisches Gerät. Mist unterstützt nur preprovisioned Virtual Chassis.

Rolle/Objekt	Funktion
Primary Routing Engine	aktive Steuerinstanz
Backup Routing Engine	Redundanz für Control Plane
Linecard Member	stellt Ports und Forwarding bereit
VCP	transportiert VC-Control- und Datenverkehr
Member ID/Serial	deterministische Preprovisionierung

Modelle mit dedizierten VCPs werden physisch verbunden und anschließend preprovisioniert. Für EX2300, EX4650 und bestimmte QFX5120 gilt ein eigener „Form Virtual Chassis“-Workflow. Juniper weist ausdrücklich an, VC-Einstellungen über die Mist-Oberfläche und nicht über CLI/Additional CLI zu verwalten.

gleiche unterstützte Junos-Version und Modellkombination prüfen
Primary/Backup auf unterschiedliche Strom-/Fehlerdomänen verteilen
VCP möglichst als Ring und mit korrekter Bandbreite auslegen
Uplinks über Mitglieder verteilen
Portregeln auf unterschiedliche VC-Größen abstimmen
Memberaustausch und Renumbering dokumentieren

18. Campus-Fabric-Topologien

Topologie	Charakter	Geeignet für
EVPN Multihoming	Collapsed Core, zweistufig; Access redundant angebunden	kleine/mittlere Campusdesigns
Core-Distribution	dreistufig; EVPN zwischen Core/Distribution, Access über LACP	mehrere Gebäude und klassische Accessschicht
IP Clos	End-to-End VXLAN bis Access, L3-IRB am Access	Skalierung und Mikrosegmentierung

„Mist-managed Switching“ bedeutet nicht automatisch Campus Fabric. Ein traditionelles VLAN-/STP-/LACP-Design kann vollständig mit Wired Assurance betrieben werden.

19. EVPN-VXLAN – Funktionskern

Underlay

IP-Erreichbarkeit zwischen VTEPs, typischerweise über Routing. Muss stabil sein, bevor das Overlay funktionieren kann.

Overlay

VXLAN kapselt Tenant-/VLAN-Verkehr; EVPN verteilt MAC-, IP- und Multihoming-Informationen per BGP.

Begriff	Bedeutung
VTEP	Endpunkt der VXLAN-Kapselung
VNI	24-Bit Overlay-Segmentkennung
EVPN Route Type 2	MAC/IP Advertisement
EVPN Route Type 3	Inclusive Multicast Ethernet Tag für BUM-Verteilung
EVPN Route Type 5	IP-Präfixroute im Overlay
ESI	Ethernet Segment Identifier für Multihoming
Anycast Gateway	gleiches logisches Gateway an mehreren Edge-Geräten

Underlay Reachability + BGP EVPN + VNI/VRF Mapping + Access Attachment = funktionierendes Overlay

20. Group Based Policies

IP Clos unterstützt Group Based Policies zur topologieunabhängigen Mikrosegmentierung. Eine Policy verknüpft Benutzergruppe und Ressourcengruppe mit einer erlaubenden oder sperrenden Entscheidung.

Variable	Frage
User Group Tag	Welche Identität beziehungsweise Endpunktgruppe initiiert Verkehr?
Resource Group Tag	Welcher Dienst oder Ressourcenbereich ist Ziel?
Policy	Welche Kommunikation ist explizit erlaubt?
Default	Was geschieht ohne Match?
Enforcement Point	Wo wird die Entscheidung technisch umgesetzt?

GBP ersetzt keine saubere Identitätsquelle, kein Routingdesign und keine Prüfung asymmetrischer Verkehrswege.

21. Telemetrie und CloudX

Wired Assurance sammelt kontinuierlich Switch-, Port-, Client- und Protokolltelemetrie. Bei CloudX nennt Juniper je nach Plattform Ereignisübertragung etwa alle 10–15 Sekunden und Statistikupdates etwa alle 60 Sekunden.

Datenart	Beispiele
Device	CPU, Memory, Uptime, Junos, Temperatur, Netzteile
Port	Link, Speed, Duplex, Bytes, Errors, Discards, PoE
Client	MAC, VLAN, Auth, DHCP, IP, Port, Traffic
Control Plane	STP, LACP, LLDP, Routing-/EVPN-Events
Configuration	Push, Commit, Failure, Change Event

Abtastrate beachten: Ein kurzer Mikroburst kann zwischen Statistikintervallen liegen. Telemetrie ist Messung mit zeitlicher Auflösung, kein lückenloser Paketmitschnitt.

22. Wired SLEs

Wired SLEs beantworten vor allem: Kann der Client verbinden, und kann er danach Verkehr übertragen?

SLE/Faktor	Beispielhafte Aussage
Successful Connect	802.1X-/DHCP-basierter Verbindungserfolg; Zielannahme 100 %, Threshold nicht frei gesetzt
Authentication	RADIUS Reject, Timeout, VLAN-/Policyproblem
DHCP	Client erreicht innerhalb der erwarteten Zeit keinen Bound State
Throughput	nutzbare Verkehrsleistung aus Experience-Sicht
Switch Health	gerätebezogene Faktoren mit Clientwirkung

Successful Connect benötigt 802.1X-Ereignisse oder DHCP Snooping. Statische IP-Endpunkte können DHCP-basierte Bewertung naturgemäß begrenzen. SLEs zeigen Impact und Klassifikation – die technische Ursache wird mit Timeline, Port- und Protokolldaten bestätigt.

23. Switch Insights und Client Timeline

Ansicht	Nutzen
Front Panel	Portstatus, Profil, Speed, PoE und verbundene Geräte
Switch Insights	Events, Konfigurationsänderungen, Ressourcen, Ports und Fehler
Client Insights	Endpunkt, Auth, VLAN, IP, Traffic und zeitlicher Verlauf
Topology	LLDP-basierte Nachbarschaften und Pfadkontext
EVPN Loop/Duplicate MAC	bei unterstützten neu aufgebauten Fabrics als Insights-Ereignis

Korrelation braucht eine gemeinsame Zeitbasis: Site-Zeitzone, Client-MAC, Switch, Port und ein enges Ereignisfenster.

24. Marvis für Wired

Abfrage

Natürlichsprachliche Suche nach Client, Switch, Port, Site oder Problemkontext.

Aktion/Insight

Priorisierte Auffälligkeiten, betroffene Entitäten und empfohlene Untersuchung beziehungsweise Aktion.

Marvis ist ein Analysewerkzeug, kein Ersatz für technische Beweisführung. Eine vorgeschlagene Ursache wird gegen Authentisierungsereignis, DHCP-Zustand, VLAN, Portcounter, Topologie und Konfigurationsänderung validiert.

KI-Hypothese + Telemetrie + Konfiguration + Reproduktion = belastbarer Befund

25. Betriebs- und Diagnosewerkzeuge

Werkzeug	Einsatz	Grenze/Risiko
Remote Shell	gezielte Junos-Show-Kommandos	nur autorisierte Diagnose; keine Schattenkonfiguration
Packet Capture	Control-/Transit-Traffic am Port untersuchen	Datenschutz, Last und begrenztes Zeitfenster
Port Bounce	Link neu initialisieren	unterbricht Dienst
PoE Cycle	Powered Device neu starten	unterbricht Strom und Dienst
Cable Test	Kupferstrecke auf Fehler/Länge prüfen	kann Link beeinflussen; Ergebnis modellabhängig
Port Mirroring	Ingress/Egress an Analyseziel spiegeln	maximaler Umfang und Plattformgrenzen prüfen
Download Junos Config	effektive Gerätekonfiguration prüfen	Secrets und sichere Ablage beachten

Juniper dokumentiert maximal vier Port-Mirroring-Konfigurationen; Management-, Fibre-Channel- und IRB-Interfaces haben Einschränkungen. Plattform- und Releaseabhängigkeit wird vor Einsatz geprüft.

26. Junos-Upgrades

Phase	Kontrolle
Auswahl	JTAC Suggested Release, Plattform, Features, Known Issues
Kompatibilität	VC-Mitglieder, Fabric, Optiken, Mist-Funktionsumfang
Vorprüfung	Storage, Alarmzustand, Backup/Config, Redundanz, Bootmedium
Planung	Sitegruppe, Wartungsfenster, Reihenfolge, Impact, Rollback
Ausführung	Download, Install, Reboot und Wiederverbindung beobachten
Nachprüfung	Version, VC, Uplinks, Routing, Clients, SLE und Events

Wired Assurance unterstützt keine Junos-Flex-Images; Juniper empfiehlt Upgrades über Mist, damit ein Standard-Junos-Image verwendet wird. Mist führt vor dem Kopieren grundsätzlich eine Storage-Cleanup-Anforderung aus, die bei einzelnen Plattformen dennoch nicht immer genügend Platz schafft.

27. Management- und LAN-Sicherheit

Bereich	Kontrolle
Mist-Zugriff	Least Privilege, MFA/SSO, getrennte Adminrollen, Audit
API	Token minimal berechtigen, rotieren und nicht in Skripten offenlegen
Switch Management	dediziertes Management, ACL, sichere Protokolle, NTP/DNS
Edge	802.1X/MAB, BPDU Guard, DHCP Snooping, Storm Control
Uplink	explizite Trunks, LACP, STP-/Routing-Trust, keine Dynamic Ports
Config	Ownership zwischen Mist und Additional CLI; Review und Export schützen
Telemetry/PCAP	Zweckbindung, Zugriff, Speicher- und Löschfristen

28. Betriebsmodell und Change

Baseline

Switch-/VC-Inventar und Junos
Template- und Override-Matrix
Uplink-, VLAN-, STP- und Routingzustand
PoE-Budget und Portfehler
SLEs und typische Clientzeiten

Change Record

Ziel und betroffene Sites/Switches
gerenderte Differenz
Client-/Netzwerkimpact
Abnahme- und Rollbackkriterien
Events und SLEs nach Änderung

Ein Template-Change ist potenziell ein Massenchange. Zielmenge, Regeln, Vererbung und Overrides werden vor dem Speichern geprüft.

29. Ende-zu-Ende-Fehlersuche

1. Scope
Ein Client, ein Port, ein Switch, eine Site oder mehrere Sites?

2. Zeit und Change
Wann begann es, welches Template/Upgrade/Portevent korreliert?

3. Physik
Link, Speed, Duplex, Optik/Kabel, Errors, Discards, PoE.

4. Zugang
802.1X/MAB, RADIUS-Ergebnis, dynamisches Profil und VLAN.

5. Adressierung
DHCP DORA, Snooping Binding, ARP/ND, Gateway.

6. Layer 2
MAC Learning, VLAN, Trunk, STP, LACP.

7. Layer 3/Fabric
Route, VRF, Underlay, BGP EVPN, VNI, Anycast Gateway.

8. Policy
ACL, GBP, RADIUS-Attribute, Firewall und Rückweg.

9. Beweis
SLE, Timeline, Counter, Show-Ausgabe oder PCAP bestätigt Hypothese.

10. Minimaler Fix
Kleinste Ursache beheben, Wirkung messen und dokumentieren.

Symptom	Erste Differenzierung
Port up, kein IP	Auth/VLAN, DHCP Snooping, DHCP DORA
Auth erfolgreich, kein Verkehr	RADIUS-VLAN, Gateway, ACL/GBP, Rückweg
LAG halb aktiv	LACP State, Memberparameter, Optik/Kabel
Switch in Mist offline	Managementpfad; Data Plane separat testen
Fabric-VLAN nur lokal	VNI-Mapping, EVPN Type 2/3, VTEP Underlay
Clients nach Template-Change gestört	Zielregel, Vererbung, Override, gerenderte Diff
PoE-Gerät rebootet	Budget, Netzteil, Portevent, Klasse und Kabel

30. Design- und Abnahmecheckliste

Design

Management-, Control-, Data Plane
Org/Site/Template-Hierarchie
VLAN-, IP-, VRF- und Gatewayplan
Portrollen und sichere Defaults
STP/LACP/Redundanz
802.1X/MAB/RADIUS
PoE- und Kapazitätsbudget
VC oder Fabric begründet
Upgrade- und Rollbackmodell

Abnahme

Config committed und operativ
Clientauth und DHCP
VLAN-/VRF-Erreichbarkeit
Uplink-/Memberausfall getestet
STP-/LACP-Zustand korrekt
PoE unter Last
SLE-/Timeline-Baseline
Alerts, Rollen und API
Dokumentation und Runbook

Häufige Fehlannahmen

Behauptung	Bewertung	Einordnung
„Mist offline heißt LAN down.“	Falsch	Cloudmanagement und lokale Data Plane sind getrennt.
„Network anlegen erzeugt überall das VLAN.“	Falsch	Erst Port-, L3- oder Fabriczuordnung macht es nutzbar.
„Ein grüner Link ist ein funktionierender Client.“	Falsch	Auth, VLAN, DHCP, Gateway und Policy folgen erst.
„Dynamic Port Profiles passen auf Uplinks.“	Falsch	Juniper begrenzt sie auf Endpunkte, IoT und APs.
„Mist-managed bedeutet EVPN-Fabric.“	Falsch	Auch klassische LANs werden vollständig verwaltet.
„SLE nennt immer die Root Cause.“	Falsch	SLE liefert Impact/Klassifikation; Ursache wird bestätigt.
„Lokale CLI und Mist sind gleichrangig.“	Falsch	Im verwalteten Bereich ist die Ownership bewusst festzulegen.

Merksätze

Mist verwaltet Intent; Junos forwarded lokal.
Cloudstatus, Protokollstatus und Clienterfahrung sind getrennte Wahrheiten.
Templates skalieren Standards – und ebenso Fehler.
Portprofile beschreiben Rollen, Port Config weist sie zu.
Ein VLAN-Objekt ist noch kein Ende-zu-Ende-Dienst.
802.1X endet nicht beim Access-Accept, sondern bei nutzbarem Verkehr.
Virtual Chassis und EVPN Multihoming lösen unterschiedliche Probleme.
Eine Fabric braucht zuerst ein stabiles Underlay.
SLEs messen Experience; Root Cause benötigt Beweis.
Der kleinste nachweisbare Fix ist besser als ein pauschaler Neustart.

Offizielle Grundlagen

Stand der fachlichen Prüfung: August 2026. Modellunterstützung, Junos-Versionen, Subscriptions, Portalbezeichnungen, SLEs, Fabric-Funktionen und Plattformgrenzen können sich ändern. Für produktive Entscheidungen gelten die aktuelle Juniper-Dokumentation, JTAC Suggested Releases, das konkrete Gerätemodell und ein geprüftes Low-Level-Design.