¿Cómo desapareció Facebook de Internet?

05/10/2021

Facebook ahora ha publicado una publicación en el blog que brinda 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 red troncal interna. Eso hizo que Facebook y otras propiedades desaparecieran y el personal interno de Facebook tuviera dificultades para volver a poner en funcionamiento el servicio.

Facebook publicó una publicación de blog adicional con muchos más detalles sobre lo que sucedió. Puede leer esa publicación para la vista interior y esta publicación para la vista exterior.

Ahora pasemos a lo que vimos desde fuera.

Conoce a BGP

BGP son las siglas de Border Gateway Protocol. Es un mecanismo para intercambiar información de enrutamiento entre sistemas autónomos (AS) en Internet. Los grandes enrutadores que hacen que Internet funcione tienen listas enormes y constantemente actualizadas de las posibles rutas que se pueden utilizar para entregar cada paquete de red a sus destinos finales. Sin BGP, los enrutadores 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 anuncia 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 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).

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 es el más rápido, y AS1 → AS6 → AS5 → AS4 → AS3 es el más lento, pero eso se puede usar si el primero falla.

A las 15:58 UTC se noto 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 sistema de resolución 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>

Un mensaje de ACTUALIZACIÓN de BGP informa a un enrutador de cualquier cambio que haya realizado en un anuncio de prefijo o retira por completo el prefijo. Podemos ver esto claramente en la cantidad de actualizaciones que recibimos de Facebook al verificar nuestra base de datos BGP de series de tiempo. Normalmente, este gráfico es bastante silencioso: Facebook no realiza muchos cambios en su red minuto a minuto.

Pero alrededor de las 15:40 UTC se noto un pico de cambios en el enrutamiento de Facebook. Fue entonces cuando empezó el problema.

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 sala 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 en 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 resolutores 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 el DNS, como muchos otros sistemas en Internet, también tiene su mecanismo de enrutamiento. Cuando alguien escribe la URL https://facebook.com en el navegador, el solucionador de DNS, responsable de traducir los nombres de dominio a direcciones IP reales para 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 propietaria.

Si no se puede acceder a los servidores de nombres o no responden por algún otro motivo, se devuelve un SERVFAIL y el navegador envía un error al usuario.

Una buena explicación sobre cómo funciona el DNS.

Debido a que Facebook dejó 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 la aplicación entran en juego y provocan otro efecto exponencial. Sigue un tsunami de tráfico DNS adicional.

Esto sucedió en parte porque las aplicaciones no aceptarán un error como respuesta y comenzarán a intentarlo de nuevo, a veces de manera agresiva, y en parte porque los usuarios finales tampoco aceptarán un error como respuesta y comenzarán a recargar las páginas, o matarán y relanzarán sus aplicaciones, a veces también de forma agresiva.

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

Entonces, 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 pueden causar problemas de latencia y tiempo de espera en otras plataformas.

Afortunadamente, 1.1.1.1 se creó para ser gratuito, privado, rápido (como puede atestiguar el monitor DNS independiente DNSPerf ) y escalable, y pudimos seguir prestando servicios 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 TTL vencidos tuvieron 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.

Impactando otros servicios

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

También se pudo ver otro efecto secundario de esta inaccesibilidad 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 las 15:45 UTC a las 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ó.

La 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 son fundamentales para que funcione para casi cinco mil millones de usuarios activos en todo el mundo.

Actualizar

Alrededor de las 21:00 UTC, se observo una actividad renovada 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 sistema de resolución 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 lugar a dudas, los servicios de Facebook, WhatsApp e Instagram tardarán más en conectarse, pero a las 21:28 UTC, Facebook parece estar reconectado a Internet global y el DNS vuelve a funcionar.

FUENTE:

https://blog.cloudflare.com/october-2021-facebook-outage/

 

COMPARTE !!!

Share on facebook
Facebook
Share on whatsapp
WhatsApp
Share on telegram
Telegram
Share on email
Email