Resumen

  • Aproximadamente a las 14:30, hora del Pacífico, del 9 de junio de 2020, era visible una interrupción amplia de la red de IBM Cloud: fallaban servicios alojados y la página principal de estado de IBM devolvía un error interno del servidor.
  • IBM atribuyó el origen técnico a un proveedor de red externo. Según el aviso de la empresa, ese proveedor inundó IBM Cloud con información de enrutamiento incorrecta, lo que causó congestión severa y afectó servicios en la nube y centros de datos.
  • La rendición de cuentas exige distinguir los mandos de cada operador y conservar un plano de gestión, el conjunto de canales desde los que se administra la red, que siga disponible aunque falle el camino utilizado por los clientes o por la página de estado.

Una interrupción visible antes de conocerse la causa

Los primeros indicios públicos no explicaban por qué estaba fallando IBM Cloud; mostraban sus consecuencias. Alrededor de las 14:30, hora del Pacífico, del 9 de junio, los usuarios tenían dificultades para acceder a servicios alojados. Al mismo tiempo, la página principal con la que IBM informaba del estado de su plataforma devolvía un error interno del servidor. Habían quedado afectadas dos capacidades distintas: utilizar los servicios y consultar un canal central de información sobre la avería.

Esa diferencia es importante. Una aplicación puede seguir ejecutándose en un servidor y, sin embargo, ser inútil si las solicitudes no pueden llegar hasta ella o si las respuestas no encuentran un camino de vuelta. Del mismo modo, un mensaje de estado puede ser correcto pero no llegar al público si comparte la conectividad que está fallando. La continuidad, por tanto, incluye tanto el servicio como la capacidad de administrarlo y explicar su estado.

Las fuentes no establecen una sola hora de restauración para todos los clientes, regiones y componentes. La recuperación fue escalonada y cada observador describió lo que podía ver desde su propio servicio. Convertir esas experiencias en una duración mundial uniforme ocultaría diferencias entre aplicaciones, consolas, enlaces y regiones que la evidencia pública no permite resolver.

La causa que IBM comunicó

En su aviso conservado, IBM atribuyó la perturbación a un proveedor de red externo. La empresa afirmó que ese proveedor había inundado IBM Cloud con información de enrutamiento incorrecta y que el resultado había sido una congestión severa con efectos en servicios en la nube y centros de datos. Esa es una atribución de IBM; no es una inspección pública de los equipos, las conexiones BGP o las reglas privadas de las dos empresas.

BGP permite que un operador diga a las redes conectadas qué bloques de direcciones puede alcanzar. La red que recibe un anuncio lo evalúa con su política de enrutamiento, el conjunto de reglas que decide qué caminos aceptar, rechazar o preferir. Si entra una cantidad anómala de datos incorrectos y las protecciones no los contienen a tiempo, los equipos pueden soportar más carga, elegir caminos que no sirven y dirigir tráfico hacia destinos equivocados.

La convergencia de rutas es el proceso mediante el cual los equipos comparten cambios hasta alcanzar una visión estable de los caminos disponibles. Durante una avería no ocurre de inmediato en todos los puntos. La retirada de una ruta —el aviso de que un camino ya no está disponible— puede tardar en llegar a redes vecinas; una regla corregida puede aplicarse antes en una zona que en otra; y las conexiones existentes pueden comportarse de forma distinta a los intentos nuevos. Este mecanismo permite entender una recuperación por etapas, pero no permite asignar tiempos concretos a equipos o regiones que no aparecen en las fuentes.

Tampoco permite identificar al proveedor. No se han hecho públicos el sistema autónomo de origen —una red administrada bajo una política común—, los prefijos, los caminos, los datos adicionales asociados a cada anuncio, las conexiones entre operadores ni el código de las reglas. Cualquier nombre o configuración que se añadiera a esos vacíos sería una conjetura.

Zello documentó cómo se tradujo la avería en pérdida de servicio

Zello aportó una observación independiente desde la posición de un cliente afectado. La empresa registró fallos generalizados al iniciar sesión y al volver a conectarse. Usuarios que ya aparecían conectados perdieron la comunicación, las consolas administrativas —las herramientas desde las que se gestiona el servicio— quedaron inaccesibles y cuatro servicios resultaron afectados.

Esos efectos muestran por qué una incidencia de red no puede reducirse a una cifra técnica. Quien no consigue iniciar sesión pierde acceso; quien parece conectado pero no puede comunicarse puede confiar en un canal que ya ha dejado de funcionar; y quien no puede abrir una consola pierde capacidad de diagnóstico y respuesta. Para un servicio de comunicación, que el cómputo siga activo no basta si los mensajes no recorren la red en ambos sentidos.

