El nuevo ShakeAlert de Edgio proporciona una mayor visibilidad de los eventos de la red
Cuando se operan redes grandes distribuidas globalmente, los fallos de hardware, las interrupciones del proveedor y otros cambios en el comportamiento son ocurrencias regulares. Por lo tanto, los sistemas que pueden levantar alarmas a los primeros signos de problemas pueden alertar a los operadores humanos o a los sistemas automatizados y permitir una acción correctiva más rápida. Con este fin, desarrollamos ShakeAlert, un sistema de alertas construido sobre datos externos disponibles públicamente para alertar sobre cambios repentinos en Internet.
ShakeAlert monitorea flujos de actualizaciones BGP (Border Gateway Protocol) observadas desde colectores públicos para las rutas que se originan en la CDN. Cuando el volumen de actualizaciones aumenta bruscamente, ShakeAlert genera una alarma, llamada Shake, señalando un posible cambio en el comportamiento de enrutamiento de Internet y, en particular, en cómo las redes externas enrutan su tráfico a la CDN. Utilizando el contenido de estas actualizaciones, ShakeAlert proporciona además una estimación de los POPs (puntos de presencia), proveedores y prefijos probablemente afectados.
El sistema lleva el nombre del sistema de alerta temprana de terremotos del Servicio Geológico de los Estados Unidos. Ese sistema funciona detectando ondas P en movimiento más rápido, pero menos destructivas, y alertando a los residentes antes de que lleguen las ondas S más destructivas. Aquí, consideramos las señales del plano de control de BGP como la señal de alerta temprana para los cambios potencialmente relacionados con el plano de datos y el tráfico del usuario final.
Antecedentes
Con el fin de facilitar el enrutamiento entre Sistemas Autónomos (ASES) en Internet, las redes comunican a qué prefijos tienen rutas vía BGP. Como parte de esta comunicación, cuando cambia la accesibilidad de un prefijo, una red envía una serie de anuncios llamados anuncios que indican los prefijos afectados y la ruta que la red usaría para llegar a ellos.
En el funcionamiento regular de Internet, miles de estos mensajes se intercambian entre redes a medida que actualizan sus tablas de enrutamiento. Cada vez que estas rutas cambian, por ejemplo, como resultado de fallos de red, nueva conectividad entre redes o mantenimiento planificado, un nuevo conjunto de mensajes puede ser intercambiado. Estos pueden incluir cambios generados por la red de origen (por ejemplo, anunciar un nuevo bloque de IP) o cambios que ocurren aguas abajo del origen (por ejemplo, cambios de conectividad en un proveedor de tránsito).
Estos mensajes necesariamente ofrecen una gran cantidad de información sobre el estado actual de Internet, revelando las ganancias y pérdidas de conectividad entre las redes. Para aprovechar esta información, muchas organizaciones1 ejecutan servicios llamados recopiladores de rutas, que se conectan con muchas redes y hacen que los mensajes de actualización recopilados estén disponibles públicamente.
Cuando cambia la conectividad, las redes ascendentes envían actualizaciones BGP, que eventualmente llegan a los recopiladores BGP.
Para desarrollar un sentido de estos comportamientos, consideramos algunas observaciones iniciales. Consideramos los feeds de actualización resultantes para un puñado de redes diferentes. Consideramos dos grandes redes CDN (CDN A, CDN B), una red de contenido (Content), dos grandes ISP (ISP A, ISP B) y una carta raíz DNS. Cada tipo de red se diseña para diferentes propósitos y potencialmente presenta diferentes políticas de emparejamiento. Para cada red, agrupamos las actualizaciones en depósitos de 1 minuto y consideramos el número de mensajes en cada depósito durante una hora en enero de 2021.
La figura anterior muestra el tamaño de cada bandeja de actualización durante ese período. Aquí, vemos las CDN, que cuentan con implementaciones grandes y muchos pares y proveedores generan la mayor cantidad de actualizaciones durante casi todo el período, con la red de contenido relativamente cerca detrás. Los ISP y las letras raíz generan significativamente menos actualizaciones. Estas diferencias dramáticas de magnitud indican que la estructura, los pares y la arquitectura de una red probablemente tienen impactos significativos en los volúmenes de mensajes correspondientes. Por lo tanto, debemos asegurarnos de que nuestro sistema sea flexible a los parámetros cambiantes, como discutimos en la siguiente sección.
El sistema de alerta de sacudida
ShakeAlert escucha las transmisiones en vivo de 21 colectores de rutas que forman parte del proyecto2 del Sistema de Información de Enrutamiento (RIS) DE RIPE NCC. Los datos llegan de estos feeds y se agrupan en contenedores de tiempo de minutos de largo. Luego contamos el número de actualizaciones en cada bandeja y usamos un algoritmo de detección de valores atípicos para determinar si una bandeja tiene un número anormalmente grande de actualizaciones en comparación con otros minutos recientes. En el caso de que se observe tal contenedor, generamos un Shake.
Con este fin, ShakeAlert mantiene una ventana deslizante del recuento de actualizaciones vistas en los últimos w bins, lo que le permite evitar almacenar información sobre actualizaciones más que w bins antiguos. Una vez que ShakeAlert ha construido un historial de w bins, y el w+1o bin está completo, considera el recuento de este nuevo bin, bw+1, en relación con los de la ventana anterior. Si bien se podrían utilizar algunos mecanismos potenciales de detección de anomalías (por ejemplo, puntuación z modificada y estimaciones de la desviación estándar, umbrales estáticos y varias técnicas de detección de cambios), empleamos un mecanismo de detección basado en la densidad 34.
Para realizar la detección de anomalías basada en la densidad, consideramos un radio R y un recuento de vecinos k. Decimos que nuestro nuevo contenedor de tiempo bw+1 es un valor atípico si hay menos de k otros contenedores en los últimos w minutos con recuentos dentro del radio R centrados alrededor del conteo del nuevo contenedor. Formalmente, cualquier valor atípico tiene menos de k bins bi en los últimos w minutos, de modo que |bw+1| – |bi| <R. Nos referimos a cualquier valor atípico como alertas de sacudida o simplemente sacudidas y los recuentos de actualización de estos sacudidos como el tamaño.
El proceso general de detección de ShakeAlert
La base subyacente de nuestra hipótesis es que los cambios de enrutamiento de Internet grandes y disruptivos generan el mayor de estos eventos: Las rutas que transportan tráfico significativo probablemente sean escuchadas por muchas redes y colectores posteriores. Fundamentalmente, sin embargo, muchos cambios implican grandes recuentos de actualizaciones que no entran en esta categoría. Por ejemplo, el mantenimiento programado regularmente para el que retiramos los anuncios de Anycast.
El contenido de las actualizaciones en la bandeja se puede observar más a fondo para revelar detalles sobre la naturaleza del evento de la red. Los prefijos en las actualizaciones se pueden usar para determinar qué POPs y regiones Anycast se ven potencialmente afectados por los cambios de red correspondientes. Podemos examinar más a fondo los caminos observados a través de las actualizaciones y estimar las redes ascendentes con mayor probabilidad de verse afectadas. Finalmente, podemos determinar la importancia de las alertas en función de su importancia para el tráfico CDN entrante.
En nuestro despliegue de CDN, utilizamos una ventana w de 360 minutos y k de 5, lo que nos permite evitar alertar sobre comportamientos horarios comúnmente observados. También tomamos R como la distancia entre los percentiles 5 y 95 de tamaños de contenedores observados en la ventana. Para aumentar el contexto operativo, subdividimos aún más los contenedores en series temporales específicas de POP basadas en los prefijos y rutas observadas en las actualizaciones, alertando a cada uno individualmente. Finalmente, consideramos una serie de ajustes específicos, por ejemplo, establecer tamaños mínimos de alerta basados en nuestras observaciones de red.
ShakeAlert en Acción
A continuación, consideramos un ejemplo simple que demuestra cómo aparecen los batidos en la naturaleza. En el ejemplo anterior tomado de septiembre de 2022, nos centramos en un pop CDN específico, notando el recuento de actualizaciones mucho más pequeño a lo largo del eje y y la escala lineal que nuestra figura anterior. Durante este período de tiempo, los recuentos de actualizaciones son casi completamente 0 hasta que aumentan repentinamente, generando un recuento de actualizaciones mucho mayor a 12:14 y un segundo pico poco después a 12:20, ambos generaron sacudidas. Estas actualizaciones fueron causadas por una interrupción inesperada en la conectividad a un proveedor.
Evaluación
Para medir si las sacudidas representan o no eventos interesantes, consideramos el siguiente análisis. Para cada batido generado durante 30 días en el verano de 2022, examinamos nuestras métricas internas en el sitio correspondiente para determinar si observamos un comportamiento anómalo dentro de los 10 minutos posteriores al batido. Para nuestras anomalías, consideramos lo siguiente: Restablecimiento del router (por ejemplo, un router reiniciado o desconectado de otro modo), cambios de estado BGP en un enlace del proveedor (es decir, una sesión BGP del proveedor salió del estado ESTABLECIDO), cambios en los anuncios anunciados desde un sitio y pérdida de paquetes detectada entre el sitio correspondiente y al menos cinco sitios más.
El gráfico anterior muestra el desglose de estos acontecimientos durante 30 días. Aquí, vemos que todos los cubos tuvieron eventos correspondientes para al menos el 60% de los batidos, y en promedio, el 80% de los batidos tuvieron eventos coincidentes. Estos hallazgos confirman que las sacudidas más grandes corresponden a eventos importantes y a menudo impactantes en el tráfico. Sin embargo, enfatizan aún más la amplitud de los eventos, que van desde el mantenimiento rutinario hasta las fallas agudas, que pueden generar tales sacudidas.
Conclusión
ShakeAlert ofrece un nuevo ángulo de visibilidad para nuestro ya rico monitoreo CDN. Al extraer sus datos de una fuente externa, sabemos que ofrece información fundamentalmente diferente sobre el comportamiento de Internet. En nuestro trabajo en curso sobre el sistema, estamos explorando cómo los datos pueden combinarse aún más con el monitoreo interno para mejorar la precisión de las alertas y permitir acciones correctivas automatizadas.
Un agradecimiento especial al Equipo de Investigación, al Equipo de Ingeniería de Confiabilidad de Networking y a todos los equipos de ingeniería internos que hicieron posible este trabajo. Además, gracias a muchos expertos externos en datos de enrutamiento, incluidos Emile Aben, Stephen Strowes y Mingwei Zhang, que proporcionaron comentarios y discusiones útiles.
1 por ejemplo, Routeviews, Ris
2 El sistema puede utilizar fundamentalmente cualquier coleccionista. Aquí simplemente nos centramos en RIS debido a la flexibilidad de su interfaz WebSocket
3 M. Gupta, J. Gao, C. C. Aggarwal, y J. Han. Detección de valores atípicos para datos temporales: Una encuesta. IEEE Transacciones en Conocimiento e Ingeniería de Datos, 2014.
4 T. Kitabatake, R. Fontugne, y H. Esaki. BLT: Una herramienta de taxonomía y clasificación para minar mensajes de actualización de bgp. En Proc. De INFOCOM ’18, 2018.
