Cloudflare jul/2020: backbone manda todo o tráfego para Atlanta

01 · CONTEXTO

Um backbone privado e uma mudança para aliviar congestionamento

A Cloudflare opera um backbone: linhas privadas entre muitos de seus data centers, usadas como caminhos mais rápidos e confiáveis que os da Internet pública. O post-mortem explica que ele dá mais qualidade de serviço porque permite evitar pontos de congestionamento da Internet. Esse arranjo faz parte do desenho de CDN e computação de borda.

1. O diagrama começa pelo visitante e pelo data center que o atende.

2. Quando precisa, o tráfego atravessa o backbone privado até outro data center em vez de seguir pela Internet pública.

3. O data center distante busca o conteúdo no servidor de origem do cliente e responde pelo mesmo caminho.

No dia da interrupção, segundo o post, um erro de configuração no backbone causou uma queda que durou 27 minutos, com o tráfego da rede caindo cerca de 50%. A equipe de rede estava tratando um problema não relacionado, no trecho entre Newark e Chicago, e atualizou a configuração de um roteador em Atlanta para aliviar congestionamento. A configuração tinha um erro que mandou todo o tráfego do backbone para Atlanta, sobrecarregou o roteador e derrubou os locais conectados ao backbone. Por causa da arquitetura do backbone, a queda ficou localizada em certas geografias.

02 · LINHA DO TEMPO

Do link perdido à recuperação completa

A sequência começa com um problema no link do backbone entre Newark e Chicago, que levou a congestionamento no trecho entre Atlanta e Washington. Como havia congestionamento do backbone em Atlanta, segundo o post, a equipe decidiu retirar parte do tráfego de backbone de Atlanta e atualizou a configuração do roteador de lá. Os horários abaixo estão em UTC e vêm da linha do tempo do post.

03 · A CONFIGURAÇÃO

Uma linha de política BGP que anunciou tudo

Segundo o post, em vez de remover as rotas de Atlanta do backbone, uma mudança de uma linha passou a vazar todas as rotas BGP no backbone. A mudança correta teria sido desativar o termo da política, e não a lista de prefixos. Ao remover a condição da lista, o roteador foi instruído a enviar todas as suas rotas BGP aos demais roteadores do backbone, com uma local-preference aumentada. É um exemplo de balanceamento de carga decidido pela camada de roteamento: a rota com maior preferência vence e atrai o tráfego.

1. Atlanta está congestionada e a equipe decide tirar parte do tráfego dela.

2. A mudança de uma linha faz o roteador anunciar todas as suas rotas BGP aos demais roteadores do backbone.

3. As rotas chegam com uma local-preference maior do que a das rotas locais dos servidores.

4. Como a maior preferência vence, o tráfego que era de servidores locais passa a ir para os servidores de Atlanta.

04 · IMPACTO

Quem caiu, quem não caiu e como voltou

O roteador de Atlanta ficou sobrecarregado e os locais conectados ao backbone falharam. O painel interno de tráfego do post mostra a CPU de Atlanta em sobrecarga e a CPU dos data centers afetados próxima de zero, porque eles deixaram de tratar tráfego. Locais não listados como afetados continuaram a operar normalmente, o que o post atribui à arquitetura do backbone.

1. O tráfego do backbone é desviado para Atlanta.

2. Os data centers conectados ao backbone falham e deixam de tratar tráfego.

3. Os locais que não dependiam do backbone seguem atendendo normalmente.

4. Com o roteador de Atlanta desativado, o tráfego volta ao normal.

5. Pouco depois, um data center do núcleo que processa logs e métricas congestiona e alguns logs são descartados, mas a borda segue operando.

Segundo o CEO, citado pelo The Register, a empresa isolou o roteador de Atlanta e desligou o backbone, roteando o tráfego por provedores de trânsito. A API e o DNS recursivo da própria empresa ficaram com desempenho degradado, e a imprensa listou terceiros afetados, como Authy, Digital Ocean, Discord, Downdetector, GitLab, Medium, Patron e Riot, entre outros.

05 · LIÇÕES

Limites para que um roteador não atraia tudo

O post anuncia duas mudanças. Uma é um limite máximo de prefixos nas sessões BGP do backbone, que teria desligado o backbone em Atlanta, algo que a rede suporta porque foi construída para funcionar sem backbone. A outra altera a local-preference das rotas de servidores locais, para que um único local não atraia o tráfego dos outros. O post também diz que a empresa nunca havia tido uma interrupção no backbone. Limitar o alcance de uma falha é tema de padrões de disponibilidade.