Zusammenfassung

  • RIPE NCC erklärte, ein DE-CIX-Peer habe am 2. Oktober um 01:30 UTC begonnen, ungewöhnlich viele BGP-Nachrichten an den Route Collector RRC12 zu senden; danach seien die Timeouts des Kafka-verarbeitenden Update-Prozesses wiederholt aufgetreten.
  • Bei einer Prüfung um 19:10 UTC desselben Tages enthielt das öffentliche RRC12-Archiv keine Update-Datei nach 01:00 UTC. Das ist eine verzögerte Veröffentlichung in einem Messdienst, kein Beleg für fehlende Internet-Routen oder unterbrochenen Datenverkehr.

Analyse

RIPE NCC eröffnete am 2. Oktober um 09:42 CEST den Statusvorfall „RRC12 MRT update files are not produced“. In der ersten Meldung hieß es, die jüngste Update-Datei von RRC12 trage den Zeitstempel 01:00 UTC; der letzte BVIEW-Snapshot stamme von 00:00 UTC. Um 13:26 CEST teilte die Organisation mit, ein DE-CIX-Peer sende seit 01:30 UTC ungewöhnlich viele BGP-Nachrichten an RRC12. Der Prozess, der Updates aus Kafka konsumiert, sei mit diesem Volumen nicht mitgekommen. Nach einem Neustart sei er erneut in einen Timeout gelaufen, bevor er ausreichend Fortschritt erzielen konnte.

RIPE meldete außerdem Verzögerungen bei der Erstellung von Update-Dateien anderer RRCs.

RRC12 ist ein Route Collector in Frankfurt am DE-CIX. Route Collector empfangen BGP-Daten von Peers; sie wählen nicht die von diesen Netzen verwendeten Routen aus. Laut RIPE-Dokumentation werden die erfassten Daten je Collector gespeichert: „Update“-Dateien halten Änderungen innerhalb eines Intervalls fest, BVIEW-Dateien einen Zustands-Snapshot. Update-Dateien entstehen demnach normalerweise alle fünf Minuten. Das ist der übliche Veröffentlichungsrhythmus eines Beobachtungsstroms, keine Garantie, dass jeder Collector ihn stets einhält.

Eine schreibgeschützte Prüfung des öffentlichen RIPE-Archivs um 19:10 UTC fand keine RRC12-Update-Datei nach updates.20261002.0100.gz – 18 Stunden und zehn Minuten vor der Prüfung. Das RRC18-Archiv reichte bis 19:05 UTC. Der Vergleich zeigt den sichtbaren Aktualitätsunterschied zwischen diesen beiden Verzeichnissen zu diesem Zeitpunkt. Er belegt weder, dass alle anderen Collector unbeeinträchtigt waren, noch welche zuvor Verzögerungen hatten oder weshalb RRC18 neuere Dateien aufwies.

Zum Prüfzeitpunkt war der Vorfall weiterhin als „identified“ geführt und wurde untersucht. Die Statusmeldung nannte weder den Peer oder seine ASN noch Nachrichtenrate, betroffene Routen, Dauer der Verzögerungen bei anderen Collectors, Replay-Status der Warteschlange oder Wiederherstellungsplan. Sie sagte auch nicht, dass Routen verloren gingen oder der Datenverkehr beeinträchtigt wurde. Bei einer verzögerten Datei muss vor der Interpretation eines leeren Zeitraums der Zeitstempel geprüft werden; daraus folgt nicht, dass es keine BGP-Änderungen gab.

Eine hilfreiche nächste Meldung wäre ein knapper Wiederherstellungsnachweis: die neuesten Update- und BVIEW-Zeitstempel der betroffenen Collector, ob verzögerte Intervalle nachgeliefert wurden und wann die reguläre Veröffentlichung wieder anlief. RIS-Nutzer könnten so Erfassung, Verarbeitung und Veröffentlichung unterscheiden, ohne eine Archivverzögerung mit einer Änderung des Routing-Systems gleichzusetzen.

Quellen