Zusammenfassung

  • RIPE führt AS212483 als administrativ aktives Objekt und verknüpft den maßgeblichen Organisationseintrag mit LEVEL EIGHTY-SIX COMMUNICATIONS LTD. Damit ist die Ressourcenidentität nachvollziehbar; über laufende Routen, Router, Sitzungen oder Kundendienste sagt der Status nichts aus.
  • PeeringDB nennt für Level 86 elf erklärte Exchange-Zeilen. Der zeitgestempelte RIPEstat-Datensatz weist zugleich eine stark unterschiedliche Sicht auf IPv4 und IPv6 aus. Das eine ist eine teilnehmergepflegte Selbstauskunft, das andere eine schwellengebundene Kollektorbeobachtung.
  • Für eine belastbare Prüfung bleibt AS212483 der gemeinsame Bezugspunkt. Registerdaten, Interconnection-Angaben und Messungen des laufenden Netzes müssen getrennt bewertet werden; Zeilenzahlen, deklarierte Geschwindigkeiten und Sichtbarkeitswerte belegen weder physische Vielfalt und Kapazität noch Ausfall oder universelle Erreichbarkeit.

Eine Nummer hält die Untersuchung auf demselben Objekt

Ein autonomes System ist ein Netz oder eine Gruppe von Netzen, die nach außen eine gemeinsame Routing-Politik vertritt. Die Autonomous System Number, kurz ASN, gibt dieser Routing-Domain eine eindeutige öffentliche Kennung. Beim Border Gateway Protocol, meist BGP genannt, dient sie dazu, Erreichbarkeitsinformationen einem bestimmten Routing-Akteur zuzuordnen.

Bei Firmennamen reicht diese Eindeutigkeit oft nicht aus. Schreibweisen, Marken und Produktnamen können zwischen Quellen variieren. AS212483 ermöglicht dagegen einen kontrollierten Abgleich: Bezieht sich der Registereintrag auf dieselbe Ressource wie das Peering-Verzeichnis? Beobachtet der Route Collector tatsächlich diesen Origin? Arbeiten zwei Incident-Teams am gleichen Gegenstand?

Die Nummer löst damit ein Identitätsproblem, aber keine Betriebsfrage. Aus einer korrekten ASN folgt nicht, dass gerade eine Route angekündigt wird, eine Gegenstelle sie akzeptiert oder ein Dienst erreichbar ist. Dafür braucht es Messungen, deren Zeitpunkt, Blickpunkt und Methode zur jeweiligen Frage passen.

Was der RIPE-RDAP-Eintrag belastbar festhält

Der RDAP-Datensatz umfasst genau die autonome Systemnummer 212483. Start- und Endnummer stimmen überein, der Handle lautet AS212483, der Objektname level86, der administrative Status active. Als maßgeblicher Organisationseintrag erscheint der Handle ORG-LECL2-RIPE mit dem Namen LEVEL EIGHTY-SIX COMMUNICATIONS LTD. Diese genaue Benennung bildet die schmale Identitätsbrücke zum Level-86-Verzeichniseintrag.

Als Registrierungsereignis nennt die Antwort den 8. August 2022 um 13:34:13 UTC. Das letzte Änderungsereignis ist auf den 9. Dezember 2025 um 10:25:29 UTC datiert. Beide Zeiten gehören zur Verwaltungsgeschichte des RDAP-Objekts. Sie sagen nicht, wann ein Router in Betrieb ging, eine Route erschien, eine Sitzung zustande kam oder ein Kunde eine Veränderung bemerkte.

Auch active ist ausschließlich in diesem administrativen Sinn zu lesen. Das Feld prüft weder BGP-Erreichbarkeit noch den Zustand von Geräten oder Anwendungen. Zudem enthält die Antwort weitere Objekte mit Registrantenrollen. Nicht jede solche Rolle darf als wirtschaftlicher Inhaber interpretiert werden; für die hier verwendete Zuordnung ist der ausdrücklich benannte Organisationseintrag entscheidend.

Ein Register wirkt damit als nachvollziehbares Verzeichnis: Es hält die Nummer eindeutig, verknüpft sie mit prüfbaren Namen und bewahrt administrative Ereignisse. Den Zustand des ausgeführten Netzes ersetzt es nicht.

PeeringDB beschreibt eine erklärte Interconnection-Oberfläche

