Netzlabor für sichere Hardware-Rollouts
Ein hybrides Testlabor, das die Konfiguration eines Switch-Stacks vollständig durchprüft, bevor er an einen weiteren Standort ausgeliefert wird. Ziel: Fehler am Schreibtisch finden statt teuer vor Ort, wo ein Fehlschlag den Betrieb lahmlegt und eine Anreise nötig macht.
01Das Szenario
Ausgangspunkt ist ein wiederkehrender Rollout von Netzwerk-Hardware (Switche und Stacks) an weitere Standorte. Bisher wurde die Hardware konfiguriert, verpackt und verschickt, ob die Konfiguration wirklich stimmt, zeigte sich oft erst vor Ort bei der Inbetriebnahme.
Das ist teuer und riskant: Stimmt eine Einstellung nicht, greift die Anmeldung am Netz (RADIUS) nicht oder ist eine Route falsch gesetzt, muss im schlimmsten Fall jemand zum Standort fahren. Reisekosten, Zeitverlust und ein Standort, der nicht ans Netz kommt.
Wie lässt sich ein solches Setup komplett am Schreibtisch prüfen, sodass ein Switch-Stack das Haus erst verlässt, wenn feststeht, dass er sich am Zielort exakt so verhält wie gewünscht?
02Die Idee: ein hybrides Netzlabor
Die Lösung ist ein Testlabor, das echte und simulierte Technik kombiniert. Der Netzwerk-Kern läuft als Simulation in Cisco CML in einer VM, der Zugangsbereich (der Teil, an den später die Endgeräte am Zielort angeschlossen werden) besteht aus einem echten physischen Switch-Stack. Beide Welten sind über eine Brücke miteinander verbunden.
So entsteht eine realistische Nachbildung des Ziel-Setups, ohne für jeden Test tatsächlich Hardware verschicken oder eine komplette zweite Umgebung aufbauen zu müssen.
Simulierter Kern (Cisco CML)
Der zentrale Switch läuft virtuell in Cisco CML in einer VM auf einem einzelnen Mini-PC. VLANs, Routing zwischen den Netzen und die Grundkonfiguration lassen sich hier gefahrlos testen und beliebig zurücksetzen.
Physischer Switch-Stack
Ein echter Switch-Stack bildet den Teil nach, an den am Zielort die Endgeräte kommen. So werden auch reale Eigenheiten der Hardware sichtbar, die eine reine Simulation verschluckt.
Netz-Anmeldung (Cisco ISE)
Cisco ISE stellt den RADIUS-Dienst und prüft per 802.1X, wer sich ans Netz hängen darf. Genau dieser Ablauf ist im Feld fehleranfällig und wird im Labor durchgespielt, bevor es zählt.
Automatisierte Tests (pyATS)
Ein Test-Client fährt die Prüfungen mit pyATS automatisiert ab, statt jeden Schritt von Hand einzugeben. CML-VM und Cisco ISE laufen dabei auf einem einzigen kompakten Rechner, dazu nur der physische Stack.
03Was im Labor geprüft wird
Bevor ein Switch ausgeliefert wird, durchläuft er eine feste Reihe von Tests. Jeder Test bildet eine Situation nach, die am echten Standort auftreten kann:
- Erreichbarkeit (Ping): Kommen die Geräte in den verschiedenen Netzen wie vorgesehen zueinander durch, und dort nicht, wo sie getrennt sein sollen?
- VLAN-Trennung: Sind die logischen Netze sauber voneinander abgegrenzt (z. B. Verwaltung getrennt vom Nutzernetz)?
- Routing zwischen den Netzen: Findet der Verkehr zwischen den VLANs den richtigen Weg?
- Netz-Anmeldung (RADIUS / 802.1X): Wird ein berechtigtes Gerät angenommen und ein unberechtigtes zuverlässig abgewiesen?
- Fallback: Was passiert, wenn Cisco ISE nicht erreichbar ist? Verhält sich der Switch dann noch kontrolliert?
Erst wenn alle Punkte grün sind, gilt die Konfiguration als auslieferbereit.
04Ein greifbares Beispiel
Ein typischer Test ist die Anmeldung eines Endgeräts am Netz. Am Zielort soll ein zugelassenes Gerät automatisch ins richtige VLAN kommen, ein unbekanntes Gerät dagegen draußen bleiben. Im Labor lässt sich genau das durchspielen, der Switch fragt bei Cisco ISE nach und entscheidet anhand der Antwort.
Switch# test aaa group RADIUS-TEST testnutzer ******** new-code Sende Anfrage an Cisco ISE (RADIUS) ... User erfolgreich authentifiziert Zugewiesenes VLAN: Nutzernetz -- berechtigtes Gerät wird angenommen und korrekt einsortiert --
Spannend war der Fall, dass der Switch nach einem Kaltstart Cisco ISE kurz für „tot\" hielt, obwohl der Dienst lief, eine Frage des Timings. Solche Effekte tauchen nur in einer realistischen Umgebung auf. Genau deshalb ist der physische Anteil im Labor so wertvoll: Eine reine Simulation hätte dieses Verhalten nie gezeigt, und im Feld wäre es zur bösen Überraschung geworden.
05Was das Labor bringt
Theoretisch weniger Anreisen
Fällt ein Konfigurationsfehler schon am Schreibtisch auf, könnte im Idealfall eine Fahrt zum Standort entfallen, das würde Reisekosten und Nerven sparen. Ob sich das in Zahlen bestätigt, müsste der Praxiseinsatz zeigen.
Wiederholbare Qualität
Jeder Switch durchläuft dieselbe Testreihe. Das Ergebnis hängt nicht mehr davon ab, wer gerade konfiguriert, sondern folgt einem festen Prüfplan.
Gefahrloses Üben
Der simulierte Kern lässt sich beliebig zurücksetzen. Neue Konfigurationen und Änderungen können ohne Risiko für das Produktivnetz ausprobiert werden.
Günstig & kompakt
Ein Mini-PC plus ein kleiner physischer Stack genügen. Kein teurer Laboraufbau, das Ganze passt praktisch auf einen Schreibtisch.
06Was ich dabei gelernt habe
Fachlich hat mich das Projekt quer durch die Systemintegration geführt: VLANs und Trunking, Routing zwischen Netzen, die Anmeldung am Netz per RADIUS und 802.1X, dazu Virtualisierung und das Zusammenspiel von simulierter und echter Hardware.
Mindestens genauso wichtig war das Drumherum: eine Idee sauber in ein Konzept überführen, den Aufwand realistisch einschätzen, alles nachvollziehbar dokumentieren und, wenn etwas nicht auf Anhieb läuft, systematisch nach der Ursache suchen. Am meisten gelernt habe ich an den Stellen, an denen es zuerst nicht funktioniert hat.
← Zurück zu den Projekten