Resumo

  • A RIPE NCC atribuiu a interrupção dos arquivos do RRC12 em 2 de outubro ao volume excepcional de mensagens BGP de um peer da DE-CIX, à carga em uma partição Kafka e a uma revarredura que expirava a cada reinício.
  • O operador informou que arquivos de atualização de outros coletores também atrasaram. Uma correção de configuração permitiu retomar o processamento; uma correção estrutural ainda estava prevista.

O alcance informado é o ponto central: a RIPE NCC não descreveu apenas uma parada local no RRC12. Segundo o registro, a produção dos arquivos de atualização de outros route collectors também ficou atrasada. Trata-se de um problema na produção de evidências de roteamento. O aviso não diz que o encaminhamento de pacotes pela Internet parou.

O registro do incidente informa que, às 01:30 UTC de 2 de outubro, um peer da DE-CIX passou a enviar um volume excepcional de mensagens BGP ao RRC12. O processo que consumia dados do Kafka não acompanhou o volume e expirou. Após reiniciar, tentou percorrer novamente uma grande quantidade de dados e voltou a expirar antes de avançar. A RIPE NCC acrescentou que uma configuração incorreta no código fazia essa varredura demorar uma ordem de grandeza a mais do que o previsto. Corrigir a configuração permitiu que o processo avançasse. O operador disse que trataria estruturalmente o defeito latente em um sprint posterior.

A sequência combina dois mecanismos. Primeiro, a carga de entrada superou o ritmo de processamento e formou um acúmulo. Depois, o método de recuperação repetiu uma varredura ampla, tornando cada reinício uma nova tentativa lenta. O registro não divulga a identidade do peer, o volume por segundo, a topologia das partições, a profundidade da fila, os tempos-limite nem o detalhe do código de revarredura. É possível descrever a explicação operacional publicada sem preencher essas lacunas por inferência.

O RIS coleta dados de roteamento BGP para que outros possam observar mudanças na rede. A documentação de route collectors os descreve como máquinas físicas ou virtuais que recebem dados por sessões com peers; o RRC12 aparece em Frankfurt, no escopo da DE-CIX. A documentação de MRT informa que os dados são guardados por coletor: dumps representam um estado em determinado momento, e arquivos update registram alterações observadas em um intervalo. A cadência documentada é de oito horas para dumps e cinco minutos para updates. Isso descreve o cronograma normal, não comprova que cada arquivo do incidente esteve completo e disponível no prazo.

Às 09:42 CEST de 2 de outubro, o status da RIPE NCC indicava que o update mais recente do RRC12 tinha carimbo de 01:00 UTC e o último bview, de 00:00 UTC. Esse registro mostra a idade das evidências naquele momento. Não indica quando a produção efetivamente parou nem o volume máximo acumulado. Mais tarde, a RIPE NCC informou que, depois que o processo inicial se recuperou, publicou os arquivos bview e update desde 2 de outubro. É uma declaração do operador sobre a recuperação do atraso, não uma auditoria arquivo a arquivo nem uma medição do impacto para usuários.

Há uma diferença entre a rota na rede e o registro dessa rota. O RFC 6396 define o formato MRT para exportação de informações de roteamento. Um arquivo MRT atrasado limita o que um pesquisador consegue observar no arquivo naquele período. Isso, sozinho, não demonstra queda de sessão BGP, retirada de rota da rede ativa ou perda de conectividade por um cliente. Ainda assim, falta de evidência pode afetar operadores e equipes de resposta que precisam reconstruir uma sequência de eventos. A RIPE NCC não quantificou esse efeito no comunicado, portanto não cabe presumir que ele ocorreu.

O atraso em outros coletores levanta a questão de isolamento. A entrada veio pelo RRC12, e a RIPE NCC atribuiu carga a uma única partição Kafka; ao mesmo tempo, relatou atraso nos updates de outros RRCs. Isso aponta para uma dependência compartilhada no caminho de processamento descrito, mas não oferece uma arquitetura completa nem revela como todas as mensagens eram distribuídas. A conclusão mais estreita é que, conforme o operador, o impacto ultrapassou o coletor que recebeu o pico. Indicadores de frescor entre coletores e limites que evitem propagação são, assim, controles relevantes.

O plano publicado antes do incidente ajuda a entender as prioridades existentes, mas não explica a ocorrência. O plano trimestral do RIS da RIPE NCC, atualizado em 17 de setembro, já listava melhorias no monitoramento do processamento de dados RIS/RIPEstat para o quarto trimestre. Também registrava, como trabalho em andamento, a substituição das máquinas Kafka e a atualização para uma nova versão, depois de um adiamento por limitações de recursos. A investigação de armazenamento alternativo para reduzir a dependência do HBase também seguia em andamento. O documento não associa esses itens ao incidente de outubro nem afirma que algum deles produziu a recuperação.

A mesma página menciona uma política de peering revisada para manter pares relevantes e diversos sem deixar o volume de dados crescer além do sustentável. Mais pares podem ampliar o valor do arquivo, mas cada entrada exige processamento. Nada nesse caso prova que o peer era dispensável, agiu de forma incorreta ou causou um defeito de projeto. A decisão de operação é preservar uma fonte útil e medir seu custo, ao mesmo tempo em que se limita o efeito de um pico sobre os demais arquivos.

O próximo recibo de recuperação deveria indicar quais arquivos atrasaram, qual intervalo cada um deveria cobrir, quando voltou a publicação, se o acúmulo foi reproduzido sem lacunas ou duplicatas e como essa verificação foi feita. Um teste de capacidade deveria registrar o volume de entrada exercitado, o atraso máximo, o comportamento do reinício com fila acumulada e a condição que afeta outro coletor. Assim, “resolvido” pode significar mais do que o processo voltou a andar: pode explicar quais evidências foram recuperadas e quais riscos permanecem.

A Nota 70 de Heng Lu, sobre a diferença entre capacidade técnica e realidade prática, serve somente como lente editorial para separar um sinal técnico das conclusões que ele autoriza. Não é fonte sobre o RIS. Os fatos e o estado das atividades vêm das páginas da própria RIPE NCC; as medidas de confiabilidade propostas aqui são análise.

A página marcou o incidente como resolvido em 6 de outubro. A correção de configuração que liberou o processamento e o reparo estrutural prometido para o defeito latente são marcos distintos. A primeira restaurou o avanço imediato. O segundo precisa ser acompanhado de testes de carga e reinício para mostrar se um próximo pico pode ser absorvido sem repetir o ciclo. O registro público sustenta essa distinção, mas ainda não apresenta o resultado do teste.

Fontes