Comprender cómo Facebook desapareció de Internet

 

"Facebook no puede estar abajo, ¿verdad?", pensamos, por un segundo.

Hoy a las 15:51 UTC, abrimos un incidente interno titulado "Búsqueda de DNS de Facebook que devuelve SERVFAIL" porque nos preocupaba que algo estuviera mal con nuestro solucionador de DNS 1.1.1.1. Pero cuando estábamos a punto de publicar en nuestra página de estado público, nos dimos cuenta de que algo más serio estaba sucediendo.

Las redes sociales estallaron rápidamente en llamas, informando lo que nuestros ingenieros confirmaron rápidamente también. Facebook y sus servicios afiliados WhatsApp e Instagram estaban, de hecho, todos caídos. Sus nombres DNS dejaron de resolverse y sus IP de infraestructura eran inaccesibles. Era como si alguien hubiera "sacado los cables" de sus centros de datos de una vez y los hubiera desconectado de Internet.

¿Cómo es eso posible?

Actualización de Facebook

Facebook ahora ha publicado una publicación de blog que da algunos detalles de lo que sucedió internamente. Externamente, vimos los problemas de BGP y DNS descritos en esta publicación, pero el problema en realidad comenzó con un cambio de configuración que afectó a toda la columna vertebral interna. Eso se estrelló en facebook y otras propiedades desapareciendo y el personal interno de Facebook teniendo dificultades para que el servicio volviera a funcionar.

Ahora a lo que vimos desde afuera.

Conoce BGP

BGP significa Border Gateway Protocol. Es un mecanismo para intercambiar información de enrutamiento entre sistemas autónomos (AS) en Internet. Los grandes routers que hacen que Internet funcione tienen enormes listas constantemente actualizadas de las posibles rutas que se pueden utilizar para entregar cada paquete de red a sus destinos finales. Sin BGP, los routers de Internet no sabrían qué hacer, e Internet no funcionaría.

Internet es literalmente una red de redes, y está unida por BGP. BGP permite que una red (digamos Facebook) anuncie su presencia a otras redes que forman Internet. Mientras escribimos, Facebook no está anunciando su presencia, los ISP y otras redes no pueden encontrar la red de Facebook y, por lo tanto, no está disponible.

Cada una de las redes individuales tiene un ASN: un número de sistema autónomo. Un sistema autónomo (AS) es una red individual con una política de enrutamiento interna unificada. Un AS puede originar prefijos (digamos que controlan un grupo de direcciones IP), así como prefijos de tránsito (digamos que saben cómo llegar a grupos específicos de direcciones IP).

El ASN de Cloudflare es AS13335. Cada ASN necesita anunciar sus rutas de prefijo a Internet usando BGP; de lo contrario, nadie sabrá cómo conectarse y dónde encontrarnos.

Nuestro centro de aprendizaje tiene una buena visión general de lo que son BGP y ASN y cómo funcionan.

En este diagrama simplificado, puede ver seis sistemas autónomos en Internet y dos rutas posibles que un paquete puede usar para ir de principio a fin. AS1 → AS2 → AS3 siendo el más rápido, y AS1 → AS6 → AS5 → AS4 → AS3 siendo el más lento, pero eso se puede usar si el primero falla.

A las 15:58 UTC notamos que Facebook había dejado de anunciar las rutas a sus prefijos DNS. Eso significaba que, al menos, los servidores DNS de Facebook no estaban disponibles. Debido a esto, el solucionador de DNS 1.1.1.1 de Cloudflare ya no podía responder a las consultas que solicitaban la dirección IP de facebook.com.

route-views>show ip bgp 185.89.218.0/23
% Network not in table
route-views>

route-views>show ip bgp 129.134.30.0/23
% Network not in table
route-views>

Mientras tanto, otras direcciones IP de Facebook permanecieron enrutadas, pero no fueron particularmente útiles ya que sin DNS Facebook y los servicios relacionados no estaban disponibles:

