Resumo

  • O RDAP da RIPE registra o AS212483 como objeto administrativo ativo e associa o registro de organização denominado à LEVEL EIGHTY-SIX COMMUNICATIONS LTD. Isso fixa a identidade do recurso numérico, mas não demonstra que uma rota, sessão BGP, equipamento ou serviço esteja funcionando agora.
  • A PeeringDB declara onze linhas de conexão em exchanges, enquanto a resposta de routing-status da RIPEstat mostra uma diferença acentuada entre a visibilidade IPv4 e IPv6 no horário consultado. Uma fonte expressa o que o participante publicou; a outra registra uma observação de coletores limitada por método e limiar.
  • A conclusão segura é preservar a disciplina da evidência: manter o ASN como objeto comum, conservar o horário e o ponto de observação de cada medição e não transformar campos de diretório em afirmações sobre tráfego, capacidade, diversidade física, resiliência ou experiência do cliente.

Primeiro, confirme qual é o objeto da investigação

Um sistema autônomo é uma rede, ou um conjunto de redes, que apresenta uma política comum de roteamento para o restante da internet. Seu número de sistema autônomo, o ASN, fornece uma identidade pública única para a troca de informações de alcance por meio do Border Gateway Protocol, conhecido como BGP.

O AS212483 aparece em todas as camadas consideradas aqui, mas cada uma responde a uma pergunta diferente. O diretório público aponta qual entidade está em pauta. O registro administrativo informa qual objeto e organização estão associados ao recurso numérico. Um diretório de interconexão apresenta o que o participante declara sobre sua rede. Um coletor de rotas registra o que determinados pontos de observação viram em um contexto temporal definido.

Essa separação é prática. Nomes comerciais e grafias podem variar, enquanto o ASN oferece um ponto de referência preciso para operadores, clientes, pesquisadores e equipes de resposta a incidentes. Ainda assim, compartilhar o mesmo identificador não torna todos os campos equivalentes. Identidade confirmada é o começo da análise, não uma resposta automática sobre o sistema em execução.

O limite exato do RDAP da RIPE

A resposta RDAP cobre exatamente o número 212483. Ela usa o identificador AS212483, nomeia o objeto como level86 e exibe o estado administrativo active. Dentro da resposta, o identificador de organização ORG-LECL2-RIPE traz o nome LEVEL EIGHTY-SIX COMMUNICATIONS LTD. É essa organização nomeada que forma a ponte restrita entre o recurso numérico e a entidade Level 86 do diretório.

O histórico mostra um evento de registro em 8 de agosto de 2022, às 13:34:13 UTC, e um evento de última alteração em 9 de dezembro de 2025, às 10:25:29 UTC. As datas pertencem ao objeto administrativo. Elas não dizem quando um roteador foi instalado, quando uma rota começou a aparecer, quando uma sessão foi estabelecida ou quando um produto sofreu alguma mudança.

O termo active também deve permanecer nesse domínio. Ele qualifica o cadastro, não a saúde de roteadores, aplicações ou serviços. Não testa alcance BGP e não informa a experiência de um cliente. A resposta ainda contém outros objetos com funções de registro e manutenção; por isso, não se pode converter toda função denominada “registrant” em identidade comercial. A organização nomeada é o vínculo utilizado.

Esse é o valor de um registro como livro de recursos: manter um número único associado a nomes e eventos que podem ser revisados. O cadastro facilita coordenação e reduz ambiguidades sem precisar alegar que descreve a rede em tempo real.

A PeeringDB documenta o que o participante declara

A consulta da PeeringDB retorna uma linha de rede para o ASN 212483. O nome publicado é Level 86, com 86 COMMUNICATIONS como denominação alternativa. O perfil é classificado como Enterprise, declara política geral aberta de peering e informa o conjunto IRR AS-86. Também apresenta 100 prefixos IPv4 e 120 prefixos IPv6.

Esses valores pertencem a um perfil mantido pelo participante. Eles ajudam a conferir identidade, política e expectativas de coordenação, mas não dizem quais prefixos estavam visíveis no mesmo instante, quais anúncios uma rede aceitou ou por onde o tráfego passou. O número declarado de prefixos não substitui uma observação independente de rotas.

Os dados aninhados contêm onze linhas de exchange. Dez estão marcadas como operacionais e uma como não operacional; todas trazem a marca de participação via servidor de rotas. As velocidades declaradas se distribuem em duas linhas de 100 Mbps, uma de 250 Mbps, uma de 500 Mbps, seis de 1.000 Mbps e uma de 10.000 Mbps.

Como lista de verificação, o conjunto é útil. Um operador autorizado pode comparar os registros com a configuração e o desenho esperados. Como telemetria, porém, ele é insuficiente. A marca “operacional” não é uma leitura contínua do estado de uma sessão BGP. A indicação de servidor de rotas não prova que uma sessão esteja estabelecida ou trocando anúncios agora. A velocidade registrada não mede tráfego, folga utilizável, capacidade contratada nem desempenho em uma falha.

Também seria incorreto tratar onze linhas lógicas como onze caminhos físicos independentes. Conexões distintas podem compartilhar fibra, energia, instalação, upstream ou sistemas de controle. Avaliar diversidade exige definir a falha que se pretende suportar e mapear as dependências reais; a contagem do diretório não resolve essa análise.

O que a fotografia do RIS realmente mostra

