Zusammenfassung

  • Der RIPEstat-Plan für das dritte Quartal 2026 kündigt Beschreibungen von BGP-Communities an. Die heutige Looking-Glass-API liefert bereits community_info; RIPEstat nennt das NLNOG Looking Glass als Quelle für einen Teil der bekannten Community-Informationen.
  • Eine eingefrorene Abfrage für 193.0.20.0/23 enthielt 349 Peer-Einträge in 23 RRC-Gruppen. 71 Einträge hatten nichtleere Community-Informationen. Das ist eine Momentaufnahme, keine plattformweite Abdeckungsquote.
  • In einem Eintrag stand auf der beobachteten Route 12859:4000; die Beschreibung lautete „customer routes“, während original den Ausdruck 12859:4xxx auswies. Die Annotation stammt somit aus einer Platzhalterregel und nicht aus einer exakten Definition dieses Einzelwerts.
  • Ein Beschreibungsbeleg sollte Community-Typ, beobachteten Wert, Trefferregel, Trefferklasse, Quelle, Version, Abrufzeit, deklarierte Bedeutung und Beobachtungszeit der Route zusammenhalten. Eine sichtbare Aktions-Community belegt weiterhin nur die Anforderung, nicht deren Ausführung.

Die Route lieferte die Zahl, eine zweite Schicht den Satz

Die Quartalsplanung für RIPEstat behandelt Community-Beschreibungen als kommende Verbesserung. Das ist praktisch: Wer die Konvention eines Netzes nicht kennt, kann aus 12859:4000 allein wenig ableiten.

Laut API-Dokumentation des Looking Glass stammen die Routen aus den BGP-Feeds der RIPE-RIS-Kollektoren; community_info ergänzt reguläre und Large Communities. Die RIPEstat-Quellenseite führt das NLNOG Looking Glass als Lieferant einiger Informationen zu bekannten BGP-Communities auf.

Damit treffen zwei Belegketten aufeinander. RIS beobachtet ein Attribut in einer von einem Peer empfangenen Route. Eine Beschreibungsschicht sucht anderswo nach einer passenden Regel und fügt lesbaren Text hinzu. Die gemeinsame Tabellenzeile verbessert die Bedienbarkeit, macht den Text aber nicht zum Bestandteil der BGP-Nachricht.

Die Startmeldung vom Mai 2025 bezeichnete das neue, RIS-basierte Looking Glass als vollständige Neugestaltung mit Verarbeitung von Large und Extended Communities, API-Zugang und frühem Veröffentlichungsstand. Gerade jetzt lässt sich die Naht dauerhaft sichtbar machen, bevor Beschreibungen ohne Kontext in Bildschirmfotos, Tickets und Skripte wandern.

Ein konkreter Treffer

Das Belegpaket bewahrt eine Antwort für 193.0.20.0/23. Sie meldete ok, Version 2.1, latest_time 2026-09-14T20:20:43, 23 RRC-Gruppen und 349 Peer-Einträge. In 71 davon war community_info nicht leer.

Diese Zahlen messen nicht die allgemeine Qualität oder Reichweite der Beschreibungen. Eine Ressource zu einem Zeitpunkt sagt weder, wie viele Communities weltweit erklärt werden, noch wie frisch oder wie nah an der Betreiberquelle die Texte sind. Die Aufnahme zeigt die Datenverknüpfung.

In einem Peer-Eintrag enthielt die Route 12859:4000. Unter community_info.regular erschien derselbe Wert als Schlüssel, „customer routes“ als Beschreibung und 12859:4xxx als original. Andere Einträge behielten eine exakte Herkunft, etwa 2914:410 für „NTT and customer routes“.

Ein knappes Interface kann beide Ergebnisse ähnlich darstellen. Der Beweisgehalt unterscheidet sich. Beim exakten Treffer hat die Quelle den Einzelwert genannt. Beim Muster ist der Einzelwert Mitglied einer beschriebenen Familie. Korrekt zitierbar ist daher: „12859:4000 traf auf die Regel 12859:4xxx, die als customer routes beschrieben ist.“

Ein Platzhalter ist nicht von sich aus unzuverlässig. Er kann die beabsichtigte Dokumentation einer ganzen Wertereihe sein. Doch exakter Wert, Bereich und offenes Muster haben verschiedene Auflösung. Wer die Trefferregel entfernt, erschwert spätere Konflikte und Korrekturen.

Der Matcher gehört zur Provenienz

Das NLNOG-Looking-Glass-Repository dokumentiert zwei Zufuhrwege. Strukturierte, YANG-artige Dateien können von angegebenen URLs abgerufen werden. Daneben gibt es das ältere Format mit einer Textdatei je ASN; jede gültige Zeile enthält Community-Ausdruck, Komma und Beschreibung.

Der ältere Matcher akzeptiert exakte Werte, Bereiche, einstellige Platzhalter und offene Zahlenmuster. Er kann erfasste Stellen in den Beschreibungstext einsetzen. Das spart lange Listen, bedeutet aber auch: Die angewandte Regel ist Teil des Ergebnisses.

