Zusammenfassung

  • Ein ungewöhnlich hohes BGP-Nachrichtenvolumen belastete laut RIPE NCC eine einzelne Kafka-Partition. Nach einem Neustart löste ein latenter Fehler wiederholt große Rescans und Timeouts aus.
  • Eine Konfigurationskorrektur ermöglichte die Wiederherstellung; RIPE NCC zufolge wurden BVIEW- und Update-Dateien seit dem 2. Oktober erfolgreich erzeugt. Die strukturelle Behebung des Neustartfehlers war weiterhin für einen späteren Sprint vorgesehen.
  • Wiederhergestellte öffentliche Dateien belegen nicht, dass der Fehlerpfad beseitigt ist. Der Vorfall betraf die Erzeugung von RIPE-RIS-Daten, nicht nachweislich Routen oder Kundenverkehr.

Das Archiv war wieder da, bevor die Reparatur abgeschlossen war

RIPE NCC schloss am 6. Oktober den Vorfall zu den MRT-Updates und BVIEW-Dateien von RRC12. Die Abschlussmeldung enthält zwei getrennte Aussagen: Nach der Erholung des Prozesses seien die Dateien seit dem 2. Oktober erfolgreich erstellt worden. Die unmittelbare Wiederherstellung folgte auf eine Konfigurationskorrektur. Eine strukturelle Behebung des latenten Fehlers sollte dagegen im nächsten Sprint bearbeitet werden.

Das sind unterschiedliche Betriebszustände. Das öffentliche Archiv wurde ergänzt; der Mechanismus, der den Prozess nach einem Neustart wiederholt scheitern ließ, war noch nicht als strukturell geändert beschrieben. Ein Dienst kann wieder laufen, während eine Engineering-Aufgabe offenbleibt. Wer den ersten Sachverhalt als Beleg für den zweiten liest, legt der Statusmeldung mehr in den Mund, als sie sagt.

Nach Angaben von RIPE NCC begann die Kette am 2. Oktober um 01:30 UTC, als ein DE-CIX-Peer ungewöhnlich viele BGP-Nachrichten an RRC12 sendete. Die Kafka konsumierende Verarbeitung kam mit dem Volumen nicht mit. Ein Prozess lief in ein Timeout; nach dem Neustart wiederholte sich das Timeout, bevor ausreichender Fortschritt erzielt war. RIPE NCC beobachtete anschließend Verzögerungen bei der Erzeugung von Update-Dateien anderer RRCs.

Die spätere Erklärung ergänzte den Verstärker: Das Volumen belastete eine einzelne Kafka-Partition. Beim Neustart ließ ein latenter Fehler eine große Datenmenge erneut scannen. Der Scan lief wiederholt in Timeouts und verhinderte Fortschritt. Eine Konfigurationsfehlanpassung machte ihn um eine Größenordnung länger als vorgesehen. Nach Korrektur der Konfiguration erholte sich der Prozess; die strukturelle Änderung stand noch bevor.

Was die Dateien abbilden

RRC12 ist der RIPE-Routenkollektor am DE-CIX in Frankfurt. RIPE unterscheidet in seiner Dokumentation zwei öffentliche Artefakte: Eine BVIEW-Datei ist eine Momentaufnahme des Routingzustands; eine Update-Datei hält Änderungen über ein Zeitintervall fest. Üblicherweise entstehen Dumps alle acht Stunden und Updates alle fünf Minuten. RIPE beschreibt MRT-Dateien als nützlich für BGP-Fehlersuche, Post-Mortems und langfristige Trends.

Eine Publikationslücke erschwert damit die Rekonstruktion eines Zeitraums aus öffentlichen Daten. Sie ist aber nicht gleichbedeutend mit einem Routingausfall. Die Incident-Angaben belegen verspätete Dateierzeugung, nicht fehlende Routen, unterbrochenen Verkehr, eine böswillige Absicht des Peers oder einen Kundenschaden. Sie nennen weder den Peer noch Nachrichtenrate, Queue-Tiefe, Dauer der Verzögerungen pro weiterem Kollektor oder Zahl betroffener Analysen.

Der Oktober-Index listet inzwischen BVIEW- und Update-Dateinamen bis zum 7. Oktober. Das ist ein sinnvoller aktueller Nachweis, dass spätere Artefakte im öffentlichen Verzeichnis stehen. Es beweist nicht, dass jede Datei vollständig ist, dass die neu erzeugten Daten eine unabhängige Integritätsprüfung bestanden haben oder dass nachgelagerte Analysen dasselbe Ergebnis erhalten hätten wie mit einem ununterbrochenen Live-Stream.

Wiederherstellung hat mehr als eine Ziellinie

Der Vorfall sollte nicht in einem einzigen grünen Status verschwinden. Zunächst blockierte das Eingangsvolumen die Verarbeitung nicht mehr. Dann konnte der neu gestartete Prozess Fortschritt machen. Anschließend wurden fehlende Dateien erzeugt. Separat blieb der fehlerhafte Startpfad als strukturelle Aufgabe bestehen. Das sind verschiedene betriebliche Aussagen.

Bei einem Messdienst beantwortet ein wiederhergestelltes Archiv die Frage: „Werden Dateien wieder erzeugt?“ Es beantwortet nicht vollständig: „Ist die Bedingung beseitigt, die das Aufholen fragil machte?“ oder „Wurde die rekonstruierte Serie auf Vollständigkeit geprüft?“ Die öffentliche Aktualisierung beantwortet die erste Frage und kündigt Arbeit für die zweite an. Einen unabhängigen Vollständigkeitsnachweis für die dritte veröffentlicht sie nicht.

Das beweist nicht, dass die Wiederherstellung unzureichend war. Die öffentliche Meldung ist lediglich enger als ein vollständiger Post-Incident-Bericht. Sie nennt Auslöser, Einzellast auf einer Partition, Neustart-Rescan, Konfigurationskorrektur und geplante strukturelle Arbeit. Nicht veröffentlicht werden Peer-Identität, Raten, Queue-Messungen, Verzögerungsfenster je Kollektor, Validierungsmethode oder Versionskennung.

Für Nutzer eines öffentlichen Messarchivs würde ein nützlicher Abschluss diese Punkte verbinden, ohne sensible Implementierungsdetails offenzulegen: betroffene Kollektoren und Zeiträume, ob Dateien neu erzeugt wurden, welche Validierung stattfand, welche Sofortmaßnahme gilt, welche strukturelle Änderung aussteht und wann sie überprüft wurde. Ein datierter Verlauf würde spätere Leser zwischen wiederhergestellter Verfügbarkeit und abgeschlossener Zuverlässigkeitskorrektur unterscheiden lassen.

Die vorsichtige Schlussfolgerung ist begrenzt. Die RRC12-Dateien wurden wiederhergestellt, nachdem eine Lastspitze eine Neustartschwäche offengelegt und die Konfiguration sie verstärkt hatte. RIPE NCC zufolge stand die strukturelle Behebung noch aus. Das Archiv ist nicht das gesamte Internet-Routing, und die Dateipublikation belegt keinen Routingausfall. Doch der Unterschied zwischen „Dateien sind wieder da“ und „der Wiederherstellungspfad ist behoben“ sollte für einen Messdienst sichtbar sein.

Quellen