1

MOOC Routage et Qualité de Service

Automne 2015

Semaine 2 : Le routage externe

Au cours de cette semaine, nous abordons le routage externe. Nous traitons de l’interconnexion entre les réseaux et de l’échange d’informations de routage. En particulier, nous analysons les types d’accords pour l’échange de trafic entre systèmes autonomes et de la classification qui en résulte. Nous présentons en détail le protocole BGP : les sessions, les types de messages et les différents attributs du protocole. Une attention particulière est portée au processus de sélection dans BGP. Finalement, nous abordons des exemples de déploiement de stratégies de routage BGP. Cette semaine se prolonge par l’interview de Franck Simon, directeur général de France-­IX, qui démystifie le fonctionnement d'un point d'échange internet.

2

Table des matières 1. Leçon 1 : Introduction à la structure d’Internet -­ Internet en quelques chiffres .................................................................................................................................... 3 2. Leçon 2 : Interconnexion des systèmes autonomes – Transit et peering ... 14 3. Leçon 3 : Principes du routage externe – Stratégies de routage ................... 26 4. Leçon 4 : Principes du protocole BGP – Sessions et messages BGP ......... 35 5. Leçon 5 : Attributs du protocole BGP ................................................................... 47 6. Leçon 6 : Processus de sélection dans BGP – Critères de sélection et informations de routage ................................................................................................... 57 7. Leçon 7 : Exemples de stratégies de routage – Peering et transit avec BGP 74

3

1. Leçon 1 : Introduction à la structure d’Internet -­ Internet en quelques chiffres

Bonjour et bienvenue dans cette série de leçons, dans laquelle nous abordons le routage externe. Nous traitons ici de l’interconnexion entre les réseaux et de l’échange d’informations de routage.

Commençons par un exemple simple d’un ordinateur à Rennes qui se connecte sur le site www.example.com. Les outils habituels de diagnostic des réseaux permettent de révéler les adresses IP des routeurs traversés. En effet, les paquets de données échangés lors de cette connexion traversent dix routeurs. Le premier est situé à Caen, le deuxième à Rouen, le troisième à Paris. Ces trois premiers routeurs sont gérés par RENATER : Le Réseau National de télécommunications pour la Technologie l'Enseignement et la Recherche. Ensuite, les paquets de données traversent deux routeurs de l’opérateur Vodafone, puis le réseau de l’opérateur TeliaSonera pour atteindre un routeur situé à Washington aux Etats-­Unis. Finalement, les paquets de données arrivent au serveur www.example.com hébergé par le fournisseur de contenu EdgeCast. Cet exemple simple permet de révéler une propriété importante de la structure d’Internet : Internet est un ensemble de réseaux gérés par différents opérateurs qui s’interconnectent afin de fournir la connectivité globale.

4

Dans la suite, quand il s’agit d’étudier le routage externe et l’interconnexion des réseaux, nous adoptons un point de vue macroscopique : cela nous permet de masquer la complexité interne des réseaux traversés et de considérer chacun comme une seule entité.

Dans la réalité, l’interconnexion entre les réseaux est plus complexe. En effet, RENATER dispose aussi d’un lien d’interconnexion avec le réseau de l’opérateur GTT. Par conséquent, les paquets de données échangés entre l’ordinateur à Rennes et le site www.example.com peuvent emprunter plusieurs chemins. A titre d’exemple, cela peut être le chemin constaté dans les mesures précédentes, ou un chemin qui passe par GTT puis TeliaSonera, ou même un chemin sans intersection avec le premier et qui passe par les réseaux des opérateurs GTT puis NTT.

5

A l’aide de l’exemple précédent, nous pouvons révéler les principales composantes du routage externe. Ces composantes font l’objet des prochaines leçons et répondent aux questions suivantes : Premièrement, comment se propage l’information de routage qui permet d’annoncer l’accessibilité à un réseau ? Quel protocole et quels mécanismes sont-­ils mis en place à travers les différents réseaux des opérateurs ? Deuxièmement, une fois l’information de routage propagée, qui décide du chemin à suivre et quels sont les critères utilisés pour faire ce choix ?

6

Le défi principal du routage externe est l’implication de plusieurs opérateurs. Dans ce contexte, les réseaux de ces opérateurs sont appelés systèmes autonomes. Un système autonome est un ensemble de réseaux connectés généralement gérés par une même entité administrative et qui se comporte comme une seule entité pour le routage externe. Qui joue alors le rôle d’un système autonome en pratique ? Et de quel type d’infrastructure de réseau dispose-­t-­il ? Un système autonome peut être le réseau d’un fournisseur de contenu, d’un fournisseur d’accès à Internet, ou de toute entreprise avec un accès à Internet, …

7

Certains systèmes autonomes comme RENATER assurent une couverture nationale. RENATER dispose d’une infrastructure de transmission en fibres optiques et de points de présence dans plusieurs villes en France. Certains points stratégiques tels que Paris, Lyon ou Marseille permettent l’interconnexion avec d’autres systèmes autonomes tels que les fournisseurs d’accès à Internet en France ou le réseau européen pour l’éducation et la recherche GEANT.

8

D’autres systèmes autonomes comme TeliaSonera assurent une couverture internationale avec des points de présence sur plusieurs continents. TeliaSonera dispose de liens d’interconnexion avec un très grand nombre de systèmes autonomes, par exemple des fournisseurs d’accès à Internet en Amérique du Nord, en Europe ou en Asie.

9

Dans le routage externe, un système autonome est identifié par un numéro unique. Comme pour les adresses IP, la gestion des numéros de systèmes autonomes est faite par l’IANA (Internet Assigned Numbers Authority), un organisme mondial. L’IANA délègue son autorité à des registres régionaux appelés Regional Internet Registry qui attribuent les numéros de systèmes autonomes dans leur zone géographique. Il existe cinq registres régionaux dans le monde. En Europe, les numéros de systèmes autonomes s’obtiennent auprès de RIPE NCC. Un numéro de système autonome est codé sur 16 bits, entre 1 et 65534. Par exemple, RENATER dispose du numéro de système autonome 2200. Notons que les 1024 derniers numéros (64512 à 65534) sont destinés à un usage privé.

10

Aujourd’hui, il existe plus de 51 000 systèmes autonomes dans l’Internet. Pour accompagner cette évolution, qui est une image de l’évolution de l’Internet, les numéros de systèmes autonomes passent de 16 à 32 bits. Par conséquent, les numéros attribués à partir de janvier 2009 sont notés sous le format X.Y avec X et Y des entiers sur 16 bits. Par exemple, l’Assistance publique -­ Hôpitaux de Paris dispose du numéro 3.2267 attribué en 2012.

11

Analysons quelques chiffres clés liés aux systèmes autonomes dans l’Internet en 2015. Dans ce contexte, on appelle systèmes autonomes voisins des systèmes autonomes qui ont établi un lien d’interconnexion pour échanger le trafic. Généralement, ce voisinage est établi sur des bases géographiques. Tout d’abord, on note que 80% des systèmes autonomes sur Internet sont des réseaux terminaux. Ces réseaux ne font pas transiter du trafic d’autres systèmes autonomes. De plus, 64% de systèmes autonomes ont un ou deux voisins, la moyenne géométrique globale du nombre de voisins sur Internet étant 2.55. Si on observe les systèmes autonomes avec le plus grand nombre d’interconnexions, on note que 1% ont plus de 100 voisins et que seulement 46 systèmes autonomes (près de 1 pour mille) ont plus de 1000 voisins.