route-views>show ip bgp 129.134.30.0   
BGP routing table entry for 129.134.0.0/17, version 1025798334
Paths: (24 available, best #14, table default)
  Not advertised to any peer
  Refresh Epoch 2
  3303 6453 32934
    217.192.89.50 from 217.192.89.50 (138.187.128.158)
      Origin IGP, localpref 100, valid, external
      Community: 3303:1004 3303:1006 3303:3075 6453:3000 6453:3400 6453:3402
      path 7FE1408ED9C8 RPKI State not found
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
route-views>

Hacemos un seguimiento de todas las actualizaciones y anuncios de BGP que vemos en nuestra red global. A nuestra escala, los datos que recopilamos nos dan una visión de cómo está conectado Internet y dónde se supone que fluye el tráfico desde y hacia cualquier parte del planeta.

Un mensaje BGP UPDATE informa a un router de cualquier cambio que haya realizado en un anuncio de prefijo o lo retire por completo. Podemos ver claramente esto en la cantidad de actualizaciones que recibimos de Facebook al verificar nuestra base de datos BGP de series temporales. Normalmente, este gráfico es bastante silencioso: Facebook no hace muchos cambios en su red minuto a minuto.

Pero alrededor de las 15:40 UTC vimos un pico de cambios de enrutamiento de Facebook. Fue entonces cuando comenzaron los problemas.

Si dividimos esta visión por rutas de anuncios y retiros, tenemos una idea aún mejor de lo que sucedió. Se retiraron las rutas, los servidores DNS de Facebook se desconectaron y, un minuto después de que ocurriera el problema, los ingenieros de Cloudflare estaban en una habitación preguntándose por qué 1.1.1.1 no podía resolver facebook.com y preocupándose de que de alguna manera fuera una falla con nuestros sistemas.

Con esos retiros, Facebook y sus sitios se habían desconectado efectivamente de Internet.

DNS se ve afectado

Como consecuencia directa de esto, los solucionadores de DNS de todo el mundo dejaron de resolver sus nombres de dominio.

➜  ~ dig @1.1.1.1 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com.			IN	A
➜  ~ dig @1.1.1.1 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com.			IN	A
➜  ~ dig @8.8.8.8 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com.			IN	A
➜  ~ dig @8.8.8.8 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com.			IN	A

Esto sucede porque DNS, como muchos otros sistemas en Internet, también tiene su mecanismo de enrutamiento. Cuando alguien escribe la URL de https://facebook.com en el navegador, el solucionador de DNS, responsable de traducir los nombres de dominio en direcciones IP reales a las que conectarse, primero verifica si tiene algo en su caché y lo usa. De lo contrario, intenta obtener la respuesta de los servidores de nombres de dominio, normalmente alojados por la entidad que lo posee.

Si los servidores de nombres son inaccesibles o no responden debido a alguna otra razón, se devuelve un SERVFAIL y el navegador emite un error al usuario.

Una vez más, nuestro centro de aprendizaje proporciona una buena explicación sobre cómo funciona DNS.

Debido a que Facebook detuvo de anunciar sus rutas de prefijo DNS a través de BGP, nuestros resolutores de DNS y los de todos los demás no tenían forma de conectarse a sus servidores de nombres. En consecuencia, 1.1.1.1, 8.8.8.8 y otros importantes solucionadores de DNS públicos comenzaron a emitir (y almacenar en caché) respuestas SERVFAIL.

Pero eso no es todo. Ahora el comportamiento humano y la lógica de aplicación se activan y causan otro efecto exponencial. Sigue un tsunami de tráfico DNS adicional.

Esto sucedió en parte porque las aplicaciones no aceptarán un error para una respuesta y comenzarán a volver a intentarlo, a veces agresivamente, y en parte porque los usuarios finales tampoco tomarán un error por una respuesta y comenzarán a recargar las páginas, o matar y relanzar sus aplicaciones, a veces también agresivamente.

Este es el aumento de tráfico (en número de solicitudes) que vimos en 1.1.1.1:

Así que ahora, debido a que Facebook y sus sitios son tan grandes, tenemos solucionadores de DNS en todo el mundo que manejan 30 veces más consultas de lo habitual y potencialmente causan problemas de latencia y tiempo de espera a otras plataformas.

Afortunadamente, 1.1.1.1 fue construido para ser gratuito, privado, rápido (como puede atestiguar el monitor DNSperf independiente) y escalable, y pudimos seguir atendiendo a nuestros usuarios con un impacto mínimo.

La gran mayoría de nuestras solicitudes de DNS se resolvieron en menos de 10 ms. Al mismo tiempo, una fracción mínima de los percentiles p95 y p99 vio un aumento en los tiempos de respuesta, probablemente debido a que los TTTL caducados tienen que recurrir a los servidores de nombres de Facebook y al tiempo de espera. El límite de tiempo de espera de DNS de 10 segundos es bien conocido entre los ingenieros.

Impacto en otros servicios

La gente busca alternativas y quiere saber más o discutir lo que está pasando. Cuando Facebook se volvió inaccesible, comenzamos a ver un aumento de las consultas de DNS a Twitter, Signal y otras plataformas de mensajería y redes sociales.

También podemos ver otro efecto secundario de esta inalcanzabilidad en nuestro tráfico WARP hacia y desde el ASN 32934 afectado de Facebook. Este gráfico muestra cómo cambió el tráfico de 15:45 UTC a 16:45 UTC en comparación con tres horas antes en cada país. En todo el mundo, el tráfico WARP hacia y desde la red de Facebook simplemente desapareció.

The Internet

Los eventos de hoy son un suave recordatorio de que Internet es un sistema muy complejo e interdependiente de millones de sistemas y protocolos que trabajan juntos. Esa confianza, estandarización y cooperación entre entidades están en el centro de hacer que funcione para casi cinco mil millones de usuarios activos en todo el mundo.

Actualizar

Alrededor de las 21:00 UTC vimos una renovada actividad de BGP de la red de Facebook que alcanzó su punto máximo a las 21:17 UTC.

Este gráfico muestra la disponibilidad del nombre DNS 'facebook.com' en el solucionador de DNS 1.1.1.1 de Cloudflare. Dejó de estar disponible alrededor de las 15:50 UTC y regresó a las 21:20 UTC.

Sin duda, los servicios de Facebook, WhatsApp e Instagram tardarán más tiempo en conectarse, pero a partir de las 21:28 UTC Facebook parece estar reconectado a la Internet global y dns funcionando nuevamente.

Fuente: CloudFlare