Zusammenfassung

  • RIPE NCC führt den Ausfall der RRC12-Dateiproduktion am 2. Oktober auf ungewöhnlich viele BGP-Nachrichten eines DE-CIX-Peers, Last auf einer Kafka-Partition und einen wiederholt abbrechenden Rescan nach Neustarts zurück.
  • Auch Update-Dateien anderer Collector seien verspätet gewesen. Eine Konfigurationskorrektur brachte die Verarbeitung wieder in Gang; die strukturelle Behebung des latenten Fehlers stand noch aus.

Die entscheidende Information ist die gemeldete Reichweite. RIPE NCC berichtete nicht nur über fehlende Dateien des RRC12. Auch die Erstellung von Update-Dateien anderer Route Collector sei verzögert gewesen. Das ist ein Fehler bei der Erzeugung von Beobachtungsdaten über Routing. Der Statusbericht besagt nicht, dass die Paketweiterleitung im Internet ausgefallen wäre.

Der Vorfallseintrag datiert den Beginn des ungewöhnlich hohen BGP-Nachrichtenvolumens eines DE-CIX-Peers am RRC12 auf den 2. Oktober, 01:30 UTC. Der aus Kafka lesende Verarbeitungsschritt konnte nicht Schritt halten und lief in ein Timeout. Nach dem Neustart versuchte der Prozess, ein großes Datenvolumen erneut zu durchsuchen; wieder endete der Versuch, bevor er Fortschritt machte. RIPE NCC ergänzte später, dass eine fehlerhafte Konfiguration den Scan um eine Größenordnung länger als vorgesehen machte. Nach ihrer Korrektur kam die Verarbeitung wieder voran. Eine strukturelle Behebung des latenten Fehlers kündigte RIPE NCC für den nächsten Sprint an.

Die Erklärung beschreibt zwei Belastungen. Zunächst überstieg die eingehende Arbeit die Kapazität eines Verarbeitungspfads. Danach wiederholte der Neustart einen aufwendigen Scan, den die Konfiguration zusätzlich verlangsamte. So entstand aus einem Rückstand eine wenig wirksame Neustartschleife. Öffentlich genannt werden weder der Name des Peers noch Nachrichtenrate, Partitionstopologie, Queue-Tiefe, Timeout-Werte oder der konkrete Scan-Code. Der Ablauf lässt sich als Betreiberangabe wiedergeben, ohne diese Lücken mit Vermutungen zu füllen.

RIS sammelt BGP-Daten, damit sich Routing beobachten lässt. Die Dokumentation der Route Collector beschreibt sie als physische oder virtuelle Systeme, die Daten über Peer-Sitzungen empfangen, und führt RRC12 für Frankfurt und DE-CIX auf. Laut der MRT-Dokumentation werden Daten pro Collector gespeichert: Dumps bilden den Routingzustand zu einem Zeitpunkt ab; Update-Dateien halten Änderungen über ein Intervall fest. RIPE nennt als regelmäßigen Takt acht Stunden für Dumps und fünf Minuten für Updates. Dieser Takt beschreibt den Normalbetrieb, nicht die Vollständigkeit oder rechtzeitige Nutzbarkeit jeder Datei während des Vorfalls.

Um 09:42 CEST am 2. Oktober nannte die Statusseite für die jüngste verfügbare RRC12-Update-Datei den Zeitstempel 01:00 UTC und für das jüngste bview 00:00 UTC. Das ist ein Stand der Archivfrische zu einem Meldezeitpunkt. Er bestimmt weder den exakten Beginn des Produktionsstopps noch die maximale Größe des Rückstands. Später erklärte RIPE NCC, dass nach der Erholung des ursprünglichen Prozesses die bview- und Update-Dateien seit dem 2. Oktober veröffentlicht worden seien. Das belegt die gemeldete Nachlieferung, aber weder eine Prüfung jedes einzelnen Bytes noch die Auswirkungen auf Nutzer.

