Une journée ordinaire : la table BGP mondiale

 (articles.foletta.org)
2 points par GN⁺ 2024-11-27 | 1 commentaires | Partager sur WhatsApp
  • À partir de 464 673 mises à jour BGP UPDATE reçues en une journée depuis un pair disposant de la table BGP complète, l’analyse observe les variations à court terme de la table de routage mondiale plutôt que sa tendance de croissance sur le long terme
  • Juste après l’établissement du peering, l’ensemble des routes et des NLRI est arrivé d’un seul coup en environ 5 secondes, avec 949 483 routes rattachées aux chemins initiaux
  • Ensuite, les UPDATE sont arrivées par lots selon un Route Advertisement Interval de 30 secondes ; environ 50 mises à jour de chemins IPv4 et 47 mises à jour de chemins IPv6 ont été observées toutes les 30 secondes
  • En IPv4, une corrélation d’environ 40 minutes apparaît à la fois dans l’évolution du nombre de chemins et dans celle de l’espace d’adressage, mais sa cause reste inexpliquée
  • L’excès d’AS path prepending, l’attribut de chemin 255 réservé, et le fort flapping de certains NLRI montrent à la fois la complexité et la résilience de l’exploitation du BGP mondial

Observer la table BGP à l’échelle d’une journée

  • L’analyse de la table BGP mondiale se concentre habituellement sur des tendances sur plusieurs mois ou années, comme la croissance de la table de routage ou l’adoption d’IPv6
  • Cette analyse s’intéresse aux variations de court terme visibles sur une journée lorsqu’un routeur reçoit directement les mises à jour BGP de l’Internet en évolution permanente
  • L’observation se divise en trois volets
    • le flux habituel d’UPDATE au cours d’une journée
    • les path attribute inhabituels
    • les flappy path qui changent fréquemment

Collecte des données et bgpsee

  • Au lieu de parser directement la sortie de debug du routeur, l’auteur a remis en état un démon BGP laissé inachevé par le passé pour utiliser bgpsee
  • bgpsee est un outil CLI multithread de peering BGP qui établit un peering avec d’autres routeurs, parse les messages BGP et les produit en JSON
    • Il traite les messages OPEN, KEEPALIVE et UPDATE
    • Les UPDATE peuvent inclure des NLRI, des withdrawn routes, et des path attribute comme ORIGIN, AS_PATH, NEXT_HOP ou AS4_PATH
  • Le jeu de données a été collecté du 6 janvier 2024 au 7 janvier 2024 et se compose de 464 673 BGP UPDATE reçues d’un pair disposant de la table BGP complète

Transmission initiale complète et nombre de routes

  • Lorsqu’un peering BGP est établi pour la première fois, toutes les routes présentes dans la table BGP du routeur et les NLRI associées sont envoyées dans un gros lot d’UPDATE
  • Ce lot initial a été reçu en environ 5 secondes après le début du peering
  • Ensuite, seules arrivent des UPDATE concernant des chemins modifiés ou des withdrawn routes qui n’ont plus de chemin
  • Le lot initial et les UPDATE suivantes ont la même structure ; la différence tient au moment de réception et à l’étendue des informations
  • La distinction importante ici est celle entre path et route
    • Un path est une unité de BGP UPDATE composée d’une combinaison de path attribute et des NLRI qui y sont rattachés
    • Un path peut être associé à une seule route ou à mille routes
    • Le nombre de routes rattachées à l’ensemble des chemins du lot initial était de 949 483

Flux d’UPDATE par tranches de 30 secondes

  • Après la transmission initiale complète, les UPDATE n’arrivent pas comme un flux temps réel continu, mais sont envoyées par lots selon le timer du Route Advertisement Interval
  • Sur ce peering, le Route Advertisement Interval était de 30 secondes
  • Le nombre moyen d’UPDATE observé était le suivant
    • IPv4 : environ 50 mises à jour de chemins toutes les 30 secondes
    • IPv6 : environ 47 mises à jour de chemins toutes les 30 secondes
  • Les moyennes étaient proches, mais l’amplitude des variations était plus forte en IPv4
    • écart-type IPv4 : 64,3
    • écart-type IPv6 : 43
  • Au lieu de compter seulement les UPDATE, l’analyse calcule aussi le volume total d’espace d’adressage IP modifié toutes les 30 secondes
    • Elle additionne le nombre d’adresses IP incluses dans chaque UPDATE, puis applique log2()
    • L’exemple consiste à convertir /22, /23 et /24 en nombre d’adresses, à les additionner, puis à prendre le logarithme
  • En se basant sur l’espace d’adressage IPv4, environ 2^16 adresses, soit l’équivalent d’un /16, changent de chemin dans la table de routage mondiale toutes les 30 secondes en moyenne
  • Dans l’intervalle à 95 %, l’espace d’adressage IPv4 modifié se situait entre environ 2^20.75 et 2^13.85
    • soit approximativement entre /11 et /18

