Home Artículos técnicos El nuevo ShakeAlert de Edgio proporciona una mayor visibilidad de los eventos de la red
Applications

El nuevo ShakeAlert de Edgio proporciona una mayor visibilidad de los eventos de la red

About The Author

Outline

El nuevo ShakeAlert de Edgio proporciona una mayor visibilidad de los eventos de la red

Cuando se operan redes grandes y distribuidas globalmente, los fallos de hardware, las interrupciones del proveedor y otros cambios en el comportamiento son frecuentes. Por lo tanto, los sistemas que pueden elevar las alarmas ante 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 basado en datos externos disponibles públicamente para alertar sobre cambios repentinos de Internet.

ShakeAlert monitorea los flujos de actualizaciones de BGP (Border Gateway Protocol) observadas desde los colectores públicos para rutas que se originan en la CDN. Cuando el volumen de actualizaciones aumenta bruscamente, ShakeAlert genera una alarma, llamada Shake, que indica un posible cambio en el comportamiento de enrutamiento de Internet, y en particular, cómo las redes externas dirigen su tráfico a la CDN. Utilizando el contenido de estas actualizaciones, ShakeAlert proporciona además una estimación de los posibles Puntos de Presencia (Puntos de Presencia), proveedores y prefijos 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 que se mueven 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 a través de 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 fallas de red, nueva conectividad entre redes o mantenimiento planificado, se puede intercambiar un nuevo conjunto de mensajes. Estos pueden incluir cambios generados por la red de origen (por ejemplo, anunciando un nuevo bloque IP) o cambios que ocurren aguas abajo del origen (por ejemplo, cambios en la conectividad de 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 redes. Para aprovechar esta información, muchas organizaciones ejecutan servicios llamados recolectores 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 de BGP, que eventualmente se dirigen a los coleccionistas de 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 está diseñada para diferentes propósitos y potencialmente presenta diferentes políticas de peering. 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 bin 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 para casi todo el intervalo, con la red de contenido relativamente cerca detrás. Los ISP y Root Letters generan significativamente menos actualizaciones. Estas diferencias dramáticas en 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 para cambiar los parámetros, como discutimos en la siguiente sección.

El Sistema de Alerta de Shake

ShakeAlert escucha feeds en vivo de 21 recolectores de rutas que son parte del proyecto 2 del Sistema de Información de Ruteo (RIS) de RIPE NCC . Los datos llegan de estos feeds y se agrupan en contenedores de tiempo de un minuto de duración. Luego contamos el número de actualizaciones en cada bin y usamos un algoritmo de detección atípico para determinar si un bin tiene un número anormalmente grande de actualizaciones en comparación con otros minutos recientes. En el caso de que se observe tal bin, generamos un Shake.

Con este fin, ShakeAlert mantiene una ventana deslizante de la cuenta de actualizaciones vistas en los últimos contenedores w , lo que le permite evitar almacenar información sobre actualizaciones más que los contenedores w antiguos. Una vez que ShakeAlert ha construido un historial de contenedores w , y el contenedor w+ 1 está completo, considera el recuento de este nuevo contenedor, bw + 1, en relación con los de la ventana anterior. Si bien se podrían utilizar algunos mecanismos de detección de anomalías potenciales (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 densidad34.

Para realizar la detección de anomalías basadas en la densidad, consideramos un radio R y un conteo de vecinos k. Decimos que nuestro nuevo cubo de tiempo bw+1 es un valor atípico si hay menos que k otros contenedores en los últimos w minutos con recuentos dentro del radio R centrados alrededor del recuento del nuevo contenedor. Formalmente, cualquier valor atípico tiene menos de k bins bi en los últimos w minutos de tal manera que |bw+1| – |bi| <R. Nos referimos a cualquiera de estos valores atípicos como alertas de sacudidas o simplemente sacudidas y la actualización cuenta 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 grandes y disruptivos cambios en el enrutamiento de Internet generan el mayor de estos eventos: Las rutas que transportan tráfico significativo probablemente sean escuchadas por muchas redes y coleccionistas posteriores. Fundamentalmente, sin embargo, muchos cambios implican grandes recuentos de actualizaciones que no entran en esta categoría. Por ejemplo, mantenimiento regularmente programado para el cual retiramos anuncios de Anycast.

El contenido de las actualizaciones en el BIN se puede observar más a fondo para revelar detalles sobre la naturaleza del evento de red. Los prefijos en las actualizaciones se pueden utilizar para determinar qué regiones POPS y Anycast se ven potencialmente afectadas por los cambios de red correspondientes. Podemos examinar más a fondo las rutas observadas a través de las actualizaciones y estimar las redes ascendentes con mayor probabilidad de verse afectadas. Por último, 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 alertas sobre comportamientos horarios comúnmente observados. También tomamos R como la distancia entre los percentiles 5 y 95 de los 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 observados en las actualizaciones, alertando a cada uno individualmente. Por último, consideramos una serie de afinaciones específicas, 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 totalmente 0 hasta que aumentan repentinamente, generando un recuento de actualizaciones mucho más grande a las 12:14 y un segundo aumento poco después a las 12:20, los cuales generaron sacudidas. Estas actualizaciones fueron causadas por una interrupción inesperada en la conectividad a un proveedor.

Evaluación

Con el fin de medir si los batidos representan o no eventos interesantes, consideramos el siguiente análisis. Por 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: se restablece el router (por ejemplo, un router reiniciado o se desconectó), cambios de estado BGP en un enlace de proveedor (por ejemplo, una sesión de proveedor BGP 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 otros cinco sitios.

La cifra 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 se corresponden con eventos importantes y a menudo que impactan el tráfico. Sin embargo, enfatizan aún más la amplitud de eventos, que van desde el mantenimiento de rutina hasta fallas agudas, que pueden generar tales sacudidas.

Conclusión

ShakeAlert ofrece un nuevo ángulo de visibilidad a nuestra ya rica monitorización CDN. Al extraer sus datos de una fuente externa, sabemos que ofrece información fundamentalmente diferente sobre el comportamiento de Internet. En nuestro trabajo continuo en 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 redes 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, vistas de rutas, 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 atípica de datos temporales: Una encuesta. IEEE Transacciones sobre Ingeniería del Conocimiento y 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.