Zusammenfassung

  • Ein Nutzer des RIPE NCC-Forums meldete leere Looking-Glass-Antworten für einzelne IP-Adressen, während die zugehörigen Präfixe Daten lieferten.
  • Bei vier Abfragen am 3. September lieferten beide Schreibweisen der beiden Beispiele Daten. Das Symptom ließ sich nicht reproduzieren; eine dauerhafte Behebung ist damit nicht nachgewiesen.
  • Eine IP-Abfrage muss zunächst ein passendes geroutetes Präfix ermitteln. Dieser Schritt ist von der Beobachtung einer Route und der tatsächlichen Erreichbarkeit zu unterscheiden.

Ein leerer Bildschirm ist schnell beschrieben. Was ihm fehlt, ist oft die eindeutige Bedeutung. Bei RIPEstat kann eine Suche nach einer IP-Adresse einen anderen Verarbeitungsschritt enthalten als die Suche nach dem Präfix, in dem diese Adresse liegt. Ein kürzlich gemeldeter Unterschied zwischen beiden Eingaben macht diese Trennung sichtbar.

Am 2. September berichtete ein Nutzer, 14.137.164.1 liefere im Looking Glass keine Daten, 14.137.164.0/24 dagegen schon. Unsere Prüfung am Folgetag ergab für beide Eingaben Daten. Auch ein früheres Beispiel aus derselben Diskussion funktionierte in beiden Varianten.

Damit ist weder ein gegenwärtig reproduzierbarer Fehler noch eine abgeschlossene Reparatur belegt. Festgehalten werden können ein datierter Nutzerbericht und vier spätere erfolgreiche Versuche. Die Erklärung für den früheren Unterschied bleibt offen.

Vor der Routenabfrage liegt eine Zuordnung

Die Dokumentation des Endpunkts unterscheidet die Eingaben ausdrücklich. Ein angegebenes Präfix muss genau mit einem gerouteten Präfix übereinstimmen. Bei einer IP-Adresse versucht der Dienst zunächst, das umfassende geroutete Präfix zu finden. Einträge jenseits der gewählten Rückblickgrenze werden ausgeschlossen; standardmäßig beträgt diese 86.400 Sekunden.

Für den Nutzer ist die Zuordnung bequem. Er braucht die tatsächlich angekündigte Netzgröße nicht zu kennen. Technisch hängt die Antwort nun aber auch davon ab, ob das Suchobjekt richtig ermittelt wird. Ein Problem an dieser Stelle könnte das Ergebnis verändern, ohne dass ein Router eine Ankündigung zurückzieht. Das beschreibt eine Abhängigkeit, nicht die bereits festgestellte Ursache dieses Vorfalls.

Ein pauschales Anhängen von /24 wäre deshalb kein belastbarer Ausweg. Die betreffende Adresse kann zu einem anders großen angekündigten Präfix gehören. Für eine sinnvolle Gegenprobe braucht es ein Präfix, dessen Auftreten im Routing bereits belegt ist. Eine beliebig gewählte Maske stellt lediglich eine andere Frage.

Ein Bericht ist noch keine Fehlerstatistik

Die öffentliche Diskussion begann am 24. August mit 159.138.184.0 und 159.138.184.0/24. Am 25. August erläuterte ties, ein öffentlich als RIPE NCC-Mitarbeiter gekennzeichnetes Konto, die Suche nach dem spezifischsten Präfix. Das Verhalten erscheine vorübergehend; die Behandlung fehlgeschlagener Suchvorgänge solle mit einem Kollegen geprüft werden.

Am 2. September schrieb derselbe Nutzer, moonteach, das frühere Beispiel funktioniere inzwischen, lieferte aber den neuen Vergleich. Die beiden im Beitrag angegebenen Abfragezeiten liegen 27 Sekunden auseinander. Es handelt sich weder um eine zeitgleiche Messung noch um mehrere unabhängige Meldungen. Eine bestätigte Ursache oder abgeschlossene Korrektur geht aus dem Austausch nicht hervor.

Unsere vier Anfragen liefen am 3. September nacheinander von 04:13:08.929 bis 04:13:10.945 UTC. Alle antworteten mit HTTP 200, Status ok und gefüllten Daten. Beide IP-Antworten meldeten ausdrücklich die Umwandlung in das entsprechende /24; auch die wirksamen Ressourcenparameter nannten dieses Präfix.

Eingabe Kollektor-Einträge Peer-Zeilen
159.138.184.0 23 343
159.138.184.0/24 23 343
14.137.164.1 23 325
14.137.164.0/24 23 325

Gezählt wurden Einträge der gesicherten Antworten, nicht unterschiedliche Netzbetreiber oder der gesamte RIS-Bestand. Bei der zweiten Paarung unterschieden sich die latest_time-Werte um 20 Sekunden. Gleiche Zeilenzahlen belegen somit keine identischen Datenstände. Die verlinkten Abfragen liefern aktuelle Antworten und sind keine unveränderlichen historischen Ansichten.

Die Nachprüfung ist gerade durch ihre Begrenzung nützlich. In diesen Versuchen trat der Unterschied nicht auf. Daraus lässt sich weder eine Verfügbarkeitsquote ableiten noch der frühere Serverzustand rekonstruieren. Auch welche Änderung gegebenenfalls zwischen den Beobachtungen lag, bleibt unbekannt.

Die Antwort beschreibt nicht die gesamte Verbindung

Die Data API trennt Status, Meldungen, Version und Cache-Angaben. Eine erfolgreich übermittelte Antwort sagt nicht automatisch, ob eine Adresse erreichbar ist. Umgekehrt beweist ein leeres Datenfeld allein keinen Rückzug einer Route.

RIS sammelt BGP-Beobachtungen über freiwillig bereitgestellte Peer-Sitzungen. Das ist keine Ende-zu-Ende-Prüfung der Paketweiterleitung. Exportierende Peers, Beobachtungspunkte, Zeitgrenzen und die Interpretation der Eingabe liegen zwischen dem laufenden Netz und der Schlussfolgerung des Betrachters.

Für einen Kundenausfall, Verkehrsverlust oder eine Routenübernahme liefert dieser Fall keinen Nachweis. Sein praktischer Wert liegt in der vorgelagerten Frage: Welches geroutete Präfix wurde tatsächlich abgefragt? Solange das offen ist, bleibt ein leeres Ergebnis ein Untersuchungsanlass und keine Entscheidung über den Zustand des Netzes.