Resumo

  • Em 17 de junho de 2016, a Cloudflare informou ter detectado perda significativa de pacotes em caminhos que passavam pela Telia Carrier AS1299 às 08h32 UTC. A perda tornou-se intermitente e desapareceu enquanto a equipe investigava. Esse primeiro episódio fornece contexto operacional imediato, mas não demonstra uma interrupção contínua até a segunda-feira seguinte nem revela a causa interna do problema. [1]
  • Em 20 de junho, a Cloudflare voltou a detectar perda maciça de pacotes na Telia Carrier, desta vez às 12h10 UTC. Segundo seu relato, pacotes da própria Cloudflare e de outros clientes da Telia estavam sendo descartados. Às 12h30, a empresa retirou de operação suas portas de interconexão com a Telia, permitindo que o tráfego migrasse para outros provedores. A mudança foi possível porque a Cloudflare dispunha de conexões alternativas e de capacidade para utilizá-las. [1]
  • Uma comunicação da Telia preservada pela Catchpoint descreveu uma fase posterior do mesmo dia. Segundo esse aviso, às 16h UTC uma atualização rotineira da política de roteamento para prefixos agregados no núcleo IP da Telia Carrier provocou o descarte de tráfego destinado a prefixos contidos nesses agregados. O aviso afirmou que a política anterior foi restaurada às 17h05 e que os serviços começaram então a se recuperar gradualmente. [2]
  • As duas descrições do dia 20 não devem ser fundidas em uma única sequência causal sem ressalvas. A perda detectada pela Cloudflare às 12h10, sua retirada de trânsito às 12h30 e a atualização de política descrita para as 16h são evidências relacionadas ao mesmo provedor e ao mesmo dia, mas as fontes públicas não demonstram que todos esses momentos resultaram de um único mecanismo técnico contínuo.
  • A Catchpoint correlacionou o aviso do operador com um aumento acentuado de anúncios e retiradas BGP observados por dois peers de AS1299 no coletor RIPE RIS rrc01. Os números apresentados — eventos envolvendo aproximadamente 500 mil redes IPv4 e 32 mil redes IPv6 — descrevem atualizações vistas em pontos específicos de observação. Eles não representam quantidade de usuários, pacotes perdidos, serviços indisponíveis ou prejuízo financeiro. [2]
  • O incidente expôs duas fronteiras diferentes de controle. A Telia controlava a criação e implantação de sua política, o comportamento dos agregados, a observação interna, o rollback e a comunicação aos clientes. A Cloudflare controlava a diversidade de seus provedores, a detecção externa de perda, a decisão de retirar o trânsito, a capacidade dos caminhos alternativos e sua própria comunicação. As responsabilidades são simultâneas, mas não equivalentes.
  • Uma sessão BGP estabelecida, um ASN registrado ou uma rota visível em um coletor não provam que o serviço de trânsito está funcionando. O plano de controle pode continuar anunciando alcançabilidade enquanto o plano de encaminhamento descarta pacotes. Por isso, evidências de rota devem ser combinadas com sondas de entrega, medições de perda, transações de aplicação e observação dos caminhos de contingência.
  • O registro público não identifica o comando incorreto, o responsável individual pela alteração, o conjunto completo de roteadores, o mecanismo de implantação, a extensão geográfica total, todos os clientes afetados, perdas financeiras, créditos contratuais ou a correção duradoura adotada pela Telia. Também não sustenta alegações de sabotagem, interceptação ou sequestro malicioso de rotas.
  • RFC 7908, RFC 7454, RFC 8212, RFC 9234 e RFC 6811 oferecem conceitos importantes para avaliar políticas BGP, vazamentos de rota, controles de importação e exportação e autorização de origem. Nenhum desses documentos prova quais mecanismos estavam implantados na Telia em 2016. A validação de origem por RPKI, isoladamente, tampouco provaria que uma política interna de agregação encaminhava pacotes corretamente. [7][8][9][10][11]
  • A conclusão central é operacional: a responsabilização de uma rede de trânsito deve seguir a capacidade real de controle e a qualidade da evidência. Ela exige mudanças delimitadas, invariantes para agregados e prefixos contidos, implantação gradual, detecção independente de perda, autoridade clara de rollback, caminhos alternativos comprovadamente utilizáveis e uma demonstração verificável de recuperação.

1. A cronologia precisa permanecer delimitada

Incidentes de backbone costumam ser resumidos como uma única “queda da Internet”. Essa formulação pode ser atraente, mas elimina distinções essenciais. Um grande provedor pode sofrer perda de pacotes em um momento, uma perturbação de roteamento em outro e uma restauração gradual depois. Sem separar essas fases, torna-se impossível determinar qual controle falhou, quem tinha autoridade para agir e qual evidência sustenta cada conclusão.

