Cloudflare detalha outage de BYOIP causado por retirada de rotas BGP

A Cloudflare publicou a análise de um outage que afetou clientes usando BYOIP, Magic Transit, Spectrum, CDN e serviços de egress dedicados associados a endereços próprios.¹ O incidente começou quando prefixos deixaram de ser anunciados corretamente pela rede, impedindo que tráfego fosse atraído para a Cloudflare e causando falhas de conexão para usuários finais.

O caso é um lembrete duro de que infraestrutura de rede moderna depende tanto de BGP e propagação global quanto de APIs internas, tarefas automatizadas e consistência de configuração. Quando a fonte de verdade para endereços muda errado, o impacto aparece na borda da internet.

Uma consulta sem valor retirou prefixos demais

A Cloudflare explica que a Addressing API funciona como dataset autoritativo dos endereços presentes na rede. Mudanças nessa API são propagadas para a borda e instruem máquinas e roteadores sobre anúncios ou retiradas de prefixos.¹ Esse desenho permite automação, mas também torna alterações nessa camada extremamente sensíveis.

O problema ocorreu em uma subtarefa de limpeza criada para automatizar a remoção de prefixos BYOIP que deveriam sair do serviço. A rotina consultava a API com o parâmetro pending_delete sem valor. Na implementação, porém, a API verificava Query().Get("pending_delete") e só tratava o caso especial quando o valor não era vazio.¹ Como a consulta veio vazia, o servidor interpretou a chamada como pedido por todos os prefixos BYOIP, não apenas pelos pendentes de remoção.

A partir daí, a subtarefa passou a remover sistematicamente prefixos BYOIP e objetos dependentes, incluindo service bindings, até que o impacto fosse percebido e a rotina desligada por um engenheiro.¹ É uma falha pequena na forma de consultar e interpretar um parâmetro, mas com blast radius grande porque o sistema conectava API, estado de endereçamento e anúncios de rede.

A recuperação variou conforme o estado de cada cliente

O impacto não foi uniforme. Clientes de CDN e segurança em intervalos afetados podiam ver falhas de conexão porque o tráfego não era atraído para a Cloudflare. Aplicações Spectrum em BYOIP falhavam pelo mesmo motivo. Usuários de Dedicated Egress e Magic Transit também foram afetados quando seus prefixos deixaram de ser anunciados ou perderam vínculos necessários.¹

A recuperação também não foi instantânea. Segundo a Cloudflare, alguns clientes tinham apenas prefixos retirados e conseguiam restaurar serviço alternando anúncios no painel. Outros tinham prefixos retirados e parte dos bindings removidos. O grupo mais difícil tinha prefixos retirados e todos os service bindings removidos, exigindo atualização global de configuração para reaplicar vínculos em todas as máquinas de borda.¹

Esse detalhe é importante para operações de rede: voltar a anunciar um prefixo pode não bastar se o estado do produto que usa aquele endereço também foi apagado. Endereço, rota e serviço precisam convergir juntos. Caso contrário, a internet volta a encontrar o caminho, mas a aplicação na borda ainda não sabe como tratar aquele tráfego.

Automação segura precisa de rollout controlado

A Cloudflare associa o incidente ao programa Code Orange: Fail Small, justamente uma iniciativa para tornar mudanças de código e configuração mais resilientes.¹ A ironia operacional é que a automação buscava remover um processo manual arriscado, mas entrou em produção antes de controles suficientes para limitar o impacto da mudança.

A empresa afirma que o ambiente de staging e os testes existentes não cobriram o cenário em que um task-runner executaria alterações em dados de usuários sem entrada explícita.¹ Essa lacuna é comum em sistemas complexos. Testes validam a jornada direta do cliente, mas deixam passar atores internos, tarefas agendadas, migrações e rotinas de manutenção que têm poderes semelhantes aos de produção.

Para equipes de plataforma, a lição é concreta. APIs que controlam estado global precisam distinguir com rigor presença de parâmetro, valor vazio e ausência. Tarefas automáticas precisam de limites de volume, dry run, aprovação, canary, rollback e alarmes por anomalia. Configuração propagada para rede deve avançar gradualmente, com health checks capazes de interromper a mudança antes que ela atravesse todo o plano de controle.

O outage de BYOIP mostra que confiabilidade de internet é feita de detalhes de software. Um parâmetro sem valor, uma consulta ampla demais e uma rotina com permissão para apagar estado podem produzir efeito equivalente a retirar rotas críticas da rede. Em ambientes de escala global, falhar pequeno não é slogan; é requisito arquitetural.