En su informe posterior, Zello explicó que se había introducido una gran cantidad de rutas y que, como consecuencia, servidores alojados en IBM Cloud enviaban tráfico IPv4 hacia destinos incorrectos. IPv4 es la versión de uso extendido del Protocolo de Internet que identifica interfaces mediante direcciones numéricas. Zello describía el comportamiento de sus servidores y su tráfico de salida; no identificaba a quien originó cada ruta ni revelaba la regla de IBM que la aceptó.

La alcanzabilidad tampoco es una propiedad única de toda una plataforma. Una dirección puede responder mientras otra no lo hace; el camino de ida puede funcionar y el de vuelta fallar; una sesión existente puede romperse mientras otra nueva toma un camino distinto. El relato de Zello demuestra efectos concretos, pero no proporciona la cifra total de clientes, regiones, transacciones o pérdidas.

Los informes de clientes y socios acotan la actuación de IBM

El medio especializado CRN informó de clientes y socios que habían perdido acceso a entornos, consolas y pantallas de estado. También comunicó que el equipo de operaciones de red de IBM ajustó políticas de enrutamiento durante la recuperación. Esto vincula una acción concreta con IBM: su equipo podía cambiar la forma en que su red trataba las rutas mientras intentaba restablecer el servicio.

La información disponible no muestra qué regla se modificó, en qué equipos se desplegó, quién autorizó el cambio ni cuál fue su efecto aislado. La recuperación también pudo coincidir con retiradas de rutas por parte del proveedor, estabilización de conexiones y recuperación de otros componentes. Por eso puede afirmarse que IBM ajustó sus políticas; no puede atribuirse toda la restauración a un único cambio privado.

Responsabilidad operativa no equivale a culpabilidad jurídica. Consiste en identificar qué operador podía observar una condición, qué decisión podía tomar y qué registro puede presentar después. Las fuentes documentan algunas acciones y consecuencias, pero no exponen contratos, alertas internas, aprobaciones ni instrucciones de respuesta.

Cada operador controlaba una parte diferente de la frontera

La titularidad del control es la identificación de quién puede cambiar cada elemento operativo. El proveedor externo controlaba la validación de lo que enviaba, la detección de anomalías en sus anuncios y la retirada de información incorrecta. IBM controlaba en su lado la aceptación de rutas, los límites y alarmas, la posibilidad de aislar una conexión, la recuperación de sus servicios y la comunicación con clientes.

Que el problema se originara fuera de IBM, según la explicación de la compañía, no eximía automáticamente al operador que recibía las rutas y prestaba el servicio final. Tampoco significa que IBM pudiera impedir cualquier error de un tercero. Las dos partes disponían de mandos diferentes. El reparto contractual exacto de las tareas de filtrado, alerta, corrección y notificación sigue sin ser público.

Un límite máximo de prefijos es una protección que restringe cuántos bloques de direcciones se aceptarán de una red conectada antes de generar una alerta o ejecutar otra respuesta. Puede reducir el efecto de un crecimiento anómalo, pero no es una solución automática: necesita un umbral adecuado, excepciones controladas y una acción segura cuando se supera. Las fuentes no dicen si IBM aplicaba ese límite en junio de 2020, qué valor tenía ni cómo estaba configurada la respuesta.

La telemetría, es decir, las mediciones y registros continuos de la red, puede revelar aumentos repentinos del número de rutas, cambios de camino, pérdida de conexiones o caída de servicios. Una alarma, sin embargo, solo reduce el riesgo si llega a alguien que tenga autoridad para actuar y si existe una respuesta previamente evaluada. Los registros internos que permitirían saber qué detectó IBM, cuándo lo detectó y quién decidió la respuesta no son públicos.

Informar durante la avería también es una función de continuidad

El error de la página principal de estado privó a los clientes de un canal importante en un momento crítico. Sin información fiable, una organización no sabe si debe esperar, cambiar de región, activar un proveedor alternativo o investigar sus propias aplicaciones. Varias respuestas improvisadas al mismo tiempo pueden aumentar el riesgo.

El acceso fuera de banda y la comunicación de estado son canales administrativos e informativos que no dependen por completo del camino principal afectado. Pueden apoyarse en conectividad alternativa, alojamiento separado y vías de contacto probadas. No son inmunes a toda avería, pero reducen la posibilidad de perder a la vez el servicio, la capacidad de administrarlo y el medio para explicar lo que ocurre.

