Zusammenfassung

  • LACNICs Studie vom 27. Mai 2026 spricht von allen Updates des März 2026 aus RRC15 und RRC24 und unmittelbar danach von mehr als 2,222 Milliarden BGP-Nachrichten, die über einen Zeitraum von 48 Stunden konsolidiert wurden.
  • Die Stabilitätstabelle nennt 2.222.981.835 Nachrichten. Die IPv4/IPv6-Tabelle nennt 159.964.848 und 693.016.987 Updates: zusammen 852.981.835 und damit exakt 1.370.000.000 weniger.
  • Die Präfixzahlen beider Familien ergeben dagegen genau 1.436.539; auch die vier ASN-Kategorien ergeben genau 86.398. Die offene Differenz kann eine andere Einheit, Auswahl oder Verarbeitungsstufe abbilden und beweist keinen Fehler.
  • Ein versionierter Abstimmungsbeleg sollte Beobachtungs- und Rechenzeit, Collector-Peers, MRT-Dateien, Softwarestände, Zählregeln, Zwischenstände und Korrekturen verbinden, ohne zwei Messpunkte zu einer regionalen Vollerhebung zu erklären.

Zwei Summen stimmen, die dritte braucht eine Legende

Die LACNIC-Veröffentlichung über „Noisy BGP Speakers“ ordnet autonome Systeme nach ihrer churn rate in vier Klassen ein. Ihre ersten arithmetischen Übergänge sind vorbildlich einfach. 1.146.937 IPv4-Präfixe plus 289.602 IPv6-Präfixe ergeben 1.436.539, genau die ausgewiesene Zahl eindeutiger Präfixe.

Auch 43.199 stabile, 41.650 unruhige, 1.530 laute und 19 kritische ASN ergeben 86.398. Ein Leser kann die Verbindung zwischen Untertabelle und Gesamtwert selbst prüfen.

Bei den Updates endet diese Spur. 159.964.848 IPv4-Updates und 693.016.987 IPv6-Updates ergeben 852.981.835. In der Stabilitätstabelle stehen hingegen 2.222.981.835 BGP-Nachrichten. Die Differenz beträgt genau 1.370.000.000.

Daraus folgt nicht, dass die große Zahl falsch ist. Eine BGP-Nachricht kann in der Pipeline etwas anderes sein als ein nach Adressfamilie zugeordnetes Update. Der erste Zähler könnte rohe MRT- oder BGP-Einheiten enthalten, der zweite nur gefilterte UPDATEs oder Präfixaktionen. Withdrawals, leere Ergebnisse nach dem Filter, Multiprotokollfelder, Duplikate und Parserfehler können weitere Unterschiede erzeugen. Unklar ist nicht, ob es eine plausible Erklärung gibt, sondern welche die Autoren verwendet haben.

März oder 48 Stunden — Beobachtung und Verarbeitung trennen

Im Abschnitt zur Datenquelle nennt der Text RRC24 in Montevideo und RRC15 in São Paulo sowie alle Updates des Monats März 2026. Der folgende Verarbeitungsabschnitt nennt Python 3, mrtparser, pandas, NumPy und Matplotlib und beschreibt die Konsolidierung von mehr als 2,222 Milliarden Nachrichten über 48 Stunden.

Möglicherweise waren 48 Stunden die Laufzeit der Software. Vielleicht war es ein zweitägiges Beobachtungsfenster, ein Ausschnitt im März oder eine Kombination aus zwei Collector-Zeiten. „Alle Updates im März“ könnte das durchsuchte Archiv und nicht die endgültige Stichprobe benennen. Die drei Sprachfassungen des LACNIC-Artikels lösen das nicht auf.

Ein Zweitagesfenster kann extreme Werte zuverlässig finden, hat aber eine andere zeitliche Reichweite als ein Monat mit Wochenenden, Wartungen, Störungen und Peer-Wechseln. Rechenzeit sagt gar nichts über die Dauer des Netzereignisses. Deshalb gehören UTC-Anfang und -Ende der Beobachtung sowie Anfang und Ende der Verarbeitung in getrennte Felder.

Auch die Aussage, 0,02 Prozent der Speaker verursachten den größten Teil der Instabilität, gilt innerhalb dieses Rahmens. 19 von 86.398 sind ungefähr 0,02 Prozent. Ob dieselben ASN in einer anderen Woche, von anderen Peers oder mit einer anderen Zählregel kritisch wären, bleibt offen. Die Kategorie ist ein statistischer Zustand, kein dauerhaftes Urteil.

Ein öffentliches Archiv ersetzt kein Run-Manifest

RIPE RIS stellt eine starke Grundlage bereit. Laut Dokumentation werden Daten pro Route Collector gespeichert; was dessen Peers liefern, landet gemeinsam in Dateien. Der Pfad folgt rrcXX/YYYY.MM/TYPE.YYYYMMDD.HHmm.gz. Dumps entstehen normalerweise alle acht Stunden, Update-Dateien alle fünf Minuten. In den März-2026-Verzeichnissen von RRC15 und RRC24 sind bview und updates getrennt sichtbar.

