Un transitaire, pour faire à la truelle, c'est une entité (société commerciale ou pas) qui est censée être présente dans tous les datacenters (bâtiments dans lesquels sont installés les ordinateurs et autres matériels qui font fonctionner Internet) du monde afin de rendre accessibles tous les réseaux qui constituent Internet. L'intérêt ? Imaginons deux opérateurs : ARN dont l'infrastructure est physiquement présente à Strasbourg, France et un opérateur B dont l'infrastructure est présente à Tokyo, Japon. On sent bien que ces deux entités ne vont pas pouvoir interconnecter directement leurs réseaux à cause d'un coût prohibitif de la liaison et auront donc recours à un intermédiaire qui mutualisera le coût d'une liaison France↔Japon entre plusieurs clients : c'est le transitaire.

• Limiter l'impact des pannes / erreurs de configuration (résilience) ;

• Augmenter la qualité du réseau et donc le confort de ses utilisateurs : certains transitaires ont un excellent réseau (capacité, latence,…) en Amérique du Nord et un moins bon réseau en Europe ou inversement. Exemple : Interoute, opérateur eurocentré est bon en Europe et moins bon en Amérique du Nord. Cette différence de qualité peut aussi se ressentir à des échelles plus locales : la qualité de l'interconnexion entre Cogent et Free est meilleure (débit) que celle entre Interoute et Free (justification : transit dans le premier cas, PNI dans le second). À l'inverse, la qualité de l'interconnexion entre Interoute et Google offre un bien meilleur débit que celle entre Cogent et Google (justification : peering bien entretenu dans le premier cas, volonté de limiter le peering dans le second) ;

• Limiter l'impact des guéguerres commerciales. Exemple : Cogent et Hurricane Electric (HE) sont en guéguerre et il est donc impossible de joindre une adresse HE IPv6 en étant client unique de Cogent et ce depuis plus de 5 ans…

Nous avons choisi de faire affaire avec Cogent (AS174) et Interoute (AS8928). En 2018, nous avons décidé de couper notre liaison avec Interoute. Pour quelles raisons ?

• Pour Cogent, notre infrastructure est hébergée dans un de leur datacenter (voir Matériel) donc le coût de l'interconnexion pour du transit IP est nul : ni frais d'accès ni récurrent mensuel. C'est toujours appréciable quand on est une petite structure comme ARN. Et oui, on peut voir ça comme une distorsion du marché au détriment de la concurrence…

• Nous avons cherché les opérateurs déclarés à l'ARCEP dont le siège social est en Alsace. Nous avons également démarché les opérateurs de grande envergure que les admins ARN connaissaient de nom. De ce travail, il est ressorti que Cogent et Interoute sont les deux transitaires les moins chers qui sont présents à Strasbourg, qui satisfont nos critères et ARN aux leurs (certaines sociétés commerciales refusent de fournir la prestation si le matériel utilisé n'est pas du Cisco/Juniper ou livrent uniquement en fibre optique, nous voulons 2 sessions BGP sur un même lien physique) et dont le contact humain a été excellent.

• Avec les critères du point précédent, il restait deux concurrents pour la place de deuxième transitaire d'ARN. Interoute a gagné par sa forte présence en Europe (l'autre opérateur était trop franco-français), plus de peering (AMS, LINX, DECIX) et des dépendances à des opérateurs (NTT, Tinet, HE) qui ne sont pas déjà des fournisseurs direct d'ARN (le concurrent repose beaucoup sur Cogent).

• En 2018, pour des raisons financières nous avons résilié le contrat Interoute, ce qui a permis de passer de 1440€ TTC à 640€ TTC mensuel, de sorte que l'association puisse continuer son activité de façon pérenne en équilibrant recettes des services et dépenses liés à l'infra Cogent. La conséquence étant qu'ARN est moins bien interconnecté, et notamment en ce qui concerne ipv6 et Google puisqu'il faut passer par un tunnel Hurricane Electric.

Pour trouver des opérateurs : il faut utiliser la liste publique des opérateurs déclarés à l'ARCEP et les noms de sociétés commerciales que vous connaissez.