Périodicité de 40 minutes dans les mises à jour IPv4

  • À la fois dans l’évolution du nombre de chemins et dans celle de l’espace d’adressage IP, les UPDATE IPv4 montrent un comportement cyclique
  • Pour vérifier cette périodicité, l’analyse utilise la fonction d’autocorrélation (ACF)
    • Les UPDATE ont été regroupées par intervalles d’une minute, et 1 lag correspond à 1 minute
    • La corrélation est calculée entre le nombre de chemins au moment présent et celui observé dans le passé pour chaque lag
  • Une forte corrélation apparaît sur les 7 premiers lags environ
    • Cela concorde avec l’idée que des changements de chemins peuvent se propager à l’échelle mondiale et provoquer d’autres changements de chemins
  • Une forte corrélation apparaît aussi aux lags 40 et 41, confirmant un comportement d’environ 40 minutes
  • La cause de cette périodicité de 40 minutes reste une question sans réponse

Cas d’AS path prepending excessif

  • Les administrateurs réseau peuvent utiliser plusieurs méthodes pour ajuster la façon dont le trafic entre vers leur ASN
    • Utiliser des préfixes réseau plus longs ne passe pas bien à l’échelle et n’est pas souhaitable du point de vue BGP
    • L’attribut MED est non-transitive, ce qui limite son usage lorsqu’on peer avec plusieurs AS
    • En pratique, on réduit généralement la préférence d’un chemin vis-à-vis d’un pair donné en répétant plusieurs fois son propre AS au début du chemin, une pratique appelée AS path prepending
  • Dans le jeu de données, la longueur maximale d’un AS path en IPv4 était de 105
    • C’est une valeur élevée si l’on considère que le plus long chemin sans prepending avait une longueur de 14
    • Ce chemin IPv4 provenait de l’AS149381 indonésien, « Dinas Komunikasi dan Informatika Kabupaten Tulungagung »
    • Le NLRI 103.179.250.0/24 a été vu avec une longueur d’AS path de 105 le 6 janvier 2024 à 06:31:18, puis mis à jour à une longueur de 4 environ 6,84 heures plus tard, à 13:21:35
  • En IPv6, la longueur maximale d’AS path atteignait 599
    • Un AS path se compose d’un ou plusieurs AS set ou AS sequence
    • La longueur maximale de chaque AS sequence étant de 255, ce chemin nécessitait trois AS sequence
  • Sur le plus long chemin IPv6, le prepending n’était pas effectué par l’originator mais par l’ISP ukrainien AS8772 NetAssist LLC
    • La destination était un chemin vers l’AS203868 d’Indonésie, Rifqi Arief Pamungkas
    • AS8772 avait prepended ce chemin pour le rendre moins préférable
  • Si l’on observe les ASN présents à toutes les positions dans les 50 plus longs chemins, la grande différence entre IPv4 et IPv6 est liée à la répétition de certains ASN

La valeur réservée 255 observée dans les path attribute

  • Chaque BGP UPDATE se compose d’informations de reachability de couche réseau et de path attribute
    • Des exemples sont AS_PATH, NEXT_HOP, etc.
  • La section 5 de la RFC4271 répartit les attributs BGP comme suit
    • well-known mandatory
    • well-known discretionary
    • optional transitive
    • optional non-transitive
  • Si l’on regarde le nombre d’attributs sur l’ensemble des chemins IPv4, les attributs well-known mandatory ORIGIN, NEXT_HOP et AS_PATH sont présents dans toutes les UPDATE et apparaissent en nombre identique
  • Des attributs courants comme AGGREGATOR et d’autres plus rares comme AS_PATHLIMIT ou ATTR_SET ont aussi été observés
  • Certains AS ajoutent l’attribute 255 à leurs UPDATE
    • Cette valeur est reserved for development
    • À ce moment-là, bgpsee n’enregistrait pas la valeur de ces path attribute rares
  • Via routeviews.org, il a été possible de confirmer que certains AS annoncent encore des routes avec cet attribut et d’observer aussi les valeurs brutes en octets
    • L’attribute 255 apparaît chez AS265999, AS10429 et AS52564
    • Les valeurs brutes des trois ISP présentent une structure similaire
  • Il n’a pas été possible de déterminer quel vendor utilise cet attribut réservé au développement, ni dans quel but

