Home Articles techniques Le nouveau ShakeAlert d’Edgio offre une meilleure visibilité des événements réseau
Applications

Le nouveau ShakeAlert d’Edgio offre une meilleure visibilité des événements réseau

About The Author

Outline

Le nouveau ShakeAlert d’Edgio offre une plus grande visibilité sur les événements du réseau

Lors de l’exploitation de grands réseaux répartis dans le monde entier, les pannes matérielles, les pannes de fournisseur et autres changements de comportement sont des phénomènes réguliers. Par conséquent, les systèmes capables de déclencher des alarmes dès les premiers signes de problème peuvent alerter les opérateurs humains ou les systèmes automatisés et permettre une action corrective plus rapide. À cette fin, nous avons développé ShakeAlert, un système d’alerte basé sur des données externes accessibles au public pour alerter en cas de changements soudains sur Internet.

ShakeAlert surveille les flux de mises à jour BGP (Border Gateway Protocol) observées à partir de collecteurs publics pour les chemins provenant du CDN. Lorsque le volume de mises à jour augmente fortement, ShakeAlert déclenche une alarme, appelée Shake, signalant un changement possible dans le comportement de routage d’Internet, et en particulier, la façon dont les réseaux externes acheminent leur trafic vers le CDN. En utilisant le contenu de ces mises à jour, ShakeAlert fournit en outre une estimation des POP (points de présence), fournisseurs et préfixes susceptibles d’être impactés.

Le système est nommé d’après le système d’alerte précoce aux tremblements de terre du United States Geological Survey. Ce système fonctionne en détectant les ondes P en mouvement plus rapide, mais moins destructrices, et en alertant les résidents avant que les ondes S les plus destructrices n’arrivent. Ici, nous considérons les signaux du plan de commande de BGP comme le signal d’alerte précoce pour potentiellement concernant des changements dans le plan de données et le trafic d’utilisateur final.

Contexte

Afin de faciliter le routage entre les systèmes autonomes (ASE) sur Internet, les réseaux communiquent les préfixes vers lesquels ils ont des routes via BGP. Dans le cadre de cette communication, lorsque l’accessibilité d’un préfixe change, un réseau envoie une série d’annonces appelées annonces qui indiquent les préfixes affectés et le chemin que le réseau utiliserait pour les atteindre.

Dans le cadre du fonctionnement normal d’Internet, des milliers de ces messages sont échangés entre les réseaux lorsqu’ils mettent à jour leurs tables de routage. Chaque fois que ces routes changent, par exemple en raison de défaillances de réseau, d’une nouvelle connectivité entre les réseaux ou d’une maintenance planifiée, un nouvel ensemble de messages peut être échangé. Il peut s’agir de changements générés par le réseau d’origine (par exemple, annonçant un nouveau bloc IP) ou de changements qui se produisent en aval de l’origine (par exemple, la connectivité au niveau d’un fournisseur de transit change).

Ces messages offrent nécessairement un grand aperçu de l’état actuel d’Internet, révélant les gains et les pertes de connectivité entre les réseaux. Pour tirer parti de ces informations, de nombreuses organisations1 exécutent des services appelés collecteurs de routes, qui s’apparient avec de nombreux réseaux et rendent les messages de mise à jour collectés disponibles publiquement.

Lorsque la connectivité change, les réseaux en amont envoient des mises à jour BGP, qui finissent par se rendre aux collecteurs BGP.

Pour développer un sens de ces comportements, nous considérons quelques observations initiales. Nous considérons les flux de mise à jour résultants pour une poignée de réseaux différents. Nous considérons deux grands réseaux CDN (Cdn A, CDN B), un réseau de contenu (Content), deux grands FAI (FAI A, FAI B) et une lettre racine DNS. Chaque type de réseau est conçu à des fins différentes et peut présenter des politiques d’appairage différentes. Pour chaque réseau, nous regroupons les mises à jour en compartiments de 1 minutes et prenons en compte le nombre de messages dans chaque compartiment sur une heure en janvier 2021.

