Point d'échange de trafic : des origines à la création de votre propre IX

« Nous avons établi une liaison téléphonique entre nous et les gars du SRI... », a déclaré Kleinrock... dans une interview :
« Nous avons tapé le L et nous avons demandé au téléphone : « Vous voyez le L ? »
« Oui, nous voyons le L », fut la réponse.
« Nous avons tapé le O et nous avons demandé : « Voyez-vous le O ? » »
« Oui, nous voyons le O. »
« Ensuite, nous avons tapé le G, et le système a planté »...

Et pourtant, une révolution avait commencé…

Le début d'Internet.

Bonjour à tous!

Je m'appelle Alexander et je suis ingénieur réseau chez Linxdatacenter. Dans l'article d'aujourd'hui, je parlerai des points d'échange Internet (IXP) : leurs origines, les tâches qu'ils accomplissent et leur conception. Je vous montrerai également le fonctionnement d'un IXP grâce à la plateforme EVE-NG et au routeur logiciel BIRD, afin que vous puissiez comprendre son fonctionnement interne.

Un peu d'histoire

Si vous regardez ici, on constate que la croissance rapide du nombre de points d'échange de trafic a débuté en 1993. Cela s'explique par le fait que la majeure partie du trafic des opérateurs télécoms de l'époque transitait par le réseau dorsal américain. Par exemple, lorsque le trafic passait d'un opérateur français à un opérateur allemand, il allait d'abord de la France vers les États-Unis, puis seulement des États-Unis vers l'Allemagne. Le réseau dorsal servait alors de point de transit entre la France et l'Allemagne. Même le trafic intra-pays transitait souvent indirectement, via les réseaux dorsaux des opérateurs américains.

Cette situation a eu des répercussions non seulement sur le coût de l'acheminement du trafic de transit, mais aussi sur la qualité des canaux et la latence. Le nombre d'utilisateurs d'Internet augmentait, de nouveaux opérateurs émergeaient, le volume de trafic augmentait et Internet gagnait en maturité. Les opérateurs du monde entier ont commencé à comprendre la nécessité d'une approche plus rationnelle de l'organisation des interactions entre opérateurs. « Pourquoi devrais-je, en tant qu'opérateur A, payer pour transiter par un autre pays afin d'acheminer du trafic vers l'opérateur B, situé juste en face ? » C'était en gros la question que se posaient les opérateurs de télécommunications à l'époque. Ainsi, des points d'échange de trafic ont commencé à apparaître dans diverses régions du monde, là où les opérateurs étaient concentrés :

• 1994 – LINX à Londres,
• 1995 – DE-CIX à Francfort,
• 1995 – MSK-IX, à Moscou, etc.

Internet et le présent

Conceptuellement, l’architecture de l’Internet moderne est un ensemble de systèmes autonomes (AS) et un ensemble de connexions entre eux, à la fois physiques et logiques, qui déterminent le chemin du trafic d’un AS à un autre.

Les AS incluent généralement les opérateurs télécoms, les fournisseurs d'accès à Internet, les CDN, les centres de données et les grandes entreprises. Ils établissent généralement des relations d'appairage logique entre eux grâce au protocole BGP (Border Gateway Protocol).

La manière dont les systèmes autonomes organisent ces connexions est déterminée par un certain nombre de facteurs :

• géographique,
• économique,
• politique,
• accords et intérêts communs entre les propriétaires d'AS,
• etc.

Bien sûr, ce système présente une certaine structure et une certaine hiérarchie. Les opérateurs sont répartis en trois catégories : Tier 1, Tier 2 et Tier 3. Alors que les clients d'un fournisseur d'accès Internet local (Tier 3) sont généralement des utilisateurs ordinaires, les clients des opérateurs de Tier 1 sont, par exemple, d'autres opérateurs. Les opérateurs de Tier 3 agrègent le trafic de leurs abonnés, les opérateurs de Tier 2 agrègent à leur tour le trafic des opérateurs de Tier 3, et les opérateurs de Tier 1 agrègent l'ensemble du trafic Internet.

Schématiquement, cela peut être représenté ainsi :

Cette image montre que le trafic est agrégé de bas en haut, c'est-à-dire des utilisateurs finaux aux opérateurs de niveau 1. Il existe également un échange de trafic horizontal entre des AS d'importance à peu près égale.

Un élément essentiel et, en même temps, un inconvénient de ce système réside dans la nature quelque peu désorganisée des connexions entre les systèmes autonomes situés à proximité de l'utilisateur final au sein d'une même zone géographique. Considérez l'image ci-dessous :

Supposons que dans une grande ville il y ait 5 opérateurs de télécommunications, entre lesquels le peering, pour une raison ou une autre, est organisé comme indiqué ci-dessus.