12

Il est donc intéressant de pouvoir schématiser l’Internet à l’échelle des systèmes autonomes. Cependant, tracer un tel graphe est une tâche complexe et nécessite de placer un grand nombre des sondes pour révéler la structure d’interconnexion. Le centre pour l’analyse appliquée des données de l’Internet (CAIDA) fournit un graphe représentant l’Internet en 2014. Sur ce graphe, les nœuds représentent des systèmes autonomes et les liens représentent les interconnexions. Les nœuds sont regroupés par zone géographique et le rayon est proportionnel au nombre de voisinages : plus un système autonome a des voisins, plus il est proche du centre du graphe. Cette représentation synthétique permet de révéler deux propriétés importantes de la structure de l’Internet appuyées par les chiffres analysés précédemment. Premièrement, la densité des nœuds centraux est faible : très peu de systèmes autonomes disposent d’un très grand nombre de connexion. Cela peut constituer une sorte de cœur de l’Internet sans toutefois enlever sa caractéristique décentralisée. Il s’agit par exemple de Level3, TeliaSonera, Cogent, … Deuxièmement, la densité des nœuds se trouvant près de la frontière du graphe est très élevée. En effet, la majorité des systèmes autonomes dans l’Internet sont interconnectés avec un ou deux voisins.

13

A ce stade, nous pouvons établir les enjeux du routage externe. Premièrement, le routage externe doit offrir la connectivité globale en rendant possibles les échanges entre différents systèmes autonomes. Deuxièmement, le routage externe doit être appliqué à l’échelle de l’Internet et permettre l’échange d’informations de routage entre un très grand nombre de systèmes autonomes. Finalement, le routage externe doit préserver l’autonomie : chaque système autonome doit pourvoir prendre les décisions d’acheminement du trafic et établir ses propres stratégies de routage.

14

Dans cette leçon, nous avons analysé la structure de l’Internet sous l’angle du routage externe. Nous avons identifié la notion de système autonome qui sera l’entité élémentaire pour étudier le routage externe. De plus, nous avons découvert quelques chiffres marquants qui révèlent les principales propriétés de l’Internet : on y trouve un petit nombre de systèmes autonome avec un très grand nombre d’interconnexions et une majorité de systèmes autonomes avec un ou deux liens d’interconnexion. Nous avons conclu en formulant les principaux enjeux du routage externe à savoir fournir une connectivité globale, assurer le passage à l’échelle, et préserver l’autonomie.

2. Leçon 2 : Interconnexion des systèmes autonomes – Transit et peering

Bonjour et bienvenue dans cette leçon, dans laquelle nous abordons l’interconnexion de systèmes autonomes. Nous traitons ici des types d’accords pour l’échange de trafic entre systèmes autonomes et de la classification qui en résulte.

15

Il existe deux types d’accords entre systèmes autonomes : le transit et le peering. Le transit est un accord commercial entre un client et un fournisseur qui assure l’acheminement du trafic du client vers ou depuis le reste de l’Internet. Le fournisseur appelé aussi opérateur de transit facture à son client le trafic échangé. Dans l’exemple suivant, le système autonome A a conclut un accord de transit avec B. Par conséquent, B fournit l’accès à Internet et facture le trafic échangé sur le lien avec A.

16

Sachant que le trafic présente des alternances de période de pointe et de périodes creuses, comment peut-­on établir la facturation d’un accord de transit ? Cette facturation est généralement établie selon la règle du 95ème centile. Pour ce faire, le débit du lien d’interconnexion entre le client et le fournisseur est mesuré toutes les cinq minutes. Les échantillons mensuels sont classés par ordre croissant et les 5% des valeurs de débit les plus élevées sont écartées : la valeur suivante est notée 95ème centile. Le maximum entre le 95ème centile du trafic sortant et entrant sert alors de base de facturation.

17

Le peering est un accord d’échange direct de trafic entre deux systèmes autonomes et entre leurs clients. Supposons que les systèmes autonomes A et B sont des fournisseurs de C et D respectivement. Si A et B concluent un accord de peering, le trafic en provenance de l’un des quatre systèmes autonomes cités et à destination de l’un d’eux peut emprunter le lien d’interconnexion : c’est le cas par exemple du trafic de A vers B ou de C vers D.

18

En général, le trafic échangé selon un accord de peering n’est pas facturé. Cependant, les deux systèmes autonomes partagent le coût de la mise en place et du maintien de l’interconnexion. Un accord de peering est généralement conclu entre deux systèmes autonomes équivalents. Les principales caractéristiques utilisées pour comparer les systèmes autonomes sont l’étendue géographique, la capacité des liens, le nombre de clients, ou le trafic généré. En effet, même si le trafic n’est pas facturé sur un lien de peering, les deux systèmes autonomes veillent à garder un ratio équilibré des débits de trafic échangé.

19

Que se passe-­t-­il si les règles d’équilibre de trafic ne sont pas respectées dans un accord de peering ? Ce déséquilibre est de plus en plus fréquent depuis la forte augmentation du trafic vidéo sur Internet. Prenons l’exemple d’un fournisseur d’accès à Internet A et d’un fournisseur de contenu vidéo B. Lorsque les clients de A accèdent à un contenu vidéo hébergé par B, leurs requêtes génèrent un débit faible comparé à celui généré par le trafic de retour transportant les vidéos. En général, si le débit moyen du trafic envoyé de B vers A dépasse largement celui envoyé de A vers B, A peut demander de renégocier l’accord de peering : soit pour facturer à B l’extension de la capacité du lien d’interconnexion, soit pour lui facturer le trafic échangé. On parle alors d’accord de peering payant. Historiquement, les règles des accords de peering et les conditions d’équilibre de trafic associées ont provoqué de nombreux conflits entre systèmes autonomes allant jusqu’à la rupture des accords.

20

Supposons maintenant que deux systèmes autonomes C et D ont signé des accords de transit avec A et B respectivement. Initialement, le trafic échangé entre C et D passe par A et B ainsi que d’autres systèmes autonomes qui assurent l’interconnexion entre ces deux derniers. Si C et D mettent en place un accord de peering, cela permettra d’échanger directement leur trafic sans passer par leurs fournisseurs. Quels sont alors les avantages de la mise en place d’un tel accord de peering ? Premièrement, le délai de bout en bout des communications entre C et D est réduit, et la qualité de service proposée par les systèmes autonomes améliorée. Deuxièmement, C et D réduisent la dépendance à leurs fournisseurs respectifs et peuvent profiter d’une tolérance aux pannes dans l’interconnexion : si le lien direct de peering tombe en panne, le trafic échangé entre C et D peut repasser par les fournisseurs. Finalement, échanger le trafic directement selon un accord de peering peut réduire les coûts de transit payés par C et D. A la différence du trafic échangé en transit et facturé en fonction du débit, le peering induit uniquement des coûts de mise en place et de maintien de l’interconnexion. Pour cela, au delà d’un débit moyen de trafic échangé, le peering devient une solution rentable pour les systèmes autonomes.

21