Das Projekt lädt zu Ergänzungen und Änderungen ein und bittet, wenn möglich, in der ersten Kommentarzeile eine Quelle zu nennen. Diese vernünftige Formulierung verspricht nicht für jeden Altbestand eine Betreiberquelle, Gültigkeitszeit und dauerhafte Revision.

Die eingefrorene Datei community_urls.yml enthielt strukturierte Quellen für AS25152 und AS197000. Sie war kein Gesamtregister sämtlicher Beschreibungen in der RIPEstat-Antwort. Daraus folgt nicht, dass 12859:4xxx falsch ist. Feststellbar ist lediglich, dass die untersuchte Antwort keine Quell-URL, Revision, Abrufzeit oder Prüfrolle für diese Regel mitlieferte.

Zwei Uhren dürfen nicht verschmolzen werden

latest_time datiert die Routing-Beobachtung. Es datiert nicht den Satz „customer routes“. Die Beschreibung kann früher aus einer Betreiberseite, einem Repository-Beitrag oder einem formalen Feed übernommen worden sein. Sie kann sich ändern, während die Route gleich bleibt, oder unverändert bleiben, während neue Routen eintreffen.

RFC 1997 definiert reguläre Communities als optionales transitives BGP-Attribut und erlaubt einem autonomen System, außerhalb reservierter Werte die lokale Semantik festzulegen. RFC 8092 gliedert Large Communities in einen globalen Administrator und zwei lokale Datenfelder, die Eigenschaften oder Policy-Aktionen ausdrücken können.

Die Zahlenstruktur weist auf einen administrativen Namensraum hin. Sie authentisiert keinen Erklärungstext und zwingt empfangende Netze nicht zu gleichem Verhalten. Lokale Policies können Communities hinzufügen, entfernen, ändern, ignorieren oder auswerten. Eine RIS-Beobachtung zeigt, was einen Peer erreichte, nicht jede Entscheidung entlang des Pfades.

Eine Anforderung ist kein Ausführungsnachweis

RFC 8195 unterscheidet informative und aktionsbezogene Communities. Die einen kennzeichnen Eigenschaften; die anderen fordern eine definierte Handlung an. Betreiber sollen Zweck und Bedeutung beider Arten öffentlich dokumentieren und pflegen.

Das Auftauchen einer Aktions-Community belegt eine beobachtete Anforderung. Es beweist weder Annahme noch Policy-Treffer, Umsetzung, Weitergabe oder Fortbestand der Wirkung. „Fordert an“ ist daher genauer als „bewirkt“. Ein tatsächlich beobachteter Effekt braucht ein eigenes Feld, eine Methode und eine Zeit.

„Customer routes“ ist im Beispiel eine Klassifikation. Auch sie beweist keinen Vertrag, keine Eigentümerschaft, keine juristische Identität und keine aktuelle Geschäftsbeziehung für jedes markierte Präfix.

Ein kompakter Beschreibungsbeleg

Die Hauptzeile kann beobachteten Wert und kurze Erklärung zeigen. Ein ausklappbarer Beleg sollte enthalten:

Feld Schutzwirkung
Community-Typ Trennt regulär, Large und Extended
Beobachteter Wert Hält das tatsächliche Routenattribut fest
Trefferexpression Legt Platzhalter oder Bereich offen
Trefferklasse Unterscheidet exakt, Bereich und Muster
Quelle und Autoritätsklasse Trennt Betreiber, formalen Feed und Community-Sammlung
Revision oder Inhalts-Hash Bindet alten Text an alte Entscheidungen
Abruf- und Gültigkeitszeit Trennt Beschreibungsfrische von Routenfrische
Semantikklasse Trennt Information von Aktionsanforderung
Routenzeit, RRC und Peer Bindet Text an die erläuterte Beobachtung
Konflikt und Ablösung Bewahrt Korrekturgeschichte

Der Beleg zertifiziert den Text nicht. Er macht die Verknüpfung reproduzierbar. Auch Leere braucht einen Zustand: keine Beschreibung gefunden, Quelle nicht erreichbar, Regeln im Konflikt, Definition abgelaufen oder Typ nicht unterstützt.

Die belastbare Schlussfolgerung

Die Aufnahme zeigt, dass RIPEstat einen beobachteten Wert, eine Erklärung und den breiteren passenden Ausdruck gemeinsam liefern kann. Sie zeigt nicht, dass die Erklärung falsch, die Route gefährlich, eine Kundenbeziehung existent oder eine Aktion ausgeführt war. Sie bewertet weder NLNOG als Ganzes noch unterstellt sie RIPE NCC, NLNOG oder einem Netz Fehlverhalten.

Die Antwort ist daher nicht weniger Erklärung, sondern mitwandernde Provenienz. Je leichter RIPEstat BGP-Communities lesbar macht, desto wichtiger wird der sichtbare Platzhalter.

Quellen