Si l'utilisateur Petya, connecté au fournisseur d'accès Internet Go, souhaite accéder à un serveur connecté au fournisseur ASM, le trafic entre eux devra transiter par cinq systèmes autonomes. Cela augmente la latence, car le nombre de périphériques réseau par lesquels le trafic doit transiter augmente, tout comme le volume de trafic transitant sur les systèmes autonomes entre Go et ASM.

Comment réduire le nombre de points d'échange de trafic que le trafic doit traverser ? La solution est un point d'échange de trafic.

Aujourd’hui, l’émergence de nouveaux IXP est motivée par les mêmes besoins qu’au début des années 90 et 2000, mais à une échelle plus réduite, en réponse au nombre croissant d’opérateurs télécoms, d’utilisateurs et de trafic, et à la quantité croissante de contenu généré par les réseaux CDN et les centres de données.

Qu'est-ce qu'un point d'échange de trafic ?

Un point d'échange de trafic (TIP) est un emplacement doté d'une infrastructure réseau dédiée où les parties intéressées par l'échange de trafic établissent des relations d'appairage. Les principaux acteurs des TIP sont les opérateurs télécoms, les fournisseurs d'accès à Internet, les fournisseurs de contenu et les centres de données. Les parties se connectent directement entre elles grâce à ces TIP. Cela permet d'accomplir les tâches suivantes :

• réduire la latence,
• réduire le volume du trafic de transit,
• optimiser le routage entre AS.

Étant donné que les IXP sont présents dans de nombreuses grandes villes du monde, cela a un effet positif sur Internet dans son ensemble.

Si nous résolvons la situation décrite ci-dessus avec Petya en utilisant IXP, cela ressemblera à ceci :

Comment fonctionne un point d'échange de trafic ?

En règle générale, un IXP est un AS distinct avec son propre bloc d’adresses IPv4/IPv6 publiques.

Un réseau IXP est généralement constitué d'un seul domaine de couche 2. Il s'agit parfois simplement d'un VLAN contenant tous les clients IXP. Cependant, pour les IXP plus importants et géographiquement dispersés, des technologies telles que MPLS, VXLAN et autres peuvent être utilisées pour organiser le domaine de couche 2.

Éléments IXP

• SKS. Il n'y a rien d'inhabituel ici : racks, croix optiques, panneaux de brassage.
• Commutateurs – la base d'un IXP. Un port de commutation constitue le point d'entrée du réseau IXP. Les commutateurs assurent également des fonctions de sécurité, filtrant le trafic indésirable qui ne devrait pas être présent sur le réseau IXP. Les commutateurs sont généralement sélectionnés en fonction d'exigences fonctionnelles, telles que la fiabilité, les débits de port pris en charge, les fonctionnalités de sécurité, la prise en charge de sFlow, etc.
• Serveur de routage (RS) Un RS est un composant essentiel et indispensable de tout point d'échange de trafic moderne. Son principe de fonctionnement est très similaire à celui d'un réflecteur de route dans iBGP ou d'un routeur désigné dans OSPF, et il résout les mêmes problèmes. À mesure que le nombre de participants au point d'échange de trafic augmente, le nombre de sessions BGP que chaque participant doit prendre en charge augmente, ressemblant à une topologie en maillage complet classique dans iBGP. RS résout ce problème de la manière suivante : il établit une session BGP avec chaque participant IXP intéressé, et ce participant devient un client RS. Dès réception d'une mise à jour BGP de l'un de ses clients, RS la distribue à tous ses autres clients, à l'exception, bien sûr, de celui d'où provient la mise à jour. Ainsi, RS élimine la nécessité d'établir un maillage complet entre tous les participants IXP et résout avec élégance le problème d'évolutivité. Il est important de noter que le serveur de routes propage les routes de manière transparente d'un AS à l'autre, sans modifier les attributs BGP transmis ; par exemple, il n'ajoute pas son numéro d'AS au chemin d'accès AS. RS effectue également un filtrage de route de base : par exemple, RS n'accepte pas les réseaux martiens ou les préfixes de l'IXP lui-même.

  Le routeur logiciel open source BIRD (bird internet routing daemon) est souvent utilisé comme serveur de routage. Ses avantages incluent sa gratuité, sa rapidité de déploiement sur la plupart des distributions Linux, la flexibilité de configuration des politiques de routage/filtrage et sa faible consommation de ressources. Un routeur matériel ou virtuel de Cisco, Juniper ou d'autres fournisseurs similaires peut également servir de serveur de routage.

