Cet article est la version initiale, informelle, du GIX Howto qui est publié par Opdop. Vous en trouverez une version au format PDF, plus formelle et plus à jour, sous ce lien

Un point d'échange (GIX = Global Internet Exchange) et un point d'accès (NAP = Network Access Point).

Le premier sert à ce que des opérateurs internet (qui disposent d'un AS et sont disposés à dialoguer en BGP) puissent échanger au plus court, au plus direct et au moins cher du traffic du réseau de l'un vers l'autre. Le second sert à ce que un opérateur qui rassemble les mêmes pré-requis puisse se faire livrer des services via une plate-forme qui ne lui appartienne pas, mais l'autorise.

Les GIX sont parfois des GIX exclusivement, mais ici je vous parlerai plus volontiers de GIX / NAP (même si parfois j'escamote le “NAP” pour faire court, parce que selon l'objectif de développer des infrastructures d'interconnexion, et dans le cas où elles sont indépendantes et donc auto-financées, il n'y a pas de raison (a priori, mais ça peut se produire parfois) de restreindre leur usage à la seule fonction de GIX, en excluant celle de NAP.

A quoi ça sert ? Je l'ai dit au-dessus.

A quoi ça sert pour de vrai ? Ca sert à facilier un peu la vie à des opérateurs.

A qui ça sert ? Pour ce qui m'intéresse, ça sert aux opérateurs qui ne sont pas en situation de se débrouiller facilement tout seuls. Ces opérateurs sont souvent petits, voire embryonnaires, pas très riches, et isolés (parfois même en région). Et dans ces cas-là, ils sont surtout isolés en terme de rapport de poids, par rapport à d'autres opérateurs, rares, et dominants, avec en plus parfois des pratiques un peu anti-concurrentielles. Bref, vulnérables.

En quoi ça sert à un opérateur vulnérable ? Ca lui sert à ne plus être tout seul. Un opérateur petit en région face à des mastodontes qui vendent des services hyper concurrentiels (voire à perte) est confronté à un double problème. Primo il a peu le choix de ses fournisseurs en ce qui concerne ses solutions de connectivité vers le reste du monde, car des gros, sur place, il y en a peu. Secundo, ces fournisseurs qui ne savent ni ne veulent faire un seul métier à la fois, sont aussi ses concurrents.

Et alors, le GIX là-dedans. Le GIX est un point de rendez-vous pour les petits opérateurs du coin. Il va leur permettre d'échanger localement des données entre eux, ce qui sera toujours ça de gagné (en sous, et en qualité) par rapport au trafic qu'ils aureient autrement été obligés de faire transiter par la capitale. Le GIX est aussi un outil de développement local, car il va permettre par exemple en s'interconnectant avec la boite d'à-coté, voire éventuellement via le GIX de pas-trop-loin, de sécuriser des services locaux (des sauvegardes, des sites, des serveurs de jeux, que sais-je…)

Mais encore ? Il y a plus : en agissant comme un point de rendez-vous, le GIX agit aussi comme un concentrateur de richesse, de services, de besoins, de créativité, d'activité liée à internet. Le genre de choses qui attire les prestataires de services, les fournisseurs de services, vendeurs de transit. Plus le GIX se développe, plus il va avoir tendance à attirer ceux qui voudront faire des offres. C'est là qu'entre en jeu la dimension de NAP : permettre la livraison de services venus de loin aux opérateurs locaux, c'est permettre aux services de venir aux opérateurs.

Je résume, développer un GIX / NAP local, c'est

• favoriser les échanges et le développement local
• économiser et améliorer le trafic local et régional
• rompre l'isolation des petits opérateurs locaux
• rendre le local attractif

C'est faire venir le réseau en région, au lieu de continuer à faire converger les petits opérateurs vers la capitale.

Globalement donc, c'est favoriser le maillage d'internet sur le territoire, au lieu de le faire se développer en étoile vers un seul point de concentration au seul profit des opérateurs dominants.

Au-delà des idées générales ci-dessus, voyons un peu plus en détail quels opérateurs seront intéressés par un GIX local.

Les premiers et les plus sincères seront les opérateurs locaux, qui ne comprendront pourtant pas forcément les avantages d'un GIX de prime abord, parce qu'ils n'auront pas connaissance de ce que c'est, techniquement, un opérateur IP, et de ce que ça implique pour eux.

Il faudra donc peut-être le leur expliquer, voire les former. Et les accompagner pour cette transition, et faire de leur réseau passif un réseau actif d'opérateur (avec des routeurs notamment), avec un numéro de système autonome (un numéro d'AS), avec des adresses IP indépendantes, éventuellement, et s'appuyer pour cela sur un LIR qui sache conseiller et accompagner, ou participer à un LIR coopératif.

Car souvent les sociétés locales sont clientes d'un opérateur national dominant ou d'une multinationale, qui les tiennent captives sur des adresses IP ne leur appartenant pas, liées à un contrat de fourniture d'autres services (transit, hébergement, liaison, collecte) et bien entendu, se sont bien passées de leur expliquer l'intérêt de devenir des systèmes autonomes pour pouvoir s'affranchir de leur unique fournisseur.

Mais ce sont les petites structures les plus dynamiques, mêmes si avec des statuts différents (associatifs ou sociétés) ils peuvent avoir des visions très différentes, ils ont en commun le besoin de se développer localement et de voir la diversité et les opportunités se développer là oùils sont. Beaucoup plus souples, ils peuvent aussi s'adapter plus facilement : les décisions se prennent plus vite, plus efficacement, les strates administratives et procédurales ne sont pas un barrage.

C'est en fait une classe assez dépeuplée, les opérateurs moyens sont des grosses entreprises qui n'ont pas fait leur business sur des activités IP, ou bien elles l'auraient fait à Paris.

Leur activité est industrielle ou tertiaire, et leur usage de réseaux est essentiellement interne, avec de grosses contraintes (de gros enjeux) parce que la totalité de leur activité repose sur le fonctionnement de ces réseaux, qui ne sont pas leur activité, mais qui leur sont vitaux. Elles sont donc prêtes à y mettre les moyens, et l'ont déjà fait. Elle sont clients de solutions clé en main, auprès des opérateurs dominants, elles sous-traitent bien souvent la compétence (et donc les vraies décisions) en ce domaine.

En plus de ça, leur trafic externe est minime car leur business n'a rien à voir avec internet : ce ne sont pas des fournisseurs de contenus, ni des fournisseurs d'accès en général, et donc l'échance de trafic avec des tiers n'est pas un enjeu majeur pour elles, et encore moins un enjeu qui jusitfie qu'elles remettent en cause une seule seconde leur réseau mal ficelé, leur contrat gold leurs infra gérée par telle société de service, etc.

Bon courage pour les attirer sur un point d'échange donc, qui sera vu comme peu fiable, inutile pour leur besoin, voire un risque pour leur stabilité et leur sécurité. Leurs prestataires qui tiennent à les garder captifs leur déconseilleront catégoriquement pour préserver leur poule aux oeufs d'or. Les banques, les gros distributeurs, les industriels sont dans celle classe d'opérateurs moyens, mais pour ainsi dire hors du net.

Il existe tout de même quelques sociétés qui se sont développés dans le domaine de d'accès à internet souvent, ou de l'hébergement. Celles-là auront des exigences assez fortes, mais aussi de l'expertise à apporter. Difficile de se tenir à la bonne distance, car la nécessité de se rassurer les poussera souvent à vouloir tout contrôler. Leur bonne volonté, leur compétence et leur capacité de financement pourra être très utile dans les phases de conception technique, pour financer le superflu (mais surtout pas le nécessaire) ce qui leur permettra aussi de se rassurer, pour prendre part aux astreintes du support, pour avoir un peu plus de trésorerie en fonds de roulement, etc.

Les gros opérateurs ne sont pas très contents qu'un point d'échange local se monte, parce que ce truc est clairement en train de piétiner leurs plates-bandes et de permettre à n'importe qui de faire les yeux doux à leurs clients. Il ne faut donc pas s'attendre à une réaction constructive d'un Foxtrott Tango, qui y verrait une formidable occasion d'échanger son trafic local avec Sierra Foxtrott Roméo ou Bravo Tango dans l'intérêt du consommateur.

N'y comptez pas. Il existe une autre raison, au refus des gros : leur traffic est leur business, il est hors de question de faire passer leurs interconnexions avec d'autres opérateurs sur des infrastructures qu'ils ne maitrisent pas. C'est un risque à ne pas prendre. Les interconnexions importantes sont gérées via des peerings privés, via des liaisons privées, prétendument maitrisées (il suffit de surveiller un peu le trafic entre certains gros opérateurs pour voir à quel point de prétexte peut facilement passer derrière certains enjeux financiers, les consommateurs étant alors pris en otage).

Toujours plus fort : peerer avec les gros, c'est une affaire privée (donc pas sur un GIX public), peerer avec les petits, ça ne vaut pas le coup. C'est même un non-sens. Parce que maintenir des centaines de sessions de peering avec des centaines d'opérateurs microscopiques, c'est juste perdre son temps. La bonne manière de faire, c'est de leur refuser le peering, et de leur proposer soit d'acheter du transit, soit d'acheter du peering privé. Un peer refusé, c'est un client potentiel, ne l'oublions pas.

Donc autant s'y faire tout de suite : les gros opérateurs ne peerent pas. Ils peuvent éventuellement être présents sur des GIX, pour des raisons politiques notamment. Mais leur présence n'aidera pas les petits opérateurs.

C'est un switch (un commutateur réseau).

Tout ce qu'on lui demande à priori, c'est de commuter les packets.

Mais aussi de gérer les aspects topologie du réseau de manière à les rendre transparents.

La première chose pour créer un GIX / NAP est de rassembler quelques bonnes volontés pour se lancer dans l'aventure.

Comme on le verra plus loin, le budget d'un GIX n'est pas forcément monstrueux. Inutile de s'en faire une montagne, de chercher des financements gigantesques et cinquante participants avant de démarrer. Peerer, ça demande d'être deux, et très peu de matériel.

Ce qui est nécessaire dès le début, c'est de définir les règles de fonctionnement et la politique du GIX.

Le GIX est un outil commun, que vont utiliser des membres. Il doit leur offrir un service qui est simplement celui d'une interconnexion de niveau 2 (ethernet), et plus il évitera de se mêler du reste, plus sa mission sera claire et bien délimitée, plus elle sera pérenne, et efficace. La première chose est donc de définir quelle entité sera en charge de sa gestion, quelles seront ses missions, et quelles missions ne seront pas les siennes.

C'est le moment de résumer la fonction de GIX, et de choisir de l'ouvrir ou non aux échanges de nature commerciale entre les participants (donc d'en faire aussi un NAP).

C'est le moment de réfléchir à créer une association qui sera en charge de ce GIX, de décider comment on en deviendra membre, comment les membres contribueront, décideront de tout ce qui a trait au fonctionnement de la structure légale, mais aussi de la vie de la structure technique.

L'indépendance est un enjeu fort sur un GIX. Les expériences du FreeIX et du Panap à Paris, on démontré que un opérateur IP qui monte un GIX pour satisfaire à ses propres intérêts peut très bien cesser de s'en occuper plus ou moins franchement, et finalement le liquider seulement quelques années après. Les autres opérateurs ne doivent pas dépendre de telles lubies, ni des intérêts de l'un d'entre eux en particulier. L'Equinix Exchange est un autre exemple français de GIX mal indépendant, car cette activité du groupe est concue comme un instrument commercial (destiné à accroitre l'intérêt du datacenter qui le maintient) et non pas comme ayant une réelle finalité de service.

Ces projets non (ou mal) indépendants se reconnaissent facilement : ils sont gratuits pour les membres, et les membres n'y décident rien.

Ces exemples sont donc à éviter pour contruire un GIX pérenne, et une strucutre simple, légère, spécialisée, avec des rêgles simples et claires apportera beaucoup plus de stabilité dans le temps.

Une conséquence est que le GIX doit être capable de s'auto-financer en trouvant le bon équilibre entre qualité de service et coût. Le GIX étant toutefois un service utile et motivant, et à la fois d'une grande simplicité, cette équation est à priori soluble.

Les attentes à la neutralité peuvent sembler assez rares sur un GIX. Mais on peut notamment citer les problématiques de neutralité du réseau (priorisation, etc.) mais aussi confidentialité, respect des libertés individuelles etc. Il est donc souhaitable pour la tranquilité de tous que la transparence soit de mise, et notamment que l'équipement du GIX ne soit pas “prêté” ou partagé par l'un des opérateurs membres, mais dédié au projet.

S'agissant d'un NAP, plus de problèmes sont bien entendu à craindre, puisque des enjeux financiers interviennent.

En tout état de cause, la neutralité du GIX / NAP doit faire partie des objectifs du projet, et il n'est pas concevable de faire confiance à un opérateur IP pour rendre le services à ceux qui sont tantôt ses partenaires, tantôt ses clients, tantôt ses concurrents.

Le prix dépendra des coûts engagés. Pour répondre aux objectifs d'indépendance et de neutralité (que je qualifierais de prioritaires), il faut les répartir équitablement, et de manière à couvrir les coûts de fonctionnement (évidemment).

Tout est imaginable, et on peut répartir les prix à loisir :

• cotisation en tant que membre
• frais d'installation et frais récurrents en fonction de la taille du port souscrit
• mesure précise de l'utilisation du réseau
• tarification en fonction de la taille du CA de l'opérateur
• un mix de tout ça…

Evidement plus le mix tarifaire est complexe, plus la facturation le sera aussi, avec en plus des risques de complexifier inutilement des développement utltérieurs, par exemple

• une implantation sur un autre site, avec donc une infra plus complexe et plus coûteuse
• une interconnexion avec un autre GIX
• lors d'un recours à des équipements plus gros (et coûteux)

Quelques notions qui peuvent jouer :

• être adhérent, payer une cotisation annuelle, c'est à la portée de tout le monde et ça peut correspondre aux frais de fonctionnement immuables et invariables de la structure (banque, assurance, papeterie, correspondance, assemblées)
• pour un petit opérateur qui passe 10 Mbps, payer 100 ou 1000 ne fait pas forcément sens
• le prix du transit à tendance à fondre (pas forcément en province), les prix du peering n'ont pas forcément besoin de faire la même chose, car l'aspect financier n'est pas le seul à entrer en jeu

Un GIX n'est, comme indiqué, qu'une infrastructure de niveau 2 (ethernet) par laquelle vont échanger (on dit “peerer”, prononcer “piré”) les opérateurs (membres) raccordés. Chacun avec une adresse IP, dans une même zone de broadcast (un même subnet), ils vont échanger deux à deux, en toute liberté.

C'est donc très simple à mettre en oeuvre et pour être complets on peut dire qu'on a besoin

• d'un lieu sur lequel les opérateurs puissent faire arriver une extrémité de leur réseau, pour se raccorder (en général, un datacenter—ou un netcentre—relativement neutre, i.e. qui ne viendra pas s'en mêler)
• sur ce lieu, d'un espace d'hébergement, qui permettre essentiellement
  • d'accueillir le switch
  • éventuellement son petit frère, s'il est pertinent et possible d'avoir du spare au même endroit
  • la possibilité de faire arriver les liaisons des futurs membres du GIX
  • un peu de place pour brasser, laisser un tournevis, des optiques ou des câbles
  • un tiroir fibre (à vous de voir selon les modalités de brassage propres au site)
  • un passe-câble
