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 distribués à l’échelle mondiale, des pannes matérielles, des pannes de fournisseurs et d’autres changements de comportement se produisent régulièrement. Par conséquent, les systèmes qui peuvent déclencher des alarmes dès les premiers signes de défaillance 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 par les collecteurs publics pour les chemins provenant du CDN. Lorsque le volume des 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 porte le nom du 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 plus rapides, mais moins destructrices, et en alertant les résidents avant l’arrivée des ondes S plus destructrices. Ici, nous considérons les signaux du plan de contrôle de BGP comme le signal d’alerte précoce pour potentiellement concerner des changements dans le plan de données et le trafic de l’utilisateur final.
Arrière-plan
Afin de faciliter le routage entre les systèmes autonomes (AS) sur Internet, les réseaux communiquent avec quels préfixes 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 fonctionnement régulier 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 à la suite de pannes de réseau, d’une nouvelle connectivité entre 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 une grande visibilité sur 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 route, qui sont associés à de nombreux réseaux et rendent les messages de mise à jour collectés accessibles au public.
Lorsque la connectivité change, les réseaux en amont envoient des mises à jour BGP, qui finissent par se diriger vers les 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 comporte potentiellement différentes politiques de peering. Pour chaque réseau, nous regroupons les mises à jour en compartiments d’une minute et considérons le nombre de messages dans chaque compartiment sur une heure en janvier 2021.
La figure ci-dessus représente la taille de chaque bac 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 FAI et les lettres racines génèrent beaucoup moins de mises à jour. Ces différences spectaculaires de magnitude indiquent que la structure, les pairs et l’architecture d’un réseau ont probablement des impacts significatifs sur les volumes de messages correspondants. Nous devons donc nous assurer que notre système est flexible pour changer les paramètres, comme nous le verrons dans la section suivante.
Le système d’alerte de secousses
ShakeAlert écoute les flux en direct de 21 collecteurs d’itinéraires qui font partie du projet de système d’information de routage (RIS) 2 de RIPE NCC. Les données arrivent de ces flux et sont regroupées dans des bacs de temps d’une minute. 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 derniers w bins, ce qui lui permet d’éviter de stocker des informations sur les mises à jour de plus de w bins anciens. Une fois que ShakeAlert a construit un historique de w bins, et que le w+1ème 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 (par exemple, score z 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 bac de temps bw+1 est une valeur aberrante s’il y a moins de k autres bacs dans les dernières w minutes avec des comptes dans le rayon R centrés autour du compte du nouveau bac. Formellement, toute valeur aberrante a moins de k cases bi au cours des dernières w minutes, de sorte que |bw+1| – |bi| <R. Nous nous référons à ces valeurs aberrantes comme alertes de secousses ou simplement secousses et les comptes de mise à jour de ces secousses comme la taille.
Le processus de détection global 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 en aval et collecteurs. 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 la corbeille peut encore être observé pour révéler des détails sur la nature de l’événement réseau. Les préfixes des mises à jour peuvent être utilisés pour déterminer les POP et les régions Anycast 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 être la distance entre les 5e et 95e percentiles des tailles de bacs observées dans la fenêtre. Pour augmenter le contexte opérationnel, nous subdivisons davantage les bacs en séries chronologiques spécifiques aux pop en fonction des préfixes et des chemins observés dans les mises à jour, en 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 en fonction de nos observations réseau.
ShakeAlert en action
Ensuite, nous considérons un exemple simple démontrant comment les shakes apparaissent dans la nature. Dans l’exemple ci-dessus, pris à partir de septembre 2022, nous nous concentrons sur un pop CDN spécifique, en 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 égal à 0 jusqu’à ce qu’il augmente soudainement, générant un nombre de mises à jour beaucoup plus important à 12:14 et un second pic peu 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é à un fournisseur.
Évaluation
Afin de mesurer si les secousses représentent ou non des événements intéressants, nous considérons l’analyse suivante. Pour chaque secousse générée pendant 30 jours au cours de l’été 2022, nous examinons nos mesures internes au 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 les éléments suivants : réinitialisations de routeur (par exemple, un routeur redémarré ou mis hors ligne), changements d’état BGP sur une liaison de fournisseur (par exemple, une session BGP de fournisseur a quitté l’état ÉTABLI), changements dans les annonces annoncées à partir d’un site, et 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 compartiments 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 impactant le trafic. Cependant, ils soulignent davantage l’ampleur des événements, allant de la maintenance de routine aux défaillances graves, qui peuvent générer de telles secousses.
Conclusion
ShakeAlert offre un nouvel angle de visibilité à notre monitoring CDN déjà riche. En extrayant 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 continus sur le système, nous étudions comment combiner davantage les données avec la surveillance interne afin d’améliorer la précision des alertes et de 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 tous les collecteurs. 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 temporelles : une enquête. IEEE transactions on Knowledge and Data Engineering, 2014.
4 T. Kitabatake, R. Fontugne et H. Esaki. BLT : outil de taxonomie et de classification pour l’exploration des messages de mise à jour bgp. Dans Proc. De INFOCOM ’18, 2018.
