Resumo

  • A RIPE NCC informou que um par da DE-CIX começou a enviar um número incomumente alto de mensagens BGP ao coletor RRC12 às 01:30 UTC de 2 de outubro; depois disso, o processo que consome atualizações do Kafka passou a expirar repetidamente.
  • Às 19:10 UTC daquele dia, o arquivo público do RRC12 ainda não tinha atualizações posteriores a 01:00 UTC. Isso é um atraso de publicação em um serviço de medição, não prova de rotas ausentes nem de interrupção do tráfego.

Análise

A RIPE NCC abriu às 09:42 CEST de 2 de outubro o incidente “RRC12 MRT update files are not produced”. O primeiro aviso indicava que o arquivo de atualização mais recente do RRC12 tinha horário de 01:00 UTC e que o último snapshot BVIEW era de 00:00 UTC. Às 13:26 CEST, a organização disse que um par da DE-CIX havia começado, às 01:30 UTC, a enviar um número incomumente alto de mensagens BGP ao RRC12. Segundo a RIPE, o processo que consumia as atualizações do Kafka não acompanhou esse volume; a cada reinício, voltava a expirar antes de avançar o suficiente.

A organização também relatou atrasos na produção de arquivos de atualização de outros RRCs.

O RRC12 é um coletor de rotas em Frankfurt conectado à DE-CIX. Coletores recebem dados BGP de seus pares; não escolhem as rotas usadas por essas redes. A documentação da RIPE informa que os dados são armazenados por coletor: arquivos “update” registram mudanças durante um intervalo, enquanto arquivos BVIEW guardam um snapshot de estado. A RIPE diz que os arquivos de atualização normalmente são criados a cada cinco minutos. Essa é a cadência habitual de publicação do fluxo de observação, não uma garantia de que todos os coletores sempre a cumpram.

Uma consulta somente de leitura ao arquivo público da RIPE às 19:10 UTC não encontrou atualização do RRC12 posterior a updates.20261002.0100.gz, 18 horas e 10 minutos antes da verificação. O arquivo do RRC18 havia chegado a 19:05 UTC. Essa comparação mostra a diferença de atualização visível entre os dois diretórios naquele momento; não prova que todos os outros coletores estavam livres de impacto, não identifica quais tiveram atrasos anteriores nem explica por que o RRC18 tinha arquivos mais recentes.

No corte da análise, o incidente seguia identificado e em investigação. A página não informou o nome ou ASN do par, sua taxa de mensagens, as rotas envolvidas, por quanto tempo outros coletores atrasaram, o estado de reprocessamento da fila ou o plano de recuperação. Também não disse que rotas foram perdidas ou que o tráfego foi afetado. Um arquivo atrasado exige que o analista confira o horário antes de interpretar um intervalo vazio; ele não prova que não houve mudanças BGP.

A próxima informação útil seria um comprovante breve de recuperação: os horários mais recentes dos arquivos update e BVIEW nos coletores afetados, se os intervalos atrasados foram reprocessados e quando a publicação normal foi retomada. Isso permitiria a quem usa RIS distinguir coleta, processamento e publicação sem confundir atraso de arquivo com mudança no sistema de roteamento.

Fontes