A falha de 2022 da Cloudflare tornou o estágio de mudança de BGP um teste de responsabilidade

Resumo

• Em 21 de junho de 2022, a Cloudflare afirmou que uma mudança de configuração de rede causou uma indisponibilidade em 19 data centers com a arquitetura Multi-Colo PoP (MCP). Esses locais representavam cerca de quatro por cento da rede, mas concentravam grande parte do tráfego. A Cloudflare atribuiu aproximadamente metade do total de requisições durante o evento ao tráfego afetado, observando que o impacto para usuários variou por localidade. [1]
• A mudança pretendida padronizava comunidades BGP informacionais em prefixos site-local. Nos roteadores de spine do MCP, uma reordenação de termos de política colocou um termo de prefixos desativados antes de termos que deveriam anunciar rotas site-local críticas. O resultado foi a retirada dessas rotas na política de exportação. [1]
• A retirada removeu mais do que alcançabilidade externa. A Cloudflare diz que seus servidores não conseguiam se comunicar normalmente nem alcançar origens de clientes, e seu Multimog, layer de balanceamento de carga interno, não conseguia mover requisições entre clusters de computação dentro dos MCP afetados. Clusters menores então receberam tráfego comparável ao de clusters maiores e se sobrecarregaram. [1]
• Engenheiros também tiveram dificuldade para alcançar os locais afetados e desfazer a mudança. Procedimentos de backup foram usados para retomar o controle. Durante a restauração, os engenheiros às vezes sobrescreviam os reverts uns dos outros', fazendo o problema reaparecer esporadicamente antes da recuperação final do local. [1]
• O processo da Cloudflare já incluía ticket de mudança, dry-run, revisão por pares e implantação escalonada. A falha de controle foi mais específica: nenhuma das etapas iniciais exercitou uma localização MCP. A primeira etapa representativa chegou quando a etapa final alcançou todos os spines MCP. [1]
• Comunidades BGP são metadados usados por política de roteamento. Elas não comprovam que uma política de exportação está corretamente ordenada ou que os prefixos exigidos permaneçam anunciados. A validação de origem RPKI verifica se um AS de origem está autorizado para um prefixo; não valida essa ordem interna de termos, seleção de canário ou procedimento de rollback. [10][11][12][14][15][16]
• Responsabilização deve, portanto, exigir evidência operacional: a configuração candidato exata antes e depois, um conjunto de prefixos exigidos verificável por máquina, simulação de política de rota, canário específico MCP, comportamento commit-confirm, alcançabilidade de gestão independente, um dono único de rollback, registros por local e observações de rota externas reconciliadas com logs de roteador.
• Coletadores públicos de rotas podem ajudar a estabelecer anúncios e retiradas visíveis externamente, mas não revelam todas as rotas site-local privadas ou decisões internas de política. Registros do operador permanecem necessários. [17][18][19]
• O registro público não estabelece intenção maliciosa, negligência, violação regulatória, todos os prefixos afetados, perda de todos os clientes, ou se toda a remediação informada permanece implantada. Esses limites devem permanecer explícitos.

Uma mudança revisada ainda pode ser uma mudança não testada

Organizações de infraestrutura costumam usar etiquetas de processo como atalho para controle. Uma mudança foi ticketed. Um dry-run foi concluído. Vários engenheiros a revisaram. O rollout foi escalonado. Cada afirmação pode ser verdadeira, enquanto o risco operacional permanece não testado.

O relato da Cloudflare sobre a indisponibilidade de 21 de junho de 2022 torna essa distinção incomumente clara. A mudança passou por um ticket de solicitação de alteração, incluiu dry-run, recebeu revisão por pares e seguiu um procedimento de implantação por etapas. As etapas iniciais não causaram indisponibilidade. A falha surgiu quando o rollout alcançou os 19 locais com arquitetura Multi-Colo PoP, ou MCP. Nenhuma das etapas anteriores exercitou uma localidade MCP. A primeira etapa que representava a topologia de roteamento relevante também foi a etapa que aplicou a configuração a todos os spines MCP. [1]

Isso não é argumento de que tickets, revisões, dry-runs ou estágios são inúteis. É evidência de que cada controle precisa de uma alegação definida. Um ticket registra autorização e intenção. Uma revisão registra que pessoas nomeadas examinaram alguma representação da mudança. Um dry-run registra o que uma ferramenta calculou contra um estado de modelo ou dispositivo especificado. Um rollout escalonado limita o escopo apenas quando cada etapa é representativa de um domínio de falha distinto e pequena o bastante para interromper antes da próxima.

A pergunta de responsabilização é, portanto, não: "O processo existiu?" É: "O que cada etapa do processo provou?" Nesse incidente, a etapa inicial provou que a mudança não interrompeu locais com a arquitetura anterior. Não provou que a política manteria anúncios obrigatórios nos spines MCP. Um resultado positivo de local não representativo não podia responder à pergunta decisiva.

Essa lacuna importa porque configuração de rede é autoridade operacional executável. Um termo de política de rota não descreve apenas para onde deve ir o tráfego. Sua ordem determina quais rotas um roteador anuncia ou oculta. Após o commit, a configuração altera o grafo de alcançabilidade usado por servidores, peers, origens, operadores e sistemas de recuperação. A diferença entre uma adição de metadados inofensiva e uma grande indisponibilidade pode ser um branch de política avaliado antes de outro.

