Gestern war es soweit: Mein erster Versuch beim neuen JNCIE‑DC. Und ja, ich habe ihn nicht bestanden. Aber ganz ehrlich – ich bin nicht enttäuscht. Im Gegenteil: Ich bin überrascht, wie viel ich mitgenommen habe. Klarheit. Selbstvertrauen. Und vor allem einen echten Plan, wie es weitergeht.
Wenn man, wie ich, schon ein paar „E“-Zertifizierungs-Versuche hinter sich hat, lernt man eins ziemlich schnell: Es geht nicht nur um das Bestehen. Es geht darum, echte Skills zu verinnerlichen und vorallem um wen Weg zum “E”. Und genau das war bei diesem Versuch für mich der große Gewinn.
Im Folgenden schildere ich, was ich erlebt habe, wie ich die einzelnen Themen empfunden habe, welche Schwierigkeiten auftraten und wie ich sie beim nächsten Mal überwinden möchte – mit etwas Netzwerkonkeln-Humor, versteht sich. Ich gehe dabei über die offiziellen Themen aus dem Blueprint (https://www.juniper.net/us/en/training/certification/tracks/data-center/jncie-dc.html):
Layer 3 Underlay
Controller‑less Data Center
Der Layer-3‑Underlay ist das Fundament jeder stabilen Data‑Center-Fabric. In einem controllerlosen Setup heißt das konkret:
- IP-Fabric aufbauen, deployen und bei Fehlern debuggen
- Routing-Policies so setzen, dass nur wirklich nötige Routen propagiert werden
- Alle verfügbaren Links auch tatsächlich für das Forwarding nutzen und im Fehlerfall entsprechend reagieren
Schwierigkeiten:
Bei meinem Versuch war eine der schwierigsten Aufgaben, sicherzustellen, dass alle Links SINNVOLL aktiv genutzt werden. Es ist leicht, Einstellungen zu übersehen, die dafür sorgen, dass Traffic nur über bestimmte Wege läuft – besonders wenn das Lab-Setup komplex wird. Außerdem können Routing‑Policies zu großzügig oder zu restriktiv sein. Ein kleiner Fehler und deine Tabellen explodieren oder wichtige Subnetze verschwinden.
Strategie zur Verbesserung:
Ich plane, künftig konsequenter in stufenweisen Schritten zu arbeiten. Erst das Underlay einfach aufbauen, dann Links testen, Ausfall-Szenarien simulieren, und parallel Routing‑Policies Stück für Stück verifizieren. In meinem nächsten Übungslab nehme ich mir vor, gezielt „Failure‑Szenarien“ zu provozieren: Link‑Down, falsche Metrik, asymmetrisches Routing.
Apstra‑verwaltetes Data Center
Wenn Apstra ins Spiel kommt, wird’s ein bisschen „Next-Level“. Neben dem IP-Fabric-Bau kommen noch Aufgaben wie:
- Tags (Custom Tags) verwenden
- Alle Konfigurationen über Apstra laufen lassen (und nicht manuell daneben)
- Wieder: alle Links nutzen
Schwierigkeiten:
Tags sind super mächtig, aber auch eine Quelle für Kopfschmerzen: Falsch getaggte Geräte oder falsche Policies führen zu schwer nachzuvollziehenden Fehlkonfigurationen. Außerdem verlangt Apstra, dass man nicht einfach auf den Geräten herumbiegt, sondern fast alles über Apstra macht – was die Kontrolle einschränkt, wenn man schnell debuggen muss. Mal eben eine config ändern? Vergiss es! Hier ist Apstras Stärke gleichzeitig in meinen Augen eine Schwäche (man hat ja nur insgesamt 6 Stunden).
Strategie zur Verbesserung:
Mein Plan: Policies in Apstra stufenweise anwenden, immer validieren und das Verhalten mit dem physischen bzw. virtuellen Fabric vergleichen. Außerdem will ich meine Debug-Prozesse dokumentieren: Wo lege ich Apstra‑Tags an, wann greife ich manuell ein, und wann verlasse ich mich auf Apstra‑Automatisierung.
Overlay
Controller‑less Data Center
Overlay bedeutet EVPN‑VXLAN, und das ist genau der Teil, bei dem sich so mancher Netzwerkingenieur nachts wach sitzt und „Warum tut das nicht?“ murmelt. Für den controllerlosen Fall verlangt die Prüfung:
- EBGP‑ oder IBGP-signalisierte EVPN-VXLAN‑Overlays ausrollen, verwalten und auf Fehler prüfen
- Kommunikation zwischen multihomed und single‑homed Devices herstellen
- Mehrere Layer‑2- und Layer‑3‑Tenant‑Umgebungen schaffen
- Routing zwischen Layer‑3‑Tenants ermöglichen
- Multicast optimieren
Schwierigkeiten:
Das Schaffen von mehreren Tenants war für mich keine große Herausforderung. Multihoming macht es nur minimal komplizierter: Traffic kann asymmetrisch laufen, manchmal landet er nicht da, wo man ihn erwartet. Und das mit dem Multicast … tja, da waren ein paar Nächte mit schweren Augenringen nötig 😉
Strategie zur Verbesserung:
Mein Ansatz für den nächsten Versuch: Schritt für Schritt aufbauen. Erst ein Tenant mit single-homed Endgerät – sicherstellen, dass das funktioniert. Dann ein zweites, multihomed – und erst am Ende Tenants kombinieren. Für Multicast werde ich gezielt Labs mit Empfängern auf beiden Seiten aufsetzen und dann testen, wie sich Querflüsse verhalten. Wichtig: Logging, Packet-Dumps und Debugging – ohne die geht gar nichts.
Apstra‑verwaltetes Data Center
Wenn Apstra das Overlay managt, ist der Workflow etwas anders, aber die Basics bleiben:
- EVPN-VXLAN-Overlay über EBGP ausrollen, verwalten und auf Fehler prüfen
- Multihomed und single-homed Endgeräte verbinden
- Mehrere Layer‑3-Tenant‑Umgebungen schaffen
Schwierigkeiten:
Hier ist es weniger „manuell zusammenschrauben“, sondern mehr „designen und beobachten“. Automatisierung ist eine fantastische Sache, aber wenn etwas schiefgeht, muss man verstehen, was Apstra eigentlich gemacht hat.
Strategie zur Verbesserung:
Ich werde intensiv mit Apstra’s Visualisierungstools arbeiten: Topologie‑Maps, Policy-Analyse, etc. Zusätzlich plane ich, schrittweise Overlay-Konfigurationen anzulegen und nach jedem Schritt zu verifizieren: Standby, Multihoming, Routing zwischen Tenants. Wenn Fehler auftreten, werde ich bewusst Apstra-Abweichungen erzeugen (z. B. falsche BGP-Parameter), um meine Debug-Fähigkeiten zu trainieren.
Data Center Interconnect (DCI)
DCI ist für mich eine der spannendsten – und gleichzeitig herausforderndsten – Komponenten der Prüfung bei der mir beim Versuch leider keine Zeit mehr blieb:
- DCI zwischen einem Apstra‑verwalteten Rechenzentrum und einem controllerlosen Rechenzentrum mit EVPN (Typ 2 oder Typ 5), um Tenant-Kommunikation zwischen den Data Centern zu ermöglichen
- DCI zwischen zwei controllerlosen Data Centern via nahtlosem VXLAN‑zu‑VXLAN-Stitching
- EIngehende VNI‑Information identifizieren
Schwierigkeiten:
Das Stimmen der VNI‑Mappings (Virtual Network Identifier) ist eine der größten Stolperfallen – wenn ein VNI falsch verwendet wird, funktioniert die Tenant-Kommunikation nicht richtig.
Strategie zur Verbesserung:
Ich will beim nächsten Mal sehr penibel alle VNI‑Mappings dokumentieren und eine Übersichtstabelle erstellen. Zusätzlich werde ich jeden Schritt des DCI-Aufbaus mit Lab‑Szenarien simulieren: Zuerst die Verbindung aufbauen, dann EVPN‑Routen testen, dann Failover-Szenarien (Link-Down, Route-Withdrawal) provozieren. Wenn Apstra beteiligt ist, nutze ich dessen Monitoring, um sicherzustellen, dass die Routen korrekt propagiert werden, und verifiziere das Verhalten mit externen Peers. Und außerdem muss das alles schneller gehen als beim letzten mal 😉
Sicherheit (Security)
Sicherheit ist kein „Nice-to-have“, sondern Pflicht – besonders im Data Center. In der Prüfung musste ich:
- Security‑Features ausrollen, verwalten und auf Fehler prüfen, die die Infrastruktur und Edge-Geräte schützen
- Zugriff auf Geräte so einschränken, dass unautorisierte Protokolle oder Netzwerke blockiert werden
- Übermäßigen Traffic erkennen, loggen und darauf reagieren
- Verschiedene Spanning‑Tree-Nachrichten monitoren und entsprechend reagieren
Schwierigkeiten:
Eigentlich sind Sicherheitsfeatures nicht per se schwierig, aber leicht zu vernachlässigen. In meinem Versuch vergaß ich zunächst, Logs umfassend zu aktivieren, und das hat mich später beim Troubleshooting ausgebremst. Außerdem ist es nicht trivial, alle möglichen Vektoren zu bedenken: STP‑Anomalien, nicht autorisierte Protokolle, Traffic-Überlastungen – hinzu kommt noch das “wording” mancher Fragen, die für mich als “non-native” manchmal etwas knifflig sind. Hier gilt: Der Proctor ist dein Freund! Einfach fragen – er / sie beißen nicht 😉
Strategie zur Verbesserung:
Mein Plan: Sec-Policies Schritt für Schritt einführen – zuerst Zugriffsregeln, danach Monitoring, dann Logging. Ich möchte gezielt Fehlerszenarien simulieren: STP-Anomalien erzeugen, Traffic-Stürme generieren und dann analysieren, wie die Logs aussehen und ob meine Regeln greifen.
Class of Service (CoS)
CoS ist die Disziplin, Traffic so zu priorisieren, dass latenzkritische Anwendungen sich nicht benachteiligt fühlen – oder anders gesagt: Es ist wie eine VIP-Schlange im Netzwerkverkehr und einzig und alleine dazu da, mich persönlich zu quälen. Bereits im JNCIE-ENT war CoS meine größte Sorge – dieser “rote Faden” zog sich leider auch durch die Punkte beim JNCIE-DC. Für die Prüfung war nötig:
- CoS‑Einstellungen für Server‑Traffic an Leaf-Nodes konfigurieren und debuggen
Schwierigkeiten:
Es ist nicht so, dass CoS per se kompliziert ist, aber leider aus 8457439857439875439875439857439875984375823750237584375943754375094703579437564935743985743ß987548ß3975 Komponenten besteht 😀 :P. Ich hatte im Lab Situationen, in denen Priorisierung eines Dienstes dazu führte, dass andere Dienste zu stark benachteiligt wurden, oder dass meine Richtlinien nicht wie erwartet angewendet wurden.
Strategie zur Verbesserung:
Ich plane, zukünftige Labs mit mehreren Traffic-Klassen aufzusetzen (z. B. Web, Datenbank, Backup) und gezielt CoS-Policys zu testen. Wichtig ist auch, die Queues genau zu beobachten: Welche Klasse landet in welcher Queue? Wie verhält sich das unter Last? Um das zu validieren, nutze ich Ostinato, um kontrolliertes Verhalten zu erzeugen und zu messen.
Management
Wenn ein Data Center ohne gutes Management läuft, ist das Risiko groß, dass du beim ersten Fehler im Dunkeln tappst – und glaub mir, der Netzwerkonkel mag keine dunklen Stellen in seinem Netzwerk. In der Prüfung wurden diese Themen geprüft:
- Tags und Probes nutzen, um kritische Services zu überwachen und Apstra-Anomalien zu triggern
- Eigene Apstra-Configlets erstellen und anwenden
- Sub‑Sekunden Link‑Failure-Detection mit BFD (Leaf ↔ externe Geräte) aktivieren
- Zeitsynchronisierung (Datum & Uhrzeit) auf allen Geräten sicherstellen
- System-Logging lokal und remote konfigurieren
- Streaming Telemetrie auf benutzerdefinierten Ports aktivieren
- SNMP Monitoring einsetzen
Schwierigkeiten:
In meinem Versuch war die BFD-Konfiguration eine echte Herausforderung (oder die vQFX – je nachdem, wie man das sieht) – wenn BFD falsch eingerichtet ist, meldet man entweder zu langsam oder zu oft. Auch das Telemetrie-Setup hat mich zeitweise gestresst: Wo müssen welche Messpunkte eingerichtet werden? Und dann noch IGP & Apstra richtig konfigurieren, damit die Probes und Anomalien auch sinnvoll sind.
Strategie zur Verbesserung:
Ich werde in meinen Lab‑Sessions feste Management-„Checklisten“ einführen: Timesync, Logging, BFD, Telemetrie, Probes – alles in einer bestimmten Reihenfolge aktivieren, testen und validieren. Dann Fehler simulieren: Link‑Ausfall, Zeitabweichung, Telemetrie‑Verlust. Und natürlich Apstra‑Anomalien provozieren, damit ich sehe, ob meine Tags und Probes korrekt anschlagen. Eben: nicht nur bauen, sondern auch kaputt machen und wieder reparieren.
Meine persönlichen Reflexionen zum Versuch
Wenn man all das zusammennimmt, dann war dieser Versuch mehr als ein „Test“. Er war eine Art Momentaufnahme: Wo stehe ich, was kann ich, und wo liegen meine Baustellen. Einige Erkenntnisse:
- Punkte in jeder Sektion: Ich habe in allen Themenbereichen zumindest etwas erreicht. Kein Abschnitt endete bei null – das war eine riesige Erleichterung. Ich habe aber auch Bereiche, in denen ich mich nur verbessern kann 😛 Andere Bereiche sahen dafür besser aus.
- Langsamkeit erkannt: Ich weiß ganz genau, in welchen Bereichen ich Zeit verloren habe – insbesondere im Overlay und beim DCI-Troubleshooting. Vieles hätte man mit einer besseren Notepad++ Routine lösen können – hier muss ich zugeben, dass ich etwas “eingerostet” bin – aber zum Glück gibt’s ganz viel Cola (mein WD-40) 😛
- Faire Prüfung: Es gab keine künstlichen Fallen oder Tricks. Die Aufgaben waren klar, solide und praxisnah.
- Selbstvertrauen: Im Vergleich zu meinen JNCIE‑ENT-Versuchen, die sich oft wie wildes Herumjonglieren mit zu vielen Themen angefühlt haben, war die DC-Prüfung fokussierter. Das macht mir Mut.
Trotz der HPE‑Akquisition (ja, ich spreche davon, was gerade alle reden) bleibe ich meinem Weg treu. Die Unsicherheit oder Veränderung hat mich nicht abgeschreckt – im Gegenteil: Ich will diese Zertifizierung jetzt mehr denn je abschließen. Der JNCIE ist nach wie vor eine der härtesten Prüfungen, die du als Netzwerker weltweit machen kannst – und genau das treibt mich an!
Strategien fürs nächste Mal – oder: Was der Netzwerkonkel gelernt hat
Basierend auf diesem Versuch und meinen bisherigen Lab-Erfahrungen habe ich mir einen konkreten Fahrplan für die nächsten 2 Monate zurechtgelegt:
- Systematisches Lab-Training
Ich werde meine Labs in klare Etappen unterteilen: Underlay, Overlay, DCI, Sicherheit, CoS, Management. Jede Etappe baue ich auf, teste sie intensiv und simuliere Fehler. - Fehlerprovozierung aktiv einplanen
Nicht nur „Happy‑Path“-Szenarien, sondern auch Ausfälle: Link-Downs, falsche Routen, Multihoming-Probleme, Telemetrie-Verlust – all das gehört dazu. Wer nicht testet, hat nicht gelernt. - Detaillierte Dokumentation
Jede Topologie, jede Tagging-Strategie, jede VNI-Mapping-Tabelle, jede BFD-Konfiguration – ich dokumentiere es penibel. Und dann überprüfe ich im „Fehlerfall“, ob meine Dokumentation mir beim Debugging hilft. Vielleicht lerne ich nebenbei Stenografie, damit ich mir schneller Notizen auf meinem Whiteboard machen kann 😛 - Monitoring & Observability
Ich setze konsequent Telemetrie, Logging, Probes und Anomalien in Apstra ein. Dann simuliere ich Ereignisse und schaue, ob die Alarme so kommen, wie ich es mir vorstelle. - Prüfungs-ähnliches Timing üben
Zeitmanagement war bei meinem Versuch ein großer Engpass. Daher werde ich Labübungen mit Zeitlimit fahren, um mich wieder an den Druck und meine alte Geschwindigkeit zu gewöhnen. - Community einbinden
Teile meine Lab-Szenarien, meine Fehlerszenarien, meine Lernpläne mit anderen, die ebenfalls JNCIE-DC anpeilen. Networking ist mehr als nur Pakete routen – Networking heißt auch, von anderen zu lernen und gemeinsam zu wachsen. Hier auch nochmal die EInladung in unsere JNCIE-Community (WINK MIT DEM ZAUNPFAHL)
Ja, mein erster JNCIE‑DC‑Versuch endete nicht mit dem Zertifikat. Ich sehe es aber als Benchmark, der mir zeigt, wo ich stehe und was ich verbessern kann. Und vor allem: Ich sehe, dass ich auf dem richtigen Weg bin.
Mein Ziel war es, nirgendwo mit 0 abzuschließen – Ziel erreicht 🙂 Nächstes Ziel: JNCIE-DC werden 😉
Es fühlt sich nicht nach Niederlage an, sondern nach einer Investition. In meine Fähigkeiten, mein Verständnis und meine Leidenschaft. Der nächste Versuch kommt – und dieses Mal gehe ich mit klarerem Kopf, strukturierterem Ansatz und noch mehr “Entschlossenheit hinein.”Speed” rein. Aber erst im Februar – denn ich habe aus meinem JNCIE-ENT eins gelernt: Nicht zu schnell und zu viel auf einmal – sonst läuft man ruck zuck Gefahr auszubrennen…
Danke an alle, die mich bisher unterstützt haben, mir Feedback geben, mich motivieren oder einfach nur mit mir über EVPN-VXLAN quatschen. Und für alle, die selbst über den JNCIE-DC nachdenken: Ja, es ist hart. Aber ja, es ist machbar.
Euer Netzwerkonkel