Resumo

  • O relatório do CRTC situa a pane entre 04h58 EDT de 8 de julho e 07h00 do dia 9, e informa mais de 12 milhões de clientes móveis e fixos sem serviço [1].
  • Na sexta etapa de uma atualização em sete fases, um filtro ACL foi removido; tabelas BGP completas entraram no OSPF e consumiram CPU e memória dos roteadores centrais [1].
  • Após o sucesso das fases anteriores, o risco da sexta caiu de Alto para Baixo, eliminando revisão adicional, aprovação superior e laboratório [1].
  • A gestão dependia do núcleo IP avariado, e locais críticos não tinham conectividade de gestão fornecida por outra operadora [1].
  • Um fechamento verificável exige limite de rotas, revisão semântica do diff, rollback automático, gestão fora de banda e testes de cada serviço essencial.

A retirada do filtro atravessou a fronteira de protocolos

A Rogers executava havia semanas uma atualização do núcleo IP em sete fases. A avaliação do CRTC localiza o gatilho na sexta, quando um filtro de política foi apagado da configuração dos roteadores de distribuição [1].

O BGP leva alcance e política entre sistemas autônomos e pode carregar grandes tabelas da internet. O OSPF distribui o estado interno de uma operadora. Redistribuir um conjunto limitado pode ser necessário; inserir uma tabela BGP completa e sem limite no protocolo interno obriga muitos equipamentos a processar estado para o qual não foram dimensionados.

O filtro foi removido às 04h43 EDT. Em dois minutos, gateways do núcleo começaram a falhar. Às 04h58, a cronologia registra um fluxo de rotas acima da capacidade. CPU e memória se esgotaram; móvel, telefone residencial, internet, acesso empresarial e 9-1-1 deixaram de funcionar. A restauração continuou até a manhã seguinte [1].

As primeiras mensagens da Rogers eram mais gerais. Em 8 de julho, o presidente executivo reconheceu a falha móvel e fixa e assumiu responsabilidade [4]. No dia 9, a companhia descreveu uma falha após manutenção do núcleo, roteadores com mau funcionamento, isolamento de equipamento e desvio de tráfego [5]. Esses textos registram o conhecimento daquele momento; a avaliação posterior delimita o mecanismo técnico.

Redundância compartilhou a mesma exposição

Vários roteadores não protegem se todos aceitam o mesmo estado excessivo. Segundo o relatório, sem o filtro a configuração padrão permitia que rotas BGP fossem distribuídas em OSPF. Ele aponta quatro lacunas: proteção contra sobrecarga, limite para rotas redistribuídas, auditoria manual e automática dos comandos de política e rollback automático [1].

O contrato de redistribuição deve nomear rotas permitidas, finalidade, quantidade máxima, atributos, equipamentos receptores e ação ao exceder o limite. O filtro não era limpeza estética, mas a fronteira executável entre dois sistemas de estado.

Se um estado inválido alcança cada par, site ou fornecedor, a falha continua comum. Um teto rígido, validação antes da propagação ou rollback deve interromper a cadeia antes do esgotamento conjunto. Um canário que exporta imediatamente o estado inseguro ao restante do núcleo não reduz o raio de impacto.

O cálculo de risco premiou fases anteriores

O programa havia sido classificado como Alto risco. Depois que as primeiras fases deram certo, o algoritmo rebaixou a sexta para Baixo, inclusive a remoção do filtro. Isso dispensou escrutínio adicional, aprovação mais alta e teste de laboratório [1].

O sucesso anterior não prova equivalência. A próxima fase pode tocar outra regra, outro equipamento ou um domínio maior. Apagar uma linha pode abrir um enorme espaço de estados. A avaliação precisa entender o significado do diff atual: retirar filtro, redistribuir entre protocolos e alcançar um núcleo comum são motivos de revisão alta, mesmo após passos bem-sucedidos.

Um registro sólido liga bytes antes e depois, intenção de roteamento legível por máquina, resultado de laboratório, número esperado de rotas, escopo, condição de parada, rollback e dono. O canário só é seguro se não puder contaminar o restante do núcleo antes das verificações.

O núcleo comum ampliou a consequência

