Resumen

  • Una orden de mantenimiento desconectó la red troncal. Después se retiraron las rutas de los servidores DNS, que seguían funcionando pero resultaban inaccesibles.
  • Las observaciones externas permiten seguir la desaparición y el regreso de esas rutas. No miden el viaje de los técnicos ni la duración exacta del fallo en todas las aplicaciones.

Si una aplicación no abre, probar otra parece una salida razonable. El 4 de octubre de 2021, pasar de Facebook a Instagram o WhatsApp no evitaba el problema: el mismo fallo alcanzaba a los tres servicios. Para quien los utilizaba para estar en contacto, cambiar de icono no significaba recuperar la conexión.

La salida dependía de una reparación, pero quienes debían hacerla tampoco podían entrar como de costumbre en sus sistemas. La empresa tuvo que enviar ingenieros a las instalaciones. Antes de devolver a los usuarios sus servicios, necesitaba recuperar parte de sus propios accesos.

Todo había empezado con una orden que no pretendía apagar nada. Debía comprobar cuánta capacidad quedaba disponible en la red troncal mundial. Según el informe técnico de la empresa, hizo algo muy distinto: desconectó los enlaces entre sus centros de datos. Un error del programa de auditoría impidió que la comprobación prevista la detuviera.

El servidor estaba; faltaba el camino

Para llegar a un servicio por su nombre, un dispositivo suele necesitar primero una respuesta del DNS, el sistema que permite localizar su dirección. Los servidores DNS de Facebook dejaron de alcanzar los centros de datos a través de la red troncal. Su reacción prevista fue retirar sus anuncios BGP, las indicaciones de ruta que intercambian las redes de internet.

No es lo mismo apagar un servidor que dejar de anunciar cómo llegar a él. Los servidores DNS seguían operativos, explica la empresa, pero desde internet ya no eran accesibles. El resultado para el usuario podía parecer idéntico: la aplicación no llegaba a su destino. Para reparar el fallo, la diferencia era decisiva.

Cloudflare observó una oleada de cambios de enrutamiento hacia las 15:40 UTC. A las 15:58 detectó la retirada de las rutas correspondientes a los prefijos DNS. Otros prefijos de Facebook conservaban sus rutas. No habían desaparecido todas las direcciones de la empresa ni había dejado de funcionar todo internet.

El registro externo encaja con el relato de Facebook, pero no permite ver la orden de mantenimiento ni el estado de la herramienta de auditoría. Son dos perspectivas que se complementan, no dos mediciones independientes de cada paso interno.

Volver a entrar era parte de la reparación

La empresa perdió tanto el acceso habitual a su red como el acceso de gestión separado, conocido como fuera de banda. La falta de DNS también inutilizó herramientas internas de investigación. El informe no establece que el DNS fuera la causa concreta del fallo del acceso fuera de banda; sumar ambos problemas no autoriza a inventar ese enlace causal.

Hubo que enviar ingenieros a las instalaciones para restablecer el acceso. Las medidas de seguridad física y de los sistemas dificultaron la entrada y los cambios en los equipos. Es un obstáculo bastante concreto sin necesidad de añadir un técnico solitario, una carrera en coche o un tiempo de viaje que las fuentes no documentan.

Cuando regresaron los enlaces, tampoco convenía encenderlo todo de golpe. La empresa describe un reinicio cuidadoso para evitar aumentos bruscos de tráfico y demanda eléctrica. Los simulacros anteriores ayudaron, aunque no se había ensayado la pérdida completa de la red troncal mundial.

Un reloj no cuenta toda la historia

Cloudflare vio reaparecer actividad BGP hacia las 21:00 UTC, con un máximo a las 21:17. A las 21:28, la reconexión mundial y el DNS parecían recuperados. Las aplicaciones podían tardar más.

Desde las 15:58 hasta las 21:28 transcurren 330 minutos. Es la distancia entre dos observaciones, no una duración idéntica para cada servicio, país y usuario. Tampoco es el tiempo que alguien pasó camino de un centro de datos. Y los dieciocho minutos entre los primeros dos registros no prueban que esa fuera la única ocasión interna para detectar el fallo.

Mientras tanto, los reintentos de aplicaciones y resolutores añadieron trabajo al DNS. En el resolutor 1.1.1.1 de Cloudflare aumentó la latencia de las consultas más lentas, pero la mayoría seguía resolviéndose en menos de diez milisegundos. El efecto se extendió fuera de Facebook sin convertir el incidente en un apagón general de internet.

La recuperación tuvo, por tanto, varias llegadas: al equipo, a la red y finalmente al servicio. Confundirlas produce una cronología más sencilla, pero peor. Estos relatos contemporáneos explican lo difícil que fue volver en 2021; no certifican cómo está construida hoy la red de Meta Platforms ni qué mejoras posteriores se ejecutaron.

Corrección del 21 de octubre de 2026: se distinguen los fallos de acceso de gestión y de las herramientas dependientes del DNS. Se han retirado las equivalencias entre horarios externos, tiempo de viaje y duración universal de la caída, así como las conclusiones no acreditadas sobre la arquitectura actual.