Кратко

  • Запись routing-status от RIPEstat для AS211386 при query_time 2026-10-17T16:00:00 показывает, что 0 из 328 IPv4-пиров RIS и 0 из 318 IPv6-пиров видят этот номер, при 0 объявленных префиксах IPv4 и IPv6 и 0 наблюдаемых соседях.
  • Уровень идентичности даёт кое-что: строку держателя LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. и запись сети в PeeringDB с id 26805 и org_id 791 под именем LINX MAPS.
  • Объект aut-num, его представление через RDAP и запрос объектов маршрутов не вернули текста в 2026-10-18; эти записи не прочитаны, а не пусты.

Номер с двумя именами

Вызов as-overview от RIPEstat для AS211386 возвращает единственное поле атрибуции, holder, со значением LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. (запись as-overview). PeeringDB, опрошенный отдельно по тому же номеру, возвращает объект сети с id 26805, org_id 791, именем LINX MAPS, asn 211386 и статусом ok (запрос сети PeeringDB). Второй ответ пришёл усечённым, с многоточиями вместо полей, которые этот текст не использует; пять названных здесь значений — всё, что даёт запись.

Два каталога, один номер, имена, оба указывающие на London Internet Exchange, и одно из них добавляет Azure. Это вся основа, на которой номер можно описать как связанный с оператором точки обмена и с облачной платформой. Строка держателя — это атрибуция внутри информационного продукта; она не является описанием услуги, документом о структуре компании или доказательством того, что описанная функция работает. Ни один собранный для этого текста документ не описывает связь между London Internet Exchange и Microsoft, и здесь она не утверждается. Запись справочника AZURE London Internet Exchange Ltd. повторяет имя; повторение имени по каталогам не доказывает работу.

Что измерили коллекторы

Запись routing-status от RIPEstat для AS211386 несёт query_time 2026-10-17T16:00:00 (запись routing-status). Она сообщает, что 0 из 328 IPv4-пиров RIS видят номер и 0 из 318 IPv6-пиров. Объявленное пространство — 0 префиксов IPv4 и 0 адресов IPv4, 0 префиксов IPv6 и 0 /48 IPv6. Объекты first_seen и last_seen пусты, observed_neighbours равен 0. Пустой объект first_seen означает, что система RIS вообще не располагает первым наблюдением этого происхождения; это утверждение об архиве коллектора, а не о мире.

Вызов announced-prefixes по тому же номеру возвращает пустой список префиксов за период с 2026-10-03T16:00:00 по 2026-10-17T16:00:00, с latest_time 2026-10-17T16:00:00 и earliest_time архива 2000-08-01T00:00:00 (запись announced-prefixes). Этот ответ несёт свой предел в собственном теле: результаты исключают маршруты с очень низкой видимостью, а именно те, которые видят менее 10 полноканальных пиров RIS. Пустой список ограничен дважды — двухнедельным окном и порогом видимости — и не читается как доказательство того, что объявления не было никогда. Что он доказывает, так это более узкое и всё же полезное: в сети сбора из 328 точек обзора IPv4 и 318 точек IPv6 ни один префикс, исходящий от AS211386, не превысил этот порог внутри записанного окна.

Соседство подтверждает ту же форму. Вызов asn-neighbours от RIPEstat возвращает neighbour_counts: left 0, right 0, unique 0, uncertain 0, при пустом массиве neighbours (запись asn-neighbours). У говорящего без наблюдаемых соседей нет наблюдаемых путей ни в одну сторону; он не участвует в той топологии, которую коллекторы способны видеть.

Где чтение заканчивается

Три запроса к реестру не удались в 2026-10-18, и их неудача — часть результата, а не сноска. REST-запрос к базе данных RIPE об aut-num AS211386 не вернул текста объекта (запрос aut-num), поэтому статус, спонсирующая организация, мейнтейнер и атрибуты создания и изменения остаются невыясненными. Представление того же объекта через RDAP было недоступно при получении (запрос RDAP). REST-запрос объектов маршрутов с происхождением AS211386 вернул отказ доступа (запрос объектов маршрутов). Существование объектов route или route6 под этим происхождением не проверено, и этот текст не утверждает ни их наличия, ни их отсутствия.

Ещё два пробела относятся к этому разделу. Не были получены ни сертификат ресурсов RPKI, ни ROA, покрывающая AS211386, не были получены ни as-set в IRR, ни текст политики aut-num, ни запись политики пиринга; поэтому о намерениях номера в области безопасности или маршрутной политики здесь не говорится ничего. Равным образом не был собран документ, опубликованный London Internet Exchange или Microsoft, который описывал бы сервер маршрутов, работающий внутри Azure; функция, подразумеваемая строкой держателя, остаётся неподтверждённой. Это пробелы данного чтения, датированные 2026-10-18, а не выводы о самих записях.

Что меняет пробел

Практическое следствие касается вопроса, на который отвечает запись реестра. Регистрация aut-num говорит, кто вправе действовать в отношении номера; она не говорит, что трафик существует. Для оператора, применяющего фильтрацию префиксов на основе IRR или валидацию RPKI, это разные входные данные с разными типами ошибок, и номер, появляющийся в реестре, ничего не объявляя, — обычное состояние, а не противоречие.

Различие становится дорогим только тогда, когда процедура закупки или проверки трактует наличие записи как доказательство работающей поверхности — присутствия на точке обмена, облачного подключения, сервера маршрутов — и на этом останавливается.

Для AS211386 две записи расходятся конкретным и измеримым образом: уровень идентичности даёт имя и запись PeeringDB, уровень наблюдения даёт нули с приложенными знаменателями. Ничто из полученного не показывает номер несущим трафик в 2026-10-17T16:00:00, и ничто из полученного не показывает, что он не нёс его никогда.

Что изменило бы это чтение

Чтение опровержимо обычными средствами, и это его полезное свойство как измерения. Непустой список announced-prefixes, ris_peers_seeing отличный от 0, заполненные first_seen или last_seen, или число соседей отличное от 0 — каждое из этого ломает его, и каждое может появиться в следующем окне, не противореча наблюдённому здесь. Чего оно не изменит — так это ещё одной записи в каталоге: второй строки справочника, описания во внешней базе данных или имени, звучащего как развёртывание. Это добавляет имена, а не пути.

Пока же номер — это регистрация с атрибуцией, записью в PeeringDB и без наблюдаемого пути в 2026-10-17T16:00:00. Вопрос, на который запись ответить не может, — тот, который покупатель обычно хочет закрыть: работало ли когда-либо названное в поле holder, — и честная форма ответа состоит в том, что чтение закончилось на трёх неудачных запросах в 2026-10-18 и на пороге видимости в 10 полноканальных пиров.