Resumen

  • A las 07:08 UTC del 25 de enero de 2023, una operación para ampliar capacidad en Madrid utilizó un comando que era local en equipos de dos fabricantes, pero que en una tercera plataforma afectaba por defecto a todos los routers conectados mediante IGP. La recomputación global de IGP y el posterior nuevo anuncio de prefijos por BGP produjeron la primera oleada.
  • Treinta y tres minutos después, la misma operación se ejecutó manualmente en el segundo router de Madrid porque la persona a cargo del cambio no había sido informada de las alertas activas. Esa segunda actuación, no una repetición automática confirmada, generó otra oleada.
  • La mayoría de los dispositivos, regiones y servicios se había recuperado a las 09:05 UTC y el último equipo de red a las 09:25. Sin embargo, los sistemas de salud de la WAN y de ingeniería de tráfico que habían quedado en pausa necesitaron reinicios manuales antes de la mitigación completa a las 12:43.

Un trabajo acotado alcanzó el dominio mundial de enrutamiento

La tarea prevista era incorporar capacidad a la red de área amplia mundial de Microsoft. En Madrid, un ingeniero estaba cambiando direcciones IP de routers nuevos e integrando esos equipos en los dominios de enrutamiento interior y exterior, IGP y BGP. El trabajo físico se concentraba en una pareja de routers. El alcance lógico de una instrucción incluida en el procedimiento no estaba igualmente acotado.

La revisión final de Microsoft señala que el procedimiento operativo había sido modificado antes del incidente, pero no se había vuelto a probar y carecía de las comprobaciones previas y posteriores requeridas. Entre sus pasos figuraba un comando que purgaba la base de datos IGP. En plataformas de dos fabricantes actuaba localmente. En la de un tercer fabricante, su comportamiento predeterminado alcanzaba a todos los routers unidos por el IGP.

El sistema de autorización de comandos de Microsoft no había clasificado ese efecto global específico de la plataforma como bloqueado. Por ello, una orden permitida pudo provocar que los routers de la WAN recalcularan la topología interna. A continuación, los routers BGP volvieron a anunciar y validaron prefijos de Internet mientras cambiaban los caminos disponibles.

Para los clientes, ese movimiento se manifestó de formas distintas según el origen y el destino: latencia, tiempos de espera agotados, pérdida intermitente de paquetes y, en algunos trayectos, ausencia completa de conectividad. Para la infraestructura, la secuencia fue una alteración del estado de encaminamiento que se propagó mucho más allá del par de equipos sobre el que se estaba trabajando.

Este mecanismo convierte el caso en un problema de responsabilidad sobre infraestructura de red, no en una interrupción genérica de servicios en la nube. Si se eliminan de la explicación la purga IGP, la recomputación de topología, los nuevos anuncios BGP y los cambios de ruta, la tesis central deja de sostenerse. La pregunta no es simplemente por qué una persona introdujo un comando, sino por qué el sistema de cambio no podía demostrar qué haría ese comando en cada plataforma desplegada antes de dejarlo entrar en el enrutamiento en vivo.

La autorización responde a quién puede actuar. La cualificación debe responder qué alcance tendrá esa acción sobre una combinación concreta de fabricante, software, función del dispositivo y dominio de red. Confundir ambas preguntas permitió que una etiqueta de trabajo limitada conviviera con una ejecución de alcance mundial.

Las diferencias entre plataformas eran parte del control, no una nota al pie

Una lista de comandos autorizados o bloqueados es útil para impedir comportamientos ya conocidos. No demuestra que toda instrucción no bloqueada sea segura. En una WAN con múltiples fabricantes, palabras parecidas pueden activar valores predeterminados distintos. La diferencia entre purgar una base local y afectar a todos los routers conectados por IGP cambia por completo el radio de impacto.

Las fuentes públicas no identifican fabricantes, modelos, versiones de software ni el texto exacto del comando. No sería correcto convertir el incidente en una acusación contra una marca o una versión determinada. Sí permiten una conclusión más precisa: la cualificación de Microsoft no incorporaba el comportamiento global de una de las plataformas que realmente operaban en la red.

Esa es la primacía del código en ejecución. El nombre de una tarea describe una intención; el router aplica una semántica. Cuando discrepan, el estado que produce el sistema real determina el riesgo. Una operación descrita como local sólo conserva ese carácter si la topología y la telemetría verifican que el efecto permanece dentro de la frontera declarada.

La ausencia de comprobaciones antes y después agravó la brecha. Una prueba previa podría haber obligado a declarar qué dispositivos, adyacencias y dominios debían cambiar. Una prueba posterior podría haber comparado esa previsión con la topología IGP, los anuncios BGP y los caminos observados. Son consecuencias de diseño extraídas del caso, no una afirmación de que una comprobación concreta habría evitado cualquier fallo posible.

