Resumo

  • O registro routing-status do RIPEstat para AS211386, com query_time 2026-10-17T16:00:00, mostra 0 de 328 pares IPv4 do RIS e 0 de 318 pares IPv6 vendo o número de AS, com 0 prefixos IPv4 e IPv6 anunciados e 0 vizinhos observados.
  • A camada de identidade, porém, devolve algo: uma cadeia de titular LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. e um registro de rede no PeeringDB com id 26805 e org_id 791 sob o nome LINX MAPS.
  • O objeto aut-num, sua representação RDAP e uma consulta de objetos de rota não devolveram texto em 2026-10-18, então esses registros estão sem leitura, não vazios.

Um número com dois nomes em cima

A chamada AS-overview do RIPEstat para AS211386 devolve um único campo de atribuição, holder, que diz LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. (registro AS-overview). O PeeringDB, consultado em separado sobre o mesmo número, devolve um objeto de rede com id 26805, org_id 791, name LINX MAPS, asn 211386 e status ok (consulta de rede no PeeringDB). Essa segunda resposta chegou truncada, com reticências no lugar de campos que este texto não usa; os cinco valores citados aqui são tudo o que o registro oferece.

Dois catálogos, um número, nomes que apontam ambos para a London Internet Exchange e um deles acrescenta Azure. Essa é toda a base sobre a qual o número pode ser descrito como ligado a uma operadora de ponto de troca e a uma plataforma de nuvem. Uma cadeia de titular é uma atribuição dentro de um produto de dados; não é descrição de serviço, nem documento de estrutura societária, nem afirmação de que uma função esteja operando. Nenhum documento obtido para este texto descreve uma relação entre a London Internet Exchange e a Microsoft, e nenhuma é afirmada aqui. A ficha de diretório AZURE London Internet Exchange Ltd. repete o nome; repetição entre catálogos não corrobora operação.

O que os coletores mediram

O registro routing-status do RIPEstat para AS211386 carrega query_time 2026-10-17T16:00:00 (registro routing-status). Ele informa 0 de 328 pares IPv4 do RIS vendo o número de AS e 0 de 318 pares IPv6. O espaço anunciado é de 0 prefixos IPv4 e 0 endereços IPv4, 0 prefixos IPv6 e 0 /48 IPv6. Os objetos first_seen e last_seen estão vazios, e observed_neighbours é 0. Um objeto first_seen vazio significa que o sistema RIS não tem nenhuma primeira observação desta origem; isso é uma afirmação sobre o arquivo do coletor, não sobre o mundo.

A chamada announced-prefixes para o mesmo número devolve uma lista vazia para a janela 2026-10-03T16:00:00 a 2026-10-17T16:00:00, com latest_time 2026-10-17T16:00:00 e earliest_time de arquivo de 2000-08-01T00:00:00 (registro announced-prefixes). Essa resposta traz seu próprio limite no corpo: os resultados excluem rotas de visibilidade muito baixa, definidas como vistas por menos de 10 pares RIS de feed completo. A lista vazia é, portanto, limitada duas vezes, por uma janela de duas semanas e por um piso de visibilidade, e não pode ser lida como prova de que nunca houve anúncio. O que ela estabelece é mais estreito e ainda útil: numa rede de coleta de 328 pontos de vista IPv4 e 318 IPv6, dentro da janela registrada, nenhum prefixo originado por AS211386 passou desse piso.

A adjacência confirma a mesma forma. A chamada asn-neighbours do RIPEstat devolve neighbour_counts de left 0, right 0, unique 0 e uncertain 0, com um arranjo neighbours vazio (registro asn-neighbours). Um falante sem vizinhos observados não tem rotas observadas em nenhuma direção; não participa da topologia que os coletores conseguem ver.

Onde a leitura para

Três leituras de registro falharam em 2026-10-18, e a falha faz parte do achado, não de uma nota de rodapé. A requisição REST da base de dados RIPE para o aut-num AS211386 não devolveu texto de objeto (requisição aut-num), então o status do objeto, sua organização patrocinadora, seu mantenedor e seus atributos de criação e última modificação seguem não estabelecidos. A representação RDAP do mesmo objeto estava inacessível no momento da consulta (requisição RDAP). A consulta REST de objetos de rota com origem AS211386 devolveu falha de acesso (consulta de objetos de rota). A existência de objetos route ou route6 sob esta origem fica, portanto, sem verificação, e este texto não afirma nem a presença nem a ausência deles.

Outras duas ausências pertencem a esta seção. Nenhum certificado de recurso RPKI nem ROA cobrindo AS211386 foi obtido, e nenhum as-set de IRR, texto de política de aut-num ou entrada de política de peering foi obtido, então nada é dito sobre as intenções de segurança de roteamento ou de política ligadas ao número. Também não foi obtido nenhum documento publicado pela London Internet Exchange ou pela Microsoft descrevendo um servidor de rotas operado dentro do Azure; a função implicada pela cadeia de titular segue não confirmada. São lacunas desta leitura, datadas de 2026-10-18, não achados sobre os registros subjacentes.

O que a lacuna muda

A consequência prática diz respeito a qual pergunta um registro responde. Uma inscrição aut-num diz quem tem autoridade para agir por um número; não diz que existe tráfego. Para um operador que aplica filtros de prefixo baseados em IRR ou validação RPKI, são entradas distintas com modos de falha distintos, e um número que aparece num registro sem anunciar nada é um caso corrente, não uma contradição. A distinção só custa caro quando um processo de compra ou de diligência trata a presença de um registro como prova de uma superfície operacional — presença num ponto de troca, conexão a nuvem, servidor de rotas — e para por aí.

Para AS211386 os dois registros divergem de forma concreta e mensurável: a camada de identidade devolve um nome e uma entrada no PeeringDB, e a camada de observação devolve zeros com denominadores anexados. Nada do que foi obtido mostra o número carregando tráfego em 2026-10-17T16:00:00, e nada do que foi obtido mostra que ele nunca o tenha feito.

O que mudaria esta leitura

A leitura é refutável por meios comuns, que é a propriedade útil de uma medição. Uma lista announced-prefixes não vazia, um ris_peers_seeing diferente de zero, um first_seen ou last_seen preenchido, ou uma contagem de vizinhos diferente de zero quebrariam cada um a conclusão, e qualquer deles poderia aparecer na próxima janela sem contradizer nada do que foi observado aqui. O que não a mudaria é mais uma entrada de catálogo: uma segunda ficha de diretório, uma descrição numa base de terceiros ou um nome que se lê como implantação. Isso acrescenta nomes, não rotas.

Por ora o número é uma inscrição com uma atribuição, um registro no PeeringDB e nenhuma rota observada em 2026-10-17T16:00:00. A pergunta que o registro não consegue responder é a que um comprador costuma querer resolvida — se a coisa nomeada no campo holder já operou — e a forma honesta da resposta é que a leitura parou em três consultas falhas em 2026-10-18 e num piso de visibilidade de 10 pares de feed completo.