Zusammenfassung

  • Die BTW-Karte zum Ziel nennt genau eine Ressource: AS211386, Typ ASN, Klasse virtual, Status observed, Eigentümerverweis azure-london-internet-exchange-ltd; zuletzt aktualisiert am 16. Juni 2026, Konfidenz 0,7.
  • Der Name legt einen Routenserver für LINX in Microsoft Azure nahe, doch die Karte räumt selbst ein, dass weder Betriebsdokumentation noch Routingaktivität noch eine offizielle Erklärung von LINX oder Microsoft diese Rolle bestätigt.
  • Rechenschaft braucht vier Glieder: Registereintrag, geprüfte Berechtigung samt erreichbarem Kontakt, beobachteter Betrieb und benannter Verantwortlicher. Zwei Aliase füllen das erste Glied und lassen die drei anderen offen.

Ein Registereintrag ist kein Unternehmen. Er ist eine Erlaubnis mit einem Namen darauf, und genau dieser Unterschied entscheidet, wer antwortet, wenn etwas schiefgeht.

In der Verzeichniskarte, die BTW über AZURE London Internet Exchange Ltd. führt Nur für den Strategischen Kreis, steht AS211386 als einzige Ressource: Typ ASN, Klasse virtual, Status observed, Eigentümerverweis azure-london-internet-exchange-ltd. Zuletzt aktualisiert wurde die Karte am 16. Juni 2026, die Konfidenz liegt bei 0,7. Eingetragen ist eine private Gesellschaft, AZURE London Internet Exchange Ltd., mit zwei Aliasen: London Internet Exchange Ltd. und LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd.

Der dritte Alias ist der aufschlussreichste. In einer einzigen Zeichenkette stehen der Londoner Austauschknoten, ein Routenserver und die Microsoft-Cloud nebeneinander. Als Beschreibung gelesen verspricht sie eine Architektur. Als Registereintrag gelesen verspricht sie nur einen Namen.

Die Karte sagt das mit einer für einen Katalog ungewöhnlichen Offenheit: Der Name legt eine Routenserver-Funktion für die London Internet Exchange (LINX) innerhalb von Microsoft Azure nahe, doch weder Betriebsdokumentation noch Routingaktivität noch offizielle Erklärungen von LINX oder Microsoft bestätigen diese Rolle; derzeit existiert das Gebilde nur als Registereintrag.

Die Karte listet außerdem vier Lücken ohne Ausschmückung: keine offizielle Erklärung von LINX oder Microsoft, die den Eigentümer bestätigt oder bestreitet; Zweck und Zeitplan einer Aktivierung von AS211386 sind unbekannt; es gibt keine Kontakt- oder Personendaten zu diesem Eintrag; und es fehlt jeder Hinweis auf Netzinfrastruktur oder einen Dienst. Daraus folgt unmittelbar etwas Praktisches: Die Karte nennt zwei große Organisationen und kann die Nummer keiner von beiden zuordnen.

Die belastbare Kette hat vier Glieder: Register, geprüfte Berechtigung samt Kontakt, beobachteter Betrieb und verantwortlicher Verantwortlicher. Ein Name besetzt das erste Glied und fällt in den drei übrigen durch. Die richtige Frage lautet deshalb nicht, wem AS211386 gehört, sondern wer belegen könnte, dass er ihn steuert, mit welchem Dokument und gegenüber wem. Die Karte stützt ihren Inhalt auf zwei technische Quellen: den as-overview-Endpunkt von RIPEstat für AS211386 und den RDAP-Eintrag autnum 211386.

Der einzige in dieser Analyse geprüfte externe Text handelt von etwas anderem. ComputerWeekly berichtete, LINX beschreibe die Zusammenarbeit mit Megaport als „powerful expansion“ des Dienstes Linx Cloud Connect, der über eine vertrauenswürdige Netzbasis direkten Zugang zu zentralen Cloud-Diensten bietet, mit niedriger Latenz, gleichbleibender Verfügbarkeit und mehr Kontrolle über den Datenverkehr. Das ist ein echter Beitrag zur Cloud-Strategie des Austauschknotens und berührt den Gegenstand dieser Analyse nicht: Der Text nennt AS211386 nicht, beschreibt keinen Routenserver und schreibt keinem ASN einen Eigentümer zu.

BTW hat dasselbe Registerstück bereits am 26. Mai 2026 in der Kategorie company-region-global-type-cloud-service profiliert und es als ruhenden ASN behandelt, der über den Namen mit einem großen Austauschknoten und einem großen Cloud-Anbieter verbunden ist. Dieses Briefing dreht die Achse. Es sagt nicht voraus, was die Nummer tun wird, sondern prüft, welche Belege nötig wären, damit jemand für sie einsteht, und welcher Teil dieser Belege schon vorliegt.

Drei Tatsachen würden die Einordnung sofort ändern. Ein Delegationseintrag mit maintainer und betrieblichem Kontakt würde Verwahrung belegen. Eine Beobachtung von Präfix-Ursprüngen würde die Nummer zu genutzter Infrastruktur machen. Ein RPKI-Status würde zeigen, ob jemand Ankündigungen in ihrem Namen freigibt. Jede dieser drei verschiebt das Gespräch vom Katalog in den Betrieb, und keine lässt sich durch eine Schlussfolgerung aus dem Alias ersetzen.

Diese Analyse behauptet für AS211386 keinen Wert für as-name, Delegationsstatus, maintainer, Änderungsdatum, Präfix-Ursprung oder RPKI-Status. Die Register- und Routingdokumente, die diese Werte festlegen würden, liegen hier nicht als lesbare Belege vor, und aus dem Namen wird keiner von ihnen abgeleitet.

Eine Nummer ohne dokumentierten Verwahrer ist kein Rätsel. Sie ist eine Erlaubnis, die auf ihren Eigentümer wartet.