• Sécurité. Puisqu'un réseau IXP regroupe un grand nombre d'AS, la politique de sécurité à laquelle tous les participants doivent se conformer doit être clairement définie. Généralement, les mêmes mécanismes que ceux utilisés pour établir des relations de voisinage BGP entre deux homologues BGP distincts extérieurs à un IXP sont également appliqués, avec quelques mesures de sécurité supplémentaires.

  Par exemple, une bonne pratique consiste à n'autoriser le trafic qu'en provenance d'une adresse MAC spécifique d'un membre IXP, négociée au préalable. Il est également recommandé de refuser le trafic dont les champs ethertype sont autres que 0x0800 (IPv4), 0x08dd (IPv6) ou 0x0806 (ARP) ; cette mesure permet de filtrer le trafic non autorisé par le peering BGP. Des mécanismes tels que GTSM, RPKI et autres peuvent également être utilisés.

Les éléments ci-dessus constituent sans doute les composants clés de tout IXP, quelle que soit sa taille. Bien entendu, les IXP de plus grande taille peuvent utiliser des technologies et des solutions supplémentaires.
Parfois, les IXP fournissent également à leurs membres des services supplémentaires :

• héberger des serveurs DNS sur les TLD IXP,
• installer des serveurs NTP matériels, permettant aux participants de synchroniser l'heure avec précision,
• fournir une protection contre les attaques DDoS, etc.

Comment ça marche?

Nous explorerons le principe de fonctionnement d'un point d'échange de trafic à l'aide d'un IXP simple modélisé avec EVE-NG, puis aborderons la configuration de base du routeur logiciel BIRD. Pour simplifier le schéma, nous omettrons des aspects importants tels que la redondance et la tolérance aux pannes.

La topologie du réseau est illustrée dans la figure ci-dessous.

Supposons que nous administrions un petit point d’échange Internet et que nous fournissions les options de peering suivantes :

• peering public,
• peering privé,
• peering via serveur de route.

Notre numéro AS est 555, nous possédons un bloc d'adresses IPv4 - 50.50.50.0/24, à partir duquel nous émettons des adresses IP à ceux qui souhaitent se connecter à notre réseau.

50.50.50.254 – Adresse IP configurée sur l'interface du serveur de route ; les clients établiront une session BGP avec cette IP en cas de peering via RS.

Nous avons également développé une politique de routage communautaire BGP simple pour le peering RS, qui permet aux participants IXP de contrôler quelles routes sont envoyées à qui :

Communauté BGP
Description

LOCAL_AS:PEER_AS
Transmettre les préfixes uniquement à PEER_AS

LOCAL_AS:IXP_AS
Transférer les préfixes à tous les participants IXP

Trois clients, par exemple des fournisseurs d'accès à Internet, souhaitent se connecter à notre IXP et échanger du trafic. Ils souhaitent tous établir un peering via un serveur de routage. Le schéma ci-dessous illustre les paramètres de connexion des clients :

Client
Numéro AS du client
Préfixes annoncés par le client
Adresse IP attribuée au client pour la connexion à l'IXP

FAI n°1
AS 100
1.1.0.0/16
50.50.50.10/24

FAI n°2
AS 200
2.2.0.0/16
50.50.50.20/24

FAI n°3
AS 300
3.3.0.0/16
50.50.50.30/24

Configuration BGP de base sur le routeur client :

router bgp 100
 no bgp enforce-first-as
 bgp log-neighbor-changes
 neighbor 50.50.50.254 remote-as 555
address-family ipv4
  network 1.1.0.0 mask 255.255.0.0
  neighbor 50.50.50.254 activate
  neighbor 50.50.50.254 send-community both
  neighbor 50.50.50.254 soft-reconfiguration inbound
  neighbor 50.50.50.254 route-map ixp-out out
 exit-address-family

ip prefix-list as100-prefixes seq 5 permit 1.1.0.0/16
route-map bgp-out permit 10
 match ip address prefix-list as100-prefixes
 set community 555:555

Le paramètre « no bgp enforce-first-as » est important à noter. Par défaut, BGP exige que le chemin d'accès d'une mise à jour BGP reçue inclue le numéro du chemin d'accès du pair BGP d'où provient la mise à jour. Cependant, comme le serveur de routage ne modifie pas le chemin d'accès, son numéro sera absent et la mise à jour sera ignorée. Ce paramètre permet de forcer le routeur à ignorer cette règle.

Nous voyons également que le client a défini la communauté BGP 555:555 sur ce préfixe, ce qui, selon notre politique, signifie que le client souhaite annoncer ce préfixe à tous les autres participants.

Pour les routeurs des autres clients, la configuration sera similaire, à l'exception de leurs paramètres uniques.

Exemple de configuration BIRD :

