Incidencia conectividad Domingo 30 de agosto de 2020
El domingo 30 de agosto de 2020 uno de los mayores proveedores de conectividad a nivel mundial (CenturyLink/Level3) experimento una caída total de su red de comunicaciones. Está caída afecto tanto a clientes de CenturyLink/Level3 como a otros servicios y proveedores en todo Internet.
Mientras seguimos esperando un informe por parte de CenturyLink/Level3 especificando el origen de la caída, como se actuó para remediarla y que medidas se están tomando para evitar que vuelva a producirse una situación similar, queremos hacerte llegar nuestro sobre informe como se gestionó la incidencia desde Clouding.io.
Antecedentes
En Clouding.io trabajamos con múltiples proveedores de conectividad, para asegurar la mayor disponibilidad y velocidad de acceso a los servidores alojados en Clouding.io, desde cualquier punto geográfico.
Agregamos o retiramos puntualmente proveedores de nuestra “pool” de conectividad en función de su calidad y confiabilidad.
CenturyLink/Level3 fue agregado hace aproximadamente dos años a nuestra plataforma, ya que entre otras cosas aporta una conectividad excelente hacia todos los clientes de Movistar en España.
Durante los últimos dos años -y hasta esta última incidencia- ha sido el mejor proveedor de nuestra “pool” de conectividad y el que en la actualidad transporta más tráfico desde y hacia Clouding.io.
Incidencia 30 de agosto de 2020
A las 12:18 PM CEST -hora local de España- nuestros sistemas de monitorización detectaron los primeros problemas de conectividad. Nuestro sistema de monitorización funciona tanto desde Clouding.io hacia el exterior -comprobando la conectividad desde nuestra plataforma hacia Internet- como desde el exterior hacia Clouding.io.
La monitorización externa de conectividad de la plataforma, se realiza mediante un proveedor de monitorización, de forma que se monitoriza la conectividad una vez por segundo desde múltiples ubicaciones geográficas.
El sistema de monitorización externa empezó a reportar de problemas puntuales de conectividad a las 12:18:31 PM CEST los cuales se recuperaban al cabo de 2 o 3 minutos.
Al recibir la primera alerta, uno de nuestros técnicos de guardia reviso el flujo de tráfico a los diferentes proveedores, detectando que no se estaba enviando ni recibiendo tráfico hacía CenturyLink/Level3 pero que la sesión BGP hacía el mismo seguía activa.
Este tipo de situaciones no deberían ocurrir, ya que, en caso de un fallo en un proveedor, el comportamiento esperando es que la sesión BGP se desconecte y el proveedor quede desactivado automáticamente.
La situación que se produjo fue lo que se suele denominar un “BGP Blackholing”, situación en la que un proveedor deja de enrutar tráfico correctamente sin llegar a desconectar la sesión BGP.
Ante estas situaciones excepcionales, nuestro protocolo de actuación es muy sencillo: Simplemente desactivamos manualmente la sesión BGP con el proveedor afectado y nos ponemos en contacto con ellos para saber que ha ocurrido. Una vez el proveedor nos indica que la situación ha sido solventada, se programa una ventana para reactivar la conectividad con el mismo.
Por precaución la conectividad se suele restablecer en horas de baja carga, habitualmente de madrugada, para evitar problemas de conectividad en el caso de que el proveedor no haya solventado la incidencia correctamente.
La “pool” de proveedores de conectividad de Clouding.io esta dimensionada de forma que incluso con un solo proveedor activo, disponemos de ancho de banda más que suficiente para que el rendimiento del servicio no vea afectado en lo más mínimo.
¿Por qué nos se solvento la incidencia en este momento?
Bien, esto es algo que nos seguimos hasta cierto punto preguntado. Estamos esperando un informe detallado por parte de CenturyLink/Level3, pero desde el equipo de Clouding.io hemos podido recopilar bastante información.
Según la información que hemos podido recabar, CenturyLink/Level3 siguió anunciando nuestras IPs al resto de Internet, a pesar de que habíamos cerrado manualmente la sesión BGP con ellos.
Esto es algo que nunca debería ocurrir, ya que un proveedor solo debería anunciar nuestras direcciones a otros proveedores siempre y cuando nosotros se las estemos anunciando en ese momento.
Al cerrar manualmente la sesión BGP de Clouding.io hacia CenturyLink/Level3, CenturyLink/Level3 tendría que haber dejado de anunciar las direcciones IP de Clouding.io al resto de Internet, de forma que el tráfico pasase a ser redirigido a otros proveedores.
Al ser CenturyLink/Level3 un proveedor Tier 1 -es decir, unos de los proveedores de conectividad más grandes con amplia presencia a nivel mundial-. Y al seguir anunciando nuestras direcciones IP al resto de Internet, parte del tráfico de entrada a Clouding.io no se redirigió normalmente hacia los otros proveedores con los que trabajamos y se siguió intentado enviar por la red de CenturyLink/Level3 la cual se encontraba inoperativa.
¿Qué hicimos desde Clouding.io para solucionar el problema?
El primer paso fue identifica el origen del problema, para lo que tuvimos que consultar a otros proveedores para ver que anuncios estaban recibiendo.
Paralelamente abrimos incidencias con todos nuestros otros proveedores, para asegurarnos de que estaban al tanto de la situación y que ellos tomasen también medidas paliativas.
Una vez detectamos que muchos proveedores seguían recibiendo los anuncios de direcciones de CenturyLink/Level3 empezamos a realizar cambios en la forma en que anunciamos nuestras direcciones IP al resto de proveedores.
El protocolo BGP suele optar siempre por el anuncio más específico. Es decir, si por ejemplo un anuncio contiene un grupo de 2048 IPs y otro un grupo de 1024 IPs, dará preferencia -excepto en algunos casos en los que el tráfico esté forzado- al anuncio más específico, es decir el de 1024 IPs.
Por lo tanto, la primera medida paliativa fue cambiar todos nuestros anuncios a anuncios más específicos, para suplantar los anuncios que CenturyLink/Level3 seguía haciendo. Este procedimiento es algo complejo, ya que implica reconfigurar nuestros Edge Routers y en algunos casos se debe coordinar con los diferentes proveedores, ya que ellos también deben realizar cambios en sus filtros de anuncios.
Esta estrategia nos permitió ir recuperando la conectividad hacía la mayor parte de Internet, si bien no fue una solución completa, ya que algunos proveedores de conectividad externos a Clouding.io nos seguían intentando enviar el tráfico mediante CenturyLink/Level3.
¿Cuál fue la escala de tiempo exacta de la incidencia?
Es bastante difícil identificar la escala de tiempo exacta, ya que esta incidencia afecto a multitud de proveedores y servicios de Internet. Entre ellos al sistema de monitorización externa que utilizamos, pero según la información que hemos podido recabar la escala aproximada fue:
12:18 PM CEST – Se detecta la primera incidencia.
12:21 PM CEST – Desactivamos la conectividad con CenturyLink/Level3 manualmente.
12:45 PM CEST Aprox. – Empezamos a publicar nuevos anuncios BGP recuperando progresivamente mayor conectividad.
Entre 12:30 y 14:30 – Diversos proveedores mundiales desactivan manualmente sus sesiones BGP con CenturyLink/Level3 para eliminar los anuncios falsos, proceso que nos ayuda a recuperar todavía mayor conectividad.
16:00 PM CEST Aprox – CenturyLink/Level3 consigue eliminar los anuncios “falsos” que estaba realizando y se recupera el 100% de conectividad
Conclusión
Debido a la naturaleza de Internet -una gran red conformada por otras redes interconectadas- siempre existirán factores que escaparán a nuestro control. Si bien nuestra filosofía siempre ha sido -y seguirá siendo- trabajar con los mejores proveedores, para minimizar el riesgo de incidencias en el servicio.
Esta ha sido una de las mayores caídas de Internet a nivel mundial de los últimos tiempos y desgraciadamente no existe una forma sencilla de automatizar un sistema capaz de reaccionar a este tipo de situaciones.
En todo caso, consideramos que una incidencia en el servicio siempre debe comportar mejoras, ya sea en nuestros sistemas o en nuestros protocolos de actuación. Por lo tanto, hemos empezado a trabajar en una forma más rápida y sencilla de cambiar los anuncios de rangos IP que realizamos a Internet. De esta forma en el extraño caso de que una situación así se vuelva a producir, podremos reaccionar más rápido y recuperar el mayor porcentaje del servicio en un menor espacio de tiempo.
Links Noticias Relacionadas
https://blog.cloudflare.com/analysis-of-todays-centurylink-level-3-outage/
https://edition.cnn.com/2020/08/30/tech/internet-outage-cloudflare/index.html
Deja una respuesta