Na sexta-feira, 17 de junho de 2016, a Cloudflare detectou perda significativa entre múltiplos destinos que atravessavam a Telia Carrier. O horário informado foi 08h32 UTC. Enquanto os engenheiros investigavam, a perda oscilou e depois desapareceu. A observação confirma uma degradação de entrega associada ao caminho de trânsito, mas não revela uma alteração de configuração específica nem autoriza tratar os dias 17 e 20 como um único incidente ininterrupto. [1]

Na segunda-feira, 20 de junho, a Cloudflare registrou nova perda, descrita como maciça, às 12h10 UTC. O relato associou o problema ao descarte de pacotes e a um aumento de erros HTTP 522. Vinte minutos depois, a empresa retirou suas portas Telia de operação. O tráfego pôde seguir por outros provedores, demonstrando que a diversidade contratada tinha utilidade operacional naquele momento. [1]

A fase das 16h aparece em outra categoria de evidência: uma explicação atribuída ao próprio operador e reproduzida pela Catchpoint. O aviso afirmou que uma atualização rotineira de política para prefixos agregados no núcleo IP produziu um blackhole para tráfego destinado a prefixos contidos. Às 17h05, segundo a mesma comunicação, a política anterior foi restaurada, seguida de recuperação gradual. [2]

Há proximidade operacional entre os relatos, mas não equivalência probatória. A medição da Cloudflare documenta aquilo que um cliente observou e a ação tomada sobre suas interconexões. O aviso preservado pela Catchpoint apresenta a explicação do operador para uma fase posterior. Os dados do RIS acrescentam observação do plano de controle. Nenhuma dessas peças, sozinha, reconstrói cada comando, cada roteador ou cada pacote.

A formulação mais defensável é, portanto, tratar 17 de junho como contexto imediato de recorrência e 20 de junho como o centro da análise. Dentro do dia 20, devem permanecer distintas a perda detectada às 12h10, a retirada de trânsito às 12h30, a atualização descrita para as 16h e o rollback informado às 17h05.

Essa separação também evita atribuir toda perda a um blackhole de agregação sem prova. Congestionamento, falha de encaminhamento, enlace óptico, hardware, dependência remota e política podem produzir sintomas semelhantes. O aviso do operador sustenta um mecanismo específico para a fase que descreve; não transforma automaticamente cada problema observado naquele dia no mesmo evento técnico.

Relatos jornalísticos contemporâneos registraram a repercussão e as explicações disponíveis naquele momento, mas não substituem medições, dados de rota ou documentação do operador. Manchetes sobre uma grande interrupção podem indicar relevância pública, porém não resolvem a classificação técnica nem demonstram intenção individual. [5][6]

Incidentes posteriores envolvendo a mesma ASN ou empresas que herdaram sua operação estão fora do limite. Eles não podem ser usados para preencher lacunas da investigação de 2016, provar reincidência do mesmo mecanismo ou inferir a situação atual da rede. O objeto desta análise continua sendo a Telia Carrier como operadora histórica de AS1299 naquele episódio.

2. Trânsito IP é uma promessa de rota e de entrega

Um serviço de trânsito não se resume a anunciar prefixos. O provedor recebe tráfego, mantém relações de roteamento, seleciona caminhos e encaminha pacotes até redes que o cliente não alcança diretamente. A utilidade econômica e operacional do serviço depende da combinação de alcançabilidade anunciada, capacidade disponível e entrega efetiva.

A Cloudflare descreveu a Telia como um de seus grandes provedores de trânsito. Ao mesmo tempo, mantinha conexões com outros provedores Tier 1 e diversas relações de peering. Essa arquitetura permitiu retirar o caminho prejudicado e deslocar carga. O incidente, assim, tornou visíveis tanto a obrigação do provedor quanto a preparação do cliente. [1]

Da perspectiva da Telia, a obrigação incluía manter políticas coerentes, encaminhamento compatível com os anúncios e capacidade para levar o tráfego aos destinos esperados. Uma alteração não deveria permitir que um agregado continuasse atraindo pacotes quando alguns dos destinos que ele cobria já não possuíam encaminhamento utilizável. Caso isso ocorresse, caberia ao operador detectar o desvio, conter sua propagação, restaurar um estado funcional e informar clientes dependentes.