• le switch
• son petit frère

Le dimensionnement du switch est à votre convenance, il est bien clair qu'on a pas besoin d'un chassis de 10u qui requiert 1 kVA pour commuter des traffics comme on en verra sur un GIX local au début de son existence. Tous les switches un peu modernes, tant qu'on ne leur demande que de commuter des paquets (ce qui sera le cas sur un GIX) feront ça très correctement, en hardware. Autant se diriger vers des équipements “top-of-rack” car leur vocation n'est pas non plus d'allumer des fibres pour faire de la longue distance.

Ceci permettra de rester dans un budget, un encombrement physique, et un besoin de puissance raisonnables.

Pour creuser un peu la question du switch, on peut tout de même évoquer les aspects suivants.

• ce doit être un switch gigabit, adapté au site notamment pour ce qui est de ses interfaces : inutile de mettre un 24 ports cuivre + 4 sfp sur un site dans lequel tous les raccordements se font en fibre
• s'il est prévu d'avoir des membres raccordés en FastEthernet, le cuivre pourra être requis, car les interfaces SFP ou GBIC ne le supportent pas toujours, une solution relativement simple peut alors être de prévoir un second switch, avec des ports cuivre, et un uplink vers le switch principal qui lui, sera full gigabit
• le réseau d'un petit GIX a beau être simple, il faut maitriser la topologie, les MAC et les risques liés aux boucles et aux broadcasts, ça veut dire filtrer correctement les BPDU en entrée/sortie, filtrer les MAC par port, envisager d'activer la détection de boucle, réfléchir à fixer des seuils sur les paquets en broadcast
• le support du 802.1q ne fait plus tellement question sur les switches professionnels
• les fonctionnalités comme RMON et SNMP bien pratiques pour lever des alertes, surveiller des seuils, relever des compteurs
• si votre GIX comprend plusieurs équipements, la gestion de la topologie va se réléver une problématique cruciale et des protocoles plus efficaces et réactifs que spanning-tree s'inviteront rapidement