O relatório da Cloudflare não deve ser reduzido ao slogan de que uma configuração ruim causou uma indisponibilidade. A lição útil é mais estreita e mais exigente: controles de mudança devem estar vinculados à arquitetura, invariantes de rota, domínios de falha e acesso de recuperação. Um procedimento escalonado que ignora a arquitetura relevante pode criar aparência de cautela sem fornecer evidência sobre o sistema que efetivamente falhará.

A mudança pretendida era informativa; a mudança efetiva foi a alcançabilidade

A Cloudflare disse que estava padronizando comunidades BGP anexadas a um subconjunto de prefixos anunciados, especificamente adicionando comunidades informacionais aos prefixos site-local. Comunidades BGP são atributos que operadores usam para rotular rotas e influenciar política de roteamento. A especificação de comunidades padrão define uma forma de agrupar destinos para que decisões de roteamento possam se aplicar a uma classe de rotas, em vez de um prefixo por vez. Large Communities ampliam o formato para necessidades operacionais modernas. [1][11][12]

As adições pretendidas não foram descritas como um esforço para retirar rotas de serviço. A Cloudflare as caracterizou como informação inofensiva nos roteadores comuns mostrados em seu relatório. A diferença com efeito concreto apareceu nos roteadores spine MCP. Um diff de configuração reordenou termos em uma política de exportação agregada. Um termo associado a prefixos desativados foi movido antes de termos que anunciavam rotas site-local para serviços e funções internas. Como os termos de política são avaliados sequencialmente, o match anterior impediu a lógica posterior de anúncio de executar seu trabalho. [1]

Essa é a diferença entre intenção semântica e comportamento efetivo. O autor de uma mudança pode pretender anexar metadados. Um revisor pode ver adições de comunidade. Um ticket pode usar título dizendo "padronizar comunidades." Nenhuma dessas representações controla o roteador. O roteador avalia a política resultante na ordem. Se a configuração gerada ou renderizada muda essa ordem, o efeito operacional é o que o mecanismo de política executa.

O próprio BGP fornece o mecanismo de alcançabilidade. Redes anunciam prefixos para informar peers que endereços são alcançáveis por um caminho. Elas retiram rotas quando essa alcançabilidade não está mais disponível ou não deve mais ser anunciada. Um prefixo retirado pode desaparecer de caminhos selecionados, tornando os endereços associados inalcançáveis por essa rota. A especificação BGP-4 define semântica desses anúncios e retiradas; não conhece a intenção de negócios de um operador para um termo de política específico. [10]

Essa distinção cria uma exigência de evidência. Aprovação da mudança deve amarrar-se à configuração candidato exata que o roteador avaliará, não apenas a uma solicitação de nível superior ou template gerado. O registro de revisão deve mostrar:

1. A política renderizada exata antes e depois da mudança.
2. A ordem de avaliação de todos os termos afetados.
3. O conjunto de rotas esperado para aceitação, rejeição, anúncio e retirada.
4. A origem de cada prefixo nesse conjunto.
5. As funções de dispositivo e arquiteturas onde a política será executada.
6. Uma simulação ou resultado de laboratório usando entradas de rota representativas.
7. Os caminhos de gestão e rollback que permaneçam alcançáveis se a saída da política estiver incorreta.

Sem esses vínculos, revisão pode verificar a solicitação enquanto perde o efeito compilado. A responsabilização de infraestrutura segue a configuração consumida pelo sistema em execução.

Os prefixes site-local faziam parte do caminho de serviço

O termo "site-local" pode parecer secundário, como se as rotas afetadas fossem entradas administrativas com pouca consequência de cliente. O relatório da Cloudflare mostra o contrário. Os prefixos habilitaram comunicação entre suas máquinas e permitiram que servidores alcançassem origens de clientes. Sua retirada interrompeu esses caminhos. [1]

A Cloudflare também vinculou os prefixos ao Multimog, um sistema interno de balanceamento de carga usado em locais MCP. O Multimog não conseguiu mais encaminhar requisições entre servidores nos MCP porque a alcançabilidade relevante desapareceu. Clusters de computação de tamanhos diferentes então receberam cargas de tráfego semelhantes. Clusters menores sobrecarregaram. [1]

Esse mecanismo importa porque explica por que uma parcela de retiradas de rota pode ter efeito de serviço muito maior do que uma simples contagem de prefixos ausentes sugere. Um prefixo pode suportar uma dependência compartilhada por muitos serviços. Se ele carrega alcançabilidade de origem, comunicação interna de cluster ou caminho de balanceamento, sua retirada altera como o trabalho é distribuído pelo sistema. Um serviço pode ainda receber tráfego na borda enquanto perde as rotas internas necessárias para processar ou encaminhar esse tráfego com segurança.

O evento, portanto, testa como um operador classifica a criticidade da rota. Um registro de prefixos não deve parar em propriedade ou autorização de origem. Deve registrar o papel operacional:

• O prefixo é voltado para Internet, apenas gestão, site-local, frente à origem do cliente, ou inter-cluster?
• Quais roteadores e políticas o anunciam?
• Quais serviços dependem dele?
• Quais checagens de monitoramento comprovam que ele é alcançável?
• Quais locais compartilham o mesmo template de política?
• O que ocorre se a rota desaparecer, mas o tráfego de entrada continua?
• O acesso de gestão usa a mesma família de rotas ou política?
• Qual caminho alternativo é esperado para carregar a dependência?

Esse registro não é soberano sobre a rede. Ele não faz uma rota existir. Cria um ledger testável do estado esperado. Operadores podem comparar o ledger com a rota-base de informação, a forwarding information base, coletadores externos, probes ativos e resultados de nível de serviço. Um registro que seja preciso, único, com mudança controlada e ligado a comportamento observado torna uma retirada detectável antes que clientes se tornem o sistema de monitoramento.