La figure ci-dessus trace la taille de chaque corbeille de mise à jour pendant cette période. Ici, nous voyons les CDN, qui comportent tous deux des déploiements importants et de nombreux pairs et fournisseurs génèrent le plus de mises à jour pour presque toute la portée, avec le réseau de contenu relativement proche derrière. Les ISP et les lettres racines génèrent beaucoup moins de mises à jour. Ces différences de magnitude considérables indiquent que la structure, les pairs et l’architecture d’un réseau ont probablement des répercussions importantes sur les volumes de messages correspondants. Nous devons donc veiller à ce que notre système soit souple face aux changements de paramètres, comme nous le verrons dans la section suivante.

Le système d’alerte Shake Alert

ShakeAlert écoute les flux en direct de 21 collecteurs d’itinéraires qui font partie du projet de système d’information sur les itinéraires (RIS) de RIPE NCC 2. Les données arrivent de ces flux et sont regroupées dans des bacs de minutes. Nous comptons ensuite le nombre de mises à jour dans chaque bin et utilisons un algorithme de détection des valeurs aberrantes pour déterminer si un bin a un nombre anormalement élevé de mises à jour par rapport aux autres minutes récentes. Dans le cas où un tel bin est observé, nous générons un Shake.

À cette fin, ShakeAlert maintient une fenêtre glissante du nombre de mises à jour vues dans les W derniers bacs, ce qui lui permet d’éviter de stocker des informations sur les mises à jour plus de W bacs anciens. Une fois que ShakeAlert a construit un historique de W bins, et que le W+1th bin est complet, il considère le nombre de ce nouveau bin, bW+1, par rapport à ceux de la fenêtre précédente. Bien que certains mécanismes de détection d’anomalies potentielles puissent être utilisés (p. ex., z -score modifié et estimations de l’écart-type, seuils statiques et diverses techniques de détection de changement), nous utilisons un mécanisme de détection basé sur la densité34.

Pour effectuer une détection d’anomalie basée sur la densité, on considère un rayon R et un nombre de voisins k. Nous disons que notre nouveau bin de temps bW+1 est une valeur aberrante s’il y a moins de k autres bin dans les W dernières minutes avec des comptages dans le rayon R centré autour du comptage du nouveau bin. Formellement, toute valeur aberrante a moins de k bins bi dans les W dernières minutes de sorte que |bW+1| – |bi| <R. Nous nous référons à des valeurs aberrantes telles que des alertes de secousse ou simplement des secousses et la mise à jour compte de ces secousses comme la taille.

Le processus global de détection de ShakeAlert

La base sous-jacente de notre hypothèse est que les changements de routage Internet importants et perturbateurs génèrent le plus grand de ces événements : les routes qui transportent un trafic important sont susceptibles d’être entendues par de nombreux réseaux et collecteurs en aval. Fondamentalement, cependant, de nombreux changements impliquent un grand nombre de mises à jour qui n’entrent pas dans cette catégorie. Par exemple, la maintenance programmée régulièrement pour laquelle nous retirons les annonces Anycast.

Le contenu des mises à jour dans le bin peut être observé pour révéler des détails sur la nature de l’événement réseau. Les préfixes dans les mises à jour peuvent être utilisés pour déterminer quelles régions POPS et Anycast sont potentiellement affectées par les modifications réseau correspondantes. Nous pouvons examiner plus en détail les chemins observés à travers les mises à jour et estimer les réseaux en amont les plus susceptibles d’être impactés. Enfin, nous pouvons déterminer l’importance des alertes en fonction de leur importance pour le trafic CDN entrant.

