Cloudflare jun/2022: política BGP fora de ordem em 19 data centers

01 · CONTEXTO

Um incidente de rede nos locais mais movimentados

Em 21 de junho de 2022, uma mudança de configuração de rede causou uma indisponibilidade que afetou o tráfego em 19 data centers da Cloudflare; ela começou às 06:27 UTC. Esses locais concentram uma parcela significativa do tráfego global, e a empresa afirma que o erro foi dela e não um ataque.

A mudança fazia parte de um projeto de longa duração para aumentar a resiliência nos locais mais movimentados. Eles foram convertidos para uma arquitetura chamada internamente de Multi-Colo PoP (MCP), desenhada como uma rede Clos com uma camada extra de roteamento, os spines, que forma uma malha de conexões.

A malha permite desativar e reativar partes da rede interna para manutenção ou para tratar um problema. Como esses locais carregam uma parcela significativa do tráfego, um problema ali pode ter impacto muito amplo.

1. O tráfego chega à camada spine, a camada extra de roteamento que forma uma malha de conexões dentro do data center.

2. Essa malha permite desativar e reativar partes da rede interna para manutenção ou para tratar um problema.

3. O balanceador interno Multimog encaminha requisições entre os servidores do MCP.

4. Os servidores se comunicam entre si e com as origens dos clientes por meio dos prefixos site-local.

02 · BGP

Como o BGP decide o que anunciar

Para ser alcançável na internet, uma rede como a Cloudflare usa o protocolo BGP. Nele, operadores definem políticas que decidem quais prefixos (conjuntos de endereços IP adjacentes) são anunciados aos pares ou aceitos deles.

Os componentes de uma política, chamados termos, são avaliados em sequência. Uma mudança pode fazer um prefixo antes anunciado deixar de ser anunciado, o que o post chama de retirada (withdrawn).

03 · A MUDANÇA

Uma mudança que parecia idêntica

O objetivo era padronizar as BGP communities anexadas a um subconjunto dos prefixos anunciados, adicionando communities informativas aos prefixos site-local. Esses prefixos permitem que as máquinas se comuniquem entre si e se conectem às origens dos clientes.

A mudança seguiu o procedimento da empresa: um ticket de Change Request com dry-run e rollout escalonado, e revisão por pares de vários engenheiros. Mesmo assim, as etapas não eram pequenas o bastante para pegar o erro antes de ele atingir todos os spines.

Nos roteadores, a mudança era inofensiva e só adicionava informação aos anúncios. Nos spines, o diff mostrava termos reordenados: 4-ADV-SITE-LOCALS e 6-ADV-SITE-LOCALS passaram do topo para o fim da política, depois do termo REJECT-THE-REST, uma rejeição explícita. A reordenação fez a empresa retirar um subconjunto crítico de prefixos.

1. Nos spines, o termo de rejeição passa a ficar antes dos termos que anunciam os prefixos site-local.

2. A Cloudflare para de anunciar os prefixos site-local, perde o acesso direto aos locais afetados e seus servidores perdem a capacidade de alcançar as origens.

3. Sem esses prefixos, o Multimog para de funcionar, pois não consegue mais encaminhar requisições entre os servidores.

4. Os clusters menores recebem a mesma quantidade de tráfego que os maiores e sobrecarregam.

04 · IMPACTO

Do primeiro local à última reversão

O rollout foi escalonado. Os primeiros locais não foram afetados porque usavam a arquitetura antiga, e o incidente começou quando a mudança chegou aos spines dos locais com MCP.

Os locais afetados somam apenas 4% da rede, mas o incidente afetou 50% das requisições totais.

05 · REMEDIAÇÃO

O que a empresa pretende mudar

O post aponta uma lacuna de processo: a política de escalonamento só incluía um data center MCP na etapa final. Por isso, os procedimentos e a automação de mudança precisam incluir testes e deploys específicos para MCP.