PeeringDB liefert zu ASN 212483 genau einen Netzdatensatz. Er nennt das Netz Level 86 und als alternative Bezeichnung 86 COMMUNICATIONS. Das Profil ist als Enterprise klassifiziert, weist eine offene allgemeine Peering-Policy aus und führt das IRR-Set AS-86. Außerdem sind 100 IPv4- und 120 IPv6-Präfixe eingetragen.

Solche Angaben helfen Netzteams, eine öffentliche Erwartung mit ihrer Konfiguration abzugleichen. Sie sind jedoch vom Teilnehmer gepflegte Verzeichnisfelder. Die Präfixzahlen sind keine gleichzeitige Auswertung eines Route Collectors. Sie zeigen weder, welche Präfixe gerade sichtbar sind, noch welche Routen eine Gegenstelle akzeptiert oder welcher Verkehr übertragen wird.

In den eingebetteten Exchange-Daten stehen elf Zeilen: NetIX, CHIX-CH, LOCIX Frankfurt, Poema IX, FogIXP, NL-ix, Lambda-IX, LOCIX Düsseldorf, BGP.Exchange Zurich, FREMIX und ZXIX Hong Kong. Zehn Zeilen tragen den Wert operational=true, eine operational=false; bei allen elf ist ein Route-Server-Peer-Flag gesetzt.

Die erklärten Geschwindigkeiten verteilen sich auf zwei Zeilen mit 100 Mbps, je eine mit 250 Mbps, 500 Mbps und 10.000 Mbps sowie sechs mit 1.000 Mbps. Für eine technische Nachprüfung können diese Werte die erwartete Zeile eingrenzen. Als Messwerte für gegenwärtigen Verkehr, nutzbare Reserve, vertragliche Kapazität oder Leistung taugen sie nicht.

Ebenso wenig ist operational eine fortlaufende Überwachung der BGP-Sitzung. Das Route-Server-Flag beweist weder den Aufbau einer Sitzung noch den Austausch von Routen. Aus elf logischen Zeilen folgen keine elf unabhängigen Gebäude, Glasfaserwege, Stromdomänen oder Upstreams. Wer physische Diversität oder Resilienz beurteilen will, muss die tatsächlichen Abhängigkeiten für ein definiertes Ausfallszenario untersuchen.

Die RIS-Antwort ist eine Momentaufnahme mit Schwelle

Der routing-status-Datensatz von RIPEstat nennt als query_time den 7. August 2026 um 00:00 UTC. Für IPv4 meldet die Antwort keinen Präfix, der unter den angegebenen Bedingungen bei den 327 aufgeführten IPv4-Full-Feed-Peers von RIS sichtbar war. Für IPv6 weist sie 16 angekündigte Präfixe beziehungsweise 31 /48-Einheiten aus, sichtbar bei allen 320 aufgeführten IPv6-Full-Feed-Peers.

RIS, der Routing Information Service, sammelt Routing-Informationen von teilnehmenden Beobachtungspunkten. Der verwendete Endpunkt schließt Routen aus, die von weniger als zehn RIS-Full-Feed-Peers gesehen wurden. Die IPv4-Angabe beschreibt daher das Ergebnis für diesen Kollektorsatz und diese Schwelle. Sie beweist nicht, dass es weltweit keine IPv4-Route gab, alle IPv4-Dienste von Level 86 unerreichbar waren oder ein Ausfall vorlag.

Die IPv6-Angabe hat dieselbe methodische Grenze. Sichtbarkeit bei 320 von 320 gelisteten Peers ist eine starke Aussage über diese konkrete Beobachtungsmenge. Sie ist kein Beleg für universelle Erreichbarkeit, Route Authorization, geringe Latenz, Resilienz oder eine funktionierende Kundenanwendung. Ein sichtbarer Pfad kann zu einem gestörten Dienst führen; ein fehlgeschlagener Anwendungstest kann umgekehrt Ursachen haben, die ein Route Collector nicht erfasst.

Die Antwort nennt außerdem 2.964 beobachtete Nachbarn. Diese Zahl entsteht im Modell des Endpunkts und darf nicht als Zahl direkter Peers, Verträge, Einrichtungen oder voneinander unabhängiger Wege wiedergegeben werden.

query_time und last_seen gehören zu verschiedenen Feldern

Im selben Datensatz steht für das IPv6-Präfix 2401:5a0:ff03::/48 ein last_seen vom 7. August 2026 um 00:00 UTC. Dieser Wert trägt denselben Zeitwert wie das ausgewiesene query_time. Die sachgerechte Darstellung bewahrt beide Feldnamen und Zeitwerte, statt daraus einen künstlichen einzigen Zeitpunkt oder eine vermeintliche Ereignisfolge zu erzeugen.