Plutôt que de faire doublons je vous renvoie vers la traduction des « Best Current Operational Pratices » (Bonne pratiques) pour la gestions des points d'échange publics, que j'ai traduite et placée en dernière partie de ce HOWTO.

Il y a très peu de travail à faire sur un GIX, une fois la mise en place initiale. Mais le GIX reste une infrastructure réseau essentielle, un concentrateur de trafic, et donc aussi un point de vulnérabilité important. Il est important qu'au moins un technicien soit à même d'intervenir sur place dans un délai raisonnable, et à ce niveau tout est permis, y compris la sous-traitance de la maintenance d'urgence à l'un des membres.

Pour ce qui est de la mise en place, les tâches sont assez variables et peuvent se répartir

Créer, déclarer la structure. Obtenir des ressources IP du Ripe ou d'un LIR (ce ne sont pas des ressources critiques, elles n'ont pas forcément besoin d'être annoncées sur internet, et il sera un peu pénible mais faisable de renuméroter en cas de besoin).

Gérer le secrétariat.

Ouvrir un compte en banque, gérer la facturation (les prélèvements, les relances) la comptabilité.

Les installations techniques physiques sont peu complexes, l'affaire d'un ou deux jours au maximum pour installer les équipements et accessoires.

Le développement d'une base informatisée pour la gestion des membres, des statistiques d'utilisation si besoin, de l'assignation des ports et des adresses, et les interfaces de commande, listing des membres, outils de gestion, monitoring, alertes, looking-glass… Tout ça peut prendre du temps, mais aussi se faire sur la durée.