As redes móveis e fixas compartilhavam o mesmo núcleo IP. O relatório não chama essa arquitetura comum em operadores Tier 1 de defeito em si. Ao mesmo tempo, conclui que a convergência tornou o alcance extremo porque uma única falha retirou as duas famílias de acesso [1].

Convergência pode reduzir duplicação e melhorar uso, mas coloca voz, dados móveis, internet fixa, empresas, emergências, alertas, monitoramento e comunicação interna atrás da mesma decisão de roteamento. A questão não é proibir convergência, e sim decidir quais serviços devem sobreviver a uma falha de controle e provar a independência.

O resumo do CRTC diz que a Rogers decidiu separar os núcleos móvel e fixo; a implantação ainda não estava concluída no relatório [2]. Dois núcleos continuam correlacionados se dividirem a mesma automação insegura, gestão ou sequência de implantação.

9-1-1 e alertas públicos também foram afetados. A Rogers notificou provedores de 9-1-1 às 08h39, três horas e 56 minutos após o início, e publicou a primeira mensagem aos clientes às 08h54 [1]. A carta do CRTC criticou a falta de orientação inicial sobre formas alternativas de pedir socorro [3]. Números exatos parcialmente ocultados não devem ser inventados.

A gestão caiu junto com a rede gerida

O acesso remoto usava o núcleo de produção. Após a falha, engenheiros não alcançavam elementos críticos. O centro de operações e locais remotos importantes não tinham gestão alternativa de outra operadora; equipes precisaram acessar equipamentos fisicamente [1].

A comunicação interna também dependia dos serviços da Rogers. Havia poucos chips de outras operadoras, logs de erro não estavam disponíveis no início e a causa levou cerca de 14 horas para ser identificada. Várias mudanças na mesma janela dificultaram escolher qual ticket reverter [1].

Independência exige caminho físico e lógico separado, identidade fora do núcleo, console local, logs retidos à parte e comunicação de terceiros. A prova é um exercício com o núcleo isolado em que o time ainda consegue observar, autenticar, mudar e voltar atrás.

A RFC 6192 explica, em termos gerais, a proteção do plano de controle por identificação, filtragem ou limitação do tráfego [8]. Ela não diagnostica a Rogers nem define redistribuição BGP-OSPF. Reforça que encaminhamento e controle têm capacidades distintas.

Melhorias precisam deixar evidência

O CRTC registra salvaguardas contra inundação de rotas, gestão separada física e logicamente, conectividade de terceiros, ferramentas de validação, novo algoritmo de risco, mais laboratório, rollback aprimorado, papéis claros e comunicação alternativa [1][2]. O conjunto foi considerado satisfatório para tratar a causa [2].

Para rotas, a evidência é o teto configurado, contagens observadas em BGP e OSPF, rejeição de um excesso controlado e recursos estáveis. Para mudanças: diff exato, aprovação independente, laboratório, canário isolado e rollback. Para gestão: acesso, identidade, logs e comunicação com o núcleo fora do ar.

O serviço deve ser testado externamente: registro móvel, voz, SMS, dados, fixo, empresas, 9-1-1, alertas e transações. Uma rota restaurada não prova uma chamada; um roteador verde não prova a entrega de alerta.

O ARIN identifica hoje AS812 como ROGERS-COMMUNICATIONS e Rogers Communications Canada Inc. como registrante [6]. O PeeringDB publica AS812 como Rogers Cable [7]. São registros atuais de identidade, não a topologia privada de 2022. Na superfície Heng.lu, o registro é o livro; código e rotas em execução determinam continuidade. Cada aprovação deve ser reconciliada com observação de rede datada.

Fontes

  1. https://crtc.gc.ca/eng/publications/reports/xonarp2023.htm
  2. https://crtc.gc.ca/eng/publications/reports/xona2024.htm
  3. https://crtc.gc.ca/eng/archive/2022/lt220712.htm
  4. https://about.rogers.com/news-ideas/a-message-from-tony-staffieri-president-and-ceo-at-rogers/
  5. https://about.rogers.com/news-ideas/a-message-from-rogers-president-and-ceo/
  6. https://rdap.arin.net/registry/autnum/812
  7. https://www.peeringdb.com/api/net?asn=812
  8. https://www.rfc-editor.org/rfc/rfc6192.html