A obrigação do cliente era diferente. A Cloudflare não podia reparar a política interna da Telia, mas podia decidir se continuaria enviando tráfego por aquele caminho. Podia medir perda de pacotes, observar erros de aplicação, retirar anúncios ou interconexões, utilizar outros provedores e informar seus próprios usuários. Essas capacidades não transferem para o cliente a responsabilidade pela alteração do backbone; elas definem seu dever de continuidade.

Essa distinção impede dois extremos. O primeiro seria afirmar que toda consequência pertence exclusivamente ao provedor, mesmo quando um cliente promete alta disponibilidade e controla alternativas de trânsito. O segundo seria culpar o cliente por não neutralizar instantaneamente uma falha criada dentro da rede do fornecedor. A responsabilização correta segue o controle efetivamente disponível a cada parte.

Nem todos os clientes possuem a escala da Cloudflare. Uma pequena rede pode depender de um único serviço gerenciado, ter pouca influência comercial ou não operar BGP diretamente. Outra pode contratar dois provedores que compartilham infraestrutura física, pontos de presença ou dependências comuns. O padrão de diligência precisa considerar essa realidade, sem fingir que diversidade nominal equivale a portabilidade operacional.

Uma arquitetura resiliente deve responder a perguntas concretas. Os caminhos alternativos aceitam os mesmos anúncios? Há capacidade suficiente durante o pico? A retirada pode ser executada por automação ou depende de autorização humana? O sistema consegue detectar perda quando a sessão BGP permanece ativa? A migração reduz o impacto ou apenas desloca congestionamento para outra interconexão?

O valor do episódio está em tornar essas perguntas verificáveis. A Telia possuía autoridade sobre sua política e rollback. A Cloudflare possuía autoridade sobre o uso daquele trânsito. A recuperação dependia de ações em ambos os lados: conter a política defeituosa no provedor e impedir que o cliente continuasse alimentando um caminho que não entregava pacotes.

3. Como uma política de agregação pode criar um blackhole

Um prefixo IP representa um bloco de endereços. Para reduzir o número de rotas transportadas, uma rede pode anunciar um agregado que cobre vários prefixos mais específicos. O encaminhamento normalmente seleciona a correspondência de prefixo mais longa; portanto, uma rota mais específica tende a prevalecer sobre uma rota abrangente quando ambas estão disponíveis.

A agregação traz eficiência, mas também cria uma obrigação. Ao anunciar um bloco amplo, a rede passa a atrair tráfego para os destinos abrangidos por ele. Precisa assegurar que cada destino pretendido tenha um caminho interno válido ou que exista uma política consciente para descartar aquilo que não deve ser servido.

O aviso da Telia reproduzido pela Catchpoint afirmou que uma atualização rotineira afetou a política de prefixos agregados e criou um blackhole para o tráfego dirigido aos prefixos contidos. Essa descrição indica uma divergência entre a aparência de alcançabilidade e o comportamento real de encaminhamento. O agregado podia continuar levando tráfego à rede, enquanto alguns componentes deixavam de possuir uma saída funcional. [2]

Um blackhole dessa natureza é diferente de uma retirada limpa. Quando uma rota desaparece, redes remotas podem escolher alternativas, se elas existirem e forem permitidas pelas políticas locais. Quando o agregado continua visível e preferido, o tráfego pode permanecer preso ao provedor defeituoso até ser descartado internamente. A sessão BGP pode parecer saudável, e uma consulta a uma tabela pode ainda encontrar uma rota.

As fontes não revelam o mecanismo exato. Não se sabe se houve rejeição de rotas mais específicas, falha de resolução de next hop, política gerada incorretamente, redistribuição incompleta, diferença entre famílias de endereços ou outra combinação. Esses são exemplos tecnicamente possíveis, não afirmações sobre a configuração da Telia.

A lacuna impede uma reconstrução linha a linha, mas não impede a definição de controles. Uma mudança que afete agregados deve ser validada contra uma lista explícita de prefixos contidos, next hops esperados, vizinhos afetados, famílias IPv4 e IPv6 e destinos representativos. A presença do agregado não pode ser tratada como prova suficiente de saúde.

É necessário examinar pelo menos três estados. O primeiro é a intenção: aquilo que a configuração deveria produzir. O segundo é o estado de controle: rotas anunciadas, aceitas e selecionadas. O terceiro é o estado de encaminhamento: o local para onde os pacotes são enviados e se chegam ao destino. Uma política pode ser sintaticamente válida e ainda produzir divergência entre esses estados.

Também há diferença entre RIB e FIB. Uma rota pode estar presente na base de informações de roteamento, mas não resultar em uma entrada funcional na base usada para encaminhar pacotes. Pode haver um next hop não resolvido, uma adjacência inadequada ou uma dependência interna ausente. Em qualquer caso, observar somente os anúncios externos seria insuficiente.

