Resumo

  • O plano do RIPEstat para o terceiro trimestre de 2026 diz que descrições de comunidades BGP serão adicionadas em breve. A API atual já expõe community_info, e a página de fontes aponta o projeto NLNOG Looking Glass como fornecedor de parte dessas informações.
  • Uma captura de 193.0.20.0/23 retornou 349 registros de peers em 23 grupos RRC; 71 tinham informações de comunidade não vazias. Isso descreve uma resposta, não mede a cobertura geral da plataforma.
  • Em um registro, o valor observado era 12859:4000, a descrição era “customer routes” e o campo original trazia 12859:4xxx. A frase veio de uma regra com curinga, não de uma definição exata daquele valor.
  • Um recibo de descrição deve manter tipo de comunidade, valor observado, expressão correspondente, classe de correspondência, fonte, versão, horário de coleta da descrição, semântica declarada e horário da rota. Uma comunidade de ação observada continua sendo pedido, não prova de execução.

O número veio pela rota; a frase veio por outra cadeia

O planejamento trimestral do RIPEstat inclui descrições de comunidades BGP entre as próximas melhorias do Looking Glass. É uma escolha útil. Quem não conhece a convenção de um operador dificilmente extrai sentido de 12859:4000 sem ajuda.

A referência da API informa que as rotas vêm das coletas BGP do RIPE RIS e que community_info acrescenta informações a comunidades regulares e grandes. A página de fontes do RIPEstat atribui ao NLNOG Looking Glass parte dos dados sobre comunidades conhecidas.

Há, portanto, duas cadeias. O RIS observa um atributo que chegou de um peer. A camada de descrição encontra uma regra em outro conjunto de dados e liga texto legível ao valor. Colocar ambos lado a lado facilita a leitura, mas não torna a descrição um campo transportado no anúncio BGP.

A nota de lançamento de maio de 2025 apresentou o Looking Glass redesenhado como baseado em RIS, capaz de analisar comunidades grandes e estendidas, disponível pela API e ainda em estágio inicial. Preservar agora a ligação documental evita que uma legenda perca sua origem quando for copiada para uma captura de tela, um chamado ou uma automação.

A resposta mostra a operação de correspondência

O pacote de evidências preservou uma consulta para 193.0.20.0/23. Ela retornou estado ok, versão 2.1, latest_time 2026-09-14T20:20:43, 23 grupos RRC e 349 entradas de peers. Setenta e uma tinham community_info não vazio.

Esses totais não são uma amostra de cobertura. Uma única consulta não informa quantas comunidades da Internet recebem descrição, quantas definições estão atualizadas ou quantas vêm diretamente do operador. O valor do exemplo é revelar a forma da junção.

Em uma entrada, a cadeia observada continha 12859:4000. Dentro de community_info.regular, a chave era o mesmo valor, a descrição era “customer routes” e original era 12859:4xxx. Em outra, 2914:410 foi associado a “NTT and customer routes” com original exatamente igual a 2914:410.

As duas legendas podem parecer equivalentes na tela, mas têm resolução diferente. A correspondência exata mostra que a fonte nomeou aquele valor. O curinga mostra que o valor entrou numa família. A afirmação auditável é: “12859:4000 correspondeu a 12859:4xxx, regra descrita como customer routes”.

Usar curinga não torna uma definição ruim. Ele pode ser a maneira correta de documentar uma série. O problema surge quando o processo de correspondência some e uma regra ampla passa a parecer um verbete exato.

O padrão faz parte da proveniência

O repositório do NLNOG Looking Glass descreve duas vias. Uma baixa arquivos estruturados em estilo YANG de URLs declaradas. A outra usa arquivos de texto legados, um por ASN, com expressão, vírgula e descrição em cada linha válida.

O formato legado aceita correspondências exatas, intervalos, curingas de um dígito e padrões numéricos abertos. Valores capturados podem ser inseridos no texto. É uma forma eficiente de cobrir um vocabulário grande, mas significa que a regra executada pertence ao resultado.

O projeto aceita acréscimos e correções e pede que uma fonte seja indicada em comentário, quando possível. Isso não promete a mesma autoridade, data ou histórico para todas as linhas antigas. O community_urls.yml congelado listava feeds estruturados para AS25152 e AS197000, e não um catálogo completo de cada explicação devolvida pelo RIPEstat.

Nada disso prova que 12859:4xxx está errado. Prova apenas que a resposta examinada não entregou, junto com a frase, a URL da fonte, uma revisão, a hora de ingestão ou o responsável pela validação.

A descrição não pode tomar emprestado o relógio da rota

latest_time situa os dados de roteamento. Não situa a idade de “customer routes”. A definição pode ter sido coletada antes, alterada depois ou permanecer estável enquanto as rotas mudam. Exibir a legenda atual numa observação histórica sem versão pode atribuir ao passado um significado posterior.

O RFC 1997 define Communities como atributo BGP opcional e transitivo e permite que o sistema autônomo dê sentido à parte local fora dos valores reservados. O RFC 8092 organiza Large Communities em administrador global e dois campos locais, usados para propriedades ou ações de política.

Essa estrutura identifica um espaço administrativo, mas não autentica a explicação publicada fora do protocolo. Também não obriga todos os receptores a agir igual. Políticas locais podem adicionar, retirar, alterar, ignorar ou usar uma comunidade. O que o RIS vê num peer não é o histórico completo das decisões ao longo do caminho.

Ação solicitada não é ação comprovada

O RFC 8195 distingue comunidades informativas e de ação. As primeiras marcam propriedades; as segundas pedem que outro AS aplique uma operação. O documento recomenda que os operadores publiquem e mantenham a finalidade de ambas.

Ver uma comunidade de ação prova que um pedido chegou ao ponto de observação. Não prova que o receptor aceitou, que a política casou, que o efeito se propagou ou que continuou ativo. A interface deve dizer “solicita”, não “faz”. Se houver observação independente do resultado, ela precisa de campo, método e horário próprios.

“Customer routes” é uma classificação, não uma ação. Ainda assim, não demonstra contrato, propriedade, identidade jurídica nem relação comercial atual de cada prefixo com a etiqueta.

Um recibo compacto

A linha principal pode exibir apenas valor e explicação. Um detalhe expansível deve guardar:

  • tipo regular, grande ou estendido;
  • valor realmente observado;
  • expressão correspondente e classe exata, intervalo ou padrão;
  • fonte, URL e classe de autoridade;
  • revisão, commit ou hash do conteúdo;
  • instante de ingestão e eventual validade declarada;
  • categoria informativa ou pedido de ação;
  • horário da rota, RRC e peer;
  • conflito, correção e substituição.

O recibo não certifica a descrição. Ele permite reproduzir a associação e escolher o limiar adequado: leitura exploratória, confirmação em documento do operador ou exclusão de automação. Também deve separar “não encontrado”, “fonte indisponível”, “regras conflitantes”, “expirado” e “tipo não suportado”.

O limite da conclusão

A resposta prova que RIPEstat já consegue apresentar o valor observado, a frase e a expressão mais ampla usada na correspondência. Não prova erro, risco da rota, relação contratual ou execução de política; tampouco mede o catálogo do NLNOG ou atribui falha à RIPE NCC, ao NLNOG ou a qualquer rede.

O próximo passo não é ocultar a explicação. É fazer a proveniência viajar com ela. Quanto mais legíveis as comunidades se tornam, mais importante é manter visível o curinga que produziu a leitura.

Fontes