La disciplina necesaria va más allá de aprobar cadenas de texto. Los resultados de ensayo deben asociarse a plataformas y roles, y una modificación del procedimiento debe invalidar o renovar la evidencia anterior. También hace falta que el operador pueda observar si el estado de las rutas sigue siendo exacto respecto a lo esperado y si la continuidad está preservada. Sin ello, el control de acceso corre el riesgo de convertirse en un sustituto inadecuado de la seguridad del cambio.

El BGP visible desde Internet corroboró los efectos, no la causa interna

ThousandEyes observó retiros y nuevos anuncios de prefijos de Microsoft, desvíos desde rutas de peering directo hacia proveedores de tránsito y pérdida considerable de paquetes. Kentik registró dos descensos agregados de tráfico y una afectación muy variable entre prefijos, regiones y caminos. Había prefijos afectados y otros que seguían transportando tráfico.

Estas observaciones independientes importan porque muestran lo que podían medir los clientes y las redes vecinas. También fijan un límite: los datos BGP públicos no revelan por sí solos el comando propietario que inició el incidente, el estado de los controles internos ni la cadena de decisión que permitió la acción. Kentik advirtió que la inestabilidad observada era probablemente un síntoma de la avería interna, no su raíz.

Los retiros de rutas, los nuevos anuncios y los cambios hacia tránsito no demuestran un secuestro malicioso de BGP, un ataque externo ni una vulnerabilidad intrínseca del protocolo. La explicación interna que prevalece es la de la revisión final de Microsoft: un comando con alcance IGP inesperadamente amplio provocó una recomputación, tras la cual BGP tuvo que volver a anunciar y validar los prefijos de Internet.

Cada capa probatoria desempeña una función distinta. El operador aporta el mecanismo interno, los tiempos de sus sistemas y la secuencia de recuperación. ThousandEyes y Kentik aportan mediciones independientes de caminos, rutas y tráfico. La coincidencia entre ambas capas refuerza la explicación. Ninguna debe sustituir a la otra: la telemetría externa no puede inventar la causa interna, y el informe interno no debe borrar el impacto que la Internet pública pudo observar.

Este criterio también resuelve una hipótesis preliminar. Durante la fase temprana se planteó que la automatización podría haber repetido el cambio. Era una pregunta razonable con información incompleta. La revisión final posterior indica que la operación se realizó de nuevo en el segundo router. Por tanto, el relato fiel conserva dos acciones manuales bajo el procedimiento no cualificado, y no presenta la repetición automática como un hecho.

Treinta y tres minutos separaron dos fallos de contención

La monitorización detectó síntomas de DNS y WAN y generó alertas a las 07:11 UTC, pocos minutos después del inicio. Sin embargo, esas alertas no llegaron a la persona que seguía ejecutando el cambio. Treinta y tres minutos tras la primera operación, la misma acción alcanzó el segundo router de Madrid y produjo una nueva perturbación.

ThousandEyes y Kentik también distinguieron dos movimientos de rutas o tráfico. Sus datos no identifican a quien operaba ni explican el circuito interno de comunicación, pero sí corroboran que hubo dos efectos separados. La revisión final aporta la relación organizativa: el canal de incidente no cambió el estado de la tarea antes de la segunda ejecución.

Una alerta que sólo existe en una consola de supervisión es un registro, no todavía una barrera. Para proteger una intervención de alto impacto, la detección debe poder detener el siguiente paso, retirar temporalmente la autorización, exigir una nueva comprobación o transferir la decisión a quien dirige el incidente. No es necesario resolver toda la causa para impedir la repetición del mismo mecanismo mientras el sistema converge.

El expediente no detalla todos los permisos, conversaciones o controles compensatorios. Tampoco identifica al ingeniero ni permite juzgar su intención o capacidad individual. Sí establece propiedades examinables del sistema: un procedimiento cambiado y no probado de nuevo, controles previos y posteriores ausentes, una clasificación incompleta de comandos y un camino de notificación que no interrumpió la continuación del trabajo.

La rendición de cuentas debe centrarse en esas condiciones. Culpar a una persona no nombrada desviaría la atención de la posibilidad concreta de mejorar la cualificación, los puntos de parada y el traspaso de autoridad. La segunda oleada demostró que detección y ejecución podían coexistir sin que la primera limitara a la segunda.

Las fuentes no cuantifican cuánto daño adicional causó cada oleada. Tampoco permiten separar cada paquete o cada cliente entre una y otra. La afirmación sostenible es más limitada: el mismo procedimiento no cualificado pudo afectar dos veces al dominio de enrutamiento, y la segunda operación ocurrió cuando ya se habían generado alertas.

