Resumo

  • Uma mensagem enviada à lista da AfNOG em 20 de julho, às 10h48 UTC, apresentou um comando curto que destaca as repetições em as-TelOneZW.
  • Uma nova consulta à AFRINIC confirmou 24 linhas members: e 21 ASNs únicos: AS37183 aparece três vezes; AS37123, duas.
  • Pela semântica de conjunto da RPSL, cópias do mesmo valor não criam membros distintos. O achado não prova queda, vazamento de rota nem rejeição de prefixo.
  • A AFRINIC informa que redes upstream e operadoras de trânsito consultam IRRs para atualizar filtros; a redundância é, portanto, um sinal de manutenção dos dados, não um incidente a ser inflado.

O objeto ganhou três linhas, não três redes.

Essa é a diferença revelada por uma mensagem curta publicada na segunda-feira na lista do African Network Operators Group. S. Moonesamy consultou o WHOIS da AFRINIC, ordenou os membros de as-TelOneZW por frequência e deixou as repetições no topo: AS37183 três vezes e AS37123 duas.

O autor não atribuiu uma causa. Disse apenas que provavelmente havia uma explicação plausível. Uma verificação posterior da BTW reproduziu o estado atual: 24 declarações de membros e 21 números de AS distintos. O objeto se descreve como “TelOne ASNs”, aponta AS8668-MAINTAINER como mantenedor e registra AFRINIC como fonte.

Não é um boletim de indisponibilidade. É um caso estreito e reproduzível de um registro de política com mais linhas do que membros efetivos.

A repetição muda o texto, não o universo do conjunto

O RFC 2622 define um as-set como um conjunto cujo atributo members lista números de AS ou outros conjuntos. Nesse modelo, três ocorrências de AS37183 continuam valendo por um único membro. As duas ocorrências de AS37123 também. A contagem de ASNs distintos permanece 21.

Por isso, a afirmação técnica imediata precisa ser contida. Nem a mensagem da AfNOG nem o registro ao vivo demonstram rota descartada, origem incorreta, mudança de tráfego ou configuração de filtro quebrada. Uma expansão que respeite a lógica de conjunto não deveria obter um novo ASN distinto de uma linha redundante.

Também não é seguro presumir que todas as ferramentas tratem a representação intermediária da mesma forma. Algumas normalizam antes de gerar a configuração; outras podem preservar as linhas brutas em arquivos temporários, diffs, auditorias ou painéis. A evidência pública estabelece redundância na entrada, não o comportamento de todo consumidor.

Os dois ASNs repetidos pertencem a registros diferentes. A AFRINIC identifica AS37183 com Utande Internet Services (Pvt) Ltd e AS37123 com Telecontract Pvt Ltd, ambas no Zimbábue. A presença em um conjunto com o nome TelOne não comprova propriedade, vínculo societário nem a relação comercial atual. Um AS-set descreve escopo de política de roteamento, não uma árvore corporativa.

O valor do alerta está na manutenção que ele permite testar

Registros de Internet Routing Registry ficam na passagem entre uma declaração de política e sistemas capazes de transformá-la em controle. O RFC 2622 foi criado para descrever políticas no nível de AS com precisão suficiente para contribuir para configurações de roteadores. O guia público da AFRINIC acrescenta que operadoras de trânsito e provedores upstream consultam esses registros para atualizar filtros e sustentar consistência nas informações BGP.

Nada disso prova que os filtros derivados de as-TelOneZW estejam errados. A duplicidade mostra algo anterior: o dado de entrada pode se desalinhar sem mudar o resultado matemático.

Uma anomalia benigna é um teste barato. Repetir um ASN válido costuma ser idempotente, mas pode levantar perguntas sobre um processo que só acrescenta e não reconcilia, duas vias administrativas atualizando o mesmo objeto ou a ausência de validação final. São possibilidades, não conclusões. A mensagem não traz histórico de alterações nem causa-raiz.

A pergunta de governança, então, não é se três linhas derrubaram a Internet. É qual erro menos tolerante poderia passar pela mesma rotina. Um membro válido duplicado geralmente preserva o resultado; um membro vencido, uma ausência ou um conjunto aninhado indevido podem não preservar.

Antes de apagar cópias, é preciso validar os 21 membros

O primeiro passo responsável é confirmar se todos os 21 ASNs únicos ainda pertencem ao escopo pretendido. Depois, o mantenedor pode localizar a origem das três linhas redundantes e publicar uma atualização limpa, se for o caso. Remover cópias sem confirmar a intenção melhora a aparência do objeto, mas não valida a política.

Os controles também devem separar representação de expansão. Uma checagem compara quantidade de linhas com membros diretos únicos. Outra expande conjuntos aninhados, acompanha mudanças no tempo e distingue alertas por duplicidade, objeto ausente, inclusão inesperada e falha de expansão. A documentação da RIPE Database sobre consultas de conjuntos mostra por que a recursão precisa de um teste próprio: o resultado final pode depender de objetos além das linhas visíveis.

Quem gera filtros a partir de um IRR deve ainda guardar a procedência do artefato: registro consultado, horário, método de expansão e estado de revisão. Isso não torna o IRR infalível, mas permite rastrear uma entrada defeituosa antes que ela se transforme em uma configuração sem contexto.

A contribuição da mensagem da AfNOG está justamente na falta de drama. As três linhas extras não alteraram os 21 membros distintos. Mesmo assim, oferecem um teste claro para saber se a política é reconciliada, revisada e observável antes que o próximo erro deixe de ser inofensivo.

Fontes