Resumen

  • La interrupción de octubre de 2021 ocurrió durante un mantenimiento concebido para reforzar las defensas anti-DDoS, pero la actividad DDoS motivó el cambio y no está establecida como causa de la caída.
  • OVHcloud explicó que una orden de redistribución de BGP a OSPF hizo que la tabla completa de Internet entrara en su IGP, llenara la tabla OSPF, sobrecargara memoria y CPU y dejara inoperativo IPv4, aunque IPv6 siguió siendo alcanzable.
  • El cambio había pasado por CAB, MOP y revisión entre pares; por ello, la cuestión de responsabilidad está en la validación del efecto, los límites de propagación, la capacidad de observación y un rollback efectivo, no en afirmar que nadie revisó la intervención.
  • La recuperación tuvo hitos distintos: el problema surgió cerca de las 09:20 CET, el router defectuoso fue apagado a las 10:18, los primeros servicios volvieron a las 10:20 y la crisis técnica terminó a las 10:57.
  • La evidencia respalda una pérdida extensa de alcance IPv4, pero no fija un número exacto de clientes o servicios afectados ni prueba pérdida de datos, incendio, daños físicos, pérdidas económicas totales o una causa definitiva basada en copiar y pegar.

El contexto de seguridad no desplaza la causa operativa

El propósito declarado de la intervención era reforzar la protección anti-DDoS en una etapa de ataques más intensos. Ese dato explica por qué OVHcloud decidió actuar sobre su red de producción. No convierte, sin embargo, el incidente en un ataque exitoso. La cadena causal documentada empieza cuando se cambia la configuración del encaminamiento y termina cuando el equipo afectado debe ser aislado y apagado para que la red vuelva a converger.

Mantener esa frontera es importante para la rendición de cuentas. Si una caída ocurrida durante una mejora de seguridad se atribuye automáticamente a la amenaza externa, se oculta la exposición creada por la propia intervención. Y si se reduce todo a «error humano», se atribuye a una persona una conclusión que las fuentes no permiten sostener. La explicación útil examina el diseño del cambio, lo que la orden podía producir, las defensas que debían contenerlo y las opciones disponibles cuando el rollback dejó de funcionar.

La urgencia tampoco elimina el deber de continuidad. Un proveedor puede necesitar ajustar filtros, capacidad o arquitectura ante un aumento del riesgo DDoS. Precisamente porque esas modificaciones se hacen sobre infraestructura crítica, la organización debe conocer el máximo efecto posible antes de activarlas. La seguridad y la disponibilidad no son objetivos opuestos: una defensa que puede derribar el plano de control necesita límites que impidan que el remedio adquiera un radio de impacto mayor que la amenaza.

Redistribuir rutas cambió la escala del problema

BGP y OSPF trabajan en ámbitos distintos. BGP transporta información de alcance entre sistemas y puede manejar una visión enorme de Internet. OSPF organiza las rutas dentro de un dominio. La redistribución entre ambos no consiste simplemente en copiar datos de un formato a otro; introduce información en un plano de control con diferentes supuestos sobre volumen, topología y frecuencia de convergencia.

El relato de OVHcloud sitúa el fallo en esa frontera. Un router no interpretó correctamente una orden relacionada con la redistribución de BGP hacia OSPF. Como resultado, la tabla completa de encaminamiento de Internet se anunció en el IGP. La tabla OSPF se llenó y el consumo de RAM y CPU creció hasta sobrecargar el equipo. Después, un bucle de convergencia entre BGP y OSPF dejó inoperativo el encaminamiento IPv4.

Esta descripción permite separar tres niveles. Primero estuvo la intención: reforzar la protección anti-DDoS. Después vino la instrucción: modificar la relación entre BGP y OSPF. Por último apareció el estado ejecutado: una cantidad de rutas ajena a la envolvente prevista inundó el IGP. La aprobación se aplicó a los dos primeros niveles; el incidente se materializó en el tercero.

Por eso una revisión textual, incluso competente, no agota la comprobación. La red necesita verificar qué prefijos cruzarán el límite, cuántos serán, qué atributos cambiarán y qué política impedirá que un conjunto inesperado sea aceptado. La validación debe trabajar sobre el resultado potencial y no solo sobre la forma de la orden. También debe existir fuera del dispositivo modificado, porque el propio router puede dejar de ser un punto fiable de control cuando sus recursos están agotados.

Los datos públicos no identifican el fabricante, el modelo, la versión de software, la sintaxis exacta ni el comportamiento preciso del intérprete. No es posible asignar el fallo a un defecto concreto de proveedor o plataforma. Sí es posible afirmar que la redistribución debía estar limitada de modo que una diferencia de interpretación no pudiera llevar la tabla completa de Internet al IGP.

La separación entre IPv4 e IPv6 revela una disponibilidad parcial