El alcance fue amplio, pero la experiencia no fue uniforme

Microsoft incluye entre las superficies afectadas el tráfico entre Internet y Azure, el tráfico entre regiones y la conectividad híbrida mediante ExpressRoute, VPN o virtual WAN. También hubo dependencias de Microsoft 365, Power Platform y servicios de Azure Government apoyados en Azure público.

La experiencia de los clientes cambiaba con el origen, el destino y el camino disponible. Algunos encontraron latencia o pérdida intermitente; otros vieron tiempos de espera agotados o pérdida total de conectividad en ciertos trayectos. India y partes de Norteamérica estuvieron entre las rutas de recuperación más prolongadas.

Este patrón concuerda con una red que retira, vuelve a anunciar y valida prefijos mientras desplaza tráfico entre peering directo y tránsito. No respalda la afirmación de que toda región, servicio, cliente o ruta de Microsoft fallara de la misma manera. Kentik observó precisamente una mezcla de prefijos afectados y no afectados.

Las fuentes tampoco establecen un número auditado de usuarios o clientes, una pérdida financiera, un inventario completo de servicios ni pérdida de datos. Mantener esos límites no reduce la gravedad del caso. Evita que una conclusión sólida sobre mecanismos de red se convierta en una cifra o acusación que las pruebas no sustentan.

La variabilidad por camino tiene además una consecuencia operacional. Un promedio general de disponibilidad puede ocultar rutas que siguen deterioradas. La recuperación debe medirse tanto a escala agregada como en pares representativos de origen y destino. De lo contrario, un indicador favorable puede declarar el final antes de que determinados usuarios hayan recuperado una conectividad estable.

Recuperar rutas no fue lo mismo que recuperar el sistema completo

Los ingenieros identificaron el comando problemático a las 08:20 UTC mientras la convergencia automática ya avanzaba. Casi todos los dispositivos, regiones y servicios se habían recuperado a las 09:05. El último equipo de red lo hizo a las 09:25. Aun entonces quedaban pérdidas localizadas.

Los sistemas de salud de la WAN y de ingeniería de tráfico se habían quedado en pausa y necesitaron reinicios manuales. Microsoft situó la mitigación completa a las 12:43. Por eso la ventana final de impacto va de las 07:08 a las 12:43, aunque la mayor parte de la conectividad regresara antes.

La información contemporánea sobre una reversión reflejaba lo que se comunicaba mientras la situación seguía abierta. No reemplaza la secuencia más completa de la revisión final: convergencia, recuperación mayoritaria, retorno del último equipo y restauración manual de funciones de apoyo. Describir todo como un rollback que restauró inmediatamente la red borraría las diferencias entre esos hitos.

Una red puede volver a transportar gran parte del tráfico y seguir careciendo de funciones plenamente operativas para detectar caminos enfermos o dirigir el tráfico. La continuidad exige algo más que alcanzabilidad momentánea. Requiere recuperar los sistemas que permiten observar, decidir y corregir el encaminamiento.

Los tres hitos responden a preguntas distintas. Las 09:05 indican una recuperación casi general de equipos, regiones y servicios. Las 09:25 marcan el último equipo de red. Las 12:43 incorporan los sistemas de salud e ingeniería y la pérdida localizada remanente. Un único tiempo resumido no describe adecuadamente el proceso.

Las pruebas sostienen un hallazgo sistémico, no un veredicto legal

La cadena documentada es concreta: una modificación no probada del procedimiento incluyó una orden con semántica distinta entre fabricantes; la orden provocó recomputación IGP, nuevos anuncios BGP y cambios de camino; el trabajo se repitió manualmente antes de que las alertas llegaran a quien podía continuarlo; la recuperación combinó convergencia automática y reinicios manuales.

Microsoft enumeró compromisos como auditar y bloquear comandos de alto impacto según fabricante y función, mostrar a los equipos de guardia actividades cualificadas y no cualificadas, exigir formación y acreditación, y someter procedimientos pendientes a revisión consultiva de cambios. Las cuatro fuentes no verifican de manera independiente que esas medidas se hayan completado ni que hayan resultado eficaces. Deben tratarse como compromisos de remediación, no como resultados comprobados.

El registro tampoco demuestra actividad maliciosa, secuestro BGP, pérdida de datos, un número exacto de afectados, daños económicos auditados, negligencia, incumplimiento contractual ni una resolución judicial o regulatoria. La responsabilidad que sí puede formularse se refiere a la arquitectura de control: una red mundial no puede depender de que autorización, procedimiento y código ejecutable coincidan por su nombre; debe demostrar esa coincidencia en el estado real de las rutas.

Fuentes