query_time bezeichnet den von der Antwort angegebenen Abfragekontext. last_seen gehört zum zurückgegebenen Last-seen-Feld des Präfixes. Ohne zusätzliche Kenntnis über Verarbeitung und Aktualisierung des Endpunkts belegt die übereinstimmende Zeitangabe weder eine Routing-Änderung noch eine Störung.

Als historischen Wert nennt die Antwort außerdem 41.216.185.0/24 mit Origin 212483 und dem First-seen-Zeitpunkt 13. Oktober 2021, 00:00 UTC. Auch das ist ein Kollektorfeld. Es beweist weder Eigentum oder Autorisierung des Präfixes noch eine lückenlose Ankündigung bis zur späteren Momentaufnahme.

Von der öffentlichen Akte zur Betriebsprüfung

Eine effiziente Untersuchung beginnt bei der Identität. Zuerst wird AS212483 als Gegenstand festgehalten und geprüft, ob der Level-86-Name im Verzeichnis und der benannte RIPE-Organisationseintrag dieselbe Nummernressource betreffen. Anschließend werden Handle, Organisation, administrativer Status und Ereignisdaten aus RDAP dokumentiert.

Danach dient PeeringDB als Koordinations- und Prüfliste. Netzname, Policy, IRR-Set, Präfixfelder und Exchange-Zeilen lassen sich mit der erwarteten Architektur vergleichen. Geht es um eine konkrete Verbindung, müssen autorisierte Betriebsquellen zusätzlich den tatsächlichen Sitzungsstatus sowie empfangene und angekündigte Routen belegen. Eine passende Verzeichniszeile beendet diese Prüfung nicht.

Erst im dritten Schritt folgt die zeitgestempelte Laufzeitevidenz. Bei einer Routing-Frage gehören Kollektor, Zeitpunkt, Sichtbarkeitsschwelle, Adressfamilie und konkrete Präfixe in die Dokumentation. Für eine Dienstfrage kommen End-to-End-Tests und Anwendungsdaten hinzu. Kapazitätsfragen benötigen definierte Interface- oder Servicemessungen über einen genannten Zeitraum.

Diese Reihenfolge hält die Schlüsse proportional. RDAP identifiziert die Ressource, ohne eine Route zu beweisen. PeeringDB erklärt Interconnection-Kontext, ohne eine Sitzung zu messen. RIS beobachtet Routen, ohne die Kundenerfahrung zu testen.

Was aus den vier öffentlichen Quellen nicht folgt

Die Datensätze stützen eine präzise Beschreibung von Level 86, AS212483, der erklärten Interconnection-Oberfläche und einer begrenzten Routing-Beobachtung. Nicht erkennbar sind die vollständige physische Topologie, wirtschaftliche Bedingungen zwischen Beteiligten oder der Weg eines bestimmten Kunden.

Auch Verkehr, freie Kapazität, Fehlerursache, Route Authorization, Sicherheitswirkung, Performance, Resilienz und Dienstverfügbarkeit bleiben offen. Der IPv4-Wert trägt keine Ausfallaussage. Der IPv6-Wert trägt keine Garantie weltweiter Erreichbarkeit. Die elf Exchange-Zeilen tragen keinen Nachweis physischer Vielfalt.

Der Nutzen der öffentlichen Akte liegt gerade in ihrer begrenzten Rolle als Realitäts- und Koordinationsebene. RIPE ordnet AS212483 einem benannten Organisationseintrag zu, PeeringDB veröffentlicht die Erklärungen des Teilnehmers, und RIS zeigt für seine angegebenen Bedingungen eine ausgeprägte Differenz zwischen IPv4 und IPv6. Aussagen über aktuelle Dienste benötigen zusätzlich zeitlich passende Betriebsdaten.

Worauf künftig zu achten ist

  • Änderungen am Organisationseintrag, administrativen Status oder an den Ereignisdaten von AS212483 bei RIPE;
  • Änderungen an Netzname, Policy, IRR-Set, Präfixfeldern oder den elf Exchange-Zeilen bei PeeringDB;
  • spätere routing-status-Beobachtungen, die Zeitpunkt, Adressfamilie, Peer-Nenner und Ausschlussschwelle vollständig festhalten;
  • autorisierte Sitzungs- oder Routendaten, die eine konkrete Verzeichnisangabe bestätigen oder widerlegen;
  • dienstbezogene Telemetrie mit Zeitpunkt und Messmethode, wenn Verfügbarkeit, Performance oder Kundenwirkung untersucht werden.

Quellen