Dans les exemples précédents, nous avons vu que les interconnexions de peering sont réalisées au travers d’un lien direct entre les infrastructures propres des deux systèmes autonomes. Autrement, la mise en place des interconnexions de peering peut être réalisée via des points d’échange ou Internet Exchange (IX). Un point d’échange est une infrastructure d’interconnexion distribuée sur plusieurs centres d’hébergement de données qui permet à des systèmes autonomes d’échanger directement leur trafic. Le schéma logique d’un point d’échange est une plateforme de commutation sur laquelle se connecte un routeur de chaque système autonome membre. Généralement, chaque système autonome membre paie des frais d’installation et des frais mensuels pour s’interconnecter au point d’échange. Comparé à un lien de peering direct entre systèmes autonomes, le point d’échange peut s’avérer comme un solution plus économique. Précisément, un système autonome qui devient membre d’un point d’échange a la possibilité d’échanger le trafic directement avec l’ensemble des autres membres et ce moyennant un seul lien d’interconnexion avec la plateforme de commutation. Les points d’échanges deviennent des éléments importants de la structure de l’Internet. Un point d’échange comme FranceIX réunit plus de 250 systèmes autonomes membres et le débit moyen du trafic échangé est près de 250 Gbits/s.

22

En considérant les accords de peering et de transit, nous pouvons établir une classification des systèmes autonomes dans l’Internet. Cette classification fait apparaître trois niveaux de systèmes autonomes. Ces niveaux sont appelés Tier en anglais : nous avons donc des systèmes autonomes Tier 1, Tier 2 ou Tier 3. Notons que cette classification reste néanmoins approximative du fait de la confidentialité de certains accords.

23

Un système autonome de niveau 1 ou Tier 1 fournit un transit pour ses clients et dispose d’un ensemble d’accord de peering. Ces deux types d’accord lui permettent de joindre tous les systèmes autonomes de l’Internet. Par conséquent, les systèmes autonomes de niveau 1 ont des accords de peering mutuels, et constituent une sorte de cœur de l’Internet. AT&T, TeliaSonera, Level3, Cogent, sont quelques exemples de systèmes autonomes de niveau 1. Particulièrement, Level3 est fournisseur de près de 4000 clients et il a conclut des accords de peering avec près de 70 systèmes autonomes. La stratégie de peering appliquée par les systèmes autonomes de niveau 1 est dite restrictive. Cela impose à tout système autonome candidat pour un accord de peering des contraintes très strictes de couverture géographique, de capacité, et d’équilibre de trafic échangé.

24

Les systèmes autonomes de niveau 2 ou Tier 2 sont mixtes : ils dépendent d’un fournisseur de transit, généralement de niveau 1, et proposent à leur tour une offre de transit à leurs clients. Un système autonome de niveau 2 applique une stratégie de peering sélective. Il négocie pour conclure des accords de peering avec des systèmes autonomes équivalents, ce qui permet de réduire les factures de transit.

25

Les systèmes autonomes de niveau 3 ou Tier 3 sont clients de fournisseurs de transit de niveau supérieur. Ils ne proposent pas d’offre de transit. Un système autonome de niveau 3 applique généralement une stratégie de peering ouverte et cherche à s’interconnecter aux points d’échange pour réduire les factures de transit.

26

Dans cette leçon, nous avons introduit et analysé les types accords entre systèmes autonomes. L’accord de transit est un accord payant de type client/fournisseur qui permet au client de joindre le reste de l’Internet. L’accord de peering est un accord généralement non payant d’échange de trafic entre deux systèmes autonomes ou entre leurs clients. Nous avons aussi souligné l’importance des points d’échange dans la structure de l’Internet. Finalement, nous avons présenté la classification des systèmes autonomes en trois niveaux selon les accords conclus.

3. Leçon 3 : Principes du routage externe – Stratégies de routage

Bonjour et bienvenue dans cette leçon, dans laquelle nous abordons les principes du routage externe. Nous traitons ici de l’échange d’informations et de la mise en place de stratégie de routage.

27

Sur Internet, chaque système autonome gère un ou plusieurs blocs contigus d’adresses IP appelés préfixes. Ces préfixes servent à numéroter les équipements du système autonome ou ceux de ses clients. La mise en place du routage externe permet de rendre joignables ces préfixes sur Internet. Considérons le système autonome A qui gère les préfixes 10.1.0.0/16 et 192.168.1.0/24. Grâce à un protocole de routage externe, le routeur du système autonome A annonce ses préfixes au voisin B. Suite à la réception des annonces du protocole de routage externe, le routeur du système autonome B met en place deux entrées dans la table de routage qui permettent de router le trafic vers les préfixes de A. Lors de l’envoi de trafic depuis le système autonome B vers l’adresse 10.1.0.1 par exemple, cette table de routage permettra de router le trafic vers A. Bien évidemment, pour avoir des échanges bidirectionnels, B doit annoncer le préfixe 192.168.2.0/24 qu’il gère. A la réception des annonces du protocole de routage, le routeur de A met en place une entrée correspondante dans la table de routage pour joindre le préfixe de B.

28

Comme il n’existe pas de système autonome central dans l’Internet, le relayage des annonces de préfixes est une fonction importante du routage externe : elle permet à un système autonome de propager l’information de ses préfixes en ayant un nombre réduit de voisins directs. Supposons que le système autonome A a deux voisins B et C. Grâce au protocole de routage externe, les routeurs du système autonome A annoncent ses préfixes aux voisins B et C. De même, les routeurs de B et C peuvent relayer l’information vers les systèmes autonomes D et E. Ainsi, de proche en proche l’information se propage pour atteindre tous les systèmes autonomes de l’Internet.

29

Suite à la réception des annonces du protocole de routage externe, les systèmes autonomes B, C, D, et E peuvent mettre en place des entrées dans leur table de routage qui permettent de router le trafic vers les préfixes de A. Par exemple, C a reçu l’annonce des préfixes de A via B. Il met alors en place une entrée dans la table de routage sur son routeur qui indique que pour joindre les préfixes de A il faut envoyer le trafic vers B. Si un équipement du système autonome C essaie de joindre l’adresse 10.1.0.1, le routeur de C consulte les informations de routage et transmets le trafic vers B. A son tour, le routeur consulte la table de routage et transmets vers la destination dans le système autonome A.

30

La possibilité de mettre en place des stratégies de routage est une caractéristique principale du routage externe. D’une manière simple, une stratégie de routage externe consiste à contrôler l’envoi des annonces de préfixes et le traitement des annonces reçues. Une stratégie de routage est décidée par chacun des systèmes autonomes. Considérons le système autonome A qui annonce ses deux préfixes vers son voisin B. Ce dernier met donc en place des entrées dans la table de routage de son routeur pour joindre les préfixes de A. Un premier exemple de stratégie de routage mise en place par A consiste à annoncer uniquement son préfixe 10.1.0.0/16 et bloquer l’annonce de 192.168.1.0/24. Cette stratégie a un impact sur B qui ne pourra plus joindre le préfixe filtré par A. Un deuxième exemple de stratégie de routage mise en place par par B consiste à ne pas sélectionner l’annonce du préfixe 10.1.0.0/16 en provenance de A. En effet, B peut décider tout simplement de ne pas envoyer de trafic vers ce préfixe ou alors préférer passer par un autre système autonome qui a relayé une annonce du même préfixe.

31