Ensuite, il faut contacter leur service commercial pour vérifier leur présence dans les datacenters où vous pourrez être hébergé à coup sûr puis pour demander la grille tarifaire adaptée à vos besoins. Le téléphone reste le moyen de communication le plus adapté pour un premier contact (ensuite, vous pourrez discuter par mail puisque, de toute façon, le service commercial vous enverra la proposition commerciale (« propale ») par mail).

Pour comparer les opérateurs, le prix est un bon indicateur dans une petite structure comme une association, on ne va pas se mentir. Ne pas oublier de prendre en compte le coût de l'interconnexion avec ce prestataire : un datacenter peut vous imposer un passage en meet-me-room (salle d'interconnexion passive 1-to-1 (pas de multiplexage d'une fibre) qui permet d'éviter les câbles qui traverse le datacenter dans tous les sens), ce qui représente généralement de gros frais d'accès au service (> 1 k€) et un petit récurrent mensuel (25-50 €).

Si plusieurs concurrents sont encore en course, il faut les comparer techniquement.

• Trouver les opérateurs dont ils dépendent. Le looking glass du NLNOG est un bon indicateur. Exemple : www.arn-fai.net NLNOG met clairement en évidence les deux transitaires d'ARN et l'absence de peering (auquel cas, on verrait beaucoup de réseaux en mesure de nous joindre directement). L'idée est de viser la variété : cet opérateur ne doit pas dépendre d'un autre opérateur que vous aurez déjà choisi (et donc avec lequel vous serez interconnecté directement).