Durante el incidente, IPv4 dejó de encaminarse correctamente mientras IPv6 siguió accesible. Esa diferencia demuestra que «la red estaba caída» es una descripción demasiado imprecisa. Para gran parte de los usuarios y servicios dependientes de IPv4, el resultado práctico fue la inaccesibilidad. Al mismo tiempo, una ruta de IPv6 aún operativa mostraba que no todos los planos y caminos habían desaparecido.

La observación tiene consecuencias para la medición. Una prueba que solo consulte IPv6 puede declarar disponibilidad mientras la mayoría de las conexiones falla. Una prueba única desde la red del proveedor puede permanecer verde aunque los clientes externos no alcancen el servicio. También ocurre lo contrario: perder el camino IPv4 no prueba que el servidor o sus datos estén destruidos. El fallo de alcance puede ocultar sistemas que siguen funcionando detrás de una capa de encaminamiento incapaz de conducir tráfico hasta ellos.

Los efectos visibles fueron amplios. Medios independientes observaron servidores y sitios de clientes inaccesibles, errores en la web pública de OVHcloud y la caída de su página de estado. La prensa francesa informó de miles de sitios afectados y citó ejemplos de páginas públicas y comerciales. Esas constataciones sirven para demostrar impacto y dependencia, no para fabricar un censo exhaustivo de clientes, países o pérdidas.

El incidente tampoco debe confundirse con el incendio del centro de datos de Estrasburgo en marzo de 2021. Las fuentes sobre la caída de octubre no establecen fuego, destrucción de instalaciones ni pérdida de datos. Su mecanismo es de alcance de red. Trasladar imágenes o hechos del incendio a este episodio cambiaría la naturaleza del suceso y atribuiría daños que no constan.

Los minutos decisivos muestran los límites del rollback

La cronología detallada comienza a las 09:05 CET, cuando se inició el cambio planificado. A las 09:18 estaban en marcha acciones de aislamiento BGP y ajustes de configuración. El problema apareció a las 09:20. Un minuto después, a las 09:21, el deterioro del rendimiento del router fue detectado y elevado. La detección fue rápida; la contención no lo fue en la misma medida.

A las 09:30, el intento de rollback había fallado y se eligió el aislamiento físico. Este hito concentra la lección de recuperación. Un rollback que depende de que el router responda, procese más rutas y ejecute nuevas órdenes puede volverse inservible cuando la propia avería consume memoria y procesador. Las condiciones del fallo privan a la organización del mecanismo en el que confiaba para salir de él.

El router fue apagado a las 10:18. A las 10:20 regresaron los primeros servicios después de la convergencia. OVHcloud marcó el final de la crisis técnica a las 10:57. Son tres hechos distintos: retirar el componente problemático, observar las primeras mejoras y alcanzar la estabilización técnica. Reducirlos a una duración única ocultaría que la restauración fue escalonada.

Una comunicación temprana del mismo día utilizó horas más aproximadas, como las 09:12 para la intervención y las 10:15 para el aislamiento. El informe detallado posterior ofrece la secuencia más precisa. La diferencia es compatible con la evolución normal de la información durante una crisis, pero obliga a no combinar marcas de tiempo sin explicar su origen.

Haber revisado el cambio no equivale a haber probado su efecto

OVHcloud declaró que la operación se había preparado mediante un comité asesor de cambios, un método de procedimiento y una revisión por pares. No hay base para decir que la orden se ejecutó sin examen. El incidente obliga a formular una pregunta más exigente: ¿qué demostraban exactamente esas actividades antes de que el cambio llegara a producción?

Un CAB puede confirmar que el objetivo es legítimo, que existe una ventana y que las partes responsables conocen el plan. Un MOP puede ordenar las acciones y ofrecer puntos de decisión. Un compañero puede detectar errores visibles en la configuración. Pero el conjunto no garantiza que la semántica final sea la prevista, que la cantidad de rutas permanezca limitada o que el rollback funcione bajo presión del plano de control.

La revisión técnica debe incluir una envolvente verificable. El equipo necesita una lista de prefijos permitidos, límites de cantidad, transformaciones previstas, políticas de rechazo y destinos autorizados. El estado que aparece durante la ejecución debe contrastarse en tiempo real con esa definición. Un desvío importante no debería depender de que una persona interprete varias señales bajo presión; tendría que activar un freno independiente.

Las defensas pueden combinar filtros, límites de prefijos, separación de protocolos, activación por etapas, canarios y simulación a escala. Ninguna medida es universal, y la información disponible no detalla cuáles estaban presentes en 2021. La exigencia general sí puede formularse: una mala redistribución no debería disponer de un camino sin límites para llenar el IGP.

También importa la independencia de las comprobaciones. Si el mismo cambio modifica la política y, a la vez, define qué resultado se considera válido, una interpretación equivocada puede aprobarse a sí misma. Una fuente separada de verdad —por ejemplo, el conjunto autorizado de prefijos y un contador observado fuera del router intervenido— permite confrontar intención y resultado sin confiar en el componente que está cambiando.