Por isso, testes de agregação precisam conter invariantes negativas e positivas. A rede deve saber que anúncios proibidos não escaparam e, simultaneamente, que todos os prefixos que deveriam permanecer acessíveis continuam recebendo pacotes. Um controle que apenas procura rotas indevidas não detecta necessariamente um destino silenciosamente engolido por um agregado.

A implantação gradual reduz o raio de impacto. Uma pequena fração de roteadores, sessões ou regiões pode receber primeiro a política candidata. Durante esse canário, a equipe compara rotas, next hops, volumes de atualização e sondas de entrega com o estado anterior. Se um prefixo contido perder alcançabilidade, o avanço deve parar antes que a política atravesse o backbone.

O rollback precisa existir antes da mudança. Não basta guardar uma cópia do texto anterior; é necessário saber se ela pode ser restaurada rapidamente, em quais equipamentos e com qual ordem operacional. Também é preciso distinguir o momento em que o rollback foi iniciado daquele em que a rede efetivamente convergiu e os pacotes voltaram a chegar.

A comunicação preservada pela Catchpoint diz que a política anterior foi restaurada às 17h05 e que houve recuperação gradual. Essa formulação é importante: restaurar uma versão é uma ação de controle, enquanto recuperar serviço é um resultado observado ao longo do tempo. [2]

4. Uma sessão BGP ativa não prova entrega de pacotes

BGP informa caminhos entre sistemas autônomos, mas não funciona como um teste contínuo de entrega. Duas redes podem manter uma sessão estabelecida e continuar trocando mensagens enquanto parte do tráfego é descartada. Um anúncio pode permanecer visível mesmo que o plano de encaminhamento tenha perdido a capacidade de levar pacotes até determinados destinos.

A Cloudflare identificou o problema por sinais de entrega e aplicação, não apenas por adjacência de roteamento. Seu relato menciona perda de pacotes e aumento de erros HTTP 522, seguido da decisão de retirar as portas Telia. Isso oferece uma perspectiva que os coletores BGP não poderiam fornecer sozinhos: um cliente estava enviando tráfego e observando falha na conclusão do caminho. [1]

A Catchpoint acrescentou evidência do plano de controle. Ao examinar dois peers de AS1299 no coletor rrc01 do RIPE RIS, encontrou um aumento pronunciado de anúncios e retiradas próximo ao horário descrito no aviso da Telia. O padrão ajuda a ligar a explicação do operador a uma perturbação visível externamente. [2]

Entretanto, um coletor enxerga apenas aquilo que os peers participantes lhe anunciam. Não conhece todas as preferências locais, sessões privadas, rotas internas, decisões de encaminhamento ou caminhos comerciais. Um prefixo pode mudar várias vezes e gerar muitos eventos. Outro pode permanecer estável no coletor enquanto usuários sofrem perda em uma parte do caminho que o coletor não observa.

Por essa razão, os aproximadamente 500 mil eventos relacionados a redes IPv4 e 32 mil relacionados a redes IPv6 não podem ser convertidos em usuários afetados. Tampouco indicam, por si sós, que cada prefixo ficou inacessível. São medidas de atividade de rota em pontos selecionados e devem permanecer descritas dessa maneira. [2]

RIPE RIS e RouteViews são valiosos justamente porque preservam observações distribuídas no tempo. Permitem comparar anúncios, retiradas e caminhos vistos por diferentes peers e reconstruir parte da cronologia. Não são autoridades capazes de determinar o que todos os roteadores aceitaram ou o que todos os pacotes experimentaram. [15][16]

RIPEstat acrescenta dados e visualizações associados a recursos como AS1299. Esses registros ajudam a identificar relações entre números de rede e operadores e a examinar observações históricas. Ainda assim, o registro de uma ASN não comanda roteadores nem garante que uma política instalada corresponda à intenção declarada. [14]

Uma investigação robusta precisa ligar quatro camadas:

  1. Política pretendida: quais rotas, vizinhos e resultados o operador esperava.
  2. Plano de controle em execução: quais anúncios, retiradas e seleções apareceram nos roteadores e coletores.
  3. Plano de encaminhamento: quais next hops foram instalados e por onde os pacotes efetivamente seguiram.
  4. Serviço observado: quais conexões, transações e aplicações funcionaram dentro dos limites esperados.

Cada camada responde a uma pergunta diferente. Um arquivo de política pode estar correto enquanto o artefato implantado está errado. Uma rota pode ser aceita e ainda apontar para um caminho morto. Um pacote pode alcançar um servidor enquanto uma dependência da aplicação falha. A declaração de recuperação precisa mostrar convergência suficiente entre essas camadas.