Les NLRI ayant le plus flappé

  • L’analyse recense les NLRI les plus souvent incluses dans les UPDATE parmi les routes dont le chemin a changé ou qui ont été entièrement withdraw
  • Les 10 NLRI actives en tête et leur nombre d’apparitions dans les UPDATE sont les suivantes
    • 140.99.244.0/23 : 2 596
    • 107.154.97.0/24 : 2 583
    • 45.172.92.0/22 : 2 494
    • 151.236.111.0/24 : 2 312
    • 205.164.85.0/24 : 2 189
    • 41.209.0.0/18 : 2 069
    • 143.255.204.0/22 : 2 048
    • 176.124.58.0/24 : 1 584
    • 187.1.11.0/24 : 1 582
    • 187.1.13.0/24 : 1 580
  • 140.99.244.0/23 est le cas le plus instable de la journée, et cet espace d’adressage appartient à EpicUp
  • Il y avait 2 879 blocs de 30 secondes au total, et cette route est apparue dans 2 637 blocs, soit sous la forme d’un autre chemin, soit comme withdrawn route
    • taux d’apparition : {p:93}
    • le taux réel était de 92,8 %

La diversité du peering révélée par les chemins qui flap

  • Pour visualiser la façon dont 140.99.244.0/23 flappait, l’analyse utilise un graphe où tous les ASN des chemins vers ce réseau sont des nœuds, et les paires d’AS sont des arêtes
  • Le chemin principal semble être un chemin central passant par NTT AS2914 et Lumen/Level3 AS3356
  • Les chemins basculent entre ces ISP de niveau 1 et d’autres ISP
    • Parmi les exemples figurent Arelion AS1299 et PCCW AS3419
  • Avec ces seules données, il est presque impossible d’identifier la cause exacte du flapping
    • Parmi les causes possibles figurent une mauvaise liaison, une panne électrique ou un crash de routeur
  • En même temps, ce cas montre la diversité du peering des réseaux mondiaux modernes et la résilience d’un protocole de routage vieux de 33 ans

Un jeu de données qui laisse encore beaucoup de questions

  • Ce jeu de données contient bien trop de sujets à explorer, et l’analyse se concentre donc sur quelques cas seulement
  • Les UPDATE de la table BGP mondiale peuvent refléter des événements du monde réel, comme une instabilité politique, des phénomènes naturels tels que des séismes ou des incendies, ou encore des erreurs d’administrateurs réseau
  • L’économie de l’Internet peering et la dimension humaine d’opérateurs aux compétences variées se retrouvent elles aussi dans de petites BGP UPDATE
  • Le BGP mondial fonctionne la plupart du temps et transmet jusqu’à un ordinateur portable, sous forme d’un petit flux d’updates, de nombreux changements du monde réel

À lire aussi