Esa comparación debe conservar la secuencia temporal. Saber que el recuento terminó fuera de límites ayuda al análisis posterior, pero no evita la propagación. La defensa operativa necesita detectar el primer salto, asociarlo a la orden recién ejecutada y dar autoridad para detener la intervención antes de que la convergencia consuma la capacidad requerida para recuperar. Cuanto antes se actúe, más reversible permanece el estado.

La revisión posterior debería evaluar igualmente los falsos negativos. Si las alarmas existentes no se activaron, hay que saber si faltaba la métrica, si el umbral era demasiado amplio, si la señal llegó tarde o si nadie tenía un mandato claro para actuar. Añadir más avisos sin resolver esa cadena puede aumentar el ruido y mantener intacta la debilidad que permitió el incidente.

Recuperar control cuando el dispositivo deja de ser fiable

La restauración física expone una dependencia que a menudo queda oculta en los planes. Mientras un equipo funciona con normalidad, enviar una orden inversa parece suficiente. Cuando ese equipo está saturado, participa en un bucle de convergencia y quizá ya no mantiene una sesión de gestión estable, el canal lógico comparte el mismo fracaso que intenta corregir.

Una estrategia robusta necesita varios escalones. Puede comenzar retirando la redistribución o restaurando la configuración previa; pasar después al aislamiento de una sesión o vecino; y terminar con separación física o corte de energía. Cada escalón debe tener un límite temporal, una autoridad clara y un medio de ejecución que no dependa del plano afectado.

No basta con anotar «hacer rollback» en el procedimiento. Hay que ensayar cuánto tarda en bajar el número de rutas, qué ocurre si la CPU está al límite, cómo se conserva el acceso fuera de banda y quién puede abandonar el plan original. Si el equipo no puede procesar la retirada, insistir con más órdenes puede alargar el evento y consumir el margen para una intervención menos reversible.

La recuperación también debe demostrarse en los extremos del servicio. Volver a cargar una configuración anterior no garantiza que las adyacencias sean estables, que las tablas hayan regresado a sus límites o que un usuario externo alcance sus aplicaciones. Los criterios de salida necesitan unir estado de protocolos, recursos, convergencia, pruebas de IPv4 e IPv6 y disponibilidad de los canales de comunicación.

La comunicación compartió el radio de impacto

Que la web de OVHcloud y su página de estado quedaran inaccesibles muestra cómo una dependencia común puede amplificar el daño. El cliente no solo pierde el servicio; pierde también la explicación sobre lo que sucede. El equipo operativo recibe más consultas en canales alternativos, mientras las partes afectadas carecen de hitos fiables para decidir si esperar, desviar tráfico o activar sus propios planes.

Un canal de estado verdaderamente independiente debe sobrevivir al fallo del proveedor que describe. Eso exige revisar DNS, alojamiento, red de distribución, autenticación administrativa y mecanismo de publicación. Una réplica alojada bajo la misma dependencia de encaminamiento aporta redundancia visible, pero no aislamiento.

La comunicación debe separar contención, primeras restauraciones y estabilización final. También debe indicar qué familias de protocolo están afectadas. En este caso, explicar la continuidad de IPv6 no habría reducido la gravedad del fallo IPv4; habría dado a los clientes una descripción más útil para evaluar rutas alternativas y evitar conclusiones erróneas.

Los hechos no autorizan una culpa individual ni cifras inventadas

El relato oficial detallado afirma que un router no interpretó correctamente una orden, pero no publica el texto de esa orden ni identifica a la persona que la introdujo. No se conocen la topología completa, los registros de decisión, el número exacto de rutas o equipos implicados ni lo que cada participante sabía en cada instante. Con esos límites, asignar responsabilidad individual sería especulativo.

Algunas informaciones citaron una publicación de dirección después eliminada y plantearon una posible acción de copiar y pegar. El informe posterior no establece esa hipótesis como causa raíz definitiva. Puede mencionarse como una teoría atribuida, pero no convertirse en hecho. El punto firme es el efecto de redistribución y la posterior sobrecarga del plano de control.

Tampoco existe un total auditado de clientes, servicios, territorios o pérdidas económicas. Los ejemplos de sitios inaccesibles ilustran la extensión de la interrupción, pero no permiten sumar una cifra completa. No se ha establecido pérdida de datos, incendio, daño físico ni destrucción de servidores. La precisión exige decir tanto lo que ocurrió como lo que no puede inferirse.

El juicio de responsabilidad más resistente es, por ello, organizativo y técnico. Un cambio planificado, documentado y revisado permitió un estado de rutas fuera de límites, perdió la capacidad de rollback y requirió aislamiento físico. La respuesta adecuada es demostrar validación semántica, barreras de propagación, autoridad de parada, acceso independiente y recuperación observada desde el servicio. Las fuentes describen medidas inmediatas, pero no permiten certificar su eficacia actual.

Fuentes