«Nous avons établi une connexion téléphonique entre nous et les gars de SRI…», a déclaré Kleinrock lors d'une interview :
«Nous avons tapé le L et nous avons demandé au téléphone : „Vous voyez le L ?“»
«Oui, nous voyons le L», a été la réponse.
«Nous avons tapé le O, et nous avons demandé : „Vous voyez le O ?“»
«Oui, nous voyons le O.»
«Ensuite, nous avons tapé le G, et le système s'est crashé»…Pourtant, une révolution avait commencé…
Le début d'Internet.
Bonjour à tous !
Je m'appelle Alexandre, je suis ingénieur réseau chez Linxdatacenter. Dans cet article, nous parlerons des points d'échange de trafic (Internet Exchange Point, IXP) : de ce qui a précédé leur apparition, des problèmes qu'ils résolvent et de comment ils sont construits. De plus, dans cet article, je vais démontrer le fonctionnement d'un IXP à l'aide de la plateforme EVE-NG et du routeur BIRD, afin de comprendre comment cela fonctionne « sous le capot ».
Un peu d'histoire
Si l'on regarde , on peut constater que l'essor rapide du nombre de points d'échange de trafic a commencé en 1993. Cela est lié au fait que la majeure partie du trafic des opérateurs existants à l'époque passait par le réseau backbone des États-Unis. Par exemple, lorsque le trafic allait d'un opérateur en France à un opérateur en Allemagne, il passait d'abord par les États-Unis, puis de là à destination de l'Allemagne. Le réseau backbone agissait ici comme un transit entre la France et l'Allemagne. Même le trafic à l'intérieur d'un même pays passait souvent non pas directement, mais par les réseaux des opérateurs américains.
Cette situation avait un impact non seulement sur le coût de la livraison du trafic de transit, mais aussi sur la qualité des canaux et le délai. Le nombre d'utilisateurs d'Internet augmentait, de nouveaux opérateurs apparaissaient, le volume de trafic croissait, Internet grandissait. Les opérateurs du monde entier ont commencé à comprendre qu'un moyen plus rationnel devait être trouvé pour organiser l'interaction entre opérateurs. «Pourquoi devrais-je, opérateur A, payer pour le transit à travers un autre pays pour livrer le trafic à l'opérateur B qui se trouve à deux pas?». C'était à peu près la question que posaient les opérateurs à cette époque. Ainsi, dans différentes parties du monde, des points d'échange de trafic ont commencé à émerger dans des lieux de concentration d'opérateurs :
- 1994 – LINX à Londres,
- 1995 – DE-CIX à Francfort,
- 1995 – MSK-IX à Moscou, etc.
Internet et nos jours
Conceptuellement, l'architecture moderne de l'internet se compose de multiples systèmes autonomes (autonomous system, AS) et de nombreuses liaisons entre eux, tant physiques que logiques, qui déterminent le chemin du trafic d'un AS à l'autre.
En tant qu'AS, on trouve généralement des opérateurs de télécommunications, des fournisseurs d'accès à internet, des CDN, des centres de données et des entreprises du secteur entreprise. Les AS établissent des liaisons logiques (peering) entre eux, généralement par le biais du protocole BGP.
La manière dont les systèmes autonomes organisent ces liaisons est déterminée par divers facteurs :
- géographiques,
- économiques,
- politiques,
- accords et intérêts communs entre les propriétaires d'AS,
- etc.
Bien sûr, dans ce schéma, il existe une certaine structure et hiérarchie. Ainsi, les opérateurs sont classés en tier-1, tier-2 et tier-3, et si les clients des fournisseurs d'accès internet locaux (tier-3) sont généralement des utilisateurs ordinaires, en revanche, pour les opérateurs de tier-1, les clients sont d'autres opérateurs. Les opérateurs tier-3 agrègent le trafic de leurs abonnés, les opérateurs de télécommunications tier-2 agrègent à leur tour le trafic des opérateurs tier-3, tandis que les tier-1 gèrent tout le trafic internet.
Schématiquement, cela peut être représenté ainsi :
Sur cette image, on peut voir que le trafic est agrégé de bas en haut, c'est-à-dire des utilisateurs finaux vers les opérateurs tier-1. Il y a également des échanges horizontaux de trafic entre des AS à peu près équivalents.
Une partie intégrante, mais en même temps un inconvénient de ce schéma, est une certaine désorganisation des liens entre les systèmes autonomes situés plus près de l'utilisateur final, au sein de la zone géographique. Regardons l'image ci-dessous :
Supposons qu'il y a 5 opérateurs de télécommunications dans une grande ville, entre lesquels le peering est organisé, pour diverses raisons, comme illustré ci-dessus.
Si l'utilisateur Petya, connecté à l'opérateur internet Go, souhaite accéder à un serveur connecté à l'opérateur ASM, le trafic entre eux devra passer par 5 systèmes autonomes. Cela augmente donc la latence, car le nombre d'appareils réseau par lesquels le trafic transite augmente, ainsi que le volume de trafic de transit sur les systèmes autonomes entre Go et ASM.
Comment réduire le nombre d'AS de transit que le trafic est obligé de traverser ? Correctement – par un point d'échange de trafic.
Aujourd'hui, l'apparition de nouveaux IXP est toujours 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 à l'augmentation du nombre d'opérateurs de télécommunications, d'utilisateurs et de trafic, ainsi qu'à la croissance du 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 est un lieu disposant d'une infrastructure réseau spécialisée où les participants intéressés par un échange de trafic réciproque organisent un peering mutuel. Les principaux acteurs des points d'échange de trafic comprennent les opérateurs de télécommunications, les fournisseurs d'accès Internet, les fournisseurs de contenu et les centres de données. Dans les points d'échange de trafic, les participants se connectent directement entre eux. Cela permet de résoudre les problèmes suivants :
- réduire la latence,
- diminuer le trafic de transit,
- optimiser le routage entre les AS.
Étant donné que les IXP sont présents dans de nombreuses grandes villes du monde, cela a également un impact positif sur le réseau Internet dans son ensemble.
Si l'on considère la situation décrite ci-dessus concernant Petya et qu'on y remédie par le biais des IXP, cela donnerait à peu près ceci :
Comment est organisé un point d'échange de trafic ?
En général, un IXP est un AS distinct avec son propre bloc d'adresses IPv4/IPv6 publiques.
Le réseau d'un IXP représente le plus souvent un domaine L2 homogène. Parfois, il s'agit simplement d'un VLAN hébergeant tous les clients de l'IXP. Lorsque l'on parle de IXP plus importants et géographiquement dispersés, des technologies comme MPLS, VXLAN, etc., peuvent être utilisées pour organiser le domaine L2.
Éléments de l'IXP
- Câblage structuré. Ici, rien de particulier : racks, panneaux de distribution optique, panneaux de brassage.
- Les commutateurs – la base de l'IXP. Le port de commutation est le point d'entrée dans le réseau de l'IXP. De plus, les commutateurs remplissent certaines fonctions de sécurité – ils filtrent le trafic indésirable qui ne devrait pas être présent dans le réseau de l'IXP. En règle générale, les commutateurs sont choisis en fonction des exigences fonctionnelles – fiabilité, vitesse prise en charge des ports, fonctions 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. Son fonctionnement ressemble beaucoup à celui d'un route reflector dans l'iBGP ou d'un routeur désigné dans l'OSPF et 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 maintenir augmente aussi, ce qui rappelle la topologie classique full-mesh dans l'iBGP. Le RS résout le problème de la manière suivante : il établit une session BGP avec chaque participant intéressé de l'IXP, et celui-ci devient le client du RS. En recevant une mise à jour BGP de l'un de ses clients, le RS transmet cette mise à jour à tous ses autres clients, bien sûr, à l'exception de celui dont la mise à jour a été reçue. Ainsi, le RS évite la nécessité d'établir un full-mesh entre tous les participants de l'IXP et résout élégamment 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 modifier les attributs BGP transmis, par exemple, sans ajouter son propre numéro d'AS dans le chemin AS. De plus, le RS effectue un filtrage de base des routes : par exemple, le RS n'accepte pas les réseaux martiens et les préfixes de l'IXP.
En tant que solution, le serveur de routes utilise souvent un routeur logiciel à code source ouvert – BIRD (daemon de routage Internet BIRD). Il est avantageux car 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'est pas exigeant en ressources informatiques. De plus, comme RS, on peut également choisir un routeur matériel/virtuel de Cisco, Juniper, etc.
- Sécurité. Étant donné que le réseau IXP est la concentration d'un grand nombre d'AS, la politique de sécurité à laquelle tous les participants doivent se conformer doit être bien définie. En général, tous les mêmes mécanismes qui sont appliqués lors de l'établissement de voisinages BGP entre deux paires BGP distinctes en dehors de l'IXP s'appliquent ici, ainsi que certains moyens de protection supplémentaires.
Par exemple, une bonne pratique consiste à laisser passer le trafic uniquement d'une adresse MAC spécifique d'un participant IXP, qui est convenue à l'avance. L'interdiction du trafic avec des champs ethertype différents de 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP) ; cela permet de filtrer le trafic pour lequel il n'y a pas de place lors d'un peering BGP. Des mécanismes tels que GTSM, RPKI, etc., peuvent également être appliqués.
Sans aucun doute, les éléments ci-dessus constituent les principales composantes de tout IXP, quelle que soit sa taille. Bien sûr, des technologies et des solutions supplémentaires peuvent être utilisées dans les grands IXP.
Il arrive que l'IXP offre également à ses participants des services supplémentaires :
- hébergement de serveurs DNS TLD sur l'IXP,
- installation de serveurs NTP matériels, permettant aux participants de synchroniser le temps avec précision,
- fourniture de protection contre les attaques DDoS, etc.
Principe de fonctionnement
Analysons le principe de fonctionnement d'un point d'échange de trafic en prenant comme exemple un IXP simple, modélisé à l'aide d'EVE-NG, puis examinons la configuration de base d'un routeur logiciel BIRD. Pour simplifier le schéma, nous passerons sous silence des éléments importants tels que la redondance et la tolérance aux pannes.
La topologie du réseau est représentée sur le schéma ci-dessous.
Supposons que nous administrions un petit point d'échange de trafic et que nous offrions les options de peering suivantes :
- peering public,
- peering privé,
- peering via un serveur de routage.
Notre numéro d'AS est le 555, nous possédons le bloc d'adresses IPv4 – 50.50.50.0/24, dont nous attribuons des adresses IP aux personnes désirant se connecter à notre réseau.
50.50.50.254 est l'adresse IP configurée sur l'interface du serveur de routage, avec cette IP, les clients établiront une session BGP en cas de peering via le RS.
De plus, pour le peering via le RS, nous avons élaboré une simple politique de routage basée sur les communautés BGP, qui permet aux participants de l'IXP de contrôler à qui et quels itinéraires envoyer :
Communauté BGP
Description
LOCAL_AS:PEER_AS
Transmettre les préfixes uniquement à PEER_AS
LOCAL_AS:IXP_AS
Transmettre les préfixes à tous les participants de l'IXP
Trois clients souhaitent se connecter à notre IXP et échanger du trafic ; supposons qu'il s'agisse de fournisseurs d'accès Internet. Tous souhaitent organiser un peering via le serveur de routage. Le schéma suivant présente les paramètres de connexion des clients :
Client
Numéro d'AS du client
Préfixes annoncés par le client
adresse IP attribuée au client pour se connecter à l'IXP
FAI #1
AS 100
1.1.0.0/16
50.50.50.10/24
FAI #2
AS 200
2.2.0.0/16
50.50.50.20/24
FAI #3
AS 300
3.3.0.0/16
50.50.50.30/24
Configuration de base de BGP sur le routeur du client :
route 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 la configuration no bgp enforce-first-as. Par défaut, le BGP exige que le numéro AS du pair BGP, à partir duquel la mise à jour a été reçue, soit présent dans le chemin AS de la mise à jour BGP reçue. Mais comme le serveur de route n'apporte pas de modifications au chemin AS, son numéro sera absent dans le chemin AS et la mise à jour sera rejetée. Ce paramètre est appliqué pour que le routeur commence à ignorer cette règle.
Nous voyons également que le client a défini la communauté BGP 555:555 pour ce préfixe, ce qui selon notre politique signifie que le client souhaite annoncer ce préfixe à tous les autres participants.
La configuration des routeurs des autres clients 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;
}
Ensuite, il décrit un filtre qui n'accepte pas les préfixes martians, ainsi que les préfixes de l'IXP :
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 met en œuvre 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;
}
Mettons en place 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 qu'il est de bon ton sur le serveur de route de stocker les routes des différents pairs dans différentes RIB. BIRD permet cela. Dans notre exemple, pour la simplicité, toutes les mises à jour reçues de tous les clients sont stockées dans une seule RIB commune.
Vérifions ce que nous avons obtenu.
Sur le serveur route, nous voyons qu'une session BGP est établie avec tous les trois clients :
Nous constatons que nous recevons des préfixes de tous les clients :
Sur le routeur as 100, nous voyons que malgré une seule session BGP avec le serveur de routes, nous recevons des préfixes à la fois de as 200 et de as 300, et les attributs BGP n'ont pas changé, comme si le peering entre les clients se faisait directement :
Nous constatons ainsi que la présence d'un serveur de routes simplifie considérablement l'organisation du peering sur l'IXP.
J'espère que cette démonstration vous a aidé à mieux comprendre comment fonctionnent les points d'échange de trafic et comment un serveur de routes fonctionne sur l'IXP.
Linxdatacenter IX
Chez Linxdatacenter, nous avons construit notre propre IXP sur une infrastructure redondante composée de 2 commutateurs et 2 serveurs de routes. Actuellement, notre IXP est en phase de test, et nous invitons tous ceux qui le souhaitent à se connecter à Linxdatacenter IX et à participer aux tests. Lors de la connexion, un port avec une bande passante de 1 Gbit/s vous sera fourni, avec la possibilité de peering via nos serveurs de routes, ainsi qu'un accès au portail personnel IXP, accessible à l'adresse .
Écrivez dans les commentaires ou en message privé pour obtenir accès aux tests.
Sortie
Les points d'échange de trafic sont apparus à l'aube d'Internet comme un outil pour résoudre le problème de l'acheminement sous-optimal du trafic entre les opérateurs de télécommunications. Aujourd'hui, avec l'apparition de nouveaux services globaux 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 tant à l'utilisateur final du service qu'aux opérateurs de télécommunication, aux opérateurs de contenu, etc. Pour les participants à l'IXP, l'avantage se traduit par une réduction des coûts d'organisation des peerings externes, une diminution du trafic pour lequel il faut payer aux opérateurs supérieurs, une optimisation du routage, et la possibilité d'avoir une connexion directe avec les opérateurs de contenu.
Liens utiles
- Voir la carte de localisation des points d'échange de trafic :
- Consulter des statistiques détaillées sur le peering BGP, y compris la présence sur l'IXP :
Source : habr.com