• Lecture de l'IRR et de peeringdb. L'objectif est toujours le même : identifier peering et transit et en particulier avec les réseaux qui vous intéressent (pour ne pas rebuter les gens en tant que FAI associatif français, il vaut mieux avoir une bonne connectivité vers les FAI commerciaux français d'envergure nationale (Orange, Numericable, Free,…) et les hébergeurs français (OVH, Online,…), par exemple). Les infos de l'IRR sont souvent dépassées et il faut donc les prendre avec des pincettes mais c'est là qu'on a le plus de probabilité de voir les interconnexions directes privées (PNI).

• Rechercher la présence de l'opérateur dans la liste des membres des principaux points d'échange Internet (AMS-IX, DE-CIX, France-IX, LINX, l'IX de votre région,…) Il faut favoriser les opérateurs qui disposent d'une très bonne présence aux IX car c'est un gage de qualité et aussi d'éthique (les FAI associatifs défendent normalement une vision de l'Internet qui correspond plus à du peering, de l'échange mutuel réciproque et gratuit qu'à du transit payant).

• Rechercher la réputation de l'opérateur sur le web et les listes de discussion qui regroupent les opérateurs (FRnOG, NANOG,…). Termes à utiliser « <nom_operateur> peering issue », « <nom_operateur> depeering », « <nom_operateur> peering dispute ». L'idée est d'identifier les embrouilles commerciales comme Cogent/Google et Cogent/HE en IPv6 et de ne pas avoir recours à des prestataires différents qui ont un même différend avec un troisième opérateur auquel cas la redondance ne sert à rien…

• Le feeling avec le/la commercial-e est également très important. Sérieux, compréhension des besoins, offre commerciale claire, réponses longues ou réponses évasives qui cachent un gros “vous m'ennuyez” ? Tout ça est très important, nous parlons d'expérience.

Notre association dispose de deux routeurs pour le transfert des paquets vers/depuis Internet. Il s'agit de deux serveurs x86 tout ce qu'il y a de plus commun. Pour avoir la description matérielle de ces machines, c'est par ici : Matériel.

Pour mettre à jour la table de routage de nos routeurs et annoncer nos préfixes IP, nous utilisons BGP, le protocole normalisé d'échange de routes entre opérateurs, ainsi que des règles statiques. Notre numéro d'AS est 60630.

Au niveau logiciel, nous utilisions BIRD sur un routeur et Quagga (bgpd + zebra) sur l'autre. Depuis 2019, nous avons décidé de simplifier le ticket d'entrée pour les nouveau adminsys et d'homogénéiser en utilisant uniquement bird. Ces logiciels sont directement installés sur les hyperviseurs, comprendre que ces démons de routage ne sont pas enfermés dans une machine virtuelle ou un conteneur. Nos configurations sont dans notre git public.

XORP est expérimental, plutôt dédié à la création de maquettes orientées recherche. La syntaxe du fichier de conf' est pénible (successions d'accolades à n'en plus finir).

Dans le monde *BSD, OpenBGPd est un logiciel à envisager sérieusement (mais qui ne semble pas avoir la fonctionnalité de définir la source dans l'optique que le routeur n'émette jamais de paquets avec une de ses IP d'interconnexion, voir ci-dessous).

• Montée en compétence : Quagga utilise la syntaxe et les concepts Cisco. BIRD utilise les concepts d'un démon GNU/Linux - BSD (configuration à partir d'un fichier, syntaxe plus brute et plus proche d'un langage de programmation surtout au niveau des filtres, stricte séparation IPv4/IPv6,…). Il est donc intéressant pour les admins tech d'ARN de se faire la main sur du Cisco-like en conditions réelles mais aussi de voir autre chose, une autre façon de faire que de voir le monde seulement à travers le prisme de Cisco.

• Redondance : la diversité du code est importante car elle empêche un bug ou une faille de sécurité de plomber tout un système. Dans notre cas, un bug sur l'un ou l'autre des logiciels ne fera pas disparaître ARN des Internets. Pour ceux et celles qui pensent que cela n'est jamais arrivé, voir l'histoire de l'attribut 99 qui date de 2010.

Un bilan des différences qui ont un impact opérationnel que nous avons constaté est disponible ici : BIRD/Quagga : différences et cas d'usage particuliers.

Avec Ganeti, nous rencontrons un autre problème : lors d'une migration à chaud d'une machine virtuelle d'un hyperviseur à un autre, Ganeti supprime l'interface réseau correspondante sur l'hyperviseur source. Linux nettoie automatiquement la ou les routes qui sont associées à une interface détruite. Mais pas Zebra. Ce dernier empoisonne donc la table de routage, ce qui provoque un trou noir partiel : les paquets IP sont attirés sur une interface qui n'existe pas et sont détruits. Zebra empoisonne également les pairs iBGP… Solution : créer un script que l'on place dans /etc/ganeti/hooks/instance-migrate-pre.d/ qui supprime toutes les routes associées à l'interface défunte (ip route flush dev <interface>).

La diversité du code est une chose importante comme nous l'avons vu ci-dessus mais elle représente également un coût humain (à la mise en place puis à la mise en place de chaque action d'ingénierie de trafic désirée) comme nous l'avons aussi vu ci-dessus.

• Si vous avez un seul routeur dans votre projet, prenez BIRD sans hésiter. Sous *BSD, une alternative à considérer est OpenBGPd (voir néanmoins la remarque ci-dessus).

• Si vous avez deux routeurs dans votre projet et du temps à passer pour trouver les bouts de conf' équivalents : prenez BIRD et Quagga. Pour les BSDistes : prenez BIRD et OpenBGPd.

• Si vous avez deux routeurs mais pas de temps : BIRD partout.

Un looking glass est un logiciel (ou une simple session telnet/ssh) qui permet d'avoir un accès en lecture uniquement aux routeurs d'une organisation. Cela permet de prendre connaissance des informations de routage et ainsi de voir de quelle manière et via quels intermédiaires les flux IP circuleront en sortie du réseau de cette organisation. Très utile pour debug ou simplement pour comprendre l'acheminement des flux réseau.

Notre looking glass est accessible ici : http://lg.arn-fai.net/. Il s'agit du logiciel bird-lg. Des units systemd pour gérer bird-lg sont disponibles dans notre dépôt git.

Chacun de nos routeurs monte une session BGP over IPv4 et une session over IPv6 avec chacun de nos transitaires. Nous avons deux transitaires : Cogent (AS 174) et Interoute (AS 8928). Nous avons donc 4 sessions par routeur, 8 sessions BGP vers l'extérieur (eBGP) en tout + 1 sessions iBGP.

À Strasbourg, ni Cogent ni Interoute n'ont plusieurs routeurs. Nos deux routeurs montent donc les sessions BGP avec le même routeur du même prestataire. La redondance vers l'extérieur est assurée via deux transitaires qui doivent donc tomber en panne en même temps pour faire disparaître ARN des Internets. Une session BGP avec chacun de nos routeurs nous permet d'éteindre totalement un de nos routeurs pour effectuer une maintenance ou en cas de panne, sans aucune interruption de service.

Aucun prestataire n'est privilégié sur un autre (nous ne modifions pas la local preference ni ne faisons d'AS prepending). Modifier la local preference permet de forcer nos routeurs à envoyer le trafic via un transitaire donné même si celui-ci n'est pas le chemin le plus court. L'AS prepending consiste à ajouter plusieurs fois son propre numéro d'AS dans le chemin d'AS afin de le rallonger artificiellement dans le but de conseiller vivement aux routeurs des autres opérateurs de ne pas emprunter tel ou tel de nos transitaires pour nous envoyer du trafic. Notons que, dans l'algorithme de sélection des routes de BGP, la local preference l'emporte sur la longueur du chemin d'AS. Cela signifie donc que l'AS prepending est un conseil qu'un opérateur donne à un autre mais ce n'est pas un ordre puisqu'il peut être contourné.

Ces méthodes dites d'ingénierie du trafic sont utiles quand un transitaire coûte beaucoup plus cher qu'un autre et qu'on souhaite donc le garder en secours c'est-à-dire l'utiliser seulement quand le transitaire moins coûteux est en panne. Ces techniques sont aussi utiles quand un problème de qualité (débit, latence) est constaté sur le prestataire choisi naturellement. À ce sujet, voir le problème de qualité que nous avons eu avec Free en IPv6 : Cas d'étude de la sélection du meilleur chemin par un routeur BGP et comment forcer le choix .

En IPv6, nous montons également deux sessions BGP (une par routeur, toujours) avec Hurricane Electric (HE). Pourquoi ? Car Cogent et Hurricane Electric sont en guéguerre commerciale depuis de nombreuses années donc on ne peut pas joindre le réseau HE depuis Cogent. Comme la proportion de tunnels 6in4 détenus par HE est importante, il n'est pas possible de les ignorer. Depuis que nous avons notre deuxième transitaire, ces deux sessions BGP, établies à travers un tunnel 6in4 sont conservées dans le cas où ce deuxième transitaire serait en panne. Il est fortement conseillé de ne pas l'utiliser pour nous joindre : nous utilisons donc la méthode de l'AS prepending et nous positionnons la localpref a 80 (au lieu de 100 par défaut donc les annonces via HE sont mises en retrait).

Parallèlement, la session iBGP entre nos routeurs-hyperviseurs permet à chacun d'entre eux d'annoncer le ou les préfixes alloués à un service (un VPS, un Raspberry Pi hébergé dans notre baie,…) à l'autre. Lorsqu'on ajoute une route (par exemple, on démarre un VPS) sur un des hyperviseurs, cette route est ainsi transmise à l'autre routeur, qui saura gérer les éventuels paquets arrivant chez lui, à destination de ce VPS qui n'est pourtant pas en cours d'exécution sur lui.

Notons que nous fournissons, temporairement et gratuitement, du transit IP à l'association GRIFON, FAI associatif autour de Rennes car elle n'a pas les ressources financières pour se payer un deuxième transitaire et se retrouve donc confrontée aux lacunes de Cogent (guéguerres commerciales avec HE et Google en IPv6, débit moisi vers/depuis Youtube). Comme GRIFON et ARN ont toutes deux souscrits à une prestation de transit Cogent, l'interconnexion entre ARN et GRIFON se fait au-dessus du réseau Cogent, dans un tunnel GRE. Le réseau Cogent est utilisé comme un L2L.

La partie la plus complexe de la configuration d'un routeur est les filtres que nous appliquons aux sessions BGP externes.

Nous n'appliquons aucun filtre à la session iBGP entre nos routeurs en nous reposant sur le formalisme de nos filtres externes. L'objectif est de ne pas ajouter une couche supplémentaire de complexité.

Nos configurations, y compris nos filtres, sont publiquement disponibles sur notre dépôt git.

En entrée, il est de bon ton de filtrer les annonces BGP qui portent sur :

• des préfixes réservés (qui ne doivent donc pas être présents sur Internet) que l'on nomme « martians »;
• les préfixes plus grands que /8 (car ils n'ont jamais été alloués) et plus petits que /24 (consensus communautaire actuel, pour éviter de saturer la table) ;
• un chemin d'AS trop long ;
• un next-hop ou un AS pair avec lequel aucune session BGP n'est montée ;
• nos préfixes (ils nous ont été alloués, personne d'autre ne doit les annoncer) ;
• un trop grand nombre de préfixes, ce qui signifie que le pair a fait une erreur comme désagréger les préfixes. 620 000 en IPv4 et 50 000 en IPv6 sont de bonnes valeurs de nos jours. Évidemment, il faut monitorer le nombre de routes présentes dans la table de routage mondiale et ajuster ces valeurs au fil de l'eau ! ATTENTION : ne pas utiliser si vous avez un seul transitaire ou si vous n'avez aucun moyen out-of-band (quand les sessions BGP tombent, quoi ;) ) de joindre votre infra !

Cela suit :

• Les recommandations de l'ANSSI ;
• Le RFC 7454 « BGP Operations And Security ».

Normalement, il convient de filtrer également les bogons c'est-à-dire les espaces d'adressage qui, bien que non-réservés, n'ont pas encore été alloués par l'IANA et les RIR. Cela nécessite une actualisation régulière. Ça s'automatise mais une vérification humaine reste nécessaire pour éviter les dégâts. Nous ne pouvons pas nous permettre ce temps-là donc nous ne filtrons pas activement les bogons en IPv6, nous nous contentons de refuser les annonces qui portent sur autre chose que 2000::/3 qui est le seul bloc routable sur Internet alloué par l'IANA à l'heure actuelle (voir https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml). En IPv4, ce n'est plus nécessaire de faire ça puisque quasiment tout l'espace d'adressage a été alloué.

Nous n'avons pas trouvé de moyen simple de vérifier :

• Le next-hop indiqué dans une annonce BGP ;
• La longueur du chemin d'AS dans une annonce BGP (cela se fait avec une regex qui fait crasher bgpd de manière irrégulière…) ;

En sortie, la règle est simple : vous ne devez pas annoncer autre chose que les préfixes qui vous ont été alloués !

Lorsqu'une machine veut émettre sur un réseau et qu'elle dispose de plusieurs adresses, laquelle doit-elle utiliser ? Il y a un algorithme normalisé pour déterminer cela. Voir RFC 6724: Default Address Selection for Internet Protocol version 6 (IPv6).

Vous pouvez penser qu'un routeur n'émet jamais directement sur le net sauf pour établir les sessions BGP puisqu'il se contente de transférer des paquets IP déjà construits d'un réseau à un autre. Et lorsqu'il faut le mettre à jour (apt, yum,…) ? Et lors d'un debug (ping, traceroute, réponse à un traceroute externe, wget,…) ?

Il est de bon ton (mais pas obligatoire) de ne pas utiliser l'adresse IP d'interconnexion. Certains transitaires interdisent même cet usage en supprimant tout paquet à destination d'une IP d'interconnexion. Ça permet d'éviter les DDoS de routeurs.

Qu'est-ce que ça change ? Ne pas utiliser une IP d'interco mais une adresse IP faisant partie du bloc qu'on vous a alloué simplifiera vos debugs : vous savez quelle IP attendre à l'autre extrémité de la communication. C'est aussi plus clean : la destination sait, sans ambiguïté que la requête vient de votre réseau.

Une bonne manière de faire cela est de configurer une interface loopback avec une IP de votre range et d'indiquer au démon de routage de forcer l'adresse source à utiliser dans la route. Avec Linux, on peut faire ça manuellement : « ip route add default via 192.0.2.1 src 192.0.2.42 dev eth0 » (traduction : pour toutes nos communications IPv4, utiliser 192.0.2.42 comme adresse source.

auto loopback1
iface loopback1 inet manual
  pre-up ip link add $IFACE type dummy
  post-up ip l s up dev $IFACE
  post-up ip a a 89.234.141.131/32 scope global dev $IFACE
  post-up ip r a 89.234.141.131/32 dev $IFACE
  pre-down ip r d 89.234.141.131/32 dev $IFACE

iface loopback1 inet6 manual
  post-up ip -6 a a 2a00:5881:8100::131/128 scope global dev $IFACE
  post-up ip -6 r a 2a00:5881:8100::131/128 dev $IFACE
  pre-down ip -6 r d 2a00:5881:8100::131/128 dev $IFACE
  post-down ip l d $IFACE

protocol kernel {
       export filter {
              krt_prefsrc = 2a00:5881:8100::131;
              accept;
      }; 
}

Évidemment, il faut faire pareil en IPv4. :)

Dans zebra.conf :

ip prefix-list ANY permit 0.0.0.0/0 le 32

route-map SET-SRC permit 10
        match ip address prefix-list ANY
        set src 89.234.141.131

ip protocol bgp route-map SET-SRC

La fonctionnalité n'est pas implémentée. Il faut donc utiliser un workaround côté noyau dans /etc/network/interfaces : pour chaque IPv6 d'interco, il faut ajouter le mot-clé « preferred_lft 0 ». Exemple :

post-up /sbin/ip -6 a a <IP_interco> dev $IFACE scope link preferred_lft 0

À ce jour, nous utilisons de l'ingénierie de trafic pour utiliser au minimum notre interconnexion avec Hurricane Electric compte tenu qu'elle est basée sur un tunnel 6in4 : locale preference diminuée, as-prepending et utilisation de la communauté BGP no-export. Voir http://shaarli.guiguishow.info/?FAvVBw

Nous y avons aussi eu recours temporairement quand un de nos transitaires avait une latence très élevée vers Free. Pour les détails et les commandes à utiliser, c'est par ici : Cas d'étude de la sélection du meilleur chemin par un routeur BGP et comment forcer le choix.

Nos deux routeurs sont également nos hyperviseurs. Tous nos services tournent dans des VM (pour être facilement migrés à chaud en cas de panne / maintenance d'un des hyperviseurs).

Il faut faire communiquer nos routeurs de bordure avec BGP (iBGP, internal BGP). Donc quoi qu'il arrive, nous avons besoin de BGP au minimum. OSPF, de par son fonctionnement (adjacences) n'est pas conçu pour manger la table de routage mondiale, il n'est pas performant pour ça. Que nous apporterait donc OSPF puisque l'on a besoin d'iBGP et que ce dernier permet tout aussi bien d'annoncer les services (VM, housing) qui sont sur une machine donnée ?

De plus, OSPF est intéressant pour du routage interne quand on a des routeurs qui ne sont pas routeurs de bordure. Ce qui n'est pas notre cas.

Non. On pourrait utiliser de multiples tables de routage mais d'une part, ça complexifie la compréhension et le debug : il faut préciser « table <nom_table> » à la commande « ip route show » sinon on ne voit pas les routes des tables alternatives. D'autre part, les tables multiples ne sont pas supportées par Quagga : il peut utiliser une et une seule table (qui peut être différente de la table principale, ceci dit).

En revanche, nous utilisons les "protocoles" ce qui permet à un admin d'afficher uniquement les routes qui l'intéressent parmi les centaines de milliers (nous avons la full view c'est-à-dire tous les préfixes utilisés sur le Net, pour rappel). Exemple : « ip route show proto ganeti » affiche uniquement les routes concernant les VPS.