Zusammenfassung

  • RIPE NCC trennte in seinem Hinweis vom 20. Oktober die Aktualität der RIPEstat-Endpunkte und erklärte, die Looking-Glass-Metadaten zeigten die größte Verzögerung unter den vorhandenen Daten.
  • Eine Abfrage um 18:04:43 UTC lieferte als jüngsten Datenzeitpunkt 12:13:37 UTC. Das ist eine einzelne Momentaufnahme zu einer Ressource, keine Aussage über alle Peers, Ressourcen oder APIs.

Eine fünf Stunden alte Routenbeobachtung kann einen Trend erklären und für eine automatische Aktion trotzdem zu alt sein. Eine erfolgreiche Antwort ist deshalb kein Beleg für aktuelle Daten: Die Abfrage kann neu sein, die Beobachtungen darin nicht. RIPE NCC meldete am 20. Oktober unterschiedliche Verzögerungen je nach RIPEstat-Endpunkt; eine Looking-Glass-Antwort macht den Unterschied zwischen den beiden Zeitpunkten sichtbar.

Der Unterschied ist wichtig, weil RIPEstat zugleich eine öffentliche Datenschnittstelle und die Datenquelle seiner Widgets und Benutzeroberfläche ist. Die API ist keine einzige Tabelle mit einem gemeinsamen Aktualisierungsplan. Jeder Endpunkt beantwortet eine andere Frage. In der Dokumentation nennt RIPE NCC mehrere Faktoren für die Aktualität: Erfassungsfrequenz, übliche Aktualisierung des Datenspeichers, Verzögerung bei der Verarbeitung, den normalen Betrieb von Erfassung und Verarbeitung sowie Zwischenspeicherung. Eine erfolgreiche Antwort zeigt, dass eine Anfrage beantwortet wurde.

Sie zeigt nicht automatisch, wann jede zugrunde liegende Beobachtung erfasst wurde.

Der Hinweis beschreibt keine gemeinsame RIPEstat-Uhr. Für Looking Glass sollten die Daten der Mehrheit – mehr als 90 Prozent – der Peers aktuell sein. Zugleich zeigen die Metadaten die größte Verzögerung innerhalb der vorhandenen Daten. Das passt zusammen: Der überwiegende Teil kann aktuell sein, während ein kleinerer Anteil zurückliegt. Der Maximalwert macht diesen Rand sichtbar, ohne jeder Zeile dasselbe Alter zuzuschreiben. RIPE NCC veröffentlichte weder eine einheitliche Aktualitätsgarantie noch einen allgemeingültigen Grenzwert dafür, wann jeder Peer als aktuell gilt.

Eine Abfrage kann gerade abgeschlossen sein und dennoch ältere Beobachtungen enthalten. In Überwachungsanzeigen verschwimmt dieser Unterschied leicht, wenn sie nur eine erfolgreiche Antwort, den jüngsten Abfragezeitpunkt oder einen einzigen Gesamtstatus zeigen. Am 20. Oktober benannte RIPE NCC zwei getrennte Dinge: Einige RIPEstat-Daten waren wegen eines Problems beim Routing Information Service (RIS) verzögert; wie stark, hing vom jeweiligen API-Endpunkt ab.

Die Looking-Glass-Dokumentation beschreibt den RIS-Datenstrom im Normalbetrieb als nahezu in Echtzeit, mit einer kleinen Verzögerung. Sie unterscheidet aber zwei Zeitangaben pro Route: wann sich die Route zuletzt geändert hat und wann sie zuletzt bestätigt wurde. Das ist nicht dasselbe. Außerdem lässt sich ein Rückblickszeitraum festlegen; standardmäßig werden Einträge ausgeschlossen, die älter als 24 Stunden sind. Eine fehlende Zeile ist deshalb nicht ohne Weiteres ein Beleg dafür, dass die Route nicht existierte. Zuerst müssen Filter und Beobachtungsfenster bekannt sein.

Der vorgelagerte RIS-Vorfall ordnet die Verzögerung dem Datenweg zu; er ist kein Bericht über einen Routing-Ausfall. RIPE NCC nannte in einem separaten Hinweis ein Problem beim Kopieren von BVIEW-Dateien aus dem Speichersystem sowie eine verzögerte Verarbeitung von Nachrichten, die RRC25 gesammelt hatte. Zum Zeitpunkt des Updates würden die neuesten BVIEW-Dateien mit Ausnahme von RRC25 veröffentlicht; auch RIS-Update-Dateien seien verspätet. Der RIPEstat-Hinweis verwies auf diesen Vorfall und warnte vor unterschiedlichen Auswirkungen je Endpunkt.

Keiner der beiden Hinweise behauptet, Routen seien aus dem Internet verschwunden oder Kunden hätten ihre Erreichbarkeit verloren.

Die praktische Maßnahme ist einfach: den Datenzeitpunkt neben dem Abfragezeitpunkt speichern. Wer eine Entscheidung auf RIPEstat stützt, sollte Endpunkt, Ressource, Abfragezeit, jüngsten Datenzeitpunkt, Cache-Status und den Umfang der Antwort festhalten. Danach wird das Alter der Daten mit der tatsächlichen Toleranz der Entscheidung verglichen. Eine fünf Stunden alte Beobachtung kann für einen historischen Trend ausreichen und für eine automatisierte Aktion zu alt sein. Der passende Grenzwert ergibt sich aus dem Einsatzzweck, nicht aus einer allgemeinen Ampelfarbe.

Der Hinweis von RIPE NCC ist gerade deshalb hilfreich, weil er den Vorfall nicht auf eine Zahl verkürzt. Die Angabe „mehr als 90 Prozent“ gibt eine Orientierung für den Dienst; die Metadaten zeigen die größte Verzögerung. Die Frage lautet nicht, ob der Hinweis wahr oder falsch ist. Entscheidend ist, ob der konkrete Endpunkt und das Beobachtungsfenster die anstehende Entscheidung tragen. Wer diese Prüfungen trennt, kann die Daten nutzen, ohne ihnen mehr Beweiskraft zuzuschreiben, als sie haben. Primärquellen: RIPEstat-Vorfall bei RIPE NCC, RIS-Vorfall bei RIPE NCC, RIPEstat-Data-API-Dokumentation, Dokumentation des Looking-Glass-Endpunkts, Was ist RIPEstat?, zeitgestempelte Looking-Glass-API-Antwort und RIS-Collector-Dokumentation.