O efeito do Multimog também mostra por que a capacidade precisa de contexto de topologia. A Cloudflare disse que os locais MCP afetados continham clusters de tamanhos diferentes. Quando o encaminhamento interno falhou, clusters menores receberam tráfego semelhante ao de clusters maiores. Um dashboard de capacidade que mostrasse capacidade total de site poderia, portanto, superestimar capacidade utilizável. A falha de rota removeu o mecanismo de balanceamento que tornava acessível a capacidade agregada.

Uma revisão com evidência perguntaria se cada MCP tinha um modo degradado testado. O tráfego poderia ser drenado externamente quando Multimog perdesse alcançabilidade site-local? Clusters menores poderiam se proteger com controles de admissão? A canary da política de rota incluía sondas para acesso de origem, encaminhamento inter-cluster e acesso de gestão, e não apenas saúde de sessão BGP? O relatório público identifica a dependência, mas não publica todos os controles protetivos.

Dezenove locais revelaram concentração dentro de uma rede distribuída

A Cloudflare disse que os 19 locais MCP eram cerca de quatro por cento da sua rede, ainda assim a indisponibilidade afetou aproximadamente 50 por cento do total de requisições. Também enfatizou que o impacto variou por local: alguns usuários não puderam alcançar propriedades usando a Cloudflare, enquanto outros locais continuaram a operar normalmente. [1]

Esses números devem permanecer atribuídos e não devem ser convertidos em contagem de pessoas, clientes, websites ou perdas financeiras. Eles apoiam uma lição de topologia. Uma rede pode ser geograficamente distribuída enquanto o tráfego permanece concentrado em um pequeno conjunto de locais de alta capacidade. Contar locais não é o mesmo que medir a participação de tráfego, dependências de clientes, capacidade de peering ou conectividade de origem carregada por eles.

O programa MCP pretendia melhorar a resiliência nos locais mais movimentados. A Cloudflare descreveu uma arquitetura estilo Clos com camada adicional de roteamento e malha de conexões spine. A arquitetura permitia habilitar ou desabilitar partes de uma rede interna para manutenção ou manejo de falhas. Esses são objetivos legítimos de resiliência. O incidente não prova que a arquitetura era inerentemente inadequada. [1]

Mas mostra que um caminho de política comum pode conectar locais fisicamente separados. Se a mesma política renderizada chega a todos os spines MCP em uma etapa final, o template da política torna-se um domínio de falha compartilhado. A diversidade física não remove essa dependência de controle comum.

Esse é um padrão recorrente de responsabilização de rede. Operadores podem ter múltiplos roteadores, instalações, carriers e caminhos, mas uma única automação de template, sistema de credenciais, política de rota, controller ou etapa de rollout pode ainda criar falha em modo comum. A diversidade precisa ser medida na superfície de controle que causou o incidente.

Para implantação MCP, um mapa de mudança útil incluiria:

O quadro evita que uma etapa inicial de baixo risco seja confundida com uma etapa representativa. Um canário deve ser pequeno, mas precisa exercitar a feature e arquitetura alteradas. Se o único site representativo carregar tráfego demais para servir de canário, isso já é risco operacional e arquitetural que exige gêmeo de laboratório, avaliação em shadow, domínio representativo menor ou invariantes estáticas mais fortes antes da produção.

Perder a alcançabilidade de gestão mudou o problema de recuperação

A Cloudflare disse que a retirada de rota tornou mais difícil para engenheiros alcançarem os locais afetados e reverterem a configuração. Foram usados procedimentos de backup para assumir controle. [1]

Esse detalhe pertence ao centro da análise. Uma mudança de rede não é reversível com segurança apenas porque um comando de rollback existe. O operador ainda precisa autenticar, alcançar o dispositivo, determinar o estado correto e coordenar o rollback enquanto a rede está degradada. Se o tráfego de gestão depende das rotas em mudança, o caminho de recuperação compartilha o domínio de falha.

Acesso independente não exige necessariamente uma rede global totalmente separada para cada dispositivo. Exige projeto razoado que sobreviva à falha em teste. As opções podem incluir servidores de console em uma rede de gestão roteada separadamente, links carrier out-of-band, automação local capaz de executar rollback programado, recursos de commit-confirm em dispositivo, acesso terminal protegido ou canal de controle cuja alcançabilidade não dependa da política candidata.

Cada opção tem limites. Um carrier out-of-band pode compartilhar instalação ou fonte de energia. Um servidor de console pode depender do mesmo provedor de identidade ou DNS. O timer de commit-confirm pode ser cancelado cedo demais ou falhar em restaurar todo o estado dependente. A automação local pode aplicar baseline incorreto. A responsabilização exige exercícios que provem que o caminho selecionado funciona sob a condição exata de perda.

O teste relevante para este incidente é direto: retirar ou suprimir o conjunto de rotas que oferece alcançabilidade site-local e de gestão em um ambiente MCP representativo, depois verificar se os operadores ainda conseguem inspecionar estado e restaurar configuração aprovada. O exercício deve medir tempo para acesso, tempo para identificar a invariável falhada, tempo para iniciar rollback, tempo para restaurar anúncios obrigatórios e tempo para confirmar recuperação de serviço.

Uma captura de tela de login normal em dia comum não basta. O teste precisa remover a dependência que falhou. Evidência de operação em produção prevalece sobre um diagrama que rotule um caminho como "out-of-band."

