Vom Hersteller-Mischmasch zum Cisco-Netzwerk mit Core-Clustern

Ausgangslage

Das Netzwerk eines mittelständischen Unternehmens mit Fertigung war über die Jahre gewachsen: Switches verschiedener Hersteller, uneinheitliche Softwarestände und eine Struktur, die sich nur noch schwer überblicken ließ. Gleichzeitig hängt am Netz vieles, was nicht ausfallen darf: Server und Virtualisierung, Backup, Telefonie, Drucker, WLAN, Gebäudetechnik und ein Maschinenpark in der Fertigung.

Ziel

Ein einheitliches, herstellerkonsistentes Netzwerk auf Cisco-Basis mit einem redundanten Kern, klar getrennten Segmenten und einem Zustand, der sich jederzeit nachvollziehen lässt.

Die Bedingung: der Betrieb läuft immer weiter

Das Projekt begann Ende 2024 und lief seitdem Schritt für Schritt. Die zentrale Vorgabe war, dass der laufende Betrieb zu jedem Zeitpunkt gewährleistet bleibt: Verwaltung, Server, Telefonie und Fertigung können nicht auf ein Wartungsfenster am Wochenende warten, bis das ganze Netz getauscht ist.

Deshalb wurde das Netzwerk in Etappen umgestellt: Bereich für Bereich, jeweils mit gesichertem Ausgangsstand und einem definierten Rückweg. Die Konfigurationssicherung (siehe unten) lieferte dafür den Vorher-Nachher-Vergleich.

Die Architektur

Den Kern bilden zwei Core-Cluster aus gestapelten Cisco-Catalyst-Switches. Sie übernehmen das Routing zwischen den Segmenten und sind über Uplinks mit den übrigen Switches verbunden.

• Core-Cluster: Zwei Stacks (vier beziehungsweise zwei Geräte) als Layer-3-Kern, mit persistenter Stack-MAC, damit sich die Identität des Verbunds beim Wechsel eines Mitglieds nicht ändert.
• Segmentierung: Getrennte Netze für Verwaltung, Server, Backup, Drucker, Gäste- und Office-WLAN, Gebäudetechnik sowie Fertigung inklusive Maschinenpark-Fernzugriff. Die Zuordnung erfolgt über Layer-3-Schnittstellen im Kern, DHCP-Relay inklusive.
• Spanning Tree: Rapid-PVST mit bewusst gesetzter Root-Priorität im Kern, damit die Kern-Rolle nicht dem Zufall überlassen bleibt.
• Schutzfunktionen: Loop Guard, PortFast mit BPDU Guard an Endgeräteports, Storm Control und aggressives UDLD auf den Uplinks, VTP abgeschaltet.
• Server-Anbindung: Virtualisierungshosts mit mehreren Netzwerkkarten, teilweise über Port-Channels angebunden, dazu getrennte Ports für Management und Storage.
• Nachvollziehbarkeit: Port-Beschreibungen an den Ports, damit jeder Anschluss seinem Zweck zugeordnet ist.

Eigenes Werkzeug: Konfigurationen herstellerübergreifend sichern

Für die Bestandsaufnahme und den späteren Betrieb haben wir ein eigenes Werkzeug entwickelt, den SwitchConfigFetcher. Er holt die Konfigurationen aller Geräte automatisiert per SSH oder Telnet ab und legt sie mit Zeitstempel ab.

• Profile je Hersteller: Neun Geräteprofile decken Cisco IOS/IOS-XE in mehreren Varianten, HP ProCurve, Aruba AOS-CX, Extreme EXOS, MikroTik RouterOS und Ubiquiti UniFi ab. Login-Ablauf, Befehle und Seitenumbruch sind je Profil hinterlegt.
• Pro Gerät und Lauf: Laufende Konfiguration, Versionsstand, Schnittstellenübersicht, MAC-Adresstabelle und VLANs.
• Parallel und robust: Mehrere Geräte gleichzeitig, mit Timeouts und Wiederholung.
• Sicher abgelegt: Zugangsdaten liegen verschlüsselt in der Konfiguration.
• Vergleichbar: Zwei Läufe zu verschiedenen Zeitpunkten lassen sich gegeneinander vergleichen. So wird sichtbar, was sich zwischen zwei Ständen verändert hat.

Stolperstein: Altgeräte mit abweichendem Login

Einzelne ältere Geräte fragen beim Login nur nach einem Passwort und nicht nach einem Benutzernamen. Der erste Lauf mit dem Standardprofil lief deshalb in einen Timeout. Wir haben ein eigenes Profil für diese Geräteklasse ergänzt und am Live-Gerät geprüft. Der Fall zeigt, warum wir pro Hersteller und Geräteklasse eigene Profile pflegen, statt von einem einheitlichen Verhalten auszugehen.

Parallel: Server und Arbeitsplätze

Das Netzwerk ist die Grundlage für zwei weitere Bausteine, die derzeit laufen:

• Migration eines alten VMware-Clusters auf eine neue Umgebung.
• Aufbau einer größeren Terminalserver-Farm mit getrennten Sammlungen für Verwaltung, Buchhaltung und Fertigung.
• Umstellung der Fertigung auf Thin Clients, um Aufwand für Patchen und Softwarelizenzen zu senken.

Stand und Ergebnis

Das Netzwerk ist umgestellt und dokumentiert, das Gesamtprojekt befindet sich in den letzten Umsetzungen. Die beiden Bausteine Virtualisierung und Terminalserver-Farm sind in Arbeit. Wir aktualisieren diese Fallstudie, sobald sie abgeschlossen sind.

• Zwölf Cisco-Switches in zwei Core-Clustern und mehreren Einzelgeräten
• Klar getrennte Segmente mit Routing im Kern
• Spanning-Tree-Struktur und Schutzfunktionen bewusst gesetzt
• Konfigurationen aller Geräte automatisiert gesichert und vergleichbar

Was bewusst nicht öffentlich ist

Kunden-, Standort- und Gerätenamen, Adressbereiche und Zugangsdaten sind aus dieser Fallstudie bewusst entfernt.