1 commentaires

 
GN⁺ 2024-11-27
Commentaires sur Hacker News

  • Il y a 25 ans, je travaillais chez un petit FAI et, au début, comme nous n’avions qu’un seul FAI amont, on m’a confié la mise en place d’une configuration multihomée
    J’ai appris en suivant un tutoriel écrit par Avi Freedman, ce qui nous a permis d’obtenir un /20 auprès de l’ARIN et d’annoncer des routes à deux pairs
    C’était vraiment passionnant d’en comprendre le fonctionnement, et plus j’en apprenais, plus j’étais étonné par le fait que l’Internet fonctionne, d’une manière ou d’une autre
    (1) http://avi.freedman.net/
    Avi

    • Merci ! Comme pour le corps humain, plus on étudie l’Internet, plus on s’étonne non pas qu’il tombe parfois en panne, mais qu’il fonctionne tout court
      C’est particulièrement vrai pour la vidéo et la téléphonie, et je suis content que le contenu ait été utile
      J’ai regroupé sur avi.net quelques liens vers les tutoriels de l’époque et d’anciens articles de Boardwatch
      Ma motivation venait uniquement de la frustration face aux ressources disponibles à l’époque, mais j’ai vite compris qu’aider les gens avec de bons articles pouvait aussi rapporter des choses comme « est-ce qu’on peut acheter un T1 ? » ou « est-ce que vous pourriez exploiter notre grand réseau mondial ? »
      C’est pourquoi je continue à encourager les gens à écrire sur les sujets qui les embrouillent et les frustrent
    • J’ai travaillé avec Avi chez Kentik ; c’était quelqu’un de brillant et de bien, et il gardait un bon souvenir du fait d’avoir écrit ces textes pour aider les autres
    • Petite digression, mais il m’arrive de voir sur HN des commentaires qui se terminent comme ça, avec un seul mot sur une nouvelle ligne
      Je me demande si le commentaire a été coupé, ou si c’est une erreur de copier-coller
      Je me demande aussi si d’autres l’ont déjà remarqué, et si cela pourrait être la trace de commentaires générés ou de l’usage d’un outil particulier
      Je l’ai surtout vu sur HN, et peut-être une fois sur Reddit ; en tout cas, cela arrive plus souvent que ce qu’on attribuerait à un simple hasard ou à une erreur

  • Bon article, mais le préfixe 140.99.244.0/23 d’EpicUp qui flapait aurait dû être soumis au route dampening
    En général, les FAI appliquent des limites de débit par pair ou par préfixe sur tous leurs pairs, afin d’éviter qu’un seul préfixe ne représente une part importante des changements BGP mondiaux
    La corrélation que l’auteur voit entre les mises à jour comme effet en cascade n’est pas très convaincante
    Modifier ses propres annonces en fonction des routes vers le préfixe d’un autre système autonome, surtout instables, est une conception assez grossière
    Je ne crois pas non plus à une périodicité de 40 minutes. Du moins, il n’y avait rien de tel quand je travaillais en profondeur sur BGP il y a 8 ans ; j’ai plutôt l’impression que le jeu de données donnait cette impression par hasard, ou que cela venait des caractéristiques du réseau depuis lequel l’auteur recevait le flux BGP
    Quand on regarde, dans les données réelles, quels AS et quels préfixes changent, c’est dispersé un peu partout et il y a très peu de grands motifs
    N’importe quel jour, il y a quelques FAI bruyants à cause de problèmes de circuits ou d’erreurs de configuration, des préfixes qui apparaissent et disparaissent lors du lancement initial de nouveaux services, et des routes qui changent lors de maintenances de drainage classiques
    Qu’une pelleteuse qui coupe une fibre chez un petit FAI du Kansas soit visible sur un routeur à Perth est à la fois fascinant et un peu effrayant, et, en même temps, grâce à de très nombreuses politiques configurées à la main, la fréquence mondiale des mises à jour reste inférieure à 10 Hz

    • Sur les réseaux actuels, le route dampening est largement passé de mode
      Beaucoup de configurations étaient très mal réglées, et la plupart des routeurs ne sont plus aussi dramatiquement limités en CPU qu’autrefois
      Bien sûr, cela n’a pas totalement disparu : quand j’ai fait BGP Battleships (https://blog.benjojo.co.uk/post/bgp-battleships), 3356 pratiquait alors le route dampening, et j’ai dû interrompre le jeu un moment

  • Si vous voulez apprendre BGP, surtout comprendre l’exploitation quotidienne dans des situations de peering, la série de vidéos du Network Startup Resource Center de l’Université de l’Oregon est très bien
    https://learn.nsrc.org/bgp

  • D’après une recherche rapide, l’attribut BGP réservé 0xff est très probablement un comportement spécifique à Huawei
    La plupart des 0xff visibles sur bgp.tools suivent le même format que celui mentionné dans l’article, et certains de ces réseaux semblent utiliser du matériel Huawei

  • J’ai appris pas mal de choses sur BGP que j’ignorais grâce à cet article, et ce qui m’a le plus intéressé, c’est surtout à quel point tout cela tourne de façon chaotique
    J’aimerais bien lire un article de suivi qui creuse davantage

  • J’ai autrefois conçu et configuré un réseau hybride satellite-micro-ondes pour un grand client américain qui avait des bureaux de terrain dans la région de Bornéo
    Je n’oublierai pas le travail de remise de circuit loué à Jakarta
    Comme je n’avais aucune expérience de ce type, j’ai cherché et découvert qu’on utilisait BGP pour connecter notre réseau OSPF/UBNT au WAN d’entreprise IGRP/Cisco du client
    Quand nous avons demandé aux gens de Tata de configurer BGP sur le routeur, ils ont réagi du genre : « vous vous prenez pour AT&T ? »
    Jusqu’à ce que la plupart de nos AirFiber tombent pendant une saison d’orages, nous avions un peu cette impression aussi

  • J’ai écrit un script Python qui extrait les données d’un fichier MRT contenant les routes BGP de [1], puis les importe dans Neo4j pour les explorer
    Ce fichier contenait environ 56 millions de routes avec énormément de doublons, et Neo4j est bien adapté pour gérer ce genre de données en les « fusionnant »
    [1] https://data.ris.ripe.net/rrc00/

  • Quel est le moyen le plus simple pour une personne ordinaire d’accéder directement à des données BGP ? Je ne connais personne chez un FAI, mais j’aimerais faire une analyse similaire

  • Si, avec le temps, on observe un comportement cyclique dans les mises à jour IPv4, à la fois dans les routes et dans l’évolution de l’espace IP, est-ce que cela signifie qu’il existe quelque chose comme des marées sur Internet ?

  • J’aimerais que l’initiative Memory Safety, qui traite la sécurité et la sûreté de l’infrastructure Internet critique en la réimplémentant en Rust, s’occupe aussi d’une implémentation de serveur BGP
    [1] https://www.memorysafety.org/