Observons la mise en place de ses stratégies de routage sur un exemple de cinq systèmes autonomes. Commençons par l’annonce sélective de préfixes qui permet à un système autonome de contrôler le trafic entrant. En particulier, le système autonome A choisit d’annoncer le préfixe 10.1.0.0/16 vers son voisin B, et le préfixe 192.168.1.0/24 vers son voisin D. L’annonce du préfixe 192.168.1.0/24 peut être relayée de D, vers E, C, puis vers B. Les routeurs de B peuvent maintenant mettre en place des entrées dans leur table de routage vers les deux préfixes de A. Ainsi, le trafic du système autonome B à destination de 10.1.0.0/16 sera transmis directement vers A, alors que le trafic à destination de 192.168.1.0/24 sera transmis vers C puis E, D, et enfin A. Avec la stratégie d’annonce sélective, le système autonome A partage le trafic à destination de ses deux préfixes : une partie du trafic entrant sur le lien avec B, une autre sur le lien avec D.

32

Prenons maintenant l’exemple d’une stratégie de routage basée sur la sélection des annonces reçues. Le système autonome A annonce ses deux préfixes aux voisins B et D. Ce dernier relaye l’annonce qui arrive de proche en proche jusqu’à B. Ainsi, B reçoit les annonces des préfixes de A via ses deux voisins. B peut mettre en place une stratégie de routage basée sur la préférence des annonces reçues. Il peut sélectionner l’annonce en provenance de A. Dans ce cas, le trafic vers les préfixes de A sera acheminé sur le lien direct de B vers A. Autrement, B peut sélectionner l’annonce en provenance de C, et le trafic vers les préfixes de A sera acheminé via C, E et D. B a même la possibilité de préférer l’annonce en provenance de A pour le préfixe 10.1.0.0/16 et celle en provenance de C pour le préfixe 192.168.1.0/24. Le trafic en sortie de B vers A sera donc partagé sur les deux chemins possibles.

33

Grâce aux informations de routage externe, le système autonome A achemine son trafic via B pour atteindre C. Supposons que les routeurs B1 et B5 qui assurent l’échange d’informations de routage externe et l’échange de trafic ne sont pas directement connectés. Le système autonome B dispose d’une infrastructure avec cinq points de présence qui sont les routeurs B1 à B5. Comment est routé le trafic qui va de A vers C lorsqu'il passe par le système autonome B ? En plus du routage externe, le système autonome B déploie un routage interne qui permet de calculer les meilleurs chemins entre ses différents routeurs. Ce calcul considère des métriques techniques telles que la capacité des liens. De plus, l’opérateur du système autonome B a le contrôle total sur le routage interne : il peut choisir le protocole, la métrique, ou le plan d’adressage associés. Considérons que le meilleur chemin entre B1 et B5 passe par B2. Ce segment de chemin permet de traverser B et vient donc compléter le chemin de bout en bout entre A et C.

34

Routage externe et interne sont donc deux fonctions complémentaires mais indépendantes. Ceci nous permet de dresser un tableau comparatif des leurs principales caractéristiques : Premièrement, le routage externe est déployé entre deux systèmes autonomes différents. Ceci impose des règles de contrôle des annonces de routage reçues depuis les voisins. Dans le routage interne, les routeurs voisins sont forcément de confiance puisqu’ils font partie d’un même système autonome. Deuxièmement, le routage externe offre la possibilité de mettre en place des stratégies de routage en filtrant les annonces envoyées ou reçues. Au contraire, le routage interne est basé sur le principe de la diffusion des informations de routage entre tous les routeurs. Finalement, le routage externe se base sur les stratégies de routage et les types d’accords entre les systèmes autonomes pour calculer le meilleur chemin. Alors que ce même calcul repose sur des métriques techniques telles que le nombre de routeurs traversés ou la capacité des liens dans le cas du routage interne.

35

Dans cette leçon, nous avons introduit les principes du routage externe. Nous avons analysé les mécanismes d’annonce de préfixes et de mise en place de tables de routage. Nous avons introduit la notion de stratégie de routage et donné deux exemples : le premier est basé sur le contrôle des annonces de routage envoyées, le deuxième sur la sélection des annonces reçues. Nous avons terminé la leçon par un comparatif entre le routage externe et le routage interne. Ces deux mécanismes sont indépendants mais se complètent pour assurer l’acheminement du trafic de bout en bout sur Internet.

4. Leçon 4 : Principes du protocole BGP – Sessions et messages BGP

Bonjour et bienvenue dans cette leçon, dans laquelle nous abordons les principes du protocole BGP. Nous traitons ici de la mise en place des sessions BGP et des différents types de messages échangés.

36

BGP ou Border Gateway Protocol est le seul protocole de routage externe déployé sur Internet. La version 4 actuellement utilisée est définie dans le RFC 4271 de l’IETF. Les systèmes autonomes utilisent BGP pour annoncer leurs préfixes d’adresses IP et pour mettre en place leurs stratégies de routage.

37

Quels sont les cas de figure qui nécessitent la mise en place de BGP ? Lorsqu'un un réseau dispose d’un seul fournisseur, et qu’il n’a pas besoin d’établir une stratégie de routage externe, la mise en place de BGP n’est pas nécessaire. Cette mise en place devient nécessaire quand un système autonome dispose de plusieurs fournisseurs, on parle alors de multi-­domiciliation. BGP permet dans ce cas d’appliquer des stratégies de routage telles que la mise en place d’un lien nominal et d’un lien de secours ou le partage de trafic sur les différents liens.

38

Le deuxième cas de figure qui nécessite typiquement la mise en place de BGP est celui d’un fournisseur qui offre le transit à d’autres systèmes autonomes ou d’un fournisseur de services qui offre par exemple la mise en place de réseaux privés virtuels (VPN) à ses clients.

39

BGP est un protocole de type vecteur chemin ou « path-­vector ». Le message BGP qui annonce un préfixe contient aussi la liste des systèmes autonomes à traverser pour atteindre ce préfixe. Prenons l’exemple du système autonome A qui gère le préfixe 10.1.0.0/16. Le message BGP envoyé par le routeur A1 vers le routeur B1 permet d’annoncer le préfixe de A. La liste de systèmes autonomes à traverser contient le numéro de A. Si la stratégie de routage de B le permet, un message BGP envoyé par B2 vers C1 annoncera le préfixe de A. Dans ce message, la liste de systèmes autonomes à traverser contient le numéro de B suivi par celui de A. C a maintenant appris qu’il peut joindre le préfixe 10.1.0.0/16 et il dispose du chemin de systèmes autonomes pour atteindre A. Les propriétés d’un protocole de type vecteur chemin permettent à BGP de répondre à deux enjeux importants du routage externe : Premièrement, l’information du chemin de systèmes autonomes à traverser est une information macroscopique. Elle permet de masquer toute le complexité interne et les états de liens dans chaque système autonome. Ceci permet à BGP de passer à l’échelle pour un déploiement sur Internet. Deuxièmement, chaque système autonome décide des annonces de préfixes et du traitement des annonces reçues par BGP. Ceci permet la mise en place de stratégies de routage et préserve l’autonomie des décisions.

40

Pour annoncer leurs préfixes, les systèmes autonomes établissent une session BGP entre leurs routeurs. Dans l’exemple des systèmes autonomes A et B, une session BGP est établie entre les routeurs A1 et B1. Cette session permet d’échanger des messages BGP : un message est envoyé de A1 vers B1 pour annoncer le préfixe 10.1.0.0/16 de A. Un autre message est envoyé de B1 vers A1 pour annoncer le préfixe 10.2.0.0/16 de B.