O relatório público não identifica todos os procedimentos de backup usados, o que é razoável por razões de segurança e operação. Topologia sensível e credenciais não devem ser publicados. Uma organização ainda pode manter evidência auditável sob controles de acesso: horários de exercício, escopos de dispositivo, atestações independentes, sondas de rota, critérios de sucesso e exceções.

A autoridade de rollback falhou como controle de coordenação

A linha do tempo da Cloudflare diz que os últimos reverts foram atrasados porque engenheiros de rede sobrescreveram mudanças de colegas. Alguns reverts desfizeram reversões anteriores, fazendo o problema reaparecer esporadicamente. [1]

Isso não é apenas um detalhe de erro humano. Identifica uma propriedade de serialização ausente na resposta ao incidente. Durante uma indisponibilidade de alto impacto, múltiplos engenheiros podem ter acesso válido e motivos fortes para agir. Se o sistema de mudança não fornecer um estado desejado autoritativo único, propriedade visível, bloqueio por dispositivo e registro de progresso compartilhado, trabalho paralelo pode produzir oscilação.

A lição operacional não é que apenas uma pessoa deve responder sempre. Investigação, observação de rota, comunicação com clientes, teste de serviço e preparação de rollback podem seguir em paralelo. A mutação do mesmo estado de roteamento precisa de coordenação. O sistema deve dificultar que um respondente reintroduza a configuração que outro tenha removido.

Controles úteis incluem:

• Um comandante de incidente e dono de mudança de rede declarados.
• Um commit desejado congelado para a recuperação.
• Bloqueios de dispositivo ou domínio de política durante rollback.
• Um único orquestrador que registra cada tentativa e rollback concluído.
• Timers de commit-confirm que restauram automaticamente o estado anterior se a confirmação de gestão é perdida.
• Observadores de leitura que verificam rota e recuperação de serviço sem mudar configuração.
• Uma regra de que mudanças manuais de emergência sejam reconciliadas no estado autoritativo antes que a automação normal retorne.
• Passagem formal de posse quando a propriedade se move entre equipes ou regiões.

Esses controles devem produzir um ledger por local. Para cada MCP, o registro deve mostrar identificador da má configuração, comando de rollback ou commit, executor, horário de início e fim, reconhecimento de dispositivo, resultado de tabela de rotas, alcançabilidade de gestão, sonda de serviço e qualquer mudança posterior que tocou a mesma política. O ledger torna interferência visível e apoia declaração confiável de que o último local foi restaurado.

Entre as ações de remediação da Cloudflare estavam rollback automático por commit-confirm e enforcement de stagger melhorado. [1] Um mecanismo commit-confirm é especialmente relevante quando uma mudança de rota pode remover acesso de gestão. O roteador pode restaurar automaticamente o estado anterior, salvo confirmação do operador após validações de alcançabilidade e invariáveis aprovadas.

Commit-confirm não é magia. O timeout deve ser longo o suficiente para validação, e curto para limitar impacto. O estado anterior precisa ser seguro por si só. A confirmação não pode ser automatizada apenas por sinal fraco. Mudanças multi-dispositivo exigem semântica coordenada para que um roteador não reverta enquanto outro permanece no candidato. O mecanismo ainda precisa de exercícios e evidência.

O processo existia; suas obrigações de prova estavam incompletas

O relatório da Cloudflare explicitamente diz que a mudança tinha ticket, dry-run, rollout escalonado e múltiplos revisores por pares. [1] Isso torna o incidente útil para organizações que já possuem maturidade em vocabulário de gestão de mudanças.

Uma resposta pós-mortem fraca adicionaria outra aprovação. Mais assinaturas podem reduzir velocidade sem testar a condição ausente. As evidências apontam para quatro perguntas mais fortes.

Primeiro, qual entrada o dry-run utilizou? Se renderizava política apenas para arquitetura anterior, não poderia revelar o efeito de ordem de termo MCP. Um dry-run deve incluir todo papel de política afetado pela lógica de geração, especialmente papéis com templates diferentes ou herança.

Segundo, quais asserções o dry-run avaliou? Uma configuração sintaticamente válida pode ainda retirar prefixos exigidos. Validação deve comparar saídas de rota, e não só resultados de parse. A ferramenta deve falhar se qualquer prefixo site-local, de gestão, voltado à origem ou de serviço mudar inesperadamente.

Terceiro, como os grupos de rollout foram definidos? Ordem geográfica sozinha não mostraria uma falha específica de arquitetura se toda geografia inicial usasse design antigo. Grupos devem refletir hardware, software, topologia, função de política, versão do plano de controle, participação de tráfego e caminho de gestão.

Quarto, o que impediu progressão? Um rollout escalonado é eficaz somente se tiver janelas de observação explícitas e gates automáticos. O sistema precisa de evidência de que o canário manteve rotas exigidas, alcançabilidade de origem, balanceamento interno, acesso de gestão e sucesso de serviço antes da próxima etapa.

A revisão por pares tem obrigações semelhantes. Revisores precisam da diff renderizada para todos os papéis, saídas de rota esperadas, matriz de canário, plano de rollback e evidência de que o caminho de recuperação é independente. Pedir que revisores infiram isso de um ticket de alto nível mantém o mesmo vazio.

O objetivo não é perfeccionismo burocrático. É amarrar processo ao mecanismo de falha. Para política BGP, a alegação operacional é que prefixos especificados permaneçam anunciados para peers especificados enquanto atributos pretendidos mudam. Essa alegação pode ser testada mecanicamente.

