Am Montag, den 19.05.2025 kam es um kurz nach 13 Uhr zu einem großflächigen Ausfall des Datennetzes an der RUB. Betroffen war das Routingsystem des Datacenters. Da sich im Datacenter fast sämtliche für den Betrieb des Datennetzes relevanten zentralen Komponenten befinden - u.a. DNS-Server, Proxy-Server, WLAN-Controller, Authentifizierungssysteme - funktionierte für die Nutzer auf dem Campus und in den Wohnheimen praktisch nichts mehr.

Wir stellten zunächst fest, dass das betroffene Routingsystem, ein redundantes Pärchen vom Typ Cisco Catalyst 9500, hohe CPU-Last aufgrund von ARP-Traffic (Broadcast) und Neighbor-Discovery-Traffic (Multicast) hatte. Diese Art Traffic kann das System nicht wie beispielsweise ACL-Regeln in speziell gefertigten Chips (sog. ASICs) verarbeiten, sondern muss dies in seiner CPU tun. Es handelt sich um eine vergleichsweise kleine 8-Core-CPU von Intel, in der jede Menge Informationen verarbeitet werden müssen.

Die hohe CPU-Last hat dazu geführt, dass der Router seine Kommunikation mit den Uplink-Systemen auf dem Campus-Ring verloren hat, denn das dazu benötigte Routingprotokoll OSPF („Open Shortest Path First“) wird in der CPU des Routers verarbeitet und benötigt zudem Multicast. Ohne Kommunikation mit den Uplink-Systemen weiß der Router nicht mehr wohin mit Daten, die das Datacenter verlassen sollen. Darüber hinaus ist der Router auch aus dem Rest des Campusnetzes (und der Welt) nicht mehr sichtbar und es kann auf Systeme hinter diesem Router nicht mehr zugegriffen werden. Das Datacenter war also abgeschnitten von der Aussenwelt und nur noch in sich selbst funktionsfähig.

Für diese Art Notfall haben wir Zugriff auf die relevanten Systeme im Datacenter über ein separat angebundenes Notfall-Managementsystem. Über dieses entfernten wir anfangs zunächst aus der Ferne die OSPF-Konfiguration und restaurierten sie von Hand. Dadurch wurde, wie sich später heraus stellte, ein Software-Bug ausgelöst, der dazu führen kann, dass die tatsächlich aktive Konfiguration des Routingsystems nicht mehr der eingestellten Konfiguration entspricht. Diese Art Software-Bug macht i.d.R. eine Neukonfiguration des Systems nötig (Reset auf Werkseinstellungen), was nur vor Ort ohne erhebliche Hürden gut klappt. Vor Ort im Datacenter gelang dies dann um kurz nach 19 Uhr, so dass ab ca. 19:20 Uhr die einzelnen Netze schrittweise wieder erreichbar wurden. Der eigentliche Auslöser für den Abbruch der Routing-Kommunikation fand sich während der Analyse der Situation in einem VLAN eines Datacenter-Nutzers, welches vorerst deaktiviert wurde. Hier war die Quelle des Broadcast- und Multicast-Sturms zu finden.

Die Cisco Catalyst 9500 Plattform setzt für die Redundanz auf das Prinzip des sogenannten Stackings (in diesem Fall vom Hersteller „Stackwise-Virtual“ genannt). Dabei werden zwei oder ggfs. mehr Systeme zu logisch einem einzigen System zusammen gefasst. Das bedeutet, dass es zwar redundante Hardware gibt, jedoch die Software auf beiden Geräten nicht unabhängig voneinander läuft sondern einem komplexen, immerwährenden Synchronisationsprozess unterliegt, bei dem Daten wie MAC-Adressen, IP-Adressen, Routing-Informationen, ACLs und vieles weitere zwischen den zusammen geschalteten Systemen innerhalb von Millisekunden ausgetauscht werden. Der Vorteil daran ist, dass man nur „ein System“ hat, was an einer einzigen Stelle konfiguriert werden muss. Auch beim Hardware-Ausfall vereinfacht das den Austauschprozess erheblich.

Es hat sich jedoch in der Vergangenheit inzwischen mehrfach heraus gestellt, dass das Prinzip des Stackings vor allem im Bereich der kritischeren Infrastruktur nicht optimal funktioniert. Aus diesem Grund verzichten wir u.a. auch in der neuen Infrastruktur im Gebäude ID komplett auf Stacking. Für unsere Routing-Plattform überlegen wir aktuell, ob und wie ein entsprechender Umbau zu einer Alternative ohne Stacking, hin zu unabhängig voneinander arbeitenden Systemen, sinnvoll ist.