41

Le protocole BGP appartient à la couche applicative selon le modèle TCP/IP. Il s’appuie sur le protocole de transport TCP. Ceci permet de s’affranchir de la nécessité de supporter explicitement les fonctions de fragmentation, de retransmission, d’acquittement et de séquencement qui sont des fonctions naturellement supportées par le protocole TCP. Les messages BGP sont donc transportés dans des segments TCP, auxquels s’ajoutent les entêtes des couches inférieures (IP et Ethernet par exemple) avant d’être transmis sur la couche physique.

42

Prenons l’exemple de quatre systèmes autonomes A, B, C, et D. En particulier, le système autonome A gère le préfixe 10.1.0.0/16. Les routeurs A1 et B1 établissent une session BGP qui permet à A1 d’annoncer le préfixe de A. Supposons que la stratégie de routage de B consiste à annoncer le préfixe de A vers C et D, comment les routeurs B2 et B3 sont-­ils informés de ce préfixe ? En effet, les routeurs B1, B2, et B3 du système autonome B établissent des sessions BGP. Ainsi, B1 peut envoyer un message BGP vers B2 pour lui annoncer le préfixe de A. B2 peut maintenant annoncer le préfixe vers C1. De même, B1 annonce le préfixe de A vers B3 qui peut relayer l’information vers le système autonome D.

43

Il existe donc deux types de sessions BGP qui servent à échanger les préfixes : Les sessions entre routeurs de deux systèmes autonomes différents par exemple A1 et B1. Ces sessions sont appelées eBGP ou external BGP. Les sessions entre routeurs du même système autonome par exemple B1 et B2. Ces sessions sont appelées iBGP ou internal BGP. Afin de garder une vue cohérente des préfixes appris par BGP, les systèmes autonomes mettent en place des sessions iBGP entre tous leurs routeurs BGP.

44

Quelle relation existe entre iBGP et le routage interne ? Même si les sessions iBGP sont établies entre les routeurs d’un même système autonome, il s’agit toujours de sessions de routage externe. Supposons qu’après l’établissement des sessions eBGP et iBGP, le système autonome C reçoit l’annonce du préfixe 10.1.0.0/16 de A. C peut maintenant joindre A à travers B. En particulier, l’échange iBGP permet de déterminer que le trafic doit être routé de B2 vers B1. Reste donc la question du calcul du chemin interne entre B2 et B1 : ce calcul est effectué par le protocole de routage interne de B et prend en compte des métriques techniques telles que la capacité ou les délais des liens. Considérons que le meilleur chemin calculé par le routage interne entre B1 et B2 passe par B4. Ce segment permet de traverser le système autonome B et vient compléter le chemin de bout en bout de C vers A.

45

Intéressons-­nous maintenant aux types de messages. Le protocole BGP est constitué de quatre messages servant à l’établissement de session, son maintien, à l’échange de préfixes et à la fermeture de session. Le message OPEN sert à ouvrir la session BGP, il permet d’annoncer les numéros de systèmes autonomes et les identifiants des routeurs. Rappelez-­vous que les routeurs qui échangent des informations par BGP sont explicitement paramétrés par l’administrateur du système autonome. L’ouverture de la session fait suite à un accord entre les deux systèmes autonomes et une désignation des équipements pour la mettre en œuvre. Le message KEEPALIVE est envoyé périodiquement afin de maintenir la session BGP. Celle-­ci est fermée si aucun message KeepAlive n’est reçu pendant une période prédéfinie. Le message NOTIFICATION sert à signaler des erreurs. La session est immédiatement fermée suite à l’émission de ce message. Le message UPDATE constitue la pierre angulaire du routage BGP. Il contient la liste des préfixes qu’un routeur souhaite annoncer (ou dont il souhaite supprimer l’annonce) ainsi que les différents attributs associés qui seront explorés dans une prochaine leçon.

46

Schématisons les phases d’un échange protocolaire BGP entre deux routeurs. Au préalable, une connexion TCP sur le port serveur 179 est établie entre les deux routeurs. Sur cette connexion le routeur A et le routeur B envoient des message d’ouverture de session. Si l’ouverture de session est acceptée, les routeurs acquittent par des messages keepalive. Ces messages keepalive sont envoyés périodiquement pour maintenir la session BGP entre les routeurs. Ensuite, chaque routeur annonce la liste de préfixes joignables dans des messages update. Dorénavant, si un changement a lieu pour un préfixe (dû une suppression ou une modification des attributs), seul le préfixe modifié sera annoncé par un message update.

47

Dans cette leçon, nous avons analysé les différents principes du protocole BGP. BGP est un protocole de routage externe de type vecteur chemin. Chaque préfixe annoncé est accompagné de la liste de systèmes autonomes à traverser pour atteindre ce préfixe. Nous avons identifié les deux types de sessions BGP entre les routeurs : les sessions iBGP entre les routeurs d’un même système autonome et les sessions eBGP entre les routeurs de deux systèmes autonomes différents. Ensuite, nous avons défini les différents types de messages BGP dont principalement le message UPDATE qui permet d’annoncer les préfixes. Finalement nous avons mis en place un exemple d’échange protocolaire entre deux routeurs BGP.

5. Leçon 5 : Attributs du protocole BGP Bonjour et bienvenue dans cette leçon, dans laquelle nous abordons les attributs du protocole BGP. Nous traitons ici des différentes propriétés transportées dans les messages d’annonce de préfixes et de leur utilisation dans le routage BGP.

48

Dans les messages BGP, les routeurs annoncent obligatoirement pour chaque préfixe un attribut qui renseigne le chemin de systèmes autonomes. Cet attribut est noté AS_PATH. Comment l’attribut AS_PATH est-­il construit ? Prenons l’exemple du système autonome A qui gère le préfixe 10.1.0.0/16. Le message BGP envoyé par le routeur A1 vers le routeur B1 permet d’annoncer le préfixe de A. L’attribut AS_PATH contient le numéro de A. Ensuite, cette annonce est relayée par iBGP jusqu’à B2, sans modification de l’AS_PATH. Si la stratégie de routage de B le permet, un message BGP envoyé par B2 vers C1 annoncera le préfixe de A. Dans ce message, l’AS_PATH contient le numéro de B suivi par celui de A. Ainsi, de proche en proche l’AS_PATH contiendra pour chaque préfixe l’ensemble des numéros de systèmes autonomes à traverser pour atteindre ce préfixe.

49

Comment est utilisé l’attribut AS_PATH dans le routage externe ? Premièrement, l’AS PATH est utilisé dans la détection des boucles dans le chemin de systèmes autonomes. Supposons que le système autonome A annonce le préfixe 10.1.0.0/16 et que cette annonce est relayée par les systèmes autonomes B, C, et D, puis transmise vers A. Lorsque le routeur A2 reçoit l’annonce BGP, l’AS_PATH contient (D C B A). A2 note la présence de son propre numéro de système autonome dans l’AS_PATH. Une boucle est alors détectée et l’information de routage reçue par A2 est ignorée.

50

