Resumen

  • El informe del CRTC sitúa la caída entre las 04:58 EDT del 8 de julio y las 07:00 del día 9, y señala más de 12 millones de clientes móviles y fijos sin servicio [1].
  • En la sexta fase de una actualización de siete etapas se retiró un filtro ACL; tablas BGP completas entraron en OSPF y agotaron CPU y memoria de los routers del núcleo [1].
  • Tras el éxito de fases anteriores, el riesgo de la sexta bajó de Alto a Bajo y dejó de requerir revisión reforzada, aprobación superior o laboratorio [1].
  • La gestión dependía del núcleo IP averiado y los sitios críticos carecían de conectividad de gestión de otro proveedor [1].
  • Un cierre verificable requiere límites de rutas, revisión semántica del cambio, rollback automático, gestión fuera de banda y pruebas por servicio esencial.

Una línea de configuración abrió una tabla completa

Rogers ejecutaba desde semanas antes una actualización del núcleo IP en siete fases. El CRTC atribuye el disparo del evento a la eliminación de un filtro de política en los routers de distribución durante la sexta fase [1].

El cambio cruzó una frontera de protocolos. BGP transporta alcance entre sistemas autónomos y puede manejar grandes tablas de Internet. OSPF distribuye el estado interno de una red. Redistribuir un conjunto seleccionado puede ser legítimo; introducir una tabla BGP completa en el protocolo interior obliga a numerosos equipos a procesar un estado para el que no fueron dimensionados.

El filtro se retiró a las 04:43 EDT. En dos minutos comenzaron a fallar gateways del núcleo. A las 04:58, la cronología registra un volumen de rutas superior a la capacidad de los equipos. El procesamiento y la memoria se agotaron, y dejaron de funcionar móvil, teléfono fijo, Internet, enlaces empresariales y 9-1-1. La recuperación se extendió hasta la mañana siguiente [1].

Los comunicados iniciales de Rogers fueron más generales. El 8 de julio, su director ejecutivo reconoció la interrupción móvil y fija y asumió responsabilidad [4]. El día 9, la empresa habló de una falla tras mantenimiento del núcleo, routers que dejaron de operar correctamente, desconexión de equipos y desvío de tráfico [5]. Esas declaraciones reflejan el conocimiento del momento; la evaluación posterior delimita el mecanismo técnico.

La redundancia compartió la misma exposición

Tener varios routers no protege si todos aceptan el mismo estado excesivo. El informe dice que, sin el filtro, la configuración estándar permitía distribuir rutas BGP en OSPF. Señala cuatro controles ausentes o insuficientes: protección contra sobrecarga, límite al número de rutas redistribuidas, auditorías manuales y automáticas de las órdenes de política, y rollback automático [1].

El contrato de redistribución debería indicar qué rutas pueden cruzar, por qué, cuántas como máximo, qué atributos se conservan, qué equipos las reciben y qué acción se toma al superar el límite. El filtro no era limpieza cosmética, sino la frontera ejecutable entre dos sistemas de estado.

Cuando el mismo flujo llega a cada equipo redundante, la multiplicación de hardware duplica la vulnerabilidad. La métrica útil no es la cantidad de routers o sitios, sino si un único estado inválido puede alcanzar a todos. Un tope, una validación previa o un rollback deben interrumpir la propagación antes del agotamiento común.

El cálculo de riesgo miró hacia atrás

El programa se clasificó inicialmente como Alto riesgo. Como las primeras fases salieron bien, el algoritmo redujo la sexta a Bajo, incluida la eliminación del filtro. Esa categoría evitó escrutinio adicional, aprobación superior y pruebas de laboratorio [1].

El éxito anterior no demuestra que el siguiente cambio sea equivalente. Cada fase puede tocar otra rama de política o un dominio de falla mayor. Borrar una línea puede habilitar millones de estados posibles. El riesgo debe interpretar el diff presente: quitar un filtro, redistribuir entre protocolos y alcanzar un núcleo común son razones para máxima revisión aunque cinco pasos previos hayan funcionado.

