Bonsoir Patrick,
Je pense que t'es bien dans la bonne section, mais je laisse les modo/admins en juger et nous déplacer si besoin
L'explication qui suit est une version simplifiée, il y a de nombreuses subtilités que les puristes ici ne manqueront pas de relever.
Il faut voir un IXP comme un swicth réparti (ou non, ça peut juste être un seul switch en fait) sur plusieurs datacenter (ou pas non plus).
Tout ce que tu dois voir en tant que peer ("client" du point d'échange), c'est un Layer 2, avec les adresses MAC de tous les autres peers de l'IXP.
Toute la complexité mise en place par un IXP pour la redondance *entre* les différents équipements où les peers sont connectés (virtualisation du L2 pour permettre sa redondance au travers de MPLS/VPLS/VxLAN/EVPN/Whatever), tu ne la vois pas, tu n'as aucune configuration à faire pour ça.
Ce que le peer doit faire c'est monter des sessions BGP au dessus de cette infrastructure L2, en annonçant ses préfixes (ou pas, selon si tu veux ou non recevoir du trafic) et recevoir des préfixes des autres membres (ou les drop, si tu ne veux pas envoyer de trafic aux autres membres).
Le nombre de sessions à monter pour s'interconnecter en direct avec tous les peers suit l'équation suivante x=(n*n-1)/2 où n est le nombre de peers sur l'IXP, et x le nombre de sessions BGP au total sur l'IXP.
On voit que le nombre de sessions croît énormément, et qu'il est difficilement viable de faire du full-mesh à grande échelle pour tous les membres (mais certains le font tout de même, pour pleins de raisons techniques différentes, et puis bon avec l'automatisation, c'est pas forcément si embêtant).
Pour éviter à tous les membres de devoir monter 99 sessions s'il y a 100 membres sur l'IXP, les gens qui opèrent ces IXP mettent en place des RS. Le but du RS est de redistribuer toutes les routes qui lui sont annoncées par les membres (en applicant ou non du filtrage sur des critères qu'on de détaillera pas ici, parce que y'aura déjà 80% de gens ici qui seront en TL;DR) aux autres membres.
Les RS ne font *que* de la signalisation BGP, ils ne routent pas les paquets entres les membres. Pour se faire, dans les ré-annonces qu'il fait, un RS renvoie un next-hop de route tel que reçu par le membre qui lui a envoyé le préfixe et qui est sélectionné comme étant la meilleure route BGP. L'AS des RS de l'IXP n'est pa ajouté à l'AS_PATH.
Puisque le RS permet cette signalisation, il est généralement doublé (il y a deux RS distinct, ça peut être deux VM sur deux hyperviseurs qui sont sur deux DC différents), afin que la perte de cette seule machine ne cause pas la perte de tout le trafic en cas de problème.
Pour cela donc, les peers montent des sessions avec les deux RS (et c'est donc de l'actif-actif comme redondance, faut pas monter RS2 quand RS1 est down, c'est trop tard), et puisque c'est uniquement de la ré-annonce protocolaire, il n'y a aucun impact en cas de perte d'un RS pour peu que les gens annoncent strictement la même chose aux deux (non, ça n'est pas si évident).
Ça n'est pas du tout antinomique au fait d'avoir des sessions directes avec d'autres membres identifiés comme plus critiques/importants, d'autant que certaines routes ne sont parfois annoncées qu'à travers ces sessions BGP directes (qui ne passent pas par les RS donc).
Du coup, comment les peerings sont établis ? Soit les gens sont déjà sur les RS et c'est automagique (woooaaaaah !), soit ils n'y sont pas et faut leur envoyer des mails ou des missive par coursier équestres (bouuuuuuh). Je troll à peine pour certains acteurs.
Ça dépend de leur politique, de leur humeur, de leurs critères techniques et du nombre de bières (ou tout autre boisson qu'ils affectionnent) que tu as pu leur payer. Personne n'est jamais obligé de peerer avec toi.
Si jamais tu ne connais pas, il y a pas mal de gens sur
https://www.peeringdb.com/ avec des détails.
Les vraies questions que tu dois te poser sont : Pour quel usage je suis sur un IXP ? A quelle panne je veux faire face ?
De manière générale, les gens vont sur les IXP pour les raisons suivantes :
- La qualité de service (faible latence via la régionalisation du trafic, infrastructure globalement très robuste, la gestion par des palmipèdes aux plumes lustrées) ;
- Le coût (possiblement moins cher que du transit, mais ça n'est pas un produit équivalent, un transit te donne accès à tout internet, un IXP à une liste de peer, tu ne peux donc échanger du trafic qu'avec eux, tout un débat) ;
- La possibilité de pouvoir sélectionner les routes envoyées et reçues de manière très fine, littéralement peer par peer, ce qu'un transitaire ne propose pas ;
- Il n'y a personne au milieu pour changer ta décision de routage (là où chez un transitaire, rien ne te garanti que le trafic de va passer que par lui, avec qui tu as un contrat).
A nouveaux, sur les arguments cités plus haut, il y a plein de débats et de cas particuliers, tous les IXP sont différents, avec des typologie de membres qui ne sont pas équivalentes et évoluent.
Comme dit au dessus, tu aura *toujours* besoin d'un transitaire (ou plusieurs), un IXP ne te donnant qu'une vision partielle des routes présentes dans la Default-Free Zone.
Si les raisons pour lesquelles tu es sur IXP sont importantes/interessantes mais pas critiques, tu peux tout à fait décider de ne pas redonder un IXP (c'est le cas de la majorité des membres).
En revanche, certains membres (fournisseurs de contenus, hébergeurs, FAI entreprise) peuvent avoir besoin de garder autant que faire se peut cette qualité de service (parce que du trafic Paris-Paris qui passe par Londres, Madrid ou Francfort c'est cool pour que les paquets voient du pays, mais moins cool pour la latence).
Dans ce cas-là ils ont plusieurs connexions à l'IXP, généralement sur plusieurs points de présence afin de faire face à la plus grande diversité de coupure de service possible (coup de pelleteuse sur multiples fibres vers un PoP, perte électrique complète de la baie de l'IXP au sein d'un datacenter parce que un technicien à débranché la mauvaise voie suite à une maintenance électrique, attaque de castors zombies, upgrade/migration des équipements de l'IXP, palmipède fatigué, hébergement au sein d'un DC ayant des notions de qualité de MMR qui lui sont propre, optique qui décide qu'au bout de 34701364258347 paquets hop, elle fait des FCS tout les 100 paquets (rayez les mentions inutiles)).
En fonction de ce que tu veux éviter tu peux avoir :
- une seule connexion vers l'IX dans un seul DC ;
- deux connexions qui partent de ton routeur et qui vont vers deux routeurs/deux PoP de l'IXP (via des xCo étendus par exemple). Cette option est discutable puisqu'elle implique d'avoir deux IPs de peering sur le même équipement, ce qui n'est pas exactement le cas de plus simple ;
- deux connexions qui partent de deux routeurs du même DC chez toi (dans deux baies d'une même salle), vont sur un seul routeur de l'IXP en face mais via deux MMR ;
- deux connexions qui partent de deux routeurs dans deux DC chez toi pour aller vers deux routeurs de deux PoP de l'IXP (solution la plus redondantes parmi celles présentées ici).
On peut multiplier/mixer les cas, par exemple deux routeurs chez toi (A et B), avec chacun deux liens vers deux routeurs de l'IXP (C et D), pour avoir encore plus de chance d'éviter les aléas du metier (A->C, A->D, B->C, B->D).
On pourrait aussi parler des LAG, mais de la même manière que RAID is NOT backup, LAG is NOT backup (en plus vous savez pas si chez l'IXP c'est sur deux linecard, le même trunk MTP du DC, bref, SPOF-Land).
Arriver avec deux routeurs sur deux PoP c'est super, très propre, mais ça demande de l'argent et des compétences pour avoir un réseau suffisamment bien fait pour répartir/reprendre le trafic quand ça casse. Qu'est-ce qui fait sens pour toi ?
Si tu as deux routeurs, l'IXP va te donner deux IPs différentes (pas de VRRP sur mon LAN de peering, goujat !), et idéalement, toutes les sessions sont doublées sur ces deux IPs pour être à ISO.
BGP choisi comme d'habitude, en fonction de ses critères (
https://www.juniper.net/documentation/us/en/software/junos/vpn-l2/bgp/topics/concept/routing-protocols-address-representation.html ou
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html j'ai pas de religion sur le constructeur qui explique le truc à peu près normalisé, ou si tu as plus de temps
https://www.rfc-editor.org/rfc/rfc4271#section-9.1).
Tu peux jouer avec cette selection (par exemple en annonçant un subset de subnet sur chaque connexion à l'IXP, en annonçant aussi les supernet pour avoir toujours les annonces en cas de perte d'un des liens).
Il y a tout un tas de manière de le faire, plus ou moins propres (on évite de trop désagréger, c'est pas gentil pour la RIB/FIB des autres).
L'IXP peut aussi te permettre de faire de la sélection supplémentaire au travers des RS (je vais mettre l'exemple que je connais vaguement mais il y en a d'autres :
https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS51706&type=aut-num)
Coinrdialement,
PS : Je vois que Hugues à fait une version TL;DR avant même que je poste, terrible ces licornes !
IXP