Il est aussi possible de s'appuyer sur des développements qui ont déjà été faits par d'autres, comme le FR-IX.

Je l'ai dit plus haut, pas besoin d'attendre de réunir tout le monde. L'expérience montre que le plus difficile est de se lancer. Car d'autres peuvent rejoindre la barque une fois qu'elle est lancée, il est donc essentiel d'avoir bien réfléchi le projet afin qu'il soit accueillant et ouvert au plus grand nombre.

Dans une association il faut parfois bien réfléchir aux nécessités un peu opposées de se garantir contre la survenue massive de nouveaux adhérents pas forcément en phase avec la visée initiale (entrisme), et la trop grande rigueur qui rend le collectif inaccessible.

Le premier risque peut être limité grâce à l'esprit du contrat associatif : c'est une convention entre les parties, donc un contrat, en vue de poursuivre un objectif. Celui-ci doit être bien cadré dans les statuts. On peut aussi faire appel à une charte, qui definira les usages admis et ceux qui ne le sont pas tant sur le plan technique (et c'est l'occasion de bannir le spam, les protocoles bizarres, les équipements qui fonctionnent mal et vont poser des problèmes à tout le monde, etc.), qu'eu égard à la destination du GIX.

A titre d'exemple vous pouvez trouver ici la convention proposée par FR-IX.