define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];

template bgp RS_CLIENT {
  local as ixp_as;
  rs client;
}

Ce qui suit décrit un filtre qui n'accepte pas les préfixes martiens, ainsi que les préfixes de l'IXP lui-même :

function catch_martians_and_ixp()
prefix set martians;
prefix set ixp_prefixes;
{
  martians = [ 
  0.0.0.0/8+,
  10.0.0.0/8+,
  100.64.0.0/10+,
  127.0.0.0/8+,
  169.254.0.0/16+,
  172.16.0.0/12+,
  192.0.0.0/24+,
  192.0.2.0/24+,
  192.168.0.0/16+,
  198.18.0.0/15+,
  198.51.100.0/24+,
  203.0.113.0/24+,
  224.0.0.0/4+,
  240.0.0.0/4+ ];

  if net ~ martians || net ~ ixp_prefixes then return false;

  return true;
}

Cette fonction implémente la politique de routage que nous avons décrite précédemment.

function bgp_ixp_policy(int peer_as)
{
  if (ixp_as, ixp_as) ~ bgp_community then return true;
  if (ixp_as, peer_as) ~ bgp_community then return true;

  return false;
}

filter reject_martians_and_ixp
{
  if catch_martians_and_ixp() then reject;
  if ( net ~ [0.0.0.0/0{25,32} ] ) then {
    reject;
  }
  accept;


}

Nous configurons le peering et appliquons des filtres et des politiques appropriés.

protocol as_100 from RS_CLIENT {
  neighbor 50.50.50.10 as 100;
  ipv4 {
    export where bgp_ixp_policy(100);
    import filter reject_martians_and_ixp;
  }
}

protocol as_200 from RS_CLIENT {
  neighbor 50.50.50.20 as 200;
  ipv4 {
    export where bgp_ixp_policy(200);
    import filter reject_martians_and_ixp;
  }
}

protocol as_300 from RS_CLIENT {
  neighbor 50.50.50.30 as 300;
  ipv4 {
    export where bgp_ixp_policy(300);
    import filter reject_martians_and_ixp;
  }
}

Il est important de noter qu'il est courant pour un serveur de routage de combiner les routes de différents homologues dans des RIB distincts. BIRD le permet. Dans notre exemple, par souci de simplicité, toutes les mises à jour reçues de tous les clients sont regroupées dans un seul RIB partagé.

Alors, vérifions ce que nous avons.

Sur le serveur de route, nous voyons qu’une session BGP a été établie avec les trois clients :

Nous voyons que nous recevons des préfixes de tous les clients :

Sur le routeur 100, nous voyons qu'avec une seule session BGP avec le serveur de route, nous recevons des préfixes à la fois de 200 et de 300, alors que les attributs BGP n'ont pas changé, comme si le peering entre les clients était effectué directement :

Ainsi, nous voyons que la présence d’un serveur de route simplifie considérablement l’organisation du peering sur les IXP.

J'espère que cette démonstration vous a aidé à mieux comprendre le fonctionnement des IXP et le fonctionnement du serveur de route sur un IXP.

Linxdatacenter IX

Chez Linxdatacenter, nous avons construit notre propre IXP basé sur une infrastructure tolérante aux pannes composée de deux commutateurs et de deux serveurs de routage. Notre IXP est actuellement en phase de test et nous invitons chacun à se connecter à Linxdatacenter IX et à participer aux tests. Une fois connecté, vous bénéficierez d'un port 1 Gbit/s, de fonctionnalités de peering via nos serveurs de routage et d'un accès à votre compte portail IX, accessible à l'adresse suivante : ix.linxdatacenter.com.

Écrivez dans les commentaires ou les messages privés pour accéder aux tests.

conclusion

Les points d'échange de trafic sont apparus à l'aube d'Internet pour résoudre le problème de flux de trafic sous-optimal entre les opérateurs télécoms. Aujourd'hui, avec l'émergence de nouveaux services mondiaux et l'augmentation du trafic CDN, les points d'échange continuent d'optimiser les performances des réseaux mondiaux. La multiplication des IXP dans le monde profite aux utilisateurs finaux, aux opérateurs télécoms, aux fournisseurs de contenu et à d'autres acteurs. Pour les participants aux IXP, les avantages comprennent la réduction des coûts de mise en place de peering externe, la réduction des coûts de trafic supportés par les opérateurs en amont, l'optimisation du routage et la possibilité de se connecter directement aux fournisseurs de contenu.

Liens utiles

• Consultez la carte des points d'échange de trafic : www.internetexchangemap.com
• Afficher les statistiques détaillées du peering BGP, y compris la présence IXP : www.peeringdb.com

Source: habr.com