Deuxièmement, l’attribut AS_PATH est utilisé dans la mise en place de stratégies de routage. Supposons que le système autonome C a reçu deux annonces de routage concernant le préfixe 10.1.0.0/16 géré par A : une première annonce via le chemin (A B), une deuxième via (A E D). Le système autonome C peut préférer le chemin de systèmes autonomes le plus court. Dans ce cas, la première annonce sera choisie et le trafic empruntera le chemin (C B A). Notons bien que rien ne garantit que le chemin avec l’AS_PATH le plus court soit le meilleur, que ce soit en débit ou en latence ou en nombre de routeurs traversés. Mais c’est la seule information de topologie que BGP connaisse. Autrement, C peut appliquer une stratégie de routage pour exclure le chemin qui contient B. De cette façon le trafic de C empruntera le chemin (C D E A).

51

Analysons maintenant l’attribut NEXT_HOP. Cet attribut obligatoire permet de désigner le prochain saut pour joindre une destination. Lorsque le routeur A1 annonce le préfixe 10.1.0.0/16 l’attribut NEXT_HOP contient l’adresse IP de A1. Par défaut, cet attribut n’est pas modifié par iBGP dans le système autonome B. Cependant, lorsque B2 annonce le préfixe de A vers C1, il modifie la valeur du NEXT_HOP pour mettre sa propre adresse. Notons que pour les routeurs de B, en particulier B2, A1 est le prochain saut vers 10.1.0.0/16. Le routeur B2 doit donc pouvoir joindre A1 qui est dans un autre système autonome. Comment cela est-­il possible en pratique ? Il existe deux solutions à ce problème. La première consiste à annoncer l’adresse IP de A1 dans le protocole de routage interne du système autonome B. Ainsi, B2 peut joindre A1 via le meilleur chemin calculé selon les métriques du routage interne. La deuxième consiste à configurer B1 pour mettre son adresse IP dans l’attribut NEXT_HOP de l’annonce iBGP.

52

Le troisième attribut que nous analysons est la préférence locale notée LOCAL_PREF. Cet attribut iBGP facultatif permet de contrôler la route empruntée par le trafic en sortie d’un système autonome. Supposons que le système autonome C a reçu deux annonces de routage pour le préfixe 10.1.0.0/16 : un première via les systèmes autonomes A et B, une deuxième via A et D. L’opérateur du système autonome C peut configurer ces routeurs C1 et C2 de la sorte : C1 ajoute une préférence locale égale à 300 dans les annonces iBGP, alors que C2 ajoute une préférence local égale à 200. Les routeurs C1, C2 et C3 recevant les deux informations sélectionnent celle qui a la préférence locale la plus élevée. Ainsi, tout le trafic du système autonome C à destination de 10.1.0.0/16 sortira par le routeur C1 pour traverser ensuite les systèmes autonomes B puis A.

53

Intéressons-­nous maintenant à l’attribut Multi-­Exit Discriminator ou MED. Cet attribut optionnel eBGP permet de contrôler la route empruntée par le trafic en entrée d’un système autonome. Généralement, l’attribut MED est utilisé dans le cas de deux systèmes autonomes qui ont mis en place plusieurs liens d’interconnexion. Supposons que les systèmes autonomes A et B disposent de deux liens d’interconnexion. A peut choisir de configurer ses routeurs pour envoyer dans les annonces de préfixe un attribut MED égal à 2000 pour A1 et 1000 pour A2. B1 et B2 reçoivent ces messages et échangent l’information de routage par iBGP avec l’attribut MED non modifié. Les routeurs du système autonome B disposant des deux informations sélectionnent celle qui a l’attribut MED le plus petit. Ainsi, tout le trafic du système autonome B à destination de 10.1.0.0/16 arrivera vers A via le lien A2-­B2.

54

Abordons maintenant l’attribut ORIGIN. Cet attribut obligatoire permet de décrire l’origine de l’information de routage pour le préfixe annoncé. Trois valeurs possibles ont été définies : 1-­ Lorsque l’attribut a pour valeur « 0 », le préfixe annoncé par BGP est interne au système autonome qui a généré l’information. 2-­ Lorsque l’attribut a pour valeur « 1 », le préfixe annoncé par BGP est externe au système autonome qui a généré l’information. 3-­ Lorsque l’attribut a pour valeur « 2 », l’origine de l’information est incomplète. Le préfixe correspondant a par exemple été injecté dans BGP par un processus de redistribution statique ou dynamique. Pour un même préfixe, une annonce avec l’attribut ORIGIN égal à 0 est préférée à une annonce avec l’attribut égal à 1, qui à son tour est préférée à une annonce avec la valeur 2.

55

Le dernier attribut que nous analysons est la communauté BGP notée COMMUNITIES. La communauté, attribut optionnel, est une étiquette qui permet d’appliquer une même stratégie à un groupe de préfixes annoncés par BGP. Cette stratégie peut consister à contrôler l’acceptation, le relayage, ou la modification des attributs du groupe de préfixes. L’objectif principal de la mise en place des communautés est la simplification de configuration des routeurs BGP. En particulier, il est d’usage de mettre en place des communautés par types de clients, par région géographique, ou selon l’accord d’échange de trafic entre les voisins. Il existe des communautés prédéfinies telles que la communauté no-­export. Les préfixes annoncés avec une telle communauté ne sont pas relayés vers les voisins eBGP. Dans l’exemple du système autonome A qui annonce à B son préfixe 10.1.0.0/16 avec la communauté no-­export. Les routeurs de B relayent cette information par iBGP mais ne l’annoncent pas par eBGP à C. Ainsi, C dispose uniquement du chemin via D et E pour atteindre le préfixe de A. Alors que B peut utiliser le lien direct avec A pour joindre ce préfixe.

56

D’autres communautés peuvent être définies par les systèmes autonomes. Généralement, les communautés sont notées sous le format « numéro_de_système_autonome (2 octets):numéro_communauté (2 octets) ». Prenons l’exemple du système autonome B qui déclare les communautés B:100 et B:200. Ces communautés lui permettent de fixer la préférence locale à 100 et 200 respectivement. Un système autonome voisin A peut annoncer son préfixe 10.1.0.0/16 avec la communauté B:100 vers B1, et B:200 vers B2. Les routeurs de B sont configurés pour appliquer la préférence locale selon la communauté transportée. Par conséquent, B2 sera la sortie préférée du trafic de B vers le préfixe de A.

57

Dans cette leçon, nous avons analysé les différents attributs des préfixes annoncés par BGP et identifié leur utilisation dan le routage BGP. Ainsi, l’attribut AS_PATH permet de détecter les boucles de routage ou d’appliquer des stratégies en fonction des systèmes autonomes traversés. Le NEXT_HOP permet d’identifier le prochain saut pour joindre le préfixe destination. Le LOCAL_PREF permet de contrôler le routage du trafic sortant d’un système autonome. Le MED permet de préférer une entrée dans un système autonome lorsque deux voisins disposent de plusieurs liens d’interconnexion. L’attribut ORIGIN identifie l’origine de l’information de routage sur le système autonome qui gère le préfixe. Finalement, la communauté BGP est un attribut flexible qui permet d’appliquer une même stratégie à un groupe de préfixes annoncés par BGP.

6. Leçon 6 : Processus de sélection dans BGP – Critères de sélection et informations de routage

58

Bonjour et bienvenue dans cette leçon, dans laquelle nous abordons le processus de sélection dans BGP. Nous traitons ici des différentes étapes qui permettent de comparer les annonces de préfixes et du traitement des informations de routage obtenues par BGP.

