Zusammenfassung

  • PeeringDB nennt für Version 2.84.0 den 21. Oktober als Veröffentlichungsdatum und führt die Korrektur von Löschungen auf, die ?since=-Nutzer nicht erhielten. Der ursprüngliche Fehlerbericht beschreibt hart gelöschte netixlan-Datensätze und Netzobjekte, deren Status zwar auf deleted sprang, deren updated-Zeit aber stehen blieb.
  • Der am 20. Oktober übernommene Patch entfernt die direkte Massenlöschung und testet, ob eine API-Anfrage gelöschte Datensätze als Änderung liefert. Bereits auseinanderlaufende Kopien brauchen laut Fehlerbericht einen vollständigen Neuabgleich. Eine veröffentlichte Zahl der erfolgreich bereinigten Kopien fehlt.

Die Verbindung im zweiten Verzeichnis

Ein Betreiber, der Peering-Kontakte plant, kann PeeringDB direkt abfragen oder auf einen lokalen Spiegel zugreifen. Beides sollte denselben öffentlichen Bestand beschreiben. Im dokumentierten Fall zeigt die Quelle die Verbindung eines Netzes zu einem Austausch-LAN nicht mehr, während die lokale Kopie sie weiter führt. Der Verzeichniseintrag ist kein Nachweis für eine laufende BGP-Sitzung. Er ist aber handlungsfähig genug, um Anfragen, Inventare und Prüfungen in Gang zu setzen. Genau deshalb ist ein veralteter Eintrag mehr als ein kosmetischer Fehler.

Die PeeringDB-API-Spezifikation erklärt den Parameter ?since=: Ein Client fragt Objekte ab, die seit einem Unix-Zeitpunkt geändert wurden. Gelöschte Objekte lassen sich mit status=deleted und positivem since abrufen. Nach der offiziellen FAQ beginnt peeringdb-py mit einem vollständigen Bestand und übernimmt anschließend Änderungen. Ein Spiegel spart damit Abfragen und Bandbreite. Die Quelle schuldet ihm im Gegenzug einen vollständigen Änderungsbegriff. Dazu gehört das Verschwinden einer Zeile genauso wie ihr Erscheinen.

Am 7. Oktober meldete Remco van Mook PeeringDB-Fehler #2057, nachdem er eine mit ?since= gepflegte Kopie mit vollständigen API-Listen verglichen hatte. Der erste Ausfall lag in der periodischen Bereinigung anhand des RIR-Status eines Netzes. Bevor das Netz gelöscht wurde, löschte das Programm sämtliche aktiven netixlan-Zeilen per Sammelbefehl. Diese Zeilen verbinden ein Netz mit dem LAN eines Internetknotens. Der Sammelbefehl umging die Modellmethode, die eine Zeile auf deleted setzt und ihren Zeitstempel aktualisiert. Die Quelle hatte keine Zeile mehr; der nächste Delta-Aufruf hatte keine Löschmeldung.

Ein zweiter Fehler traf Netzobjekte selbst. Sie konnten den Status deleted erhalten, während updated den alten Zeitpunkt behielt. Die im Bericht genannten Beispiele verbinden Löschungen aus 2026 mit Zeitstempeln aus 2022. Wer Änderungen seit dem letzten Lauf im Jahr 2026 anfordert, bekommt eine vermeintlich vier Jahre alte Zustandsänderung nicht geliefert. Der Client erfüllt die dokumentierte Anfrage korrekt und trägt dennoch einen falschen Bestand weiter.

Was die Stichprobe trägt

Der Meldende fand in rund sechs Monaten Vergleichsdaten 286 direkt gelöschte netixlan-Zeilen aus 125 Netzen und 46 Netzlöschungen ohne neuen updated-Wert. Das sind Zählungen seines Abgleichs, keine Gesamtzahl betroffener PeeringDB-Nutzer. Die konkreten IDs, Zeiten und API-Beispiele machen den Fehler reproduzierbar. Sie erlauben keine Aussage darüber, wie viele Peering-Entscheidungen getroffen oder Sitzungen verändert wurden.

