Summary

  • RIPEstat's routing-status record for AS211386, at query_time 2026-10-17T16:00:00, shows 0 of 328 RIS IPv4 peers and 0 of 318 RIS IPv6 peers seeing the ASN, 0 announced IPv4 and IPv6 prefixes, and 0 observed neighbours.
  • The identity layer does return something: a holder string reading LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. and a PeeringDB network record with id 26805 and org_id 791 under the name LINX MAPS.
  • The aut-num object, its RDAP rendering and a route-object query all failed to return text on 2026-10-18, so those records are unread rather than empty.

A number with two names attached

RIPEstat's AS-overview call for AS211386 returns a single attribution field, holder, reading LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. (AS-overview record). PeeringDB, queried separately for the same number, returns a network object with id 26805, org_id 791, name LINX MAPS, asn 211386 and status ok (PeeringDB network lookup). That second response arrived truncated, with ellipses standing in for fields this article does not use; the five values named here are the whole of what the record contributes.

Two catalogues, one number, names that both point at London Internet Exchange and one of which appends Azure. That is the entire basis on which the number can be described as connected to an exchange operator and to a cloud platform. A holder string is an attribution inside a data product; it is not a service description, a corporate-structure filing or a statement that a function is running. Nothing retrieved for this article documents a relationship between London Internet Exchange and Microsoft, and none is asserted here. The directory record for AZURE London Internet Exchange Ltd. repeats the name; repetition across catalogues is not corroboration of operation.

What the collectors measured

RIPEstat's routing-status record for AS211386 carries query_time 2026-10-17T16:00:00 (routing-status record). It reports 0 of 328 RIS IPv4 peers seeing the ASN and 0 of 318 IPv6 peers seeing it. Announced space is 0 IPv4 prefixes and 0 IPv4 addresses, 0 IPv6 prefixes and 0 IPv6 /48s. The first_seen and last_seen objects are empty, and observed_neighbours is 0. An empty first_seen object means the RIS system holds no first observation of this origin at all; that is a statement about the collector's archive, not about the world.

The announced-prefixes call for the same number returns an empty list for the window 2026-10-03T16:00:00 to 2026-10-17T16:00:00, with latest_time 2026-10-17T16:00:00 and an archive earliest_time of 2000-08-01T00:00:00 (announced-prefixes record). That response carries its own limit in the body: results exclude routes with very low visibility, defined as fewer than 10 RIS full-feed peers seeing them. The empty list is therefore bounded twice, by a two-week window and by a visibility floor, and it cannot be read as proof that no announcement was ever made. What it does establish is narrower and still useful: across a collector network of 328 IPv4 and 318 IPv6 vantage points, within the recorded window, no prefix originated by AS211386 cleared that floor.

Adjacency confirms the same shape. RIPEstat's asn-neighbours call returns neighbour_counts of left 0, right 0, unique 0 and uncertain 0, with an empty neighbours array (asn-neighbours record). A speaker with no observed neighbours has no observed paths in either direction; it is not a participant in the topology the collectors can see.

Where the reading stops

Three registry reads failed on 2026-10-18, and their failure belongs to the finding rather than to a footnote. The RIPE Database REST request for aut-num AS211386 returned no object text (aut-num request), so the object's status, sponsoring organisation, maintainer, and created and last-modified attributes remain unestablished. The RDAP rendering of the same object was inaccessible at retrieval (RDAP request). The REST query for route objects with origin AS211386 returned an access failure (route-object query). Whether route or route6 objects exist under this origin is therefore unverified, and this article states neither their presence nor their absence.

Two further absences belong here. No RPKI resource certificate or ROA covering AS211386 was retrieved, and no IRR as-set, aut-num policy text or peering policy entry was retrieved, so nothing is said about the routing-security or policy intentions attached to the number. Nor was any document published by London Internet Exchange or by Microsoft describing a route server operated inside Azure retrieved; the function implied by the holder string remains unconfirmed. These are gaps in this reading, dated 2026-10-18, not findings about the underlying records.

What the gap changes

The practical consequence concerns which question a registry record answers. An aut-num registration says who is entitled to act for a number; it does not say that traffic exists. For an operator running IRR-based prefix filters or RPKI validation, those are separate inputs with separate failure modes, and a number that appears in a registry while announcing nothing is a routine case rather than a contradiction. The distinction becomes expensive only when a procurement or diligence process treats the presence of a registration as evidence of an operating surface — an exchange presence, a cloud on-ramp, a route server — and stops there.

For AS211386 the two records disagree in a specific, measurable way: the identity layer returns a name and a PeeringDB entry, and the observation layer returns zeros with denominators attached. Nothing retrieved shows the number carrying traffic at 2026-10-17T16:00:00, and nothing retrieved shows that it never did.

What would change this reading

The reading is falsifiable by ordinary means, which is the useful property of a measurement. A non-empty announced-prefixes list, a non-zero ris_peers_seeing, a populated first_seen or last_seen, or a non-zero neighbour count would each break it, and any of them could appear in the next window without contradicting anything observed here. What would not change it is another catalogue entry: a second directory listing, a description in a third-party database, or a name that reads like a deployment. Those add names, not paths.

For now the number is a registration with an attribution, a PeeringDB record and no observed paths at 2026-10-17T16:00:00. The question the record cannot answer is the one a buyer usually wants answered — whether the thing named in the holder field has ever operated — and the honest form of the answer is that the reading stopped at three failed queries on 2026-10-18 and at a visibility floor of 10 full-feed peers.