A evidência decisiva, portanto, não é um painel verde isolado. É a combinação temporal de política restaurada, rotas estabilizadas, next hops funcionais, entrega verificada e aplicações recuperadas. Quando uma peça não está disponível, a limitação deve permanecer explícita.

5. Por que o rótulo “vazamento de rota” exige cautela

RFC 7908 descreve vazamento de rota como a propagação de anúncios além de seu escopo pretendido. O escopo depende de relações entre clientes, provedores e peers, bem como das políticas de importação e exportação aplicadas em vários sistemas autônomos. [7]

A definição evita que qualquer comportamento incomum seja chamado de sequestro. Um vazamento pode ser acidental e envolver uma origem autorizada cuja rota foi propagada de modo incompatível com a relação comercial. Um sequestro, por outro lado, pode sugerir origem não autorizada ou intenção maliciosa. Essas categorias não devem ser aplicadas apenas pela gravidade do impacto.

No caso da Telia, o aviso preservado descreve uma política de agregados que criou blackholing. A Catchpoint observou aumento de anúncios e retiradas. Isso sustenta a existência de uma falha de política e de uma perturbação BGP, mas não revela todo o escopo pretendido de exportação, todas as relações entre ASes ou a autorização de origem de cada atualização. [2]

Também não há evidência pública de atacante, credencial comprometida, origem forjada, interceptação ou sabotagem. A explicação atribuída ao operador foi uma atualização rotineira seguida de rollback. Tratar o episódio como sequestro malicioso acrescentaria intenção e mecanismo não demonstrados.

A cautela terminológica não reduz a importância do incidente. Ela apenas direciona a análise para os controles realmente expostos: geração de política, validação comportamental, segurança dos agregados, detecção independente, retirada de trânsito, rollback e comprovação de recuperação.

A validação de origem definida pela RFC 6811 responde a uma pergunta específica: a ASN de origem está autorizada, segundo os dados RPKI disponíveis, a originar determinado prefixo? Uma resposta “válida” não demonstra que a rede autorizada possui next hop funcional, capacidade suficiente ou política interna correta para cada prefixo contido. [11]

Assim, não se pode afirmar que RPKI, ASPA, BGP Roles, Peerlock ou um único filtro teria certamente impedido o blackhole. Esses mecanismos tratam classes importantes de risco, mas a causa divulgada envolve a relação entre agregação, política e encaminhamento dentro da operação do provedor.

6. A responsabilização da Telia deve seguir seus controles

A Telia controlava a origem da política aplicada a AS1299. Isso inclui o processo de geração ou edição, a revisão, a aprovação, o escopo de implantação e a possibilidade de voltar a uma versão anterior. O fato de a alteração ter sido descrita como rotineira não reduz sua relevância: mudanças frequentes em componentes de alto alcance precisam de controles proporcionais ao possível raio de impacto.

O primeiro controle deveria ser um conjunto de invariantes explícitos. Para cada agregado afetado, a equipe precisaria saber quais prefixos contidos continuariam alcançáveis, quais next hops permaneceriam válidos, quais vizinhos receberiam o anúncio, que volume de atualizações seria esperado e quais exceções eram legítimas.

O segundo controle é a comparação com o estado atual. Uma política pode ser correta em um ambiente de teste baseado em topologia desatualizada e falhar em produção por causa de rotas, exceções ou dependências que mudaram. A validação deve usar entradas representativas e declarar o que não pode ser simulado.

O terceiro é o cálculo de raio de impacto. Uma alteração reutilizada por diversos roteadores, regiões ou famílias de endereço não deveria ser tratada como uma modificação local. O processo deve identificar equipamentos, sessões, clientes, prefixos, regiões e serviços potencialmente afetados antes da implantação.

O quarto é a implantação em etapas. Um canário oferece uma oportunidade de comparar o comportamento da política candidata com a versão estável. Se anúncios ou retiradas ultrapassarem um limite, se next hops deixarem de resolver ou se sondas a prefixos contidos falharem, a expansão deve ser interrompida.

O quinto é a medição independente. Monitores que dependem exclusivamente do mesmo caminho alterado podem desaparecer junto com o serviço. A rede precisa de observação externa, coletores, sondas de diferentes regiões e testes de aplicação capazes de continuar reportando durante a falha.

O sexto é a autoridade de rollback. A organização deve definir quem pode interromper uma mudança e restaurar o estado anterior sem aguardar uma cadeia excessivamente longa de aprovação. Essa autoridade precisa vir acompanhada de um pacote verificável: versão restaurada, equipamentos abrangidos, horário, erros encontrados e critérios de recuperação.