Esa separación limita el radio de impacto, el conjunto de usuarios, servicios y funciones que puede alcanzar un solo fallo. Si las cargas de clientes, las herramientas de gestión y la página de estado dependen del mismo camino, una perturbación puede inutilizar las tres. Si algunas funciones tienen independencia real, el operador conserva opciones para observar, comunicar y recuperar.

El fallo visible de la página no prueba que todas las herramientas internas de IBM estuvieran caídas. La arquitectura privada de gestión no se conoce. Sí prueba que un canal público importante no estuvo disponible cuando era necesario, y eso basta para preguntar si la comunicación de estado tenía suficiente independencia.

Restaurar el servicio no demuestra la eficacia actual de las medidas

IBM dijo que los servicios se habían restaurado, que había adoptado medidas de mitigación y que su investigación sobre la causa principal no había identificado pérdida de datos ni problemas de ciberseguridad. Estas son afirmaciones de IBM con un alcance limitado; no constituyen una auditoría independiente del estado de cada cliente.

No haber identificado pérdida de datos tampoco excluye transacciones fallidas, retrasos o costes de respuesta. Pérdida de datos, indisponibilidad y perjuicio comercial son consecuencias diferentes. Las fuentes no ofrecen una cifra completa con la que cuantificarlas ni establecen el resultado de acuerdos de nivel de servicio.

Las medidas comunicadas después del incidente no prueban por sí mismas que hoy sean eficaces. Para evaluar esa eficacia harían falta datos sobre su implantación, alcance, excepciones, pruebas posteriores y resultados independientes. La información utilizada aquí no los aporta. Solo permite afirmar que IBM comunicó medidas de mitigación, no que estas eliminen la posibilidad de que el problema se repita.

El RFC 7454 ofrece orientación, no una reconstrucción del incidente

El documento técnico RFC 7454 describe buenas prácticas para operadores de BGP. Entre ellas figuran las reglas en los bordes, el filtrado de prefijos entrantes y salientes y los límites máximos adaptados a cada red conectada. Es una referencia para pensar qué protecciones pueden aplicarse y qué preguntas deben hacerse.

No demuestra la configuración que IBM o el proveedor utilizaban en 2020, ni garantiza que una sola medida hubiera evitado todos los efectos. Un filtro necesita datos correctos y mantenimiento; un límite necesita un umbral y una respuesta; cortar una conexión puede contener información incorrecta y también retirar caminos válidos. Lo decisivo es cómo funcionan las reglas en la red real, no que una recomendación exista sobre el papel.

La guía sirve para formular preguntas verificables hacia el futuro: qué anuncios se esperan de cada red, qué volumen es normal, qué alerta se genera, quién puede aislar la conexión y cómo se recupera el servicio. Las respuestas exigirían registros y pruebas actuales; el documento no puede suministrarlas para este caso.

Lo que sigue sin saberse

La evidencia no identifica al proveedor ni al sistema autónomo que originó la información. Tampoco revela prefijos, caminos, atributos, conexiones BGP, reglas privadas, topología interna, alertas, responsables individuales de cada decisión o diseño del plano de gestión. No existe una cifra completa de clientes, regiones, transacciones o pérdidas.

Ninguna fuente utilizada establece negligencia, incumplimiento regulatorio, daños jurídicamente atribuibles, un resultado contractual concreto, conducta delictiva o responsabilidad individual. Tampoco demuestra un origen malicioso, una denegación de servicio distribuida (DDoS) —una saturación provocada desde múltiples sistemas—, sabotaje o compromiso de ciberseguridad. La afirmación de IBM de que no identificó problemas de ciberseguridad debe seguir atribuida a su propia investigación.

La conclusión responsable distingue cuatro categorías. Se observó una interrupción amplia y la caída de un canal de estado. IBM atribuyó el incidente a información incorrecta procedente de un proveedor externo. Zello y CRN aportaron observaciones sobre efectos y recuperación. La identidad del proveedor, la configuración privada, el reparto contractual y la eficacia actual de las medidas continúan sin verificación pública.

Fuentes

  1. https://www.theregister.com/2020/06/11/ibm_blames_external_network_provider/
  2. https://techcrunch.com/2020/06/09/ibm-cloud-suffers-prolonged-outage/
  3. https://www.crn.com/news/cloud/ibm-blames-massive-cloud-outage-on-third-party-network-provider
  4. https://status.zellowork.com/issues/5ef227ab4a0ebd6da0cb113e
  5. https://www.rfc-editor.org/rfc/rfc7454.html
  6. https://btw.media/en/directory/international-business-machines-corporation-united-states-of-america-the