Dans notre déploiement CDN, nous utilisons une fenêtre W de 360 minutes et k de 5, ce qui nous permet d’éviter d’alerter sur les comportements horaires couramment observés. Nous prenons également R pour la distance entre le 5e et le 95e percentiles des tailles de bac observées dans la fenêtre. Pour augmenter le contexte opérationnel, nous subdivisons davantage les bins en séries chronologiques spécifiques aux POP basées sur les préfixes et les chemins observés dans les mises à jour, alertant chacun individuellement. Enfin, nous considérons un certain nombre de réglages spécifiques, par exemple, la définition de tailles d’alerte minimales basées sur nos observations de réseau.

ShakeAlert en action

Ensuite, nous considérons un exemple simple démontrant comment les milkshakes apparaissent dans la nature. Dans l’exemple ci-dessus pris en septembre 2022, nous nous concentrons sur un pop CDN spécifique, notant le nombre de mises à jour beaucoup plus petit le long de l’axe y et de l’échelle linéaire que notre chiffre précédent. Pendant cette période, le nombre de mises à jour est presque entièrement de 0 jusqu’à ce qu’ils augmentent soudainement, générant un nombre de mises à jour beaucoup plus important à 12:14 et un deuxième pic peu de temps après à 12:20, qui ont tous deux généré des secousses. Ces mises à jour ont été causées par une interruption inattendue de la connectivité avec un fournisseur.

Évaluation

Afin de mesurer si les shakes représentent ou non des événements intéressants, nous considérons l’analyse suivante. Pour chaque secousse générée sur 30 jours au cours de l’été 2022, nous examinons nos métriques internes sur le site correspondant afin de déterminer si nous avons observé un comportement anormal dans les 10 minutes suivant la secousse. Pour nos anomalies, nous considérons ce qui suit: les réinitialisations de routeur (par exemple, un routeur redémarré ou autrement mis hors ligne), les changements d’état BGP sur une liaison de fournisseur (c’est-à-dire, une session BGP de fournisseur a quitté l’état ÉTABLI), les changements dans les annonces annoncées à partir d’un site, et la perte de paquets détectée entre le site correspondant et au moins cinq autres sites.

La figure ci-dessus montre la répartition de ces événements sur 30 jours. Ici, nous voyons que tous les seaux avaient des événements correspondants pour au moins 60% des shakes, et en moyenne, 80% des shakes avaient des événements correspondants. Ces résultats confirment que les secousses les plus importantes correspondent à des événements importants et souvent ayant un impact sur la circulation. Cependant, ils soulignent davantage l’ampleur des événements, allant de l’entretien de routine aux défaillances aiguës, qui peuvent générer de tels secousses.

Conclusion

ShakeAlert offre un nouvel angle de visibilité à notre monitoring CDN déjà riche. En tirant ses données d’une source externe, nous savons qu’il offre des perspectives fondamentalement différentes sur le comportement d’Internet. Dans le cadre de nos travaux en cours sur le système, nous explorons comment combiner davantage les données avec la surveillance interne pour améliorer la précision des alertes et permettre des actions correctives automatisées.

Nous remercions tout particulièrement l’équipe de recherche, l’équipe d’ingénierie de fiabilité des réseaux et toutes les équipes d’ingénierie internes qui ont rendu ce travail possible. Merci également à de nombreux experts externes sur les données de routage, dont Emile Aben, Stephen Strowes et Mingwei Zhang, qui ont fourni des commentaires et des discussions utiles.

1 par exemple Routeviews, RIS

2 le système peut fondamentalement utiliser n’importe quel collecteur. Ici, nous nous concentrons simplement sur RIS en raison de la flexibilité de son interface WebSocket

3 M. Gupta, J. Gao, C. C. Aggarwal et J. Han. Détection des aberrations pour les données temporelles : une enquête. IEEE transactions sur l’ingénierie des connaissances et des données, 2014.

4 T. Kitabatake, R. Fontugne et H. Esaki. BLT : un outil de taxonomie et de classification pour l’exploration des messages de mise à jour bgp. Dans Proc. De INFOCOM ’18, 2018.