O aviso preservado afirma que a política anterior foi restaurada às 17h05. O registro público não informa o momento exato em que o comando alcançou cada dispositivo, nem quais verificações determinaram que o serviço havia voltado. A expressão “recuperação gradual” reconhece que rollback e restauração completa não são sinônimos. [2]

A Telia também controlava sua comunicação aos clientes. O aviso reconheceu que o volume de reclamações prejudicou o atendimento por telefone e e-mail. Em uma rede de backbone, a capacidade de distribuir informações técnicas durante uma crise é parte do serviço, porque clientes tomam decisões de roteamento e capacidade com base nelas. [2]

Uma comunicação eficaz deveria separar detecção, diagnóstico, mitigação, rollback e recuperação. Deveria informar o que é conhecido, o que permanece incerto, quais serviços estão no escopo e qual evidência sustenta cada atualização. A frase “serviço restaurado” não deveria aparecer antes de medições de rota e entrega confirmarem o resultado.

Por fim, o operador deveria preservar os artefatos da mudança: diferença de configuração, aprovação, resultado do canário, alarmes, cronologia de decisão, comandos de rollback, dados de rota, sondas e revisão posterior. Sem esse conjunto, clientes e analistas ficam limitados a uma mensagem resumida e a medições externas parciais.

O material público não mostra se a Telia adotou uma correção duradoura. A ausência, nessas fontes, de outro episódio idêntico não prova que controles tenham sido implementados. A responsabilização precisa distinguir a restauração de 2016 da prevenção de futuros eventos.

7. A responsabilidade dos clientes começa onde existe capacidade de escolha

A Cloudflare possuía conexões alternativas e conseguiu retirar a Telia. Esse fato não transforma a falha interna do provedor em falha do cliente. Demonstra, porém, que a Cloudflare controlava uma camada de mitigação capaz de reduzir sua exposição. [1]

A existência de dois contratos não basta. Um caminho alternativo pode não ter capacidade para absorver a carga, pode compartilhar instalações físicas com o principal, pode depender do mesmo upstream ou pode não aceitar todos os anúncios necessários. A diversidade precisa ser comprovada sob condições de falha.

A Cloudflare reconheceu que desenvolvia um mecanismo para detectar perda de pacotes e deslocar tráfego proativamente, mas que ele estava ativo apenas em locais remotos menores, não em toda a área afetada. A empresa também identificou deficiências em sua comunicação inicial. Essas observações tornam seu relato especialmente útil: ele não descreve apenas o defeito do fornecedor, mas também os limites de sua própria automação e resposta. [1]

O monitoramento de um cliente deve ir além da sessão BGP. É preciso medir perda, latência, handshakes, transações de aplicação e, quando apropriado, mudanças de caminho. Sinais diferentes ajudam a evitar que um único monitor defeituoso provoque uma retirada desnecessária.

A regra de comutação deve ser conhecida antes do incidente. Quantos destinos ou pontos de observação precisam falhar? Por quanto tempo? Qual limiar de perda justifica a retirada? Que mecanismo evita oscilação entre provedores? Quem pode suspender a automação? Quando o tráfego pode voltar ao caminho original?

Também é necessário reservar capacidade. Um circuito secundário utilizado apenas em condições normais muito leves pode não sustentar a carga do primário. Testes periódicos devem transferir tráfego suficiente para verificar anúncios, convergência, filtragem, latência e comportamento de aplicações, sem criar risco desnecessário.

A autoridade operacional precisa ser clara. Algumas organizações podem desligar uma interconexão ou alterar preferência local em minutos. Outras dependem de um provedor gerenciado ou de aprovação executiva. Os objetivos de recuperação devem refletir essa realidade, e não uma representação idealizada do diagrama de rede.

A concentração de dependências também importa. Dois provedores comerciais podem atravessar o mesmo cabo, prédio, equipamento ou rede de trânsito em etapas posteriores. A diligência deve examinar diversidade física e lógica, não apenas nomes diferentes em contratos.

Clientes menores não devem ser avaliados como se possuíssem a malha global da Cloudflare. Seu controle pode se limitar a contratação, escalonamento, continuidade de aplicações e comunicação. Ainda assim, quem promete um serviço resiliente deve explicar quais dependências foram aceitas e quais alternativas realmente funcionam.

A portabilidade operacional é o teste final. Um segundo provedor só representa resiliência quando o tráfego consegue migrar a tempo, a capacidade suporta a carga e os usuários continuam recebendo serviço. A Cloudflare demonstrou essa portabilidade ao retirar suas portas Telia; o relato também mostra que a decisão não foi totalmente automática em toda a sua infraestrutura. [1]

