Les copains d'Alsace Réseau Neutre, FAI associatif neutre en Alsace ont racké leurs machines en début de semaine et ils ont monté leur première session BGPoIPv4 hier soir. L'idée m'est venue de constater le temps de propagation de leur préfixe à travers les Internets.
Table des matières
Que mesure-t-on ?
Je précise d'abord, pour les mesures-nazi qui passeraient par là, que je ne cherche pas à faire une mesure précise et fiable. L'idée n'est pas de démontrer quelque chose ni d'argumenter une publication scientifique. On est plus dans le domaine du "for ze fun" parce que, oui, voir son préfixe apparaître dans les tables de routage de routeurs à l'autre bout du monde, c'est beau. :')
Et puis avoir une idée et voir les outils disponibles pour la réaliser, c'est formateur.
L'idée est donc de voir comment/à quelle vitesse se propage la première annonce BGP d'ARN de routeur de bordure en routeur de bordure, à travers les Internets.
Nous chercherons à obtenir une chronologie de la propagation. Exemple fictif :
21h00m00 : ARN lance la session BGP.
21h00m49 : Le préfixe apparaît chez notre transitaire
.... : le préfixe apparaît dans tel point d'échange européen
.... : le préfixe apparaît la table d'un routeur à Sydney
Etc, etc.
Comment mesure-t-on ?
On sent, de manière assez intuitive, que la mesure doit être faite depuis d'autres réseaux.
Plusieurs idées peuvent venir en tête :
- On peut utiliser des looking glasses ou des traceroute mis à la disposition par des opérateurs. Exemples : le préfixe v4 d'ARN dans le looking glass du FAI associatif toulousain Tetaneutral.net, traceroute.org. Inconvénient : à part un mass-F5-autoreload, ça me semble difficilement automatisable.
- On peut utiliser le service Routing Information Service (RIS) du RIPE. Exemple : le préfixe v4 d'ARN dans RIS (on remarquera au passage qu'il y a une annonce large invalide dans la nature : 88.0.0.0/6 par 3303 depuis le 20/04/2013 ). C'est simple mais ça ne permet pas d'obtenir la chronologie que nous voulons. ÉDIT du 19/07/2013 à 10h30 : En revanche, l'outil BGPlay permet une visualisation très sympathique de la timeline. Exemple : le préfixe v4 d'ARN dans BGPlay. Fin de l'édit
- On peut utiliser les routeurs en accès libre du projet Route Views. Avec l'outil ctel (du package cssh dont je vous ai déjà parlé), il est possible d'exécuter la même commande en parallèle sur plusieurs collecteurs du projet Route-Views. Le projet permet même de récupérer les archives des annonces BGP vues par les différents collecteurs du projet. Les archives sont disponibles par tranches de 15 minutes.
- Utiliser les sondes du projet Atlas du RIPE pour lancer un traceroute depuis plusieurs points des Internets. Le résultat doit être intéressant mais je n'ai ni sonde, ni crédit.
Déroulement
RIS
Rien de spécial à faire : à partir du lancement du démon de routing (BIRD dans le cas d'ARN), il suffit de recharger la page à une fréquence donnée.
Route-Views
Avant l'instant I, il suffit de préparer ctel en ajoutant les routeurs que l'on souhaite interroger dans .clusterssh/clusters. Exemple :
ARN-test route-views.sydney.routeviews.org route-views.saopaulo.routeviews.org route-views2.routeviews.org rpki-rtr.ripe.net |
Les lecteurs attentifs remarqueront rpki-rtr.ripe.net qui n'est pas un collecteur du projet Route-Views mais un routeur Cisco mis à disposition par le RIPE pour jouer avec RPKI+ROA. L'username est ripe, sans mot de passe.
Peu avant le lancement du démon de routing, il suffira de se connecter aux machines :
ctel ARN-test |
et de saisir :
show bgp ipv4 unicast 89.234.141.0/24 |
ou
show bgp ipv6 [unicast] 2a00:5881:8100::/40 |
Il faudra maintenir les connexions avec une activité car il y a des timeout. 😉
Suite au lancement de BIRD, il suffit normalement de relancer la commande plusieurs fois (fleche haut-entrée, classique) pour voir les différences.
Archives Route-Views
Les archives sont au format MRT. Il nous faut donc un outil pour les lire. J'ai choisi arbitrairement bgpparser. Attention : la version 0.3b2 distribuée sur le site officiel ne compile pas.
On installe les dépendances nécessaires :
sudo apt-get update && sudo apt-get install libxml2 libxml2-dev liblog4cxx10 liblog4cxx10-dev libboost-all-dev git |
On récupère le dépôt git :
git clone https://github.com/cawka/bgpparser.git |
Les commandes classiques :
./bootstrap.sh ./configure make sudo make install |
Il faut penser à ajouter /usr/local/lib en tant que dossier où chercher des bibliothèques (/usr/local/lib est déjà indiqué dans /etc/ld.so.conf.d/libc.conf sinon, il faudrait le faire nous même avant de lancer la commande) :
ldconfig |
Ensuite, il suffit de récupérer une archive. Comme écrit sur la page web du projet Route-Views : de nos jours, les fichiers sont nommés en fonction de l'heure UTC (bon, il y a une exception mais ce n'est pas important ici 😛 ). Donc pour un événement qui s'est produit vers 20h31/20h32 UTC+2 le 17 juillet 2013, il faut récupérer un fichier de la forme : updates.20130717.1830.bz2. Ce fichier couvre donc de 20h30 à 20h44m59s UTC+2 du 17 juillet 2013 pour un collecteur donné.
Pour le collecteur de Sydney, on aura donc :
wget http://archive.routeviews.org/route-views.sydney/bgpdata/2013.07/UPDATES/updates.20130717.1830.bz2 |
Il ne reste plus qu'à lire ce fichier :
bgpparser2 --file updates.20130717.1830.bz2 --ipv4 | grep 89.234.141.0/24 BGP4MP|1374085909|A|202.167.228.20|4739|89.234.141.0/24|4739 3356 1299 42456 60630|IGP|202.167.228.20|0|0|4739:0|NAG|| BGP4MP|1374085922|A|202.167.228.74|4826|89.234.141.0/24|4826 6939 42456 60630|IGP|202.167.228.74|0|0|4826:5901 4826:6150|NAG|| BGP4MP|1374085924|A|202.167.228.37|38809|89.234.141.0/24|38809 2914 1299 42456 60630|IGP|202.167.228.37|0|0|2914:420 2914:1005 2914:2000 2914:3000 65504:1299|NAG|| BGP4MP|1374085930|A|202.167.228.44|10026|89.234.141.0/24|10026 1299 42456 60630|IGP|202.167.228.44|0|10051|10026:3050 10026:31840 10026:40903|NAG|| BGP4MP|1374085936|A|202.167.228.20|4739|89.234.141.0/24|4739 1239 1299 42456 60630|IGP|202.167.228.20|0|0|4739:0|NAG|| BGP4MP|1374086082|A|202.167.228.44|10026|89.234.141.0/24|10026 1299 42456 60630|IGP|202.167.228.44|0|10052|10026:3050 10026:31840 10026:40912|NAG|| |
ÉDIT du 19/07/2013 à 12h30 :
ou
bgpparser2 --file updates.20130719.0915.bz2 --ipv6 | grep 2a00:5881:8100::/40 BGP4MP|1374226150|A|2001:12f8::20|28571|2a00:5881:8100::/40|28571 1251 20080 6939 42456 60630|IGP|2001:12f8::20|0|0||NAG|| BGP4MP|1374226150|A|2001:12f8::218:21|52888|2a00:5881:8100::/40|52888 1251 20080 6939 42456 60630|IGP|2001:12f8::218:21|0|0||NAG|| BGP4MP|1374226150|A|2001:12f8::20|28571|2a00:5881:8100::/40|28571 1251 20080 6939 1299 42456 60630|IGP|2001:12f8::20|0|0||NAG|| BGP4MP|1374226150|A|2001:12f8::20|28571|2a00:5881:8100::/40|28571 22548 3549 1299 42456 60630|IGP|2001:12f8::20|0|0|3549:2471 3549:30840|NAG|| BGP4MP|1374226150|A|2001:12f8::218:21|52888|2a00:5881:8100::/40|52888 1251 20080 6939 42456 60630|IGP|2001:12f8::218:21|0|0||NAG|| BGP4MP|1374226150|A|2001:12f8::20|28571|2a00:5881:8100::/40|28571 1916 6939 42456 60630|IGP|2001:12f8::20|0|0|1916:1250|NAG|| [...] |
Fin de l'édit
On a : le type de message, le timestamp du message, le sous-type (ajout de route (« A »), suppression (« W »)), l'IP du peer, l'ASN du peer puis le message BGP qui se décompose en préfixe, AS_PATH, origine, next-hop, localpref, MED, communautés, pas d'aggrégation (« NAG »).
Pour convertir le timestamp, utilisez votre langage favori (troll inside) comme :
php -r 'echo date ("d/m/Y H:i:s", "1374085909")."\n";' 17/07/2013 20:31:49 |
Comme c'est tout bien classé par ordre chronologique, on voit que le collecteur de Sydney a reçu la première annonce d'ARN à 20h31m49s.
Donc, les résultats ?
(Temps en UTC+2)
RIS
20h31m?s : lancement de BIRD (première vue : 2013-07-17 20:31:48)
21h : 76% de visibilité
21h30 : 89% de visibilité
22h : 97% de visibilité
Route-Views
IPv4
LINX : 17/07/2013 à 20:31:48
São Paulo : 17/07/2013 à 20:31:48
Sydney : 17/07/2013 à 20:31:49
Oregon : 17/07/2013 à 20:32:07
Tokyo : 17/07/2013 à 20:32:17
IPv6
(Pour les curieux : non, nous ne considérons pas l'annonce du 19/07/2013 à 00h20 comme étant la première)
LINX : 19/07/2013 à 11:29:09
São Paulo : 19/07/2013 à 11:29:10
Sydney : 19/07/2013 à 11:29:09
Oregon : 19/07/2013 à 11:29:09
Tokyo : 19/07/2013 à 11:29:21
J'avais toujours entendu dire qu'il fallait 3 à 4 minutes pour qu'un préfixe nouvellement annoncé apparaisse dans 90% des réseaux des Internets. Avec cette mise en pratique, je constate que c'est jouable en 1 minute. 🙂 Bon, ok, les sessions BGP avec notre transitaire étaient déjà montées au moment du reload de BIRD qui a provoqué l'annonce. Forcement, on gagne un peu. 😀
Atlas
ÉDIT du 19/07/2013 à 12h30 :
Merci à Stéphane Bortzmeyer.
IPv4 :
Monde : Measurement #1013491 to 89.234.141.1 uses 400 probes 400 probes reported Test done at 2013-07-19T08:16:35Z Tests: 398 successful tests (99.5 %), 0 errors (0.0 %), 2 timeouts (0.5 %), average RTT: 71 ms Europe : Measurement #1013493 to 89.234.141.1 uses 399 probes 399 probes reported Test done at 2013-07-19T08:21:20Z Tests: 398 successful tests (99.7 %), 0 errors (0.0 %), 1 timeouts (0.3 %), average RTT: 52 ms Asie (toujours moins bien) : Measurement #1013494 to 89.234.141.1 uses 114 probes 113 probes reported Test done at 2013-07-19T08:24:20Z Tests: 107 successful tests (94.7 %), 0 errors (0.0 %), 6 timeouts (5.3 %), average RTT: 298 ms Measurement #1013495 to 89.234.141.1 uses 115 probes 115 probes reported Test done at 2013-07-19T08:43:21Z Tests: 112 successful tests (97.4 %), 0 errors (0.0 %), 3 timeouts (2.6 %), average RTT: 298 ms |
IPv6 :
Monde : Measurement #1013513 to 2a00:5881:8100::1 uses 396 probes 396 probes reported Test done at 2013-07-19T13:22:53Z Tests: 344 successful tests (86.9 %), 17 errors (4.3 %), 35 timeouts (8.8 %), average RTT: 71 ms |
Fin de l'édit
ÉDIT du 26/10/2013 à 16h30 :
D'autres stats IPv6 homemade cette fois-ci :
Monde : 392 probes, 938 successful tests (79.8 %), 144 errors (12.3 %), 93 timeout (7.9 %), average RTT: 75 Europe : 396 probes, 971 successful tests (81.6 %), 114 errors (9.6 %), 105 timeout (8.8 %), average RTT: 51 Asie : 52 probes, 119 successful tests (76.3 %), 27 errors (17.3 %), 10 timeout (6.4 %), average RTT: 314 Amérique : 151 probes, 295 successful tests (65.1 %), 93 errors (20.5 %), 65 timeout (14.3 %), average RTT: 146 |
Fin de l'édit
Conclusion
Je vais être bref : expérience enrichissante.