Resumo

  • Segundo a RIPE NCC, um volume elevado de mensagens BGP sobrecarregou uma partição Kafka; após a reinicialização, uma falha latente fez o processo revarrer muitos dados e expirar repetidamente.
  • Uma correção de configuração permitiu a recuperação, e a RIPE NCC informa que os arquivos BVIEW e de atualizações desde 2 de outubro foram produzidos com sucesso. A correção estrutural da falha ficou para um próximo sprint.
  • Recuperar os arquivos públicos não significa eliminar o caminho de falha. O incidente foi na produção de dados do RIPE RIS, não uma evidência de rotas desaparecidas ou tráfego interrompido.

Os arquivos voltaram antes de a correção terminar

Em 6 de outubro, a RIPE NCC encerrou o incidente de produção dos arquivos MRT e BVIEW do RRC12 com duas afirmações distintas. Depois da recuperação do processo, os arquivos desde 2 de outubro haviam sido produzidos com sucesso. A recuperação imediata veio de uma correção de configuração. Separadamente, a organização disse que trabalharia em uma correção estrutural para a falha latente no sprint seguinte.

São estados diferentes. O arquivo público foi reposto; o mecanismo que fazia o processo falhar a cada reinício ainda não havia sido descrito como corrigido estruturalmente. Um serviço pode voltar a operar enquanto uma tarefa de engenharia continua aberta. Tratar o primeiro fato como prova do segundo faria o aviso de status afirmar mais do que afirma.

A RIPE NCC situa o início às 01:30 UTC de 2 de outubro, quando um peer da DE-CIX começou a enviar um volume incomum de mensagens BGP ao RRC12. O pipeline que consome dados do Kafka não acompanhou o volume. Um processo expirou; após reiniciar, expirou de novo antes de avançar o suficiente. A RIPE NCC também observou atrasos na produção de arquivos de atualização de outros RRCs.

A explicação posterior acrescentou o fator de amplificação: a carga se concentrou em uma única partição Kafka. Quando o processo reiniciou, uma falha latente provocou uma nova varredura de grande volume de dados na inicialização. A varredura expirava repetidamente e impedia o progresso. Um problema de configuração a tornava uma ordem de grandeza mais demorada do que deveria. Corrigir a configuração permitiu a recuperação; a mudança estrutural ainda estava por fazer.

O que os arquivos registram

O RRC12 é o coletor de rotas da RIPE em Frankfurt, na DE-CIX. A documentação da RIPE distingue dois artefatos públicos. Um BVIEW é uma fotografia do estado do roteamento em determinado instante; um arquivo de atualizações registra mudanças ao longo de um intervalo. A cadência habitual documentada é de oito horas para dumps e cinco minutos para atualizações. A RIPE diz que arquivos MRT podem apoiar depuração de BGP, análises posteriores e estudos de tendências.

Por isso, um atraso de publicação dificulta reconstruir um período usando evidências públicas. Isso não transforma o incidente em uma falha de roteamento. O registro comprova atraso na geração de arquivos, não rotas ausentes, tráfego interrompido, intenção maliciosa do peer ou dano a clientes. Não identifica o peer nem quantifica a taxa de mensagens, a profundidade da fila, o atraso de cada outro coletor ou quantas análises foram afetadas.

O índice de outubro agora lista nomes de arquivos BVIEW e de atualização até 7 de outubro. É uma verificação atual de que o diretório público contém artefatos posteriores. Não prova que cada arquivo esteja completo, que os dados regenerados tenham passado por uma auditoria independente de integridade ou que toda análise subsequente reproduza o resultado que um fluxo contínuo teria produzido.

A recuperação tem mais de uma linha de chegada

Não se deve condensar o incidente em um único status verde. Primeiro, o volume deixou de bloquear o processamento. Depois, o processo reiniciado conseguiu avançar. Em seguida, os arquivos ausentes foram gerados. Separadamente, a rota defeituosa de inicialização continuou como trabalho estrutural. São afirmações operacionais diferentes.

Em um sistema de medição, restaurar o arquivo responde: “os arquivos voltaram a ser produzidos?”. Não responde por completo: “a condição que tornava a recuperação frágil foi removida?” ou “a série recuperada foi verificada como completa?”. A atualização pública responde à primeira pergunta e aponta trabalho futuro para a segunda. Não publica um comprovante independente de completude para a terceira.

Isso não prova que a recuperação da RIPE NCC foi inadequada. O aviso público simplesmente é mais limitado que um relatório pós-incidente completo. Ele identifica o gatilho, a carga concentrada em uma partição, a revarredura após o reinício, a correção da configuração e a futura mudança estrutural. Não revela identidade do peer, taxa de mensagens, métricas da fila, janela de atraso por coletor, método de validação ou identificador da versão corrigida.

Para quem usa um arquivo público de medições, um bom registro de encerramento conectaria esses pontos sem expor detalhes sensíveis: coletores e intervalos afetados, arquivos regenerados, validações executadas, solução temporária ativa, mudança estrutural pendente e data de verificação. Um histórico datado permitiria distinguir disponibilidade restaurada de correção de confiabilidade concluída.

A conclusão cuidadosa é modesta. Os arquivos do RRC12 foram recuperados depois que uma carga elevada expôs uma fragilidade na reinicialização, amplificada pela configuração. A RIPE NCC disse que a correção estrutural ainda estava por vir. O arquivo não representa sozinho todo o roteamento da Internet, e o aviso não prova falha de rotas. Mas a diferença entre “os arquivos voltaram” e “o caminho de recuperação foi corrigido” precisa ficar legível.

Fontes