8. Comunicação faz parte da recuperação da rede

Uma falha de trânsito pode deixar clientes sem clareza sobre qual ação tomar. Se o provedor não diferencia congestionamento, manutenção, falha de política e evento de segurança, cada cliente precisa investigar isoladamente. Isso prolonga o impacto e aumenta a chance de alterações conflitantes.

A Telia reconheceu, no aviso reproduzido pela Catchpoint, atrasos de comunicação associados ao volume de reclamações. A Cloudflare, por sua vez, afirmou que sua comunicação externa inicial não representou adequadamente a dependência do upstream e que precisava melhorar. [1][2]

Esses reconhecimentos demonstram que comunicação não é um exercício separado da engenharia. Um cliente precisa saber se deve retirar trânsito, manter uma mitigação, esperar convergência ou procurar outra causa. Informações imprecisas podem fazer com que continue enviando tráfego a um blackhole ou realize mudanças desnecessárias.

Um comunicado responsável deve conter horário, escopo, sintomas, mecanismo conhecido, incertezas, mitigação em curso e condição de recuperação. Se o rollback já ocorreu, mas a convergência continua, essa diferença precisa ser informada. Se apenas alguns pontos de observação foram verificados, a mensagem não deve afirmar recuperação universal.

Grandes operadoras também precisam de canais que resistam ao aumento de demanda: página de status, atualizações estruturadas, distribuição direta para clientes, contatos de escalonamento e informações que não exijam a abertura individual de milhares de chamados.

A documentação posterior deve registrar quando ocorreu a primeira detecção interna, o primeiro relato de cliente, a primeira comunicação, a identificação do mecanismo, o início da mitigação, o rollback e a recuperação medida. Cada horário deve indicar a origem da evidência, evitando que narrativas posteriores comprimam fases diferentes.

9. O que os padrões ajudam a avaliar — e o que não provam

A RFC 7454 reúne práticas operacionais para BGP, incluindo filtragem de prefixos, limites de quantidade de rotas, tratamento de caminhos AS e políticas coerentes para clientes, peers e upstreams. Ela fornece uma linguagem útil para avaliar fronteiras de roteamento, mas sua existência não demonstra que uma implementação específica estivesse ativa na Telia em 2016. [8]

A RFC 8212 estabelece a expectativa de políticas explícitas de importação e exportação para eBGP, evitando que a ausência de configuração resulte automaticamente em troca permissiva de rotas. Esse padrão reduz uma classe de risco, mas uma política explicitamente configurada ainda pode estar errada. [9]

A RFC 9234 descreve BGP Roles e o atributo Only-to-Customer, mecanismos voltados a representar relações entre redes e limitar certas propagações incompatíveis. Eles tratam o escopo interdomínio de anúncios. Um blackhole interno relacionado a agregados pode ocorrer mesmo quando a origem e a relação externa não apresentam o defeito coberto por esses mecanismos. [10]

A RFC 6811 trata da validação de origem de prefixos com dados RPKI. Ela pode verificar se uma ASN está autorizada por uma ROA a originar um prefixo. Não verifica se o next hop funciona, se há capacidade, se a política de agregação mantém todos os destinos contidos ou se os pacotes chegam. [11]

A RFC 7908 ajuda a classificar vazamentos de rota pela propagação além do escopo pretendido. Para aplicá-la formalmente ao conjunto completo de atualizações da Telia, seria necessário conhecer as relações e intenções de política que não estão publicadas. O documento é contexto técnico, não uma prova de classificação do episódio. [7]

A NIST SP 800-189 e as ações do MANRS reúnem recomendações posteriores sobre segurança de roteamento, autorização, filtragem, coordenação e resposta. Elas podem orientar uma avaliação atual de controles. Não devem ser usadas para declarar retroativamente que a Telia seguia ou violava uma prática específica sem evidência de implantação. [12][13]

RIPEstat, RIPE RIS e RouteViews fornecem identificação e observações. Eles preservam dados úteis para reconstruir o plano de controle, mas não fiscalizam a operação da Telia, não aplicam políticas em seus roteadores e não certificam entrega de pacotes. [14][15][16]

A pesquisa posterior sobre Peerlock examina como grandes redes podem limitar certas formas de vazamento. É um ponto de comparação importante para contenção interdomínio, não evidência sobre a configuração de AS1299 em 2016 nem garantia de que teria evitado esse blackhole específico. [17]