Un registro sólido une el ticket con configuración previa y propuesta, intención de rutas legible por máquina, prueba de laboratorio, recuento esperado, ámbito, condición de parada, rollback y dueño. Un canario sirve únicamente si no puede exportar el estado defectuoso al resto del núcleo antes de pasar las comprobaciones.

La convergencia amplió el impacto

Las redes móviles y fijas compartían núcleo IP. El informe no califica esa arquitectura, habitual en un operador Tier 1, como un defecto por sí misma. Sí concluye que la convergencia hizo extremo el alcance al eliminar ambos tipos de acceso a la vez [1].

La convergencia puede mejorar uso y costes, pero coloca voz, datos móviles, Internet fijo, empresas, emergencias, alertas, monitorización y comunicaciones internas detrás de una política común. La cuestión es qué servicios deben sobrevivir a una sola falla de control y qué independencia ha sido ensayada.

El resumen del CRTC dice que Rogers decidió separar los núcleos fijo y móvil. La implantación seguía incompleta cuando se publicó [2]. Dos núcleos reducen la correlación solo si no comparten la misma automatización insegura, gestión o secuencia de despliegue.

El 9-1-1 y las alertas públicas también resultaron afectados. Rogers avisó a los proveedores de 9-1-1 a las 08:39, tres horas y 56 minutos después del inicio, y publicó su primer mensaje a clientes a las 08:54 [1]. La carta del CRTC criticó la falta de orientación rápida sobre formas alternativas de pedir ayuda [3]. Algunos datos exactos aparecen censurados, por lo que no deben completarse con estimaciones.

La red de gestión cayó con la red gestionada

La gestión remota dependía del núcleo de producción. Al fallar, los ingenieros perdieron acceso a elementos críticos. El centro de operaciones y otros sitios no tenían conectividad alternativa de otro proveedor para esa función, y hubo que desplazar personal físicamente [1].

Las comunicaciones internas también se apoyaban en servicios de Rogers. Había pocas SIM de otros operadores, los logs de error no estuvieron disponibles al principio y la causa tardó unas catorce horas en quedar identificada. Varios cambios en la misma ventana dificultaron saber qué ticket revertir [1].

La independencia exige camino físico y lógico distinto, identidad fuera del núcleo, consolas locales, logs retenidos de forma separada y comunicación de un tercero. La prueba real es un ejercicio en el que el núcleo de datos está aislado y el equipo todavía puede observar, autenticarse, cambiar y deshacer.

RFC 6192 explica en términos generales que el plano de control debe protegerse identificando, filtrando o limitando tráfico [8]. No diagnostica este incidente ni define redistribución BGP-OSPF. Sí recuerda que el plano de reenvío y el de control tienen capacidades diferentes.

Las mejoras necesitan evidencia de ejecución

El CRTC enumera salvaguardas contra la inundación de rutas, gestión física y lógicamente separada, conectividad de terceros, herramientas de validación, nuevo algoritmo de riesgo, más laboratorio, automatización del rollback y comunicaciones de crisis alternativas [1][2]. La evaluación considera satisfactorio el conjunto para tratar la causa [2].

Cada control debe dejar una prueba. Para rutas: límite configurado, conteos BGP y OSPF observados, rechazo de una sobrecarga controlada y recursos estables. Para cambios: diff exacto, aprobación independiente, laboratorio, canario y rollback. Para gestión: acceso, identidad, logs y comunicación durante una caída completa del núcleo.

La continuidad debe verificarse desde fuera: registro móvil, voz, SMS, datos, Internet fijo, negocios, 9-1-1, alertas y transacciones. Una ruta restaurada no prueba una llamada. Un router en verde no prueba que una alerta llegue al usuario.

ARIN identifica hoy AS812 como ROGERS-COMMUNICATIONS y a Rogers Communications Canada Inc. como registrante [6]. PeeringDB publica AS812 como Rogers Cable [7]. Son libros de identidad actuales, no la topología privada de 2022. En la superficie Heng.lu, el registro guarda derechos e identidad; el código y las rutas ejecutadas determinan la continuidad. Cada aprobación debe reconciliarse con una observación fechada.

Fuentes

  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