Le peering à distant (remote peering) consiste à avoir recours à des liaisons de transport de niveau 2 pour se raccorder à des GIX distants, au lieu de liaisons locales (donc physiques, dites « layer-1 »).

Ce mode de raccordement permet à beaucoup plus de participants de rejoindre le point d'échange sans avoir à faire des investissements lourds pour étendre leur réseau jusqu'au pied du GIX pour s'y relier. C'est donc un levier intéressant pour développer la fréquentation du GIX et donc au bénéfice de tout le monde sur cet aspect.

Il y a pourtant de nombreux inconvénients, qui ne sont pas sans impact sur la qualité et la stabilité du GIX, et ceci explique que les raccordements de ce type ne sont pas toujours autorisés.

Parmi ces désagréments on trouve en particulier : les risques d'instabilités accrus du fait d'un lien L2 (actif), la plus longue durée requise pour repérer la chutte d'une liaison en L2 par rapport au L1 et donc l'impact de cette durée sur la quantité de trafic perdu, les risques d'interférence de la topologie L2 du switch par le L2 qui sert à transporter le participant distant. Tous ces risques sont proportionnels au nombre de participants ainsi raccordés et dégradent globalement la qualité du GIX.

Il convient bien évidement de considérer aussi l'accroissement de la latence qui vient en directe contradiction avec la qualité résultant d'une proximité physique que viennent chercher les membres locaux.