O uso correto desses padrões é diagnóstico. Para cada mecanismo, deve-se perguntar qual objetivo ele cobre, qual evidência mostraria sua implantação, qual falha ele pode detectar e o que permanece fora de seu alcance. A existência de uma especificação não equivale a conformidade, e conformidade com um controle não elimina todas as classes de falha.

10. Um livro-razão de responsabilização por capacidade de controle

Ator Capacidade sob seu controle Evidência necessária Questão não resolvida
Telia Carrier / AS1299 Geração e revisão de política, escopo de implantação, agregados, estado interno, encaminhamento, rollback e comunicação Diferença da política, aprovação, dispositivos afetados, testes, alertas, cronologia, versão restaurada e medições de recuperação Qual configuração exata falhou e qual correção duradoura foi implantada?
Cloudflare Diversidade de trânsito, medição de perda, preferência de rota, retirada das portas Telia, capacidade alternativa e comunicação Limiar de perda, momento da mudança, capacidade após a retirada, cobertura da automação e normalização das aplicações Por que a automação não cobria toda a área afetada e como foi ampliada com segurança?
Outros clientes Contratação de conectividade, rotas alternativas quando disponíveis, escalonamento e continuidade de aplicações Topologia real, dependências comuns, autoridade de retirada, testes de failover e registro do impacto Quais clientes possuíam capacidade técnica e comercial para mudar de caminho?
Peers e upstreams Políticas próprias de importação e exportação Configuração de fronteira, anúncios aceitos, filtros e horários Alguma política externa ampliou o impacto? As fontes públicas não demonstram isso.
RIPE RIS e RouteViews Coleta e preservação de observações BGP Identidade do peer, coletor, horário e dados arquivados O que ocorreu em sessões privadas ou pontos não observados?
Operadores de aplicações Detecção do impacto ao usuário e comunicação Erros, transações, regiões, início e fim do impacto Quais falhas de aplicação tiveram causa direta naquele caminho?

Esse livro-razão evita que “responsabilidade compartilhada” se torne uma expressão vazia. A Telia não pode transferir para clientes o controle de sua política interna. A Cloudflare, por outro lado, não pode apresentar diversidade de trânsito como garantia automática se o mecanismo de comutação não está disponível onde ocorre a falha.

Peers que receberam rotas de AS1299 também não devem ser responsabilizados apenas por participarem da troca. Seria necessário demonstrar que uma política específica aceitou ou propagou algo indevido e que isso contribuiu para o dano. O conjunto público não fornece essa demonstração.

Coletores possuem outra função. Eles preservam evidência, mas não controlam o encaminhamento. A ausência de uma atualização em um coletor não prova sua ausência global, assim como a presença de muitos eventos não prova indisponibilidade correspondente para todos os usuários.

Questões legais e contratuais permanecem separadas. Poderiam existir obrigações de serviço, créditos ou disputas, mas as fontes utilizadas não estabelecem violação legal, valor de dano ou resultado contratual. A tese aqui é operacional: quem controla uma função crítica deve produzir evidência proporcional a esse controle.

A atribuição individual também seria imprópria. O registro não identifica quem escreveu, aprovou ou implantou a alteração. Mesmo que uma pessoa tenha executado o comando final, políticas, ferramentas, revisão, implantação e monitoramento são controles organizacionais. Não há base para transformar o episódio em acusação pessoal.

Sources

  1. https://blog.cloudflare.com/a-post-mortem-on-this-mornings-incident/
  2. https://www.catchpoint.com/blog/incident-review-an-account-of-the-telia-outage-and-its-ripple-effect
  3. https://www.thousandeyes.com/blog/analyzing-internet-issues-traffic-outage-detection
  4. https://servebolt.com/articles/telia-went-down-and-so-did-we/
  5. https://www.theregister.com/2016/06/20/telia_engineer_blamed_massive_net_outage/
  6. https://www.theregister.com/2016/06/21/cloudflare_apologizes_for_telia_screwing_you_over/
  7. https://datatracker.ietf.org/doc/html/rfc7908
  8. https://datatracker.ietf.org/doc/html/rfc7454
  9. https://datatracker.ietf.org/doc/html/rfc8212
  10. https://datatracker.ietf.org/doc/html/rfc9234
  11. https://datatracker.ietf.org/doc/html/rfc6811
  12. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf
  13. https://www.manrs.org/wp-content/uploads/2021/02/MANRS-Network-Operators-Actions-v2.4.4.pdf
  14. https://stat.ripe.net/AS1299
  15. https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
  16. https://archive.routeviews.org/bgpdata/2016.06/UPDATES/
  17. https://arxiv.org/abs/2006.06576