"Nous avons établi une connexion 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 : « Voyez-vous 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."
"Puis nous avons tapé le G, et le système s'est écrasé"...Pourtant, une révolution avait commencé…
Le début d'Internet.
Bonjour à tous!
Je m'appelle Alexander, je suis ingénieur réseau chez Linxdatacenter. Dans l'article d'aujourd'hui, nous parlerons des points d'échange de trafic (Internet Exchange Points, IXP) : ce qui a précédé leur apparition, quelles tâches ils résolvent et comment ils sont construits. Également dans cet article, je démontrerai le principe de fonctionnement de l'IXP en utilisant la plate-forme EVE-NG et le routeur logiciel BIRD, afin que vous compreniez comment cela fonctionne « sous le capot ».
Un peu d'histoire
Si vous regardez , vous pouvez alors constater que la croissance rapide du nombre de points d'échange de trafic a commencé en 1993. Cela est dû au fait que la majeure partie du trafic des opérateurs de télécommunications qui existaient à cette époque passait par le réseau fédérateur américain. Ainsi, 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 fédérateur faisait ici office de transit entre la France et l’Allemagne. Même le trafic à l'intérieur d'un pays ne transitait souvent pas directement, mais via les réseaux fédérateurs des opérateurs américains.
Cet état de fait affectait non seulement le coût d'acheminement du trafic de transit, mais également la qualité des canaux et les délais. Le nombre d'utilisateurs d'Internet a augmenté, de nouveaux opérateurs sont apparus, le volume de trafic a augmenté et Internet a mûri. Les opérateurs du monde entier ont commencé à se rendre compte qu'une approche plus rationnelle de l'organisation des interactions entre opérateurs était nécessaire. « Pourquoi devrais-je, en tant qu'opérateur A, payer le transit via un autre pays afin d'acheminer le trafic vers l'opérateur B, qui se trouve dans la rue voisine ? C’est en gros la question que se posaient les opérateurs télécoms à l’époque. Ainsi, des points d'échange de trafic ont commencé à apparaître dans différentes parties du monde aux points de concentration des opérateurs :
- 1994 – LINX à Londres,
- 1995 – DE-CIX à Francfort,
- 1995 – MSK-IX, à Moscou, etc.
Internet et nos jours
Conceptuellement, l'architecture de l'Internet moderne se compose de nombreux systèmes autonomes (AS) et de nombreuses connexions entre eux, à la fois physiques et logiques, qui déterminent le chemin du trafic d'un AS à l'autre.
Les AS sont généralement des opérateurs de télécommunications, des fournisseurs Internet, des CDN, des centres de données et des sociétés du secteur des entreprises. Les AS organisent des connexions logiques (peering) entre eux, généralement en utilisant le protocole BGP.
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 propriétaires d’AS,
- etc.
Bien entendu, ce schéma a une certaine structure et hiérarchie. Ainsi, les opérateurs sont divisés en niveau 1, niveau 2 et niveau 3, et si les clients d'un fournisseur Internet local (niveau 3) sont, en règle générale, des utilisateurs ordinaires, alors, par exemple, pour le niveau 1 opérateurs de niveau, les clients sont d’autres opérateurs. Les opérateurs de niveau 3 regroupent le trafic de leurs abonnés, les opérateurs de télécommunications de niveau 2, à leur tour, regroupent le trafic des opérateurs de niveau 3 et le niveau 1 – tout le 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 horizontal de trafic entre des AS qui sont à peu près équivalents les uns aux autres.
Une partie intégrante et en même temps un inconvénient de ce schéma est une certaine confusion des connexions entre des systèmes autonomes situés plus près de l'utilisateur final, au sein d'une zone géographique. Considérez l'image ci-dessous :
Supposons que dans une grande ville il existe 5 opérateurs télécoms, entre lesquels le peering, pour une raison ou une autre, est organisé comme indiqué ci-dessus.
Si l'utilisateur Petya, connecté au FAI Go, souhaite accéder à un serveur connecté au fournisseur ASM, alors le trafic entre eux sera obligé de passer par 5 systèmes autonomes. Cela augmente le délai car le nombre de périphériques réseau par lesquels passera le trafic augmente, ainsi que le volume du trafic de transit sur les systèmes autonomes entre Go et ASM.
Comment réduire le nombre d’AS de transit par lesquels le trafic est obligé de passer ? C'est vrai - 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-2000, mais à une échelle moindre, en réponse au nombre croissant d'opérateurs télécoms, d'utilisateurs et de trafic, à la quantité croissante de contenus générés par les réseaux CDN. et les centres de données.
Qu'est-ce qu'un point d'échange ?
Un point d'échange de trafic est un lieu doté d'une infrastructure réseau spéciale où les participants intéressés par un échange de trafic mutuel organisent un peering mutuel. Les principaux acteurs des points d'échange de trafic : opérateurs télécoms, fournisseurs Internet, fournisseurs de contenus et centres de données. Aux points d'échange de trafic, les participants se connectent directement les uns aux autres. Cela vous permet de résoudre les problèmes suivants :
- 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, tout cela a un effet bénéfique sur Internet dans son ensemble.
Si la situation ci-dessus avec Petya est résolue à l'aide d'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 publiques IPv4/IPv6.
Le réseau IXP est le plus souvent constitué d'un domaine L2 continu. Parfois, il s'agit simplement d'un VLAN qui héberge tous les clients IXP. Lorsqu'il s'agit d'IXP plus grands et géographiquement répartis, des technologies telles que MPLS, VXLAN, etc. peuvent être utilisées pour organiser un domaine L2.
Éléments IXP
- SKS. Il n'y a rien d'inhabituel ici : racks, interconnexions optiques, panneaux de brassage.
- Commutateurs – la base de l’IXP. Le port du commutateur est le point d'entrée dans le réseau IXP. Les commutateurs remplissent également une partie des fonctions de sécurité : ils filtrent le trafic indésirable qui ne devrait pas être présent sur le réseau IXP. En règle générale, les commutateurs sont sélectionnés en fonction des exigences fonctionnelles : fiabilité, vitesses de port prises en charge, fonctionnalités de sécurité, prise en charge de sFlow, etc.
- Serveur de routage (RS) – une partie intégrante et nécessaire de tout point d’échange de trafic moderne. Le principe de fonctionnement est très similaire à celui du réflecteur de route dans iBGP ou du routeur désigné dans OSPF et résout les mêmes problèmes. À mesure que le nombre de participants dans un point d'échange de trafic augmente, le nombre de sessions BGP que chaque participant doit prendre en charge augmente, c'est-à-dire cela rappelle la topologie classique à maillage complet dans iBGP. RS résout le 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. Recevant une mise à jour BGP d'un de ses clients, RS envoie bien entendu cette mise à jour à tous ses autres clients, à l'exception de celui dont cette mise à jour a été reçue. Ainsi, RS élimine le besoin d’établir un maillage complet entre tous les membres IXP et résout avec élégance le problème d’évolutivité. Il convient de noter que le serveur de routes transmet de manière transparente les routes d'un AS à un autre sans apporter de modifications aux attributs transmis par BGP, par exemple, il n'ajoute pas le numéro de son AS au chemin AS. Également sur RS, il existe un filtrage de base des routes : par exemple, RS n'accepte pas les réseaux martiens et les préfixes de l'IXP lui-même.
Un routeur logiciel open source, BIRD (bird Internet Routing Daemon), est souvent utilisé comme solution de serveur de routage. L'avantage est qu'il est gratuit, se déploie rapidement sur la plupart des distributions Linux, dispose d'un mécanisme flexible pour configurer des politiques de routage/filtrage et n'exige pas de ressources informatiques. En outre, un routeur matériel/virtuel de Cisco, Juniper, etc. peut être sélectionné comme RS.
- Sécurité. Puisqu’un réseau IXP est une concentration d’un grand nombre d’AS, la politique de sécurité que tous les participants doivent suivre doit être bien rédigée. En général, tous les mêmes mécanismes qui s'appliquent lors de l'établissement d'une contiguïté BGP entre deux homologues BGP distincts en dehors d'un IXP s'appliquent ici, ainsi que quelques fonctionnalités de sécurité supplémentaires.
Par exemple, il est recommandé d'autoriser le trafic uniquement à partir d'une adresse MAC spécifique du participant IXP, qui est négociée à l'avance. Refuser le trafic avec des champs ethertype autres que 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP) ; ceci est fait afin de filtrer le trafic qui n'appartient pas au peering BGP. Des mécanismes tels que GTSM, RPKI, etc. peuvent également être utilisés.
Les éléments ci-dessus constituent peut-être les principaux composants de tout IXP, quelle que soit son échelle. Bien entendu, les plus grands IXP peuvent disposer de technologies et de solutions supplémentaires.
Il arrive qu'IXP propose également à ses participants des services supplémentaires :
- placé sur le serveur DNS IXP TLD,
- installer des serveurs NTP matériels, permettant aux participants de synchroniser avec précision l'heure,
- assurer une protection contre les attaques DDoS, etc.
Comment ça marche?
Regardons le principe de fonctionnement d'un point d'échange de trafic à l'aide de l'exemple d'un IXP simple, modélisé à l'aide d'EVE-NG, puis considérons la configuration de base d'un routeur logiciel BIRD. Pour simplifier le diagramme, nous omettrons des éléments aussi importants 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 administrons un petit point d'échange et proposons les options de peering suivantes :
- le peering public,
- peering privé,
- peering via le serveur de routage.
Notre numéro AS est le 555, nous possédons un bloc d'adresses IPv4 – 50.50.50.0/24, à partir duquel nous émettons des adresses IP pour ceux qui souhaitent se connecter à notre réseau.
50.50.50.254 – Adresse IP configurée sur l'interface du serveur de route, avec cette IP, les clients établiront une session BGP en cas de peering via RS.
De plus, pour le peering via RS, nous avons développé une politique de routage simple basée sur la communauté BGP, qui permet aux participants IXP de réguler à qui et quelles routes envoyer :
Communauté BGP
description
LOCAL_AS : PEER_AS
Envoyer des préfixes uniquement à PEER_AS
LOCAL_AS : IXP_AS
Transférer les préfixes à tous les participants IXP
3 clients souhaitent se connecter à notre IXP et échanger du trafic ; Disons que ce sont des fournisseurs Internet. Ils souhaitent tous organiser le peering via un serveur de routage. Vous trouverez ci-dessous un diagramme avec les paramètres de connexion client :
Client
Numéro AS du client
Préfixes annoncés par le client
Adresse IP délivrée au client pour se connecter à 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
Il convient de noter ici le paramètre no bgp apply-first-as. Par défaut, BGP exige que le chemin as d'une mise à jour BGP reçue contienne le numéro as BGP de l'homologue à partir duquel la mise à jour a été reçue. Mais comme le serveur de routes n'apporte aucune modification au chemin as-path, son numéro ne sera pas dans le chemin as-path et la mise à jour sera rejetée. Ce paramètre est utilisé pour que le routeur ignore 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 d'autres clients, les paramètres seront similaires, à 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, appliquons les filtres et les 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 convient de noter que sur un serveur de routes, il est recommandé de placer les routes de différents pairs dans différents RIB. BIRD vous permet de le faire. Dans notre exemple, par souci de simplicité, toutes les mises à jour reçues de tous les clients sont ajoutées dans un RIB commun.
Alors, vérifions ce que nous avons.
Sur le serveur de routes, nous voyons qu'une session BGP a été établie avec les trois clients :
On voit que nous recevons des préfixes de tous les clients :
Sur le routeur as 100, nous voyons que s'il n'y a qu'une seule session BGP avec le serveur de route, nous recevons les préfixes as 200 et as 300, alors que les attributs BGP n'ont pas changé, comme si le peering entre clients s'effectuait directement :
Ainsi, on voit que la présence d'un serveur de routage simplifie grandement l'organisation du peering sur l'IXP.
J'espère que cette démonstration vous a aidé à mieux comprendre le fonctionnement des IXP et le fonctionnement du serveur de routage sur un IXP.
Linxdatacenter IX
Chez Linxdatacenter, nous avons construit notre propre IXP basé sur une infrastructure tolérante aux pannes de 2 commutateurs et 2 serveurs de routage. Notre IXP fonctionne désormais en mode test et nous invitons tout le monde à se connecter à Linxdatacenter IX et à participer aux tests. Une fois connecté, vous disposerez d'un port avec une bande passante de 1 Gbit/s, de la possibilité de peerer via nos serveurs de route, ainsi que d'un accès à votre compte personnel du portail IX, disponible sur .
Écrivez des commentaires ou des messages privés pour accéder aux tests.
conclusion
Les points d'échange de trafic sont apparus à l'aube d'Internet comme outil permettant de résoudre le problème du flux de trafic sous-optimal entre les opérateurs de télécommunications. Désormais, avec l'avènement de nouveaux services mondiaux et l'augmentation du trafic CDN, les points d'échange continuent d'optimiser le fonctionnement du réseau mondial. L’augmentation du nombre d’IXP dans le monde profite à la fois à l’utilisateur final du service et aux opérateurs télécoms, opérateurs de contenus, etc. Pour les participants IXP, l'avantage s'exprime dans la réduction des coûts d'organisation du peering externe, la réduction de la quantité de trafic pour laquelle les opérateurs de niveau supérieur doivent payer, l'optimisation du routage et la possibilité d'avoir une interface directe avec les opérateurs de contenu.
Liens utiles
- Visualisez une carte de localisation des points d'échange de trafic :
- Consultez des statistiques détaillées sur le peering BGP, y compris la présence sur IXP :
Source: habr.com