Sur les mailing-lists techniques (enfin... le niveau baisse année après année sur certaines...) qui rassemblent les opérateurs réseaux (FRnOG, NANOG), on lit souvent, à propos des guéguerres commerciales entre opérateurs (exemple : Cogent/Hurricane Electric et Cogent/Google, tout deux en IPv6), que ce n'est pas nouveau, que même le monde IPv4 est fragmenté (on n'accède pas à n'importe quelle IPv4 depuis n'importe quelle IPv4 pour des raisons techniques ou business). C'est ce point que j'ai voulu mesurer afin de me faire une idée.
L'idée est de comparer les deux arrivées BGP d'ARN : une fournie par Cogent, l'autre par Interoute. La question est : y a-t-il les mêmes préfixes (ou apparentés, on va y venir) dans les deux arrivées ? De là, on verra s'il y a des trous noirs c'est-à-dire des espaces d'Internet que l'un ou l'autre de ces fournisseurs ne savent pas joindre. On voit là un premier biais de notre méthodologie : si un réseau n'est visible ni par Cogent ni par Interoute, on ne verra pas que ce réseau manque à l'appel.
Le principal piège, c'est qu'un « diff » naïf ne peut pas fonctionner à cause de la désagrégation qui consiste à découper un bloc IP en un ou plusieurs blocs plus spécifiques (un /24 de 256 adresses est plus spécifique qu'un /22 de 1024 adresses) et d'annoncer ces blocs-là seulement à un seul ou plusieurs prestataires bien définis. Cela tient d'un concept fort du routage IP qui sélectionne toujours la route la plus spécifique, la plus précise, celle qui porte sur le moins d'adresses. Si ARN annonce des préfixes plus spécifiques uniquement sur Interoute, par exemple, alors le trafic arrivera forcément par là, +/- ce qu'on nomme le trafic résiduel qui provient de réseaux qui ne reçoivent pas ces annonces plus spécifiques pour diverses raisons...
Du coup, si l'opérateur A relaie un /23 et l'opérateur B relaie les 2 * /24 qui composent ce /23, il faut quand même considérer que l'opérateur A peut joindre les réseaux /24. Si l'opérateur A relai un /23 et l'opérateur B relai un /24, il faut considérer que A peut joindre un /24 de plus que B. Généralement, quand on désagrège, on annonce quand même le bloc moins spécifique pour ne pas avoir d'impact si les blocs plus spécifiques étaient refusés par des opérateurs donc normalement A aurait /23 et B aurait /23 + 1 * /24. Donc égalité entre les deux opérateurs.
Avec une petite recherche sur un moteur de recherche web, on trouve une implémentation :
https://github.com/tibordp/bgpcompare . On trouve aussi un billet de blog de l'auteur qui explique l'implémentation qu'il a retenue (une comparaison bit à bit) :
https://www.ojdip.net/2012/10/comparing-bgp-routing-tables/ . L'ennui, c'est que ce n'est pas ce que nous recherchons.
On se décide à dégainer Python et python-radix (voir
http://shaarli.guiguishow.info/?GZW_8g ). Mon programme est disponible ici :
http://www.guiguishow.info/wp-content/uploads/2016/03/compareBGPRIBs.py . Pour résoudre le problème de la désagrégation, on enregistre tous les préfixes d'une première RIB dans un arbre radix puis on capture uniquement les adresses (donc pas la représentation du réseau comme « /24 ») de la deuxième RIB pour les comparer à la première. Ainsi, la recherche se fera à partir d'un /32 et la première occurrence gagnera. Dans le cas présenté ci-dessus, on trouvera le /23 de A et les 2 * /24 de B. C'est exactement comme cela que procède un routeur : dans un paquet IP, seule l'IP est indiquée.
Commandes utiles :
* « sudo birdc6 sh route protocol <nom_protocol> > prefixes_protocol » : on demande à BIRD d'afficher tous les préfixes obtenus via un peer sur stdout et on redirige stdout dans un fichier ;
* « ./compareRIBs.py -u prefixes_v6_cogent prefixes_v6_interoute | cut -d '/' -f 1 | xargs -I {} sudo birdc6 sh route for {} protocol bgp_interoute | grep -v BIRD » : on vérifie que mon programme ne se trompe pas. Ici, grâce au flag « -u », il va retourner les préfixes que l'on a dans la RIB Cogent mais pas dans Interoute. On vérifie en demandant tout simplement à BIRD. Si rien n'est affiché, alors le programme a raison :)
Et du coup, ça donne quoi ?
* IPv4 : Cogent a environ 59 préfixes qu'Interoute n'a pas et Interoute a environ 950 préfixes que Cogent n'a pas.
* IPv6 : Cogent a environ 1 préfixe qu'Interoute n'a pas et Interoute a environ 1599 préfixes que Cogent n'a pas.
Comment expliquer ça ?
* On constate une fluctuation de +/- 10 préfixes entre 2 mesures réalisées à deux semaines d'écart. Aucune idée d'où cela peut bien venir puisqu'il ne s'agit pas de nouveaux réseaux ;
* Environ +/-5 préfixes flappent non-stop (apparaissent, disparaissent,...) donc ils manquent dans nos dumps de RIB ;
* Si on élargit la ligne précédente, on constate qu'environ une 10aine de préfixes (différents du premier point et englobant le second) flappent plutôt souvent et peuvent donc se faire filtrer en amont d'un de nos prestataires par la technique dite du dampering (filtrage temporaire et automatique des routes instables qu'il n'est plus recommandée d'appliquer de nos jours, cependant mais les comportements changent très lentement) ;
* On trouve des conflits commerciaux notamment en IPv6. Exemple : le désaccord entre Cogent et Google représente 34 préfixes de différence. Celui avec HE en représente 20. Parmi ce qui reste, on constate beaucoup de préfixes d'opérateurs brésiliens, chinois et d'Europe de l'Est (Ukraine, Pologne, Russie,...). Cogent apporte un seul préfixe... provenant du Crédit Agricole :O ;
* Même constat en IPv4 : Interoute a des préfixes chinois, russes et d'Europe de l'Est que n'a pas Cogent. Cogent a des préfixes US dont 32 sont à Dataframe qui désagrège son /19 en 32 * /24 et à peu près autant pour Time Warner Cable.
Après, ce n'est pas tout d'avoir un itinéraire, il faut encore avoir des interconnexions physiques de bonnes qualités (pas trop de pertes de paquets, pas trop de latence,...). Et ça, ça ne se mesure pas à partir d'une table de routage. Voir
http://shaarli.guiguishow.info/?nNMTjQ
Merci à b4n (
http://ban.netlib.re/shaarli/ ) pour son aide sur le bout de Python. :)