Invariantes de rota transformam intenção em teste

Uma invariável de rota é uma declaração que precisa permanecer verdadeira antes, durante e após uma mudança. Exemplos incluem:

• Cada spine MCP anuncia o conjunto aprovado de prefixos site-local.
• Prefixos de gestão permanecem alcançáveis a partir de pontos de acesso independentes designados.
• Sondas de conectividade à origem do cliente têm sucesso em cada cluster de computação.
• O balanceamento interno pode mover requisições entre clusters de tamanhos diferentes.
• Nenhum prefixo público inesperado é anunciado.
• Nenhum prefixo protegido é retirado.
• O número e atributos de rotas alteradas correspondem ao escopo da mudança aprovada.

O conjunto de prefixos exigidos deve vir de um registro operacional preciso ligado à propriedade de serviço. Não deve ser uma lista informal copiada em um único ticket. Identidade do prefixo, função, origem, peers esperados, metadados de segurança e histórico de mudança precisam de propriedade durável.

Antes do commit, simulação de política pode avaliar candidato contra rotas representativas e contextos de peer. Após um commit de canário, o sistema pode comparar a base de informações de rota do roteador e a visão de rota anunciada com a invariável. Sondas ativas podem testar caminhos de serviço. Coletadores externos podem fornecer visão separada dos anúncios públicos. [17][18][19]

A comparação deve distinguir mudanças esperadas de mudanças inesperadas. Se o objetivo é adicionar comunidades, a presença de rota deve permanecer estável enquanto atributos mudam dentro do conjunto aprovado. A retirada de prefixos site-local exigidos torna-se falha de gate imediata, não sintoma à espera de erros globais de HTTP.

As invariantes de rota também melhoram a comunicação de incidente. Em vez de dizer "a rede está se recuperando," operadores podem relatar que anúncios obrigatórios foram restaurados em número definido de locais, a alcançabilidade de gestão retornou, o encaminhamento interno está passando, e o sucesso de requisições do cliente está dentro de uma faixa definida. Cada afirmação tem evidência e limite.

Há risco de confiança excessiva. O conjunto de invariantes pode ser incompleto. Uma rota pode estar presente e encaminhar incorretamente. A visão do plano de controle pode diferir do plano de dados. Por isso checagens de rota devem ser pareadas com sondas de forwarding e serviço. A suíte de testes deve ser atualizada quando incidente revela dependência não representada.

Comunidades BGP não causaram a indisponibilidade sozinhas

Seria incorreto resumir o incidente como "comunidades BGP quebraram a Cloudflare." Comunidades são metadados anexados a rotas. Operadores as usam para política, marcação, engenharia de tráfego e sinalização operacional. RFC 1997 e RFC 8092 definem formatos de comunidade; não determinam a ordem de política da Cloudflare. [11][12]

As adições de comunidade eram parte do contexto da mudança. O mecanismo de indisponibilidade foi a ordem efetiva dos termos da política nos spines MCP e a retirada resultante de prefixos site-local exigidos. [1] A distinção importa porque remediação deve atacar o controle que falhou, não estigmatizar mecanismo padrão.

Comunidades podem melhorar responsabilização quando seu significado é documentado, único e aplicado consistentemente. Elas podem identificar classes de rota, tratamento pretendido, estado de manutenção, geografia ou relacionamento com cliente. Mas rótulos são úteis só se a avaliação de política preserva o resultado exigido. Uma comunidade que diz "site local" não mantém uma rota anunciada quando um termo anterior a rejeita.

O mesmo princípio se aplica a nomes e comentários de mudança. Rótulos legíveis para humanos apoiam revisão, mas a política em execução determina alcançabilidade. Um operador deve conseguir rastrear de uma definição de comunidade até o conjunto de rotas, ramos de política, anúncios esperados e resultados observados. Se o rastreio termina na documentação, a evidência operacional fica incompleta.

RPKI é importante e não a reparação direta

RPKI fornece forma de vincular recursos de endereço IP a ASs de origem autorizados. Validação de origem de rota permite ao roteador classificar um anúncio com base em se origem e tamanho de prefixo são consistentes com uma Route Origin Authorization. A RFC 6480 descreve a arquitetura, e a RFC 6811 descreve validação de origem. [15][16]

Esses controles tratam de pergunta diferente da falha de junho de 2022. RPKI pode ajudar a determinar se o AS da Cloudflare estava autorizado a originar um prefixo público. Não determina se um termo interno de política de exportação deve anunciar um prefixo site-local, se os termos estão em ordem correta, se um canário MCP é representativo ou se acesso de rollback é independente.

Uma rota autorizada pode ser retirada acidentalmente. Uma origem válida não prova disponibilidade. Inversamente, uma rota site-local interna pode nunca ficar visível em RPKI público ou coletadores externos. Apresentar RPKI como correção universal ocultaria a falha real de controle.

RPKI ainda pertence ao modelo de evidência porque autorização de recursos de rede, política de rota e continuidade operacional interagem. Um operador deve manter registros de recursos numéricos e metadados de segurança precisos enquanto valida separadamente comportamento de política e alcançabilidade de serviço. Integridade de registro e evidência de execução são complementares, não substitutas.

Essa fronteira também é útil para responsabilização pública. Um pós-mortem pode informar se incidente envolveu autorização de origem, vazamento de rota, sequestro, retirada de política interna ou outro mecanismo de roteamento. Classificação precisa evita tratar todo evento BGP como o mesmo tipo de falha e apoia remediação correta.

Observação externa de rotas é valiosa, mas incompleta