Eine Route im Netz ist nicht dasselbe wie ihre archivierte Beobachtung. RFC 6396 legt das MRT-Format für den Export von Routing-Informationen fest. Eine verspätete MRT-Datei schränkt ein, was Analysten aus dem Archiv zu diesem Zeitpunkt erkennen können. Allein daraus folgt weder ein Abbruch einer BGP-Sitzung noch ein Rückzug einer aktiven Route oder ein Verbindungsverlust bei einem Kunden. Trotzdem können solche Dateien für Betreiber, Forschung und Incident Response wichtig sein, wenn sie Ereignisabläufe rekonstruieren. RIPE NCC hat eine nachgelagerte Wirkung nicht quantifiziert; eine solche sollte nicht unterstellt werden.

Die Verzögerung über andere Collector hinweg lenkt den Blick auf Fehlerisolation. Der Anstieg kam am RRC12 an; laut RIPE NCC belastete er eine einzelne Kafka-Partition und verzögerte zugleich Update-Dateien anderer RRCs. Das deutet auf eine gemeinsam genutzte Verarbeitungskomponente hin, veröffentlicht aber weder einen vollständigen Architekturplan noch den Nachweis, wie jede Nachricht verteilt wurde. Belastbar ist nur die enge Aussage des Betreibers: Der Effekt blieb nicht am Eingangs-Collector. Deshalb sind Freshness-Messungen über mehrere Collector und Grenzen gegen eine Ausbreitung relevant.

Der vor dem Ereignis veröffentlichte Plan liefert Kontext, keine Kausalerklärung. Der Q4-2026-Plan für RIS, zuletzt am 17. September aktualisiert, führte Verbesserungen an der Überwachung der RIS/RIPEstat-Datenverarbeitung bereits als laufende, auf Q4 begrenzte Arbeit auf. Auch der Austausch der Kafka-Maschinen und ein Upgrade auf eine neue Version waren als laufend vermerkt; laut Plan war dieser Schritt wegen begrenzter Ressourcen zuvor verschoben worden. Eine Untersuchung alternativer Speicherarchitekturen zur Verringerung der HBase-Abhängigkeit lief ebenfalls. Die Seite verbindet diese Vorhaben weder mit dem Vorfall noch mit der Wiederherstellung.

Der Plan nennt zudem einen überarbeiteten Peering-Ansatz: Die Auswahl soll relevant und vielfältig bleiben, während das Datenwachstum tragbar bleibt. Mehr Beobachtungsquellen können das Archiv wertvoller machen, erhöhen aber die Verarbeitungslast. Nichts an diesem Vorfall zeigt, dass der Peer unnötig war, sich falsch verhalten hat oder für das Design des Verarbeitungspfads verantwortlich wäre. Die operative Aufgabe ist, nützliche Eingaben beizubehalten und zugleich deren Kosten sichtbar zu machen und die übrigen Collector-Ausgaben zu schützen.

Ein belastbarer Wiederherstellungsnachweis sollte benennen, welche Dateien verspätet waren, welches Intervall sie abdecken sollten, wann die Veröffentlichung wieder anlief, ob der Rückstand lückenlos und ohne Duplikate nachgeliefert wurde und wie dies geprüft wurde. Ein Kapazitätstest sollte das erprobte Eingangsvolumen, die maximale Verarbeitungsverzögerung, das Verhalten eines Neustarts mit Rückstand sowie die Schwelle dokumentieren, ab der ein anderer Collector betroffen ist. Dann würde „behoben“ beschreiben, welche Beobachtungsdaten zurückgekehrt sind und welche strukturelle Verwundbarkeit bleibt.

Heng Lus Note 70 über den Unterschied zwischen technischer Fähigkeit und praktischer Wirklichkeit dient nur als redaktionelle Perspektive: Ein technisches Signal erlaubt nicht jede Schlussfolgerung über seine Folgen. Sie ist keine technische Quelle zum RIPE-Vorfall. Fakten und Projektstatus stammen aus RIPE NCCs eigenen Seiten; die vorgeschlagenen Zuverlässigkeitskontrollen sind Analyse.

RIPE NCC markierte den Vorfall am 6. Oktober als behoben. Die Konfigurationskorrektur, die den Prozess wieder in Gang brachte, und die angekündigte strukturelle Behebung des latenten Fehlers sind unterschiedliche Meilensteine. Das eine stellte die unmittelbare Verarbeitung wieder her; das andere muss mit Last- und Neustarttests zeigen, dass ein künftiger Eingangsanstieg die Schleife weniger leicht auslöst. Der öffentliche Bericht trägt diese Unterscheidung, enthält aber noch kein Testergebnis.

Quellen