Nach der Umstellung eines Unternehmensnetzwerks auf einen neuen Glasfaseranschluss müssen häufig auch die Netzwerkeinstellungen vorhandener Server und Speichersysteme angepasst werden.
Normalerweise übernimmt ein DHCP-Client die neuen Einstellungen automatisch. Doch was passiert, wenn eine Synology DiskStation weiterhin das bisherige Standardgateway verwendet – obwohl der DHCP-Server bereits korrekt konfiguriert wurde?
Genau diese Situation haben wir bei IT-LAS kürzlich in einer produktiven Kundenumgebung untersucht und gelöst. Die besondere Herausforderung: Auf der DiskStation liefen aktive iSCSI-LUNs, die von mehreren Servern genutzt wurden. Eine Unterbrechung der Netzwerkverbindungen sollte deshalb unbedingt vermieden werden.
Ausgangssituation: Neues Gateway, alte DHCP-Einstellungen
Nach der Aktivierung des Glasfaseranschlusses wurde das Standardgateway im Netzwerk geändert.
Der vorhandene Windows-DHCP-Server war bereits entsprechend angepasst und verteilte die neue Routeradresse.
Auf einer Synology DiskStation zeigte sich jedoch weiterhin das bisherige Standardgateway.
Die betroffene DiskStation verfügte über:
- Vier physische Netzwerkanschlüsse
- Aktiviertes Open vSwitch
- DHCP-Konfiguration auf allen vier Schnittstellen
- Docker-Netzwerke
- Produktive iSCSI-LUNs mit mehreren aktiven Verbindungen
Ein vollständiger Neustart der DiskStation oder das kurzzeitige Deaktivieren der Netzwerkadapter kam deshalb nicht als erste Maßnahme infrage.
Schritt 1: Netzwerkkonfiguration analysieren
Zunächst wurde über SSH eine Verbindung zur DiskStation hergestellt.
Mit folgendem Befehl lassen sich die vorhandenen Netzwerkadapter und ihre IP-Adressen anzeigen:
ip -br addr
Dabei zeigte sich, dass die DiskStation nicht direkt über die Schnittstellen eth0 bis eth3 adressiert war. Stattdessen wurden die IP-Adressen über die zugehörigen Open-vSwitch-Schnittstellen ovs_eth0 bis ovs_eth3 bereitgestellt.
Anschließend wurde die Routingtabelle überprüft:
ip -4 route
Die Ausgabe bestätigte, dass weiterhin das bisherige Gateway als Standardroute eingetragen war.
Eine zusätzliche Kontrolle der Konfigurationsdateien ergab, dass alle vier Schnittstellen DHCP verwendeten:
sudo grep -H 'BOOTPROTO=' /etc/sysconfig/network-scripts/ifcfg-ovs_eth[0-3]
Das Problem lag somit nicht an einer manuell vergebenen IP-Adresse. Vielmehr hatte die DiskStation die neue Gateway-Information zu diesem Zeitpunkt noch nicht übernommen.
Schritt 2: Aktive iSCSI-Verbindungen überprüfen
Bevor Änderungen an den Netzwerkeinstellungen vorgenommen wurden, mussten die bestehenden Speicherverbindungen geprüft werden.
Dazu verwendeten wir:
sudo netstat -tn | grep ':3260'
Port 3260 ist der standardmäßige TCP-Port für iSCSI.
Die Ausgabe zeigte drei bestehende Verbindungen mit dem Status ESTABLISHED.
Alle drei iSCSI-Clients befanden sich im gleichen IPv4-Subnetz wie die DiskStation.
Das war ein wichtiger Hinweis: Für die direkte Kommunikation innerhalb dieses Subnetzes wird normalerweise keine Standardroute über den Router benötigt.
Eine Änderung ausschließlich des Standardgateways erschien deshalb als geeigneter Weg, ohne die Netzwerkadapter oder die iSCSI-Targets neu starten zu müssen.
Schritt 3: Neues Gateway auf Erreichbarkeit prüfen
Vor der eigentlichen Änderung wurde zunächst getestet, ob der neue Router über die vorgesehene Netzwerkschnittstelle erreichbar war.
Beispiel mit anonymisierten IP-Adressen:
sudo ping -c 3 -I ovs_eth0 192.168.50.254
Alle drei Testpakete wurden erfolgreich beantwortet. Damit war bestätigt, dass das neue Gateway aus dem lokalen Netzwerk erreichbar war.
Schritt 4: Standardgateway ohne Adapterneustart ändern
Die eigentliche Änderung erfolgte über die bestehende SSH-Sitzung mit dem Linux-Befehl ip route replace.
Beispiel:
sudo ip route replace default via 192.168.50.254 dev ovs_eth0 src 192.168.50.20
Die IP-Adressen dienen hier ausschließlich als Beispiel und müssen an die jeweilige Netzwerkumgebung angepasst werden.
Mit diesem Befehl wird die Standardroute im laufenden Betrieb ersetzt.
Ein Neustart der Netzwerkschnittstelle ist dafür nicht erforderlich. Auch die bestehenden IP-Adressen bleiben unverändert.
Die neue Routingtabelle wurde anschließend kontrolliert:
ip -4 route
Die Ausgabe bestätigte, dass jetzt das neue Standardgateway eingetragen war.
Schritt 5: iSCSI-Verbindungen nach der Änderung kontrollieren
Unmittelbar nach der Anpassung wurde der Status der bestehenden iSCSI-Verbindungen erneut geprüft:
sudo netstat -tn | grep ':3260'
Das Ergebnis war erfreulich: Alle drei zuvor bestehenden TCP-Verbindungen waren weiterhin mit dem Status ESTABLISHED vorhanden.
Damit konnte bestätigt werden, dass die Gateway-Änderung die beobachteten iSCSI-Sitzungen nicht getrennt hatte.
Eine zusätzliche Kontrolle der Speicherdienste und der angebundenen Server bleibt bei solchen Eingriffen grundsätzlich empfehlenswert.
Schritt 6: Dauerhafte DHCP-Konfiguration sicherstellen
Ein wichtiger Punkt darf bei dieser Vorgehensweise nicht übersehen werden:
Die Änderung mit ip route replace ist zunächst nur temporär.
Bei einem Neustart oder einer erneuten DHCP-Konfiguration kann die Standardroute wieder durch die automatisch bezogenen Einstellungen überschrieben werden.
Deshalb wurde auch der zuständige Windows-DHCP-Server überprüft.
Entscheidend waren dabei:
- DHCP-Option 003: Neues Standardgateway
- DHCP-Option 006: Vorgesehene DNS-Server
- DHCP-Reservierungen für die Netzwerkadapter der DiskStation
Die bisherigen IP-Adressen wurden durch entsprechende DHCP-Reservierungen abgesichert.
Die DNS-Konfiguration auf der DiskStation ließ sich zusätzlich mit folgendem Befehl kontrollieren:
cat /etc/resolv.conf
Im untersuchten Fall war weiterhin der vorgesehene interne DNS-Server eingetragen.
Die dauerhafte Übernahme des neuen Gateways durch DHCP muss nach einer regulären Lease-Verlängerung beziehungsweise einem späteren kontrollierten Neustart noch überprüft werden.
Warum wir auf einen Neustart verzichtet haben
Ein Neustart der Netzwerkschnittstellen wäre technisch eine mögliche Vorgehensweise gewesen, hätte jedoch unnötige Risiken mit sich gebracht.
Gerade bei produktiven iSCSI-LUNs kann ein Verbindungsabbruch Auswirkungen auf angeschlossene Server, virtuelle Maschinen und laufende Anwendungen haben.
Deshalb haben wir uns bewusst für eine gezielte Änderung der Routingtabelle entschieden.
Diese Vorgehensweise eignet sich insbesondere dann, wenn die bisherigen IP-Adressen unverändert bleiben und ausschließlich die Standardroute angepasst werden muss.
Sie sollte allerdings nicht ungeprüft auf andere Netzwerkumgebungen übertragen werden. Insbesondere bei mehreren Subnetzen, Multipath-I/O oder zusätzlichen Routingregeln muss die jeweilige Konfiguration berücksichtigt werden.
Fazit: Kleine Änderung, große Bedeutung für den laufenden Betrieb
Die Umstellung eines Internetanschlusses betrifft häufig weit mehr als nur den Router.
Auch bestehende Server, NAS-Systeme und andere Netzwerkkomponenten müssen ihre Konfiguration an die neue Infrastruktur anpassen.
In unserem Praxisfall ließ sich das Standardgateway einer Synology DiskStation im laufenden Betrieb aktualisieren, ohne die Netzwerkschnittstellen neu zu starten.
Die bestehenden iSCSI-Verbindungen blieben während der überprüften Änderung erhalten.
Der entscheidende Punkt war dabei nicht ein besonders komplizierter Befehl, sondern die vorherige Analyse der Netzwerk- und Speicherverbindungen.
Erst prüfen, dann gezielt ändern und anschließend die Funktion kontrollieren.
Genau diese Vorgehensweise hilft dabei, Änderungen an produktiven IT-Systemen möglichst sicher und nachvollziehbar umzusetzen.
IT-LAS – persönliche IT-Betreuung, zuverlässige Server- und Speicherlösungen und praxisorientierte Fehleranalyse.
Mehr über unsere Leistungen erfahren Sie unter Synology & Datensicherung.