A resposta de routing-status da RIPEstat acrescenta uma camada ligada ao sistema em execução, mas somente dentro de seu escopo. O campo query_time é 7 de agosto de 2026 às 00:00 UTC. Nesse contexto, a resposta informa que nenhum prefixo IPv4 qualificado estava visível entre os 327 peers full-feed IPv4 listados pelo RIS. Para IPv6, registra 16 prefixos anunciados, equivalentes a 31 blocos /48, visíveis nos 320 de 320 peers full-feed IPv6 listados.

O contraste entre as duas famílias de endereços é um fato importante da resposta. Não é, por si só, evidência de indisponibilidade. O endpoint informa que exclui rotas vistas por menos de dez peers full-feed do RIS. Assim, o zero de IPv4 descreve aquilo que passou pelo método e pelo limiar desse retorno. Não prova que toda rota IPv4 possível estivesse ausente de todos os lugares, nem que qualquer serviço da Level 86 estivesse fora do ar.

O resultado IPv6 carrega fronteira equivalente. A presença em todos os 320 peers listados é evidência forte para esse conjunto de coletores e esse retorno. Não comprova alcance universal, autorização de rotas, resiliência, baixa latência ou funcionamento de aplicações. Uma rota pode estar visível enquanto um serviço atrás dela falha; um serviço também pode enfrentar um problema que um coletor BGP não enxerga.

A resposta ainda traz 2.964 vizinhos observados. O número é derivado do modelo de coleta e não deve ser apresentado como 2.964 peers diretos, contratos, instalações ou caminhos independentes. Ele descreve uma propriedade da observação, não a topologia comercial ou física da empresa.

Horário de consulta e “última vez vista” não são sinônimos

Separadamente, a resposta atribui ao prefixo IPv6 2401:5a0:ff03::/48 um campo de última observação em 7 de agosto de 2026 às 00:00 UTC. Esse valor tem a mesma marca temporal do query_time declarado, mas pertence a um campo diferente. O tratamento correto é conservar os dois horários e associar cada um ao seu campo, sem fabricar um único instante de “estado atual”.

O horário da consulta identifica o contexto retornado pelo endpoint. O horário de última observação pertence ao registro específico daquele prefixo. Sem documentação adicional sobre processamento e atualização, a coincidência temporal não autoriza construir uma cronologia operacional nem afirmar que uma mudança ocorreu a partir desses campos. Tempo e método fazem parte da evidência; não são notas de rodapé.

Uma sequência de verificação que reduz falsos atalhos

Uma investigação pode começar confirmando que o objeto pretendido é o AS212483 e que o nome da organização e a entrada de diretório apontam para a mesma identidade de rede. Em seguida, convém revisar o estado administrativo, o identificador da organização e o histórico do objeto. Essa etapa evita que uma marca parecida ou outra rede seja analisada por engano.

Depois, a PeeringDB funciona como uma lista de expectativas. Nome, política, conjunto IRR e linhas de exchange podem ser comparados com o desenho relevante. Quando uma linha é usada para investigar um produto, é necessário verificar configuração e estado real da sessão por fontes operacionais autorizadas. Um registro coincidente orienta a checagem; não a encerra.

Só então entram evidências do ambiente em funcionamento e com horário preservado. Uma pergunta de roteamento pede coletor identificado, instante da consulta, limiar, família de endereços e prefixos exatos. Decisões que exigem confiança mais ampla devem comparar pontos de observação adequados. Perguntas de serviço requerem testes ponta a ponta e evidência da aplicação. Perguntas de capacidade exigem medições definidas em uma janela temporal clara.

Essa ordem mantém as conclusões proporcionais. O RDAP identifica o recurso sem provar uma rota. A PeeringDB publica contexto de interconexão sem provar sessão. O RIS observa rotas sem provar experiência do cliente. As três camadas continuam úteis justamente porque seus limites permanecem visíveis.

O que os registros públicos não estabelecem

As quatro fontes sustentam uma descrição precisa da identidade de rede da Level 86, de sua superfície declarada de interconexão e de uma observação de rotas com escopo limitado. Não estabelecem a topologia física completa, os termos comerciais das relações ou o caminho usado por um cliente específico.

Também não demonstram volume de tráfego, capacidade de reserva, isolamento de falhas, autorização de rotas, controles de segurança, desempenho, resiliência ou disponibilidade. O campo IPv4 não sustenta uma conclusão de interrupção. O campo IPv6 não sustenta uma conclusão de alcance universal. O número de exchanges não sustenta uma conclusão de diversidade física.

O uso mais forte do registro público é como camada de realidade: objetos nomeados, declarações publicadas e observações datadas que podem ser comparados com o sistema vivo. Qualquer afirmação sobre resultado de serviço ainda precisa de evidência operacional adicional e compatível no tempo.

O que acompanhar

  • alterações na organização, no estado administrativo ou no histórico do AS212483 no RDAP da RIPE;
  • mudanças no nome, na política, no conjunto IRR, nos números declarados de prefixos ou nas linhas de exchange da PeeringDB;
  • novas respostas de routing-status que preservem horário, família de endereços, denominador de peers e limiar de baixa visibilidade;
  • evidência autorizada e datada de sessão ou rota que confirme ou contradiga uma declaração específica;
  • telemetria ligada ao produto quando a pergunta for disponibilidade, desempenho ou impacto para clientes.

Fontes