Das Verzeichnis zeigt aber nicht, welche Dateien der LACNIC-Lauf tatsächlich verwendet hat. Es dokumentiert keine unvollständigen Objekte, Download- oder Parserfehler, Peer-Lücken, Ausschlüsse oder die Rolle der bview-Dateien. Offen verfügbare Rohdaten sind eine Voraussetzung, aber keine Ausführungsquittung.

Die Collector sind zudem begrenzte Beobachter. RIPE NCC führt RRC15 bei PTTMetro-SP in São Paulo und RRC24 als LACNIC Multihop in Montevideo. Beide sehen ihre jeweilige Peer-Kohorte. Sie zählen nicht sämtliche LACNIC-Mitglieder, Router, Datenströme, Nutzer, Ausfälle oder Schäden der Region.

„Nachricht“ wird erst durch eine Regel zur Einheit

RFC 4271 unterscheidet OPEN, UPDATE, KEEPALIVE und NOTIFICATION. RFC 6396 unterscheidet Table Dumps, BGP4MP-Nachrichten und BGP4MP-Zustandswechsel. RIS Live führt auch Peer-State-Metadaten als eigenen Typ. Diese Quellen erklären LACNICs Code nicht; sie zeigen, warum der Oberbegriff mehrere legitime Zähler zulässt.

Ein UPDATE kann mehrere Präfixe mit gemeinsamen Attributen, Announcements, Withdrawals und Multiprotokollinformationen tragen. Nach dem Parsing sind MRT-Records, BGP-Nachrichten, UPDATEs, NLRI-Elemente, Präfixaktionen und Beobachtungen pro Peer nicht dasselbe. Ein Zustandswechsel kann churn erklären, ohne als Familien-Update gezählt zu werden.

Auch die Zuordnung zu IPv4 und IPv6 ist eine Entscheidung. Wird eine Nachricht mit beiden Familien doppelt gezählt? Was geschieht, wenn nach Filtern kein NLRI übrig bleibt? Wie werden Multi-Origin, AS_SET und fehlerhafte Pfade einem ASN zugerechnet? Wann werden gleiche Präfixe aus zwei Collectors dedupliziert? Da die churn rate Updates durch angekündigte Präfixe je ASN in Beziehung setzt, definieren diese Regeln Zähler und Nenner.

Der Beleg muss nicht groß sein

Er braucht zunächst zwei Uhren: UTC-Grenzen der Beobachtung und Zeit der Verarbeitung. Er muss sagen, wofür die 48 Stunden stehen und wie März zur finalen Auswahl gehört.

Dann folgt das MRT-Manifest mit exakten Namen, Hashes, Bytezahlen, Collector, aggregierter Peer-Kohorte, Lücken und Fehlern. Die Nutzung von bview muss von updates getrennt sein.

Ein Zählwörterbuch definiert MRT-Record, BGP-Nachricht, UPDATE, Announcement, Withdrawal, NLRI, Präfixvorkommen und eindeutiges Präfix. Jeder Filter erhält Vorher-/Nachher-Zahlen. Regeln für Adressfamilien, leere Updates, Duplikate, Fehlersätze, Multi-Origin und ASN-Zuordnung werden versioniert.

Eine Zwischenwerttabelle führt von akzeptierten Rohdaten zu geparsten Nachrichten, erhaltenen UPDATEs, Aktionen je Familie und der churn-Population. Gehören 2.222.981.835 und 852.981.835 zu verschiedenen Universen, benennt eine Zeile, wo die 1.370.000.000 verbleiben.

Abschließend werden Python-, mrtparser- und Bibliotheksversionen, Code-Revision, Konfigurationshash, Run-ID, Veröffentlichung und Korrekturen festgehalten. Ein verbesserter Lauf darf den früheren Beleg ergänzen, nicht unsichtbar ersetzen.

Reproduzierbarkeit schützt die Beobachteten

Der Artikel nennt Softwarefehler, Fehlkonfiguration, Hardware, Strom und Angriffe als mögliche Ursachen. Er weist keine davon für die 19 kritischen ASN nach. Hohes Volumen allein belegt weder Absicht noch Kundenschaden oder vermeidbares Fehlverhalten.

Mit einer Herkunftsspur kann ein Betreiber erkennen, ob sein ASN über einen oder viele Peers, kurz oder dauerhaft und unter welcher Origin-Regel auffiel. Forschende können die Konzentration in anderer Zeit oder Kohorte testen. LACNIC kann eine Transformation korrigieren, ohne die gesamte Studie zur Anklagebank zu machen.

Die nüchterne Schlussfolgerung: LACNIC hat eine wertvolle große Messung veröffentlicht. Zwei Zahlenübergänge sind prüfbar, einer nicht. Der nächste Transparenzgewinn liegt nicht in einer weiteren Grafik, sondern in der dokumentierten Strecke zur vorhandenen Grafik.

Quellen