Sur Internet, l’interconnexion entre systèmes autonomes offre une diversité des chemins : il existe souvent plusieurs chemins qui permettent de joindre un même préfixe. Cette diversité rend le routage externe robuste en cas de pannes dans l’un des systèmes autonomes. Prenons l’exemple du système autonome C qui reçoit l’annonce du préfixe de A via le chemin (B A), et via le chemin (D E A). C doit sélectionner une des annonces pour mettre en place une entrée correspondante dans sa table de routage. Cette entrée servira à router le trafic de C vers A. Dans ce contexte, nous dégageons la problématique suivante : comment un système autonome sélectionne-­t-­il une annonce parmi celles reçues ? Quels sont les critères qui sont pris en compte ? Quels sont les attributs transportés dans les messages BGP qui interviennent dans cette sélection ?

59

Considérons un exemple de cinq systèmes autonomes A, B, C, D et E, et un préfixe 10.1.0.0/16 géré par A. Les sessions eBGP permettent de relayer les annonces du préfixe de A jusqu’à C. Ensuite, les sessions iBGP permettent de faire parvenir à C3 deux annonces de ce préfixe : l’une en provenance de C1, l’autre de C2. Dans la suite, nous allons dérouler le processus de sélection sur les routeurs du système autonome C.

60

Le processus de sélection prend en compte une suite de critères. Les annonces candidates sont comparées en utilisant chacun des critères dans l’ordre indiqué. Au début du processus, les annonces candidates correspondent à toutes les annonces reçues pour un même préfixe. A chaque critère, certaines annonces peuvent être écartées. Le processus s’arrête alors lorsque le résultat de la comparaison permet de sélectionner une et une seule annonce.

61

Le premier critère de comparaison est la valeur de l’attribut de préférence locale ou LOCAL_PREF transporté dans les messages iBGP. L’annonce avec la valeur de préférence locale la plus élevée est sélectionnée.

62

Dans l’exemple étudié, le routeur C3 reçoit deux annonces en provenance de C1 et C2 avec une valeur de l’attribut de préférence locale égal à 200 et 100 respectivement. Dans ce cas, l’annonce en provenance de C1 est sélectionnée et le processus s’arrête.

63

Le premier critère étudié peut ne pas aboutir à la sélection d’une seule annonce : ceci se présente lorsque l’attribut de préférence locale n’est pas utilisé ou lorsque plusieurs annonces vers le même préfixe ont la même valeur de LOCAL_PREF. Dans ce cas, le processus de sélection passe au deuxième critère. Ce critère correspond à la longueur du chemin de systèmes autonomes pour joindre le préfixe annoncé. L’annonce avec le chemin de système autonome le plus court est sélectionnée.

64

Dans notre exemple, l’annonce en provenance de C1 indique qu’il faut traverser deux systèmes autonomes pour joindre le préfixe de A. Celle en provenance de C2 indique un chemin de trois systèmes autonomes. Par conséquent, la première annonce est sélectionnée. Rappelons-­nous que rien ne garantit que le chemin le plus court en termes de systèmes autonomes soit le meilleure, que ce soit en débit ou en latence ou en termes de routeurs traversés.

65

Après l’AS_PATH, on compare l’attribut ORIGIN des annonces candidates restantes. Selon cet attribut, les annonces sont sélectionnées dans l’ordre suivant: Un préfixe interne au système autonome qu’il l’a généré l’emporte sur un préfixe externe à ce système autonome, qui à son tour l’emporte sur un préfixé appris par un processus de redistribution statique ou dynamique.

66

Le processus peut maintenant passer à la comparaison de l’attribut MED contenu dans les annonces candidates. L’annonce avec la valeur MED la plus petite est sélectionnée. Rappelons-­que l’attribut MED permet de proposer à un système autonome voisin un lien préféré pour le trafic entrant.

67

Ensuite, la comparaison porte sur le type de session BGP. L’annonce du préfixe en provenance d’un routeur d’un système autonome différent est préférée à une annonce en provenance du même système autonome.

68

Dans notre exemple, le routeur C1 reçoit une annonce eBGP du préfixe de A en provenance de B2, et deux annonces iBGP en provenance de C2 et C3. Selon le critère étudié, l’annonce en provenance de B2 est sélectionnée. Ainsi, C1 route le trafic vers A en passant par B2 au lieu de passer par C2 ou C3. Globalement, ce critère permet de préserver les ressources du système autonome qui déroule le processus de sélection en préférant router le trafic directement vers le voisin.

69

En poursuivant sur le même objectif de préservation des ressources, le prochain critère de comparaison est le coût du chemin interne. L’annonce qui utilise le chemin le plus court vers le prochain saut est sélectionnée. En général, le coût du chemin est évalué selon la métrique du routage interne.

70

Revenons au routeur C3 qui reçoit deux annonces du préfixe de A. La première indique un prochain saut qui est C1, la deuxième C2. C1 compare les coûts selon le protocole de routage interne pour atteindre le prochain saut. Supposons que le coût du chemin pour atteindre C1 est égal à 10, alors que pour atteindre C2, ce coût est égal à 100. Dans ce cas, l’annonce en provenance du routeur C1 est sélectionnée. Comme indiqué, ce critère permet de joindre le plus rapidement la sortie du système autonome, afin de minimiser l’utilisation des ressources internes telles que la capacité sur les liens.

71

Si le processus ne réussit pas à départager les annonces candidates après la suite des critères analysés précédemment, un dernier critère est introduit. Ce critère est typiquement basé sur les identifiants ou les adresses IP inclut dans l’attribut NEXT_HOP. Par exemple, l’annonce en provenance du routeur avec l’identifiant le plus petit est sélectionnée et le processus s’arrête.

72

Analysons maintenant le traitement des informations de routage effectué par un routeur BGP. A la réception des annonces de préfixes, un routeur BGP applique des stratégies d’import. Ces stratégies de routage peuvent consister par exemple en un filtrage de certaines annonces, ou la modification d’attributs tels que la communauté ou la préférence locale, … Après passage par les stratégies d’import, les annonces BGP sont stockées dans une table dédiée par voisin. L’ensemble de ces annonces alimentent le processus de sélection étudié précédemment. Ce processus sélectionne la meilleure annonce par préfixe. Cette dernière génère alors une information de routage constituée par le préfixe destination et le prochain saut hérité de l’attribut NEXT_HOP. L’information de routage s’ajoute dans la table de routage du routeur BGP et peut désormais servir à acheminer les paquets vers la destination. Suite à l’apparition ou au changement d’une entrée dans la table de routage, le routeur applique des stratégies d’export et décide des informations à annoncer à chaque voisin. Ces annonces sont stockées dans des tables dédiées puis transmises dans des messages BGP vers les voisins correspondants.

73