In einem Kommentar vom 9. Oktober tauchte eine umgekehrte Abweichung auf: 569 an der Quelle aktive netixlan-Zeilen fehlten im Spiegel, verteilt auf 349 Netze und 279 Internetknoten. Als mögliche Ursache nannte der Meldende eine lange Transaktion, deren Daten nach dem abgefragten Zeitfenster sichtbar wurden, oder eine Wiederherstellung ohne aktualisierten Zeitstempel. Der Kommentar entscheidet zwischen beiden nicht. Der Patch für die Löschroute darf deshalb nicht als Lösung für diese andere zeitliche Lücke ausgegeben werden.

PeeringDB übernahm am 20. Oktober Commit 81ac767. Er entfernt die explizite Sammellöschung der Verbindungszeilen und lässt die Löschmethode des Netzes ihre abhängigen Objekte behandeln. Ein neuer Test legt Netz, Austausch-LAN, Verbindung und technischen Kontakt an, führt die RIR-Bereinigung aus und verlangt anschließend deleted-Status und neue Zeitstempel. Vor allem fragt er /api/netixlan?since=... ab und erwartet die gelöschten Verbindungen in der Antwort. Die Prüfung endet dort, wo der Spiegel seine Wahrheit bezieht: an der öffentlichen Schnittstelle.

Die Release Notes datieren 2.84.0 auf den 21. Oktober und ordnen #2057 den Korrekturen für synchronisierende Nutzer zu. In der Planungstabelle steht noch der 20. Oktober als Produktionsziel. Merge, Ziel und veröffentlichter Releasetag sind unterschiedliche Belege. Der Patch belegt die neue Behandlung im getesteten Pfad; er hat keine bereits abgelegten lokalen Datensätze der Nutzer nachträglich geöffnet.

Ein Patch ist kein Rückruf

Eine früher hart entfernte Zeile kann aus der Quelldatenbank keine verspätete Löschmeldung mehr senden. Ein Objekt mit updated von 2022 passiert auch keinen Cursor von 2026. Der Fehlerbericht nennt einen vollständigen Neuabgleich als clientseitige Reparatur. PeeringDB veröffentlichte keine Bilanz darüber, wie viele Spiegel diesen Schritt getan haben. Eine solche Bilanz würde zeigen, welcher Anteil alter Einträge trotz des Quellpatches noch herumliegt.

Der Neuabgleich kostet gerade die Last, die inkrementelle Synchronisierung vermeiden sollte. PeeringDB kontrolliert den Quellzustand, die Löschroutine und den API-Vertrag. Jeder lokale Betreiber kontrolliert den Spiegel und die Entscheidung, wann er ihn neu aufbaut. Zwischen beiden liegt die praktische Autorität des Datensatzes. Eine erfolgreiche Polling-Aufgabe bescheinigt nur, dass eine Antwort kam. Sie bescheinigt nicht, dass alles, was verschwunden ist, auch aus dem Spiegel verschwand.

Im Entwurf für API v3 verlangt PeeringDB, Löschungen und Rücknahmen im Delta sichtbar zu machen; tägliche Snapshots sollen Ausgangspunkt und Rückfallweg bieten. Der Entwurf ist noch in Konsultation. Als Prüfstein für die nächste Schnittstelle ist er dennoch konkret: Hat jede Rücknahme eine beobachtbare Version? Kann der Verbraucher feststellen, welchen öffentlichen Datenstand er hält? Ein Server kann jeden Request beantworten und trotzdem eine entscheidende Zustandsänderung auslassen.

Aus einer kurzen Sammellöschung wurde ein langer Schatten in fremden Kopien. 2.84.0 schließt die gefundene Lücke für künftige Vorgänge. Die alte Abweichung endet erst beim Vergleich jedes betroffenen Spiegels mit der Quelle.