===== Routing-Probleme durch DHCPv6-Relay ===== Am Mittwoch, den 09.04.2025 kam es zwischen 11:09 Uhr und ca. 15:00 Uhr zu zahlreichen Erreichbarkeitsproblemen vieler IT-Systeme der RUB. Die Ursache ist nicht eine einzige sondern eine Verkettung mehrerer Umstände. Alles begann vor einigen Tagen - genauer gesagt am 1. April - als wir auf Wunsch eines Netzbetreuers eine Konfigurationsänderung an einem VLAN auf einem der Datacenter-Router durchgeführt haben. Dabei haben wir ein wichtiges Detail übersehen: Diese Konfigurationsänderung war unnötig und problematisch. Was wir allerdings nicht geahnt haben ist, dass diese Konfigurationsänderung einige Tage später zu einem mehrstündigen Routingproblem mit zahlreichen Auswirkungen und einer umfangreichen Troubleshooting-Aktion unter erschwerten Bedingungen führen würde. ==== Was im Detail geschah ==== Am 1. April haben wir das DHCPv6-Relay in einem VLAN auf Wunsch des Netzbetreuers so umgestellt, so dass es nicht mehr auf unseren zentralen DHCPv6-Server sondern auf die eigenen DHCPv6-Server des Netzbetreuers zeigt. Dabei hätte uns auffallen müssen, dass diese im selben VLAN stehen und man daher überhaupt keine spezielle Konfiguration auf dem Router dafür benötigt. Der Router macht an dieser Stelle auch keine Konsistenzprüfung und hat die Konfiguration anstandslos akzeptiert. Das sieht dann (auf unserem Cisco Catalyst 9500 System mit IOS-XE) beispielsweise so aus: interface Vlan999 ipv6 address 2001:DB8:123:456::1/64 ipv6 nd prefix default 900 300 no-autoconfig ipv6 nd managed-config-flag ipv6 dhcp relay destination 2001:DB8:123:456::DACB ipv6 dhcp relay destination 2001:DB8:123:456::DACC ipv6 verify unicast source reachable-via rx allow-default Hier ist lediglich ein Auszug der VLAN-Konfiguration dargestellt und es handelt sich um fiktive Daten. Man kann aber erkennen, dass die beiden Relay-Destinations (zweit- und drittletzte Zeile) auf Adressen innerhalb des selben VLANs zeigen (vgl. IPv6-Adresse in der zweiten Zeile). Die Relay-Destinations sind DHCPv6-Server. Diese Konfiguration geht genau so lange gut, bis man mindestens einen der DHCPv6-Server einschaltet. Und das ist neun Tage später, am 09.04.2025 um 11:09 Uhr passiert. Ab dann kam es zum sogenannten Packet Loop. Systeme aus dem VLAN versuchten, den DHCPv6-Server unter der Multicast-Adresse ''ff02::1:2'' zu erreichen. Der Router empfing das Paket, weil er auf der Multicast-Adresse mit hörte (wegen der konfigurierten Relays). Das Paket wurde dann an alle Relays weiter geleitet mit dem eingebetteten Hinweis, dass das Antwortpaket wieder zurück zum Router muss. Und dann ging es aufgrund eines Logikfehlers im Betriebssystem des Routers im Kreis: wieder an die DHCPv6-Server und zurück an den Router und wieder an die DHCPv6-Server und zurück an den Router und so weiter und so fort. Das ganze passierte natürlich nicht nur mit einem sondern mit zahlreichen Paketen. ==== Wie wir dem Problem auf die Spur kamen ==== Relativ schnell konnten wir heraus finden, dass einer unserer Datacenter-Router regelmäßig vom Netz ging. Seine OSPF-Anbindungen an das Campus-Routing brachen immer wieder zusammen. Auf diesen Router haben wir für den Notfall eine serielle Verbindung und können ihn auch erreichen wenn er seinen Dienst nicht mehr tut. So konnten wir heraus finden, dass der Router Probleme aufgrund seiner CPU-Last hatte. Auch den die Last verursachenden Prozess konnten wir identifizieren, wodurch schnell klar wurde, dass es sich um ein Problem im Zusammenhang mit DHCPv6-Relays handeln musste. Nur gab das Protokoll des Routers leider keine hilfreichen Informationen. Wir gingen dann nach dem Prinzip der Intervallschachtelung vor und deaktivierten zunächst alle VLANs, die auch IPv6 konfiguriert haben. Das Problem verschwand. Nun schalteten wir so lange Teile der VLANs wieder ein bis das Problem erneut auftrat. Als das Problem wieder kam schalteten wir noch einmal Teile der VLANs ab und wiederholten das Prinzip so lange bis wir die Ursache in einem einzigen VLAN ausmachen konnten. Dort war der Konfigurationsfehler dann schnell erkannt und beseitigt. ==== Warum die Auswirkungen so umfangreich waren ==== Das ist ganz einfach: Wenn DNS nicht funktioniert, klappt nichts. Das Routing für einen der beiden zentralen DNS-Caches der RUB, nämlich für ''ns1.ruhr-uni-bochum.de'' (''134.147.32.40'' bzw. ''2a05:3e00:1:1003::32:40''), befand sich auf dem betroffenen Router. Dieser DNS-Cache war meistens nicht erreichbar. Der weitere DNS-Cache ''ns2.ruhr-uni-bochum.de'' (''134.147.222.4'' bzw. ''2a05:3e00:9:1001::222:4'') wird aus guten Gründen über einen anderen Router ans Netz angebunden und war durchgehend erreichbar. DNS hat jedoch die Eigenart, dass der Client entscheidet, welcher der konfigurierten DNS-Server verwendet wird. Und je nach Client-Implementierung und -Konfiguration werden entweder alle konfigurierten DNS-Server wechselweise gefragt (round-robin) oder - was im Allgemeinen die Standardeinstellung ist - es wird nur einer der konfigurierten DNS-Server und im Fehlerfall bzw. bei Timeout der zweite DNS-Server gefragt. Dadurch, dass ''ns1.ruhr-uni-bochum.de'' zwischenzeitlich immer wieder für einige Sekunden erreichbar war, wurde auf den Clients oft der Timer für's Umschwenken auf den alternativen DNS-Server zurück gesetzt, so dass nicht zuverlässig der alternativ konfigurierte DNS-Server benutzt wurde. Diese Problematik ist nur durch Anycast-DNS nachhaltig lösbar, was an der RUB allerdings nicht eingesetzt wird. Auch Server benutzen DNS um mit anderen Systemen (z.B. Datenbanken, Speichersysteme etc.) zu kommunizieren. Diese Verbindungen funktionieren ohne DNS oft auch nicht lange, so dass es beispielsweise auch zu im Nachgang noch länger andauernden Zugriffsproblemen auf Mailaccounts kam. Viele weitere Systeme waren ebenfalls betroffen. Wir haben während des Troubleshootings das Routing für ''ns1.ruhr-uni-bochum.de'' händisch auf einen anderen Router umgezogen, so dass die DNS-Caches beide wieder zuverlässig erreichbar wurden. Aber auch dies brauchte ein wenig Zeit, denn dabei wollten wir uns natürlich keine weiteren Konfigurationsfehler erzeugen. ==== Was wir daraus mit genommen haben ==== Es hat uns erstaunt, dass dieser vergleichsweise kleine Packet Loop zu so hoher Last und darüber hinaus auch noch zu Folgen im Routing führen konnte. Wir müssen prüfen, warum es diesen Zusammenhang gibt und wie er verhinderbar ist. Man kann sich jetzt aussuchen auf wen man mit dem Finger zeigen will. Dem Netzbetreuer ist jedenfalls nichts vorzuwerfen, er hat sich korrekterweise an uns gewendet und um eine Änderung der Konfiguration seines VLANs gebeten. IT.SERVICES betreibt zwar das DNS-System der RUB, aber auch dieses ist nicht Ursache des Problems, es war lediglich mit betroffen. Wir können uns jedoch den Schuh anziehen, dass wir die Sinnhaftigkeit der Konfigurationsänderung nicht ordentlich geprüft haben. Letztendlich kam es aber hier zum Ausfall aller Anbindungen eines Routers aufgrund eines einzigen Prozesses, der hohe CPU-Last verursacht hat. Unserer Auffassung nach handelt es sich hier um ein Design-Problem im Betriebssystem des Routers.