Cet exemple permet d’illustrer le traitement des informations de routage dans BGP. Considérons cinq routeurs qui ont établi des sessions de routage BGP. Le routeur R2 annonce à R1 le préfixe 10.1.0.0/16 avec un AS_PATH contenant deux systèmes autonomes. Le routeur R3 annonce à R1 le même préfixe avec un AS_PATH contenant trois systèmes autonomes. A la réception de ces annonces, R1 applique les stratégies d’import. Supposons que ces stratégies sont transparentes dans cet exemple. Par conséquent, R1 stocke les annonces reçues dans les tables dédiées à chaque voisin R2 et R3. Le processus de sélection traite ensuite l’ensemble des annonces reçues pour le préfixe 10.1.0.0/16. En comparant la longueur des chemins de systèmes autonomes, R1 sélectionne l’annonce en provenance de R2. Cette annonce est injectée dans la table de routage de R1 qui peut désormais router les paquets vers 10.1.0.0/16 en passant par R2. L’étape suivante consiste à annoncer ce préfixe aux voisins de R1. Supposons que la stratégie d’export lui autorise uniquement d’annoncer ce préfixe vers R4. Dans ce cas, cette annonce est stockée dans la table d’annonces envoyées dédiée à R4 en mettant un attribut NEXT_HOP qui correspond à l’adresse de R1. Cette information est enfin envoyée dans un message BGP vers R4.

74

Dans cette leçon, nous avons analysé les différentes étapes de sélection des annonces BGP. Le processus prend en compte un ensemble de critères qui proviennent des attributs transportés (tels que la préférence locale ou le chemin de systèmes autonomes) ou des configurations des routeurs (tels que le type de session ou le coût du routage interne). Ce processus a pour objectif de sélectionner une annonce par préfixe. Les critères sont alors utilisés successivement afin d’atteindre cet objectif. Nous avons aussi révélé les différentes étapes de traitement des informations de routage depuis la réception jusqu’à l’envoi des annonces BGP en passant par la sélection et la mise en place de la table de routage.

7. Leçon 7 : Exemples de stratégies de routage – Peering et transit avec BGP

Bonjour et bienvenue dans cette leçon, dans laquelle nous abordons des exemples de déploiement de stratégies de routage BGP. Nous traitons ici de la mise en place des accords de peering et de transit avec BGP.

75

Prenons l’exemple de cinq systèmes autonomes A, B, C, D, et E. Des accords de transit sont conclus entre les différents systèmes autonomes : A est fournisseur de transit de B, B est fournisseur de C, et D est fournisseur de E. De plus, un accord de peering est conclu entre B et D pour échanger leur trafic ainsi que celui de leurs clients. Dans un tel schéma, comment sont établies les stratégies de routage BGP ? Quels sont les préfixes annoncés entre les différents systèmes autonomes ?

76

Prenons le point de vue du système autonome B et notons les annonces de préfixes reçues. B reçoit un message BGP de C qui lui annonce son préfixe 10.2.0.0/16. Il reçoit sur le lien de peering l’annonce du préfixe de D 192.168.1.0/24 et de son client E 192.168.2.0/24. Finalement, il reçoit de la part de son fournisseur A la table globale de l’Internet. Cette table contient tous les préfixes d’adresses publiques annoncés par tous les systèmes autonomes.

77

A ce stade, B a reçu toutes les annonces de préfixes via A, D, et C. Établissons donc les annonces de préfixes envoyés par B. Ce dernier met en place des stratégies d’export afin de relayer convenablement les préfixes vers les voisins. En particulier, B annonce son préfixe interne à son fournisseur A afin de le rendre joignable depuis Internet. De plus, B annonce à A le préfixe de son client C conformément à l’accord de transit. C peut alors recevoir du trafic depuis l’Internet via B. Notons que B ne doit en aucun cas annoncer à A les préfixes de son voisin en peering D ni de son client E. Sinon, B recevra du trafic depuis l’Internet à destination de D ou de E. Ce trafic lui sera facturé par A alors qu’il ne pourra pas recevoir une compensation de la part D. En effet, l’accord de peering avec D est un accord non payant. Selon les règles de l’accord de peering, B annonce à D son préfixe et celui de son client C. B et D peuvent donc maintenant échanger directement du trafic vers leurs préfixes et ceux de leurs clients sans passer par les fournisseurs. Finalement, B envoie la table globale de l’Internet vers son client C. Ce dernier peut donc joindre l’ensemble des préfixes sur Internet via B.

78

Autrement, B peut choisir de remplacer l’annonce de la table globale par une route par défaut. Cette solution réduit les possibilités de mise en place de stratégies de routage sur C mais allège d’une manière significative la charge de son routeur.

Ajoutons à l’exemple précédent un accord de transit établi entre C et D. Le système autonome B reçoit maintenant trois annonces pour le préfixe 10.2.0.0/16: une annonce en provenance directe de son client C. Une deuxième en provenance de son voisin D en peering. Plus précisément, D annonce son préfixe interne et les préfixes de ses clients C et E. Une troisième annonce en provenance de A et inclue dans la table globale de l’Internet. Dans ce cas de figure, comment peut-­on traduire les préférences de B entre les différents accords ? Quelle annonce sera sélectionnée par B afin de router le trafic vers le préfixe de C ? B a donc reçu l’annonce du préfixe de C via trois types d’accords différents : client, fournisseur et peering. En prenant en compte les types de facturation de chacun de ces accords, B préfère en premier lieu envoyer le trafic directement vers C. Sur ce lien, il facture le débit échangé avec C selon l’accord de transit. En deuxième lieu, B peut choisir de passer par D pour atteindre C. Sur ce lien de peering, il n’y a pas de facturation mise en place. En dernier lieu, B peut envoyer le trafic vers C en passant par A: dans ce cas, il sera facturé selon l’accord de transit signé conclu avec A.

79

A l’aide de BGP, la mise en place de cet ordre de préférence est simple. Il suffit de configurer l’attribut de préférence locale à une valeur élevée pour l’annonce arrivant depuis C. Une valeur moyenne peut être choisie pour les annonces en provenance de D. Enfin, une valeur faible est réservée aux préfixes de la table globale de l’Internet annoncés par A. Les échanges iBGP dans le système autonome B permettent de sélectionner l’annonce en provenance de C avec la valeur de la préférence locale la plus élevée. Par conséquent, le trafic de B vers C sera routé sur le lien direct. Si ce lien tombe en panne, le trafic bascule sur le lien de peering et atteindra C via le voisin D. Finalement, si les deux liens précédents sont en panne, le trafic ira vers A qui offre le transit vers tous les préfixes de l’Internet.

Dans les exemples précédents, nous avons mentionné la table globale de l’Internet. Cette table contient les préfixes routés de tous les systèmes autonomes. Il existe actuellement près de 560 000 entrées dans cette table de routage. En observant attentivement l’évolution de cette table, on peut retracer globalement l’évolution de l’Internet. Au début, la progression dans les années 90 est lente. En particulier un palier est constaté entre 1997 et 1999;; ce palier est dû à la mise en place du routage de préfixes sans classes d’adresses et de l’agrégation de préfixes contigus. On note un autre palier en 2001 qui fait suite à l’éclatement de la bulle technologique. Finalement, la croissance à partir de 2010 est exponentielle et témoigne de l’augmentation du nombre de préfixes annoncés, et donc des équipements connectés à Internet.

80

Dans cette leçon, nous avons analysé la mise en place des accords de peering et de transit avec BGP. En particulier, nous avons établi les stratégies d’annonce de préfixes et de sélection des annonces reçues. Ces stratégies renforcent les accords conclus et satisfont les intérêts et les engagements des systèmes autonomes. Par exemple, un système autonome peut mettre en place des préférences locales pour privilégier le lien vers les clients, par rapport à celui avec les voisins en peering, et en dernier lieu le lien de transit payant.