Peering et points d'échange : sortir du transit unique

Un client qui télécharge un fichier depuis un service hébergé à 40 km de chez lui, et dont le trafic fait un aller-retour par un transitaire à 600 km, paie deux fois : en latence, et en euros au mégabit. C'est le scénario par défaut d'un AS qui n'achète que du transit. Le trafic sort chez un fournisseur unique, quel que soit le chemin réel entre les deux réseaux qui se parlent. Un port sur un point d'échange internet corrige ça, mais pas de la façon qu'on imagine en lisant une plaquette commerciale.

Le transit IP, c'est payer un opérateur pour qu'il porte votre trafic vers le reste d'Internet. Facturation au débit, en 95e centile la plupart du temps, et une garantie simple : tout ce qui n'est pas directement joignable passe par ce fournisseur. C'est un abonnement à la connectivité universelle, et ça reste indispensable, parce qu'aucun réseau ne peut peerer avec l'intégralité d'Internet.

Le peering, c'est l'inverse : deux réseaux qui échangent leur trafic mutuel sans facturation entre eux, en général sous forme de « settlement-free peering ». La condition tacite : un volume de trafic à peu près équilibré dans les deux sens, sinon l'un des deux réseaux a l'impression de subventionner l'autre. Sur un point d'échange internet (IX), cette mise en relation se fait à un endroit physique unique où des dizaines de réseaux distincts branchent un port sur le même commutateur.

L'aspect financier est direct. Un port de peering coûte un abonnement au switch fabric de l'IX, indépendant du volume écoulé dessus. Le trafic vers un pair connecté au même IX ne consomme plus de capacité de transit facturée au débit. Sur un réseau qui échange une part significative de son trafic avec des acteurs présents sur le même point d'échange, le calcul se fait vite : le port de peering s'amortit en quelques mois face à la facture de transit qu'il évite.

L'autre bénéfice, moins visible sur une facture mais souvent plus déterminant côté exploitation, c'est le chemin réseau. En transit pur, le chemin dépend entièrement de la politique de routage du transitaire, qui peut faire ressortir le trafic à des centaines de kilomètres du point d'entrée réel. Avec un port sur un IX, le trafic entre deux réseaux pairés emprunte le chemin le plus court possible entre eux : un saut, parfois deux, sans traverser de troisième réseau.

Sur un service qui répond à des requêtes synchrones (API, base de données répliquée, jeu en ligne, VoIP), chaque hop en moins et chaque kilomètre de fibre économisé se traduit en millisecondes gagnées. Ce n'est pas anecdotique sur un déploiement anycast multi-POP, où la promesse même du modèle repose sur le fait que BGP choisisse le chemin topologiquement le plus court : un port de peering bien placé améliore directement la qualité de cette décision de routage pour les pairs connectés au même IX.

Techniquement, se connecter à un IX ne veut pas dire établir une session BGP avec chacun des centaines de réseaux présents sur le fabric. C'est le rôle du serveur de routes (route server), décrit dans la RFC 7947 : un intermédiaire qui reçoit les annonces de tous les participants volontaires et les redistribue, sans modifier l'AS_PATH ni s'insérer dans le chemin de données réel. Le trafic, lui, continue de circuler directement entre les deux réseaux pairés : le route server ne fait que simplifier la négociation du contrôle, pas le transport.

En pratique, une session eBGP unique vers le route server suffit pour recevoir les préfixes de tous les participants au « peering multilatéral ». C'est ce qui rend le modèle scalable : sans route server, connecter N réseaux demanderait N sessions BGP distinctes à configurer et maintenir de chaque côté. Avec un serveur de routes comme celui qu'opère France-IX à Paris, une seule session suffit pour peerer avec la majorité du fabric, avec une validation IRR appliquée en amont pour filtrer les annonces non conformes.

Ce peering multilatéral via route server ne dispense pas de faire du peering privé (PNI, Private Network Interconnect) avec les réseaux dont le volume d'échange justifie une liaison directe hors du fabric public. Le PNI offre un chemin dédié, une bande passante garantie et une visibilité de trafic isolée, utile pour les gros CDN ou les échanges à fort volume avec un partenaire précis. Le peering public via route server reste la porte d'entrée la plus rentable pour tous les autres.

Recevoir des annonces BGP de centaines de réseaux tiers sans filtrage, c'est une surface d'attaque. La bonne pratique, documentée par les opérateurs de FRR comme de BIRD, est de valider chaque préfixe reçu du route server contre les objets IRR et RPKI publiés par l'annonceur, pas de faire une confiance aveugle au filtrage de l'IX. Le choix du démon qui porte cette session, FRR ou BIRD, influence directement la richesse des politiques de filtrage qu'on peut exprimer proprement. Et la validation d'origine par RPKI reste la dernière ligne de défense contre une fuite de préfixe ou un détournement, qu'elle vienne d'un pair direct ou d'ailleurs sur Internet.

Un port de peering n'élimine jamais le besoin de transit. Il l'allège. Aucun réseau ne peer avec l'intégralité d'Internet : la longue traîne des petits AS, les réseaux non présents sur le même IX, tout ce qui n'a pas de relation de peering directe continue de transiter par un fournisseur de transit classique. Un opérateur qui ne garderait aucun transit et miserait tout sur le peering se retrouverait injoignable dès qu'un pair coupe une session ou qu'un préfixe distant n'est simplement pas annoncé sur le fabric.

La bonne architecture combine les deux : du transit dimensionné pour couvrir l'intégralité de la table Internet en secours, et du peering pour absorber le trafic à fort volume vers les réseaux directement joignables sur les IX où l'on est présent. C'est un calcul de rentabilité, pas une bascule tout ou rien.

Un backbone comme AS41652 illustre le principe : présence sur plusieurs IX, d'abord Nine-IX puis France-IX Paris, avec plus de 500 peerings directs établis au fil du temps, sur une capacité totale de 150 Gbps. Ce n'est pas un chiffre de façade, c'est le résultat mécanique de la logique décrite plus haut : chaque nouveau peering établi retire un peu de trafic du transit facturé et raccourcit un peu plus le chemin réseau vers le réseau pair. Le PoP réseau de Paris (TH2) sert justement de point de présence pour cette activité de peering, sans être un site d'hébergement.

La question à se poser n'est pas « faut-il peerer », c'est « avec qui, et à partir de quel volume ». Un port sur un IX a un coût fixe. En dessous d'un certain volume de trafic échangeable avec les réseaux présents sur le fabric, le transit reste plus simple et pas nécessairement plus cher. Le seuil de rentabilité dépend du prix du transit local, du coût du port IX et surtout de la part de trafic qui a une chance réelle d'être captée par du peering, c'est-à-dire les destinations avec lesquelles l'échange est déjà significatif.

L'analyse commence par un traceroute massif sur les principales destinations du trafic sortant, croisé avec la liste des participants publiée sur PeeringDB pour chaque IX candidat. Si une part notable du trafic transite déjà par des AS présents sur un même point d'échange, le port se justifie. Sinon, mieux vaut renégocier le contrat de transit avant d'investir dans une connectivité qui ne servira à rien.

Concevoir une architecture réseau qui combine transit et peering sans dépendre d'un fournisseur unique, avec un chemin de secours propre en cas de coupure d'un pair, c'est un travail qu'on mène en continu sur le backbone qu'on opère. Si votre trafic sortant dépend aujourd'hui d'un seul transitaire, on peut étudier avec vous une stratégie de connectivité réseau plus résiliente.

• RFC 7947, Internet Exchange BGP Route Server (IETF) : spécification du fonctionnement d'un serveur de routes en environnement multilatéral, gestion du NEXT_HOP et de l'AS_PATH.
• Route servers, France-IX : documentation technique du peering multilatéral opéré sur France-IX Paris, filtrage IRR et communautés BGP.
• RIPE NCC, RPKI : documentation officielle sur la validation d'origine BGP par RPKI, appliquée en complément du filtrage IRR d'un IX.
• PeeringDB : base de données publique des réseaux, IX et politiques de peering, référence pour identifier les pairs potentiels sur un point d'échange donné.