Resumo

  • A Cloudflare informou que, por volta de 10:30 UTC em 24 de junho de 2019, uma pequena empresa se tornou caminho preferido para muitas rotas via Verizon AS701, incluindo prefixos ligados à Cloudflare [1].
  • A análise posterior da Cloudflare colocou a camada de route optimizer e a propagação por um grande provedor de trânsito no centro do problema [2].
  • A Noction respondeu publicamente porque seu produto de otimização fazia parte da discussão, separando intenção do produto e governança de implantação [3].
  • A ThousandEyes/Catchpoint observou efeitos externos de alcançabilidade para usuários da Cloudflare, dando limite mensurável ao impacto [4].
  • RFC 7908 e RFC 9234 explicam por que o evento é uma violação de relação BGP e por que papéis explícitos, como Only-to-Customer, são relevantes [6][7].

O que aconteceu

A Cloudflare descreveu muitas rotas sendo enviadas pela Verizon depois que uma pequena empresa apareceu como caminho preferido. Em BGP, o problema público não é apenas uma rede anunciar algo. O problema surge quando outras redes tratam esse caminho como utilizável, preferem-no e o exportam além da relação em que ele deveria ficar. Um anúncio local estranho se torna incidente amplo quando redes vizinhas o aceitam e o propagam.

Por isso a DQE importa. A Verizon era o grande provedor visível, mas a análise de responsabilidade começa antes: fonte de rota do cliente, camada de otimização e regras de aceitação upstream. Uma rede pequena não é inofensiva por padrão. BGP executa políticas e relações, não reputação ou tamanho de empresa.

Por que importa

Um vazamento de rota pode manter origem válida e ainda violar a relação no meio do AS path. RPKI Origin Validation ajuda quando a origem é inválida, mas não resolve todos os vazamentos. O reparo responsável precisa de evidência de relação, política de importação, política de exportação, limites de prefixos, filtros AS-path, disciplina IRR/RPKI, detecção de vazamento e monitoramento.

Fontes públicas podem provar que houve um evento de roteamento. Elas não substituem route maps internos, tickets de mudança, configuração do otimizador, logs de aceitação e decisões da sala de incidente. Assim, a conclusão deve ser estreita: o registro público não prova intenção da DQE, da Noction ou da Verizon. Ele sustenta que a cadeia de aceitação foi fraca o suficiente para uma fuga do lado do cliente se propagar por um grande provedor.

A camada técnica

RFC 7908 descreve vazamentos como propagação que viola a relação esperada entre redes. RFC 9234 aponta uma direção de reparo: tornar papéis de provedor, cliente e par mais explícitos com BGP Roles e Only-to-Customer. Isso não repara todas as interconexões antigas, mas transforma uma suposição oculta em evidência de protocolo.

Um encerramento técnico confiável deveria listar prefixos, AS paths, horários de início e fim, pontos de coleta, sessões afetadas, filtros de importação e exportação, limites max-prefix, base IRR/RPKI, withdrawals e testes de não recorrência. Sem isso, o público não distingue convergência curta, política ampla demais ou falha operacional mais séria.

Quem é afetado

Afetados são usuários e redes cujos operadores escolheram o caminho vazado ou viram latência, perda ou indisponibilidade parcial por causa da seleção de rota. As fontes públicas não listam todas as transações. O dano deve ser medido por duração, prefixos afetados, escolha de caminho, pontos de medição e sintomas.

O que observar

Observar sessões de clientes que exportam prefixos fora do conjunto normal, route optimizers que mudam best path sem guardrails de relação, grandes provedores aceitando rotas anormais de clientes e comunicações de incidente sem classe de vazamento, duração, conjunto de prefixos e controles de recorrência.

Sources

  1. https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
  2. https://blog.cloudflare.com/the-deep-dive-into-how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-monday/
  3. https://www.noction.com/news/incident-response
  4. https://www.thousandeyes.com/blog/cloudflare-users-burned-by-internet-routing-pile-up
  5. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/
  6. https://www.rfc-editor.org/rfc/rfc7908
  7. https://www.rfc-editor.org/rfc/rfc9234