O Routing Information Service da RIPE NCC coleta dados BGP de peers, e o RIS Live expõe fluxos de atualização. O BGPStream da CAIDA fornece ferramentas para trabalhar com dados de roteamento de múltiplos coletadores. Esses sistemas ajudam pesquisadores e operadores a observar anúncios, retiradas, mudanças de caminho e restauração visíveis aos pontos de vista participantes. [17][18][19]

Para um incidente de prefixo público, observações externas podem responder perguntas importantes:

• Quando um prefixo desapareceu de coletores selecionados?
• Quais peers ou regiões observaram a retirada?
• Quando os anúncios retornaram?
• As rotas ou atributos mudaram após a restauração?
• O evento bateu com a linha do tempo pública do operador?

O pós-mortem de junho de 2022 trata de prefixos site-local e comportamento interno MCP, além de falha de serviço também sentida externamente. Coletores públicos podem não ver toda rota relevante. Eles não expõem termos internos de política, configurações candidatas de roteador, alcançabilidade interna de gestão ou estado Multimog. Ausência de sinal externo não prova que sistema privado estava saudável.

Essa limitação não deve ser usada para descartar evidência externa. Ela define a tarefa de reconciliação. Operadores podem manter logs de roteador, commits de configuração, snapshots de rotas anunciadas, resultados de probes ativas e telemetria de serviço. Coletadores externos fornecem camada independente. Um fechamento crível explica onde as visões convergem, onde a visibilidade diverge e por quê.

A evidência deve ser cronometrada com relógio consistente. Atualizações de roteamento, commits de configuração, declarações de incidente, reverts, sondas de alcançabilidade e erros de clientes podem parecer fora de ordem sem sincronização temporal e logs imutáveis. Sincronização de tempo e trilhas de auditoria imutáveis são controles de responsabilização porque preservam sequência necessária para avaliar resposta.

As cifras de impacto precisam de seus próprios limites

A Cloudflare disse que os 19 locais MCP representavam aproximadamente quatro por cento de sua rede, mas a indisponibilidade afetou 50 por cento das requisições totais. Também publicou gráfico de volume de requisições e visão de egress-bandwidth. [1]

Os números mostram concentração de tráfego em sites de alta capacidade. Não estabelecem que metade de todos os usuários da internet, metade dos clientes da Cloudflare ou metade de todos os websites ficaram totalmente indisponíveis. Tráfego de requisições não é contagem de população. Alguns locais continuaram a operar normalmente, e efeitos sobre clientes dependiam de geografia e caminho de serviço.

Uma prestação de contas responsável deve separar:

• Requisições que falharam.
• Requisições que foram retardadas ou repetidas.
• Locais que perderam rotas obrigatórias.
• Clusters que sobrecarregaram.
• Origens de clientes que ficaram inalcançáveis a partir dos locais afetados.
• Serviços que continuaram em locais não afetados.
• Tempo até a primeira recuperação e até o rollback final.
• Erros residuais após restauração de rota.

O relatório público fornece informação forte sobre várias dessas dimensões, mas não inventário completo por cliente. O artigo não deve fabricar precisão.

Para incidentes futuros, um operador pode melhorar divulgação publicando denominadores e incerteza. Se 50 por cento das requisições foram afetadas, defina intervalo de medição, critério de sucesso, tratamento de retry, geografia e se a cifra inclui tráfego deslocado para outros sites. Métricas claras permitem ao cliente comparar a declaração com seus próprios logs.

Responsabilização segue controle, não exposição de marca

A Cloudflare controlava política de rota, procedimento de rollout, agrupamento MCP, escopo de dry-run, materiais de revisão por pares, automação e coordenação de rollback. Seu pós-mortem admite que a indisponibilidade foi seu erro e não ataque. [1] Esses fatos tornam a Cloudflare o operador central na análise de responsabilização.

Isso não significa que toda consequência seja legalmente atribuível ou que todo engenheiro tenha dividido igual responsabilidade. O registro público não estabelece culpa individual ou negligência. A governança deve mapear controles para times e sistemas:

• O dono de arquitetura de rede definiu papéis MCP e domínios de falha.
• O dono de política definiu termos de exportação e tratamento de comunidades.
• O dono de automação renderizou e distribuiu a configuração.
• O dono da mudança selecionou etapas e janelas de observação.
• Revisores avaliaram a evidência apresentada.
• O comandante de incidente coordenou recuperação.
• Times de dispositivo e plataforma forneceram rollback e mecanismos commit-confirm.
• Times de serviço monitoraram alcançabilidade de origem, Multimog, carga de cluster e requisições de clientes.
• Alta liderança definiu concentração aceitável de tráfego e risco de mudança.

Fornecedores de roteadores e software influenciam mecanismos de segurança disponíveis, mas o relatório público da Cloudflare não atribui a ordem de termos a defeito de fornecedor. Órgãos de padrão definem comportamento de protocolo, mas não operam a política da Cloudflare. Clientes dependiam do serviço, mas não controlavam a configuração interna de rota site-local.

Clientes ainda têm responsabilidade por sua arquitetura de dependência. Uma organização cujo serviço público dependa de um CDN ou caminho de DNS autoritativo deve compreender essa dependência, testar acesso alternativo quando viável e definir comunicação quando o provedor estiver indisponível. Essa responsabilidade não transfere o controle dos roteadores da Cloudflare ao cliente nem torna toda dependência evitável.

Reguladores e grandes compradores podem pedir evidência sem prescrever topologia privada. Podem perguntar se o provedor usa canários representativos da arquitetura, invariantes de rota, acesso de gestão independente, rollback serializado e exercícios. Contratos podem definir divulgação e evidência de recuperação. Devem evitar pedir configurações privadas em público quando revisão protegida servir ao objetivo.

Um pacote de evidência prático

O fechamento pós-incidente mais forte não é garantia de que o mesmo erro não recorra exatamente. É um pacote delimitado que mostra o que mudou e como os novos controles performam.

O pacote separa registros de prova operacional. Um registro de prefixos é útil por preservar unicidade, propriedade, função, peers esperados, metadados de segurança e histórico de mudança. Não é autoridade para fazer pacotes passarem. Simulação de política é útil porque prevê comportamento; o canário e o estado de rota em produção ainda precisam de observação. Um pós-mortem público é útil porque descreve o evento; não prova que todo compromisso posterior permaneceu ativo.

Detalhes sensíveis podem ser protegidos. Endereços exatos de gestão, credenciais, topologia e configurações de roteador podem gerar risco de segurança se publicados. Auditores independentes, reguladores ou clientes sob confidencialidade podem revisá-los. Divulgação pública pode resumir resultados de controle, horários, escopo e limites não resolvidos.

Os limites de comparação importam

A Cloudflare já teve outros incidentes de roteamento e configuração. Tratar todos como uma única indisponibilidade genérica enfraqueceria a análise.

O evento de junho de 2019 envolveu vazamento de rota externo. Esse não é o mesmo de falha de estágio de MCP de 2022.

O incidente de julho de 2020 da Cloudflare foi uma indisponibilidade por regra de roteador. O mecanismo direto difere da retirada de prefixo site-local de 2022.

O evento de março de 2025 envolveu ROA defeituoso. Em 2022, rotas foram retiradas por política interna; o registro público não descreve um ROA defeituoso como causa.

O erro de arquivo de recurso de 2025 da Cloudflare não foi um evento de política de exportação BGP.

Os casos compartilham uma lição abstrata: pequenas entradas de controle podem ganhar alcance global. A evidência e reparações específicas diferem. Responsabilização de rede exige nomear protocolo, camada, autoridade, caminho de propagação e fronteira de recuperação que realmente falhou.

O que o registro público não prova

O pós-mortem da Cloudflare é detalhado, mas é uma conta de primeira parte. Ele fornece a fonte pública mais forte para mecanismo e cronologia, enquanto deixa material importante em privado.

O registro público não revela todo prefixo retirado, configurações completas de roteador, ticket de mudança integral, comentários de revisores, código de automação, topologia privada, projeto de acesso de gestão ou todas as dependências de serviço. Também não mostra a base de informações de rota completa ou estado de encaminhamento de todos os dispositivos.

Os gráficos de tráfego não identificam todo cliente afetado, usuário, tipo de requisição, origem ou consequência financeira. O artigo não deve inferir crédito de serviço, receita perdida, penalidade regulatória, descumprimento contratual ou negligência do cliente.

O pós-mortem diz que o incidente foi erro da Cloudflare e não um ataque. Não estabelece intenção maliciosa, ocultação, conduta criminosa ou culpa individual. Não estabelece por si só um padrão jurídico de diligência.

A seção de remediação registra mudanças planejadas e imediatas. Não prova que todo canário MCP específico, redesign de política, automação de stagger ou mecanismo commit-confirm permaneçam implantados e eficazes hoje. Documentação atual pode explicar arquitetura e controles, mas não deve ser tratada como prova retroativa do estado exato de 2022.

RIPE RIS e BGPStream podem fornecer observações de roteamento independentes, mas a evidência pública disponível não fornece reconstrução completa de coletor para toda retirada de site-local em todos os sites. Visibilidade externa tem limites.

Esses desconhecimentos não impedem análise de responsabilização. Eles definem perguntas que mantenedores de evidência devem responder e evitam que o artigo transforme um pós-mortem técnico em acusação sem suporte.

Perguntas para operadores, conselhos, clientes e revisores

Operadores de rede devem perguntar:

• Quais políticas de rota diferem por arquitetura ou função de roteador?
• O dry-run renderiza todos os papéis afetados?
• Quais prefixos devem permanecer anunciados após mudança?
• Listas de prefixos exigidos estão versionadas, com dono, e ligadas a dependências de serviço?
• A simulação de política avalia entradas de rota representativas e ordem de termos?
• O primeiro canário é pequeno e representativo de arquitetura?
• Qual janela de observação e gate automático para parar progresso?
• Operadores alcançam dispositivos após política candidata remover rotas comuns de gestão?
• O commit-confirm restaura estado coerente em múltiplos dispositivos?
• Quem detém mutação durante rollback do incidente?
• Times de leitura conseguem observar rotas e serviço sem alterar configuração?

Conselhos e comitês de risco devem perguntar:

• Qual parte do tráfego depende do domínio de controle mais movimentado?
• A distribuição geográfica esconde dependência comum de política ou automação?
• Quais dependências compartilhadas de gestão, identidade, DNS, energia e carrier existem entre caminhos primário e de recuperação?
• Que evidência demonstra exercícios recorrentes, e não apenas remediação pontual?
• Como as métricas de impacto do cliente são definidas e reconciliadas com rotas e evidência de serviço?

Clientes devem perguntar:

• Quais serviços dependem da alcançabilidade via CDN, DNS, segurança, acesso ou origem da Cloudflare?
• Comunicações críticas podem continuar se o provedor e seu status path estiverem comprometidos?
• Existem provedores alternativos ou caminhos diretos à origem testados técnica e operacionalmente?
• Que trade-offs de segurança surgem ao pular etapas ou fazer failover?
• Quais logs estabelecem o impacto do cliente sem assumir indisponibilidade universal?

Revisores e auditores devem perguntar:

• Eles inspecionaram a política renderizada exata, e não apenas a solicitação?
• O canário correspondeu à topologia MCP e à política de spine?
• As rotas site-local e de gestão entraram nas invariantes?
• Medidas independentes e logs de roteador concordaram?
• Dois engenheiros podem sobrescrever uns aos outros em rollback?
• Cada alegação de remediação está amarrada a resultado de teste atual e registro de exceções?

Essas perguntas não presumem que falha zero seja possível. Elas testam se uma classe conhecida de erro de roteamento está delimitada, observável e recuperável.

Conclusão: uma etapa é tão boa quanto o sistema que ela representa

A indisponibilidade de junho de 2022 da Cloudflare começou com uma mudança de rede controlada. A mudança tinha ticket, dry-run, revisão por pares e múltiplas etapas de rollout. Mesmo assim, ela retirou prefixos site-local críticos quando chegou a uma arquitetura em que nenhuma etapa anterior tinha exercitado: os spines MCP. A retirada rompeu alcançabilidade de servidor e origem, desativou redistribuição interna de carga, sobrecarregou clusters menores e prejudicou o caminho de gestão necessário à recuperação. Em seguida, reverts simultâneos causaram recorrência esporádica. [1]

O incidente tornou o estágio de mudança BGP num teste de responsabilização. Uma etapa não é evidência apenas por vir antes de outra. Ela deve representar topologia relevante, função de política, software, entradas de rota, concentração de tráfego e dependência de gestão. Seus critérios de sucesso devem incluir as rotas e serviços que precisam permanecer disponíveis.

O modelo de reparo é concreto. Amarre aprovação à política renderizada. Mantenha ledger preciso de prefixos exigidos e seus papéis operacionais. Simule saída de política. Use canário específico MCP. Observe anúncios, encaminhamento, alcançabilidade de origem, balanceamento interno e acesso de gestão. Proteja rollback com commit-confirm e um único dono de alteração. Reconcile registros privados de roteador com medições públicas independentes onde a visibilidade permitir.

Comunidades BGP, RPKI, coletores de rota, tickets e diagramas todos contribuem para evidência. Nenhum substitui resultado operacional. Comunidades rotulam rotas; ordem de política controla decisões. RPKI valida autorização de origem; não prova disponibilidade ou correção interna de política. Coletores observam visões externas selecionadas; não revelam todas as dependências privadas. Tickets registram intenção; não mantêm rota anunciada.

Essa camada de realidade é a lição duradoura. Uma rede distribuída é resiliente quando seus caminhos em execução, políticas de controle, acesso de gestão e mecanismos de rollback preservam serviço sob uma falha representativa. A prova não é o nome do processo. É a rota que permaneceu alcançável, o canário que parou o rollout e a recuperação que uma equipe concluiu sem outra equipe desfazê-la.

Fontes

1. Cloudflare, "Cloudflare outage on June 21, 2022":https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
2. Cloudflare, 2022 Impact Report:https://cf-assets.www.cloudflare.com/slt3lc6tev37/fBTOgkechN3IcaoT3kbA3/c9b74ee483d28c795d3c7891d8d36034/2022_Cloudflare_Impact_Report.pdf
3. Cloudflare, "Cloudflare Backbone: uma via rápida na internet movimentada":https://blog.cloudflare.com/cloudflare-backbone-internet-fast-lane/
4. Cloudflare, "A espinha dorsal por trás da Connectivity Cloud da Cloudflare":https://blog.cloudflare.com/backbone2024/
5. Cloudflare, "Load Balancing without Load Balancers":https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/
6. Cloudflare, Arquitetura de referência de CDN:https://developers.cloudflare.com/reference-architecture/architectures/cdn/
7. Cloudflare, IP addresses and anycast network:https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/
8. Cloudflare, Peering Policy:https://www.cloudflare.com/peering-policy/
9. PeeringDB, registro de rede da Cloudflare:https://www.peeringdb.com/net/4224
10. IETF / RFC Editor, RFC 4271, Border Gateway Protocol 4:https://www.rfc-editor.org/rfc/rfc4271
11. IETF / RFC Editor, RFC 1997, Atributo de Comunidades BGP:https://www.rfc-editor.org/rfc/rfc1997
12. IETF / RFC Editor, RFC 8092, Atributo BGP Large Communities:https://www.rfc-editor.org/rfc/rfc8092
13. IETF / RFC Editor, RFC 8326, Encerramento adequado de sessão BGP:https://www.rfc-editor.org/rfc/rfc8326
14. IETF / RFC Editor, RFC 7454, Operações e segurança BGP:https://www.rfc-editor.org/rfc/rfc7454
15. IETF / RFC Editor, RFC 6811, Validação de origem de rota:https://www.rfc-editor.org/rfc/rfc6811
16. IETF / RFC Editor, RFC 6480, Arquitetura RPKI:https://www.rfc-editor.org/rfc/rfc6480
17. RIPE NCC, Manual do RIS Live:https://ris-live.ripe.net/manual/
18. RIPE NCC, Serviço de Informações de Roteamento:https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
19. CAIDA, BGPStream:https://bgpstream.caida.org/
20. Cloudflare, "What is BGP?":https://www.cloudflare.com/learning/security/glossary/what-is-bgp/