Zusammenfassung

  • Der routing-status-Datensatz von RIPEstat für AS211386 zeigt bei query_time 2026-10-17T16:00:00, dass 0 von 328 RIS-IPv4-Peers und 0 von 318 IPv6-Peers die AS-Nummer sehen, bei 0 angekündigten IPv4- und IPv6-Präfixen und 0 beobachteten Nachbarn.
  • Die Identitätsebene liefert dagegen etwas: eine Halterzeichenkette LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. und einen PeeringDB-Netzeintrag mit id 26805 und org_id 791 unter dem Namen LINX MAPS.
  • Das aut-num-Objekt, seine RDAP-Darstellung und eine Routenobjektabfrage lieferten am 2026-10-18 keinen Text; diese Datensätze sind ungelesen, nicht leer.

Eine Nummer mit zwei Namen

Der AS-overview-Aufruf von RIPEstat für AS211386 gibt ein einziges Zuordnungsfeld zurück, holder, mit dem Inhalt LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. (AS-overview-Datensatz). PeeringDB, separat zur selben Nummer befragt, liefert ein Netzobjekt mit id 26805, org_id 791, name LINX MAPS, asn 211386 und status ok (PeeringDB-Netzabfrage). Diese zweite Antwort kam abgeschnitten an, mit Auslassungspunkten anstelle von Feldern, die dieser Text nicht verwendet; die fünf hier genannten Werte sind alles, was der Datensatz beiträgt.

Zwei Kataloge, eine Nummer, Namen, die beide auf London Internet Exchange zeigen und von denen einer Azure anhängt. Das ist die gesamte Grundlage, auf der die Nummer als mit einem Austauschbetreiber und einer Cloud-Plattform verbunden beschrieben werden kann. Eine Halterzeichenkette ist eine Zuordnung innerhalb eines Datenprodukts; sie ist keine Dienstbeschreibung, kein Dokument zur Unternehmensstruktur und kein Beleg dafür, dass eine beschriebene Funktion läuft. Kein für diesen Text beschafftes Dokument beschreibt eine Beziehung zwischen London Internet Exchange und Microsoft, und hier wird keine behauptet. Der Verzeichniseintrag AZURE London Internet Exchange Ltd. wiederholt den Namen; Wiederholung über Kataloge hinweg belegt keinen Betrieb.

Was die Kollektoren gemessen haben

Der routing-status-Datensatz von RIPEstat für AS211386 trägt query_time 2026-10-17T16:00:00 (routing-status-Datensatz). Er meldet 0 von 328 RIS-IPv4-Peers, die die AS-Nummer sehen, und 0 von 318 IPv6-Peers. Der angekündigte Raum beträgt 0 IPv4-Präfixe und 0 IPv4-Adressen, 0 IPv6-Präfixe und 0 IPv6-/48. Die Objekte first_seen und last_seen sind leer, und observed_neighbours ist 0. Ein leeres first_seen-Objekt bedeutet, dass das RIS-System überhaupt keine erste Beobachtung dieses Ursprungs besitzt; das ist eine Aussage über das Archiv des Kollektors, nicht über die Welt.

Der announced-prefixes-Aufruf zur selben Nummer liefert eine leere Präfixliste für das Fenster 2026-10-03T16:00:00 bis 2026-10-17T16:00:00, mit latest_time 2026-10-17T16:00:00 und einem Archiv-earliest_time von 2000-08-01T00:00:00 (announced-prefixes-Datensatz). Diese Antwort trägt ihre eigene Grenze im Rumpf: Ergebnisse schließen Routen mit sehr geringer Sichtbarkeit aus, definiert als von weniger als 10 RIS-Full-Feed-Peers gesehen. Die leere Liste ist damit doppelt begrenzt, durch ein Zwei-Wochen-Fenster und durch eine Sichtbarkeitsschwelle, und sie lässt sich nicht als Beweis lesen, dass nie eine Ankündigung erfolgte. Was sie belegt, ist enger und dennoch nützlich: In einem Kollektornetz von 328 IPv4- und 318 IPv6-Sichtpunkten hat innerhalb des aufgezeichneten Fensters kein von AS211386 ausgehendes Präfix diese Schwelle überschritten.

Die Nachbarschaft bestätigt dieselbe Form. Der asn-neighbours-Aufruf von RIPEstat liefert neighbour_counts von left 0, right 0, unique 0 und uncertain 0, mit einem leeren neighbours-Array (asn-neighbours-Datensatz). Ein Sprecher ohne beobachtete Nachbarn hat in keine Richtung beobachtete Pfade; er nimmt an der Topologie, die die Kollektoren sehen können, nicht teil.

Wo die Lesung endet

Drei Registerabrufe scheiterten am 2026-10-18, und ihr Scheitern gehört zum Befund, nicht in eine Fußnote. Die REST-Anfrage an die RIPE-Datenbank für aut-num AS211386 gab keinen Objekttext zurück (aut-num-Anfrage), sodass Status, Sponsoring-Organisation, Maintainer sowie Erstellungs- und Änderungsattribute des Objekts ungeklärt bleiben. Die RDAP-Darstellung desselben Objekts war zum Abrufzeitpunkt nicht erreichbar (RDAP-Anfrage). Die REST-Abfrage nach Routenobjekten mit Ursprung AS211386 gab einen Zugriffsfehler zurück (Routenobjektabfrage). Ob unter diesem Ursprung route- oder route6-Objekte existieren, ist damit ungeprüft, und dieser Text behauptet weder ihr Vorhandensein noch ihr Fehlen.

Zwei weitere Lücken gehören in diesen Abschnitt. Es wurde kein RPKI-Ressourcenzertifikat und keine ROA für AS211386 abgerufen, und es wurde kein IRR-as-set, kein aut-num-Richtlinientext und kein Peering-Richtlinieneintrag abgerufen; über die routingbezogenen Sicherheits- oder Richtlinienabsichten der Nummer wird daher nichts gesagt. Ebenso wurde kein von London Internet Exchange oder Microsoft veröffentlichtes Dokument beschafft, das einen innerhalb von Azure betriebenen Routenserver beschreibt; die von der Halterzeichenkette nahegelegte Funktion bleibt unbestätigt.

Das sind Lücken dieser Lesung, datiert auf den 2026-10-18, keine Befunde über die zugrunde liegenden Datensätze.

Was die Lücke ändert

Die praktische Folge betrifft die Frage, die ein Registereintrag beantwortet. Eine aut-num-Eintragung sagt, wer befugt ist, für eine Nummer zu handeln; sie sagt nicht, dass Verkehr existiert. Für einen Betreiber, der IRR-basierte Präfixfilter oder RPKI-Validierung einsetzt, sind das getrennte Eingaben mit getrennten Fehlerarten, und eine Nummer, die im Register erscheint, ohne etwas anzukündigen, ist ein Normalfall und kein Widerspruch.

Teuer wird die Unterscheidung erst, wenn ein Beschaffungs- oder Prüfverfahren das Vorhandensein eines Eintrags als Beleg für eine Betriebsfläche behandelt — eine Präsenz an einem Austauschpunkt, eine Cloud-Anbindung, einen Routenserver — und dort stehen bleibt.

Für AS211386 widersprechen sich die beiden Datensätze auf konkrete und messbare Weise: Die Identitätsebene liefert einen Namen und einen PeeringDB-Eintrag, die Beobachtungsebene liefert Nullen mit angehängten Nennern. Nichts des Abgerufenen zeigt die Nummer am 2026-10-17T16:00:00 Verkehr tragen, und nichts des Abgerufenen zeigt, dass sie es nie getan hätte.

Was diese Lesung ändern würde

Die Lesung ist mit gewöhnlichen Mitteln widerlegbar, und das ist die nützliche Eigenschaft einer Messung. Eine nicht leere announced-prefixes-Liste, ein von null verschiedenes ris_peers_seeing, ein gefülltes first_seen oder last_seen oder eine von null verschiedene Nachbarzahl würden sie jeweils brechen, und jedes davon könnte im nächsten Fenster erscheinen, ohne dem hier Beobachteten zu widersprechen. Was sie nicht ändern würde, ist ein weiterer Katalogeintrag: eine zweite Verzeichniszeile, eine Beschreibung in einer Fremddatenbank oder ein Name, der wie ein Rollout klingt. Das fügt Namen hinzu, keine Pfade.

Vorerst ist die Nummer eine Eintragung mit einer Zuordnung, einem PeeringDB-Eintrag und keinem beobachteten Pfad am 2026-10-17T16:00:00. Die Frage, die der Datensatz nicht beantworten kann, ist die, die ein Käufer meist geklärt haben will — ob das im holder-Feld Benannte je in Betrieb war — und die ehrliche Form der Antwort lautet, dass die Lesung bei drei gescheiterten Abfragen am 2026-10-18 und bei einer Sichtbarkeitsschwelle von 10 Full-Feed-Peers endete.