Autoriser ou non le remote peering est donc un compromis à faire entre la qualité et la volonté d'ouvrir le GIX à davantage de peers. On peut aussi envisager des solutions comme le recours à des VLANs différents : l'un autorisé et l'autre non au remote peering, avec des route serveurs différents, et les membres peuvent ainsi choisir.

Monter un GIX local c'est bien. Mais on peut pousser le raisonnement en développant des GIX et en développant entre eux des interconnexions. Raccorder des GIX voisins permettra en effet de doubler virtuellement les effectifs de chaque GIX (s'ils sont de même taille) tout en conservant la plupart des avantages d'un GIX local (trajet plus court, bas coût, efficacité) tout en multipliant les possibilités de développement des opérateurs participants.

Un modèle standard d'interconnexion est développé sous le nom de Dual GIX, comme une sorte de domino, brique de base constitué de deux GIX qui cofinancent à égalité un lien pour se raccorder l'un à l'autre. La famille de GIX FR-IX tend à encourager le développement de GIX qui suivent ces recommandations, et s'interconnectent avec eux sur ce modèle.

• Source : http://www.ipbcop.org/
• Auteurs : Michaël Smith, Florian Hibler
• Date : 8 octobre 2011
• Statut : draft
• Titre original : Public Peering Exchange Configuration best current operations practices
• Traduction : Sylvain Vallerot

Ce document passe en revue les différentes composantes qui tendent à instaurer de bonnes pratiques pour la gestion et le raccordement à des points d'échanges. Il indique des principes de configuration et de paramétrage, mais pas d'information liée à des équipements en particulier.

Il y a une multitude de points d'échanges dans le monde, qui sont utilisés pour fournir à des opérateurs une infrastructure mutualisée afin de leur permettre de s'interconnecter et d'échanger du trafic. Bien qu'il puisse y avoir des spécificités propres à chaque point d'échange, il y a aussi des éléments de configuration communs qui, s'ils sont mis en œuvre, contribueront à la stabilité du service.

Ce document décrit les grandes lignes qui devraient s'appliquer dans la plupart des situations, proposant ainsi une base pour les spécifications de points d''échanges mais ne prévalant pas sur elles. Les règles spécifiques à chaque point d'échange doivent être respectées même lorsqu'elles sont contraires aux recommandations faites ici.

Ce document est divisé en quatre sections.

• recommandations physiques
• recommandations pour les couches OSI 1 et 2
• recommandations pour la couche transport
• autres recommandations

Ce document utilise les définitions ou conventions de nommage suivantes.

• GIX - terme générique utilisé pour désigner un point d'échange, un point d'accès au réseau (NAP), etc.
• participant(s) - terme générique utilisé pour désigner une ou des entités se raccordant à un GIX

Section 1

Autant que possible chaque participant devrait se raccorder sur l'équipement de commutation du GIX au moyen d'une interface de niveau 3.

Une connection directe permet de minimiser les risques d'apparition de trames de broacast inattendues ou de tout autre type de trafic indésirable et provenant d'un autre réseau de niveau 2.

En particulier, les connections de switch à switch entre GIX et participant devraient être évitées. Le risque de problèmes pouvant avoir un impact sur l'ensemble de l'infrastructure de commutation et sur les participants est considérablement plus élevé du fait de problèmes liés au niveau 2 qu'avec des connections directes.

Dans cette situation, le participant ne se raccorde pas physiquement directement au GIX, car il n'a pas d'équipement sur place ou à proximité. Ce choix est généralement motivé par une recherche d'économie. Le transport s'effectue en général par MPLS via des opérateurs agréés par le GIX. Ces opérateurs de transport doivent s'assurer de leur compatibilité avec le réseau du GIX (la plupart des pré-requis sont indiqués dans la section 2).

Certains GIX prévoient des ports pour les revendeurs (avec des offres de peering à distance). Un opérateur de transport agréé se raccorde alors au GIX et revend des connexions en utilisant ce raccordement. La revente peremt à des participants de devenir membres du GIX au travers de l'opérateur de transport, sans avoir besoin de payer directement pour un raccordement sur le GIX.

Par exemple si le transporteur se raccorde au GIX avec un port 10G, il peut revendre 10 fois 1G, ou 100 fois 100 Mbps, ou 1000 fois 10 Mbps à des participants potentiels. Toutefois le port 10G ne doit pas être sur-souscrit.

Lors de la première connection à un GIX, il est recommandé de prendre note des caractéristiques observées afin de pouvoir s'y référer si plus tard des problèmes apparaissent. En particulier la qualité du lien devrait être vérifiée et consignée.

Les puissances d'émissions et de réception devraient être relevées au moyen d'un puissance mètre optique, et consignées. Toute mesure suspecte devrait donner lieu à des réparations avant que du trafic soit envoyé sur cette liaison.

Des tests de continuité devraient être conduits et leurs résultats consignés. Comme pour la fibre, toute mesure suspecte devrait donner lieu à des réparations avant que du trafic soit envoyé sur cette liaison.

Une fois le raccordement fait, les compteurs devraient être consultés pour repérer d'éventuelles anomalies. En particulier on ne devrait pas observer d'erreurs (CRC, Framing, Input, Ouput, Drops, etc.) sans quoi des mesures curatives devraient être mises en œuvre avant d'utiliser la liaison.

Tous les éléments de connectique devraient être étiquetés pour une identification aisée, en utilisant des règles de nommage standardisées. Ceci concerne les câbles fibre et cuivre, les patch panels, les interfaces et les équipements raccordés.

Une bonne documentation des configurations sera d'une valeur inestimable en cas de problème ou pour une transmission de compétence. Elle devrait inclure :

• une définition segment par segment de chaque circuit : chaque point de raccordement entre une interface et le GIX devrait être répertoriée avec les didentifications utilisées sur l'étiquetage

• une liste des prestataires, intervenants ou fournisseurs impliqués dans la couche physique : avec au strict minimum un contact ou une liste de contacts doit figurer dans la documentation, si plusieurs opérateurs fournissent des services au GIX ces informations doivent apparaître popur chacun et être associées aux éléments qu'ils fournissent dans l'infrastructure.

Section 2

Il convient de veiller à ce que les bons masques de réseau soient utilisés sur les interfaces. Il n'est pas sûr de supposer que tous les GIX utilisent des préfixes de taille identique.

Les trames échangées sur les GIX ont habituellement les types suivants.

• 0x0800 - IPv4
• 0x0806 - ARP
• 0x86dd - IPv6

Les protocoles fonctionnant en broadcast ou pas en IP doivent être désactivés sur les interfaces raccordées au GIX, ou filtrées d'une manière ou d'une autres lorsque la désactivation n'est pas possible. Ceci concerne (mais sans se réduire à cette liste) les trames DHCP, MOP, Ethernet Keepalive, NetBIOS et les annonces RA IPv6.

Tous les protocoles dynamiques d'exploration (CDP, FDP, etc.) doivent être désactivés sur les interfaces raccordées au GIX.

Les redirections doivent être inhibées sur les interfaces reliées au GIX.

Doit être également désactivé sur les interfaces reliées au GIX.

Les protocoles de proxy, tels que Proxy ARP et IPV6 Proxy Neighbor Discovery, doivent être désactivés.

Dans une configuration de switch à switch, sauf spécification inverse, les protocoles de spanning tree doivent être désactivés sur les interfaces reliées au GIX. En cas d'impossibilité tout le traffic doit être filtré au niveau de l'interface.

Les IGP ne doivent pas apparaitre sur l'interface reliée au GIX.

La plupart des GIX sont très vigilants sur le nombre de MACs autorisées sur une connection. Habituellement une seule MAC est autorisée. Si le participant a un équipement intermédiaire, il doit s'assurer que celui-ci est parfaitement silencieux et n'introduit pas de trames indésirables (comme décrit précédemment). Ceci pourrait provoquer un déclenchement du mécanisme de sécurisation du port par lequel le participant est raccordé.

Section 3

Les participants ne doivent pas annoncer le réseau qui sert pour l'interconnexion sur le GIX en BGP.

Les participants ne doivent pas configurer à l'avance des sessions BGP avec d'autres participants, tant que tous les deux ne sont pas prêts.

Un participant devrait mettre en place des règles de maximum prefix count, ou des filtres sur les annonces de ses pairs à chaque fois que cela est possible.

Lorsqu'un GIX propose un service de Route Serveur et que le participant a une politique de peering ouverte, il devrait faire usage de ce service afin de pouvoir en récupérer le plus grand nombre d'adresses possible avec un minimum d'efforts. Il est également important si beaucoup de trafic est échangé ou si la session de peering revêt une importance particulière, d'établir des sessions de peering directes.

Le centre des opérations du participant devrait être conscient de l'existance d'une liste d'échange pour les participants du GIX et y être inscrit. L'adresse utilisée pour cette souscription ne peut pas être reliée à un système de gestion de ticket ni donner lieu à des réponses automatiques.

Si un participant quitte le GIX, les autres participants doivent déconfigurer leurs sessions avec lui au plus vite, afin de réduire le trafic ARP sur le GIX.

Section 4

Il n'y a pas beaucoup de mesures disponibles pour affermir la sécurité des connections entre les participants, compte tenu de ce que les sessions sont réalisées bilatéralement entre eux à travers le GIX, on peut proposer mais pas forcément recommander telle ou telle méthode.

• MD5 : les participants peuvent utiliser MD5 pour authentifier leur session BGP,
• Liste d'accès MAC : un participant peut utiliser des ACL sur les adresses MAC pour vérifier que ses pairs établissent des sessions à partir de sources connues. Cependant ces ACL peuvent poser des difficultés,
• Liste d'accès sur les IP : un participant peut utiliser des ACL pour limiter les peers autorisés à établir des sessions BGP en filtrant sur leur IP,
• GSTM (Genralized TTL Security Mechanism, RFC 5082) : les participants devraient utiliser GSTM sur leurs routeurs à chaque fois que c'est possible
• les plus récents mécanismes de sécurisation de BGP ne sont pas traités dans cette version du document

«Soyez restrictifs dans ce que vous émettez et ouverts sur ce que vous recevez» : Eu égard à l'extrème sensibilité d'une infrastructure qui raccorde une multitude de participants sur une seule et même plate-forme de niveau 2, il serait utile de corriger cet adage en «Soyez restrictifs dans ce que vous envoyez et recevez».

Un réseau de niveau 2 est certainement la manière la moins coûteuse et la plus simple pour permettre l'interconnection de multiples réseaux via une plate-forme commune, mais c'est aussi la plus vulnérable à des erreurs qui peuvent se produire pour ainsi dire n'importe où.

Il est dans l'intérêt de tous les participants et des opérateurs du GIX de limiter le trafic parasite sur cette plate-forme dans le but d'en améliorer la stabilité. Idéalement seules des interfaces de niveau 3 devraient être connectées à l'équipement de commutation, et les routeurs raccordés ne laisseraient jamais passer de protocoles indésirables. Mais en réalité il existe de telles disparités entre les équipements, et bien souvent même entre les versions logicielles et les fonctionnalités d'un même équipement, que chacune de présentes recommandations doit être adaptée au cas par cas.