Rapport de TER Résolution des oscillations du protocole BGP

Transcription

1 Rapport de TER Résolution des oscillations du protocole BGP Eltaf ALAMYAR, Pierre de MURALT, Jonathan MICHEL-VILLAZ, Vincent NUNGE Encadrants : Ehoud AHRONOVITZ, Clément SAAD 18 mai 2007

2 Table des matières 1 Introduction Le protocole BGP Annonce des routes dans BGP Processus de sélection Politique de ltrage des annonces Oscillations dans BGP Principe de la solution proposée Maintien de l'état des chemins Détection et Résolution des oscillations Pannes et apparitions de liaisons entre routeurs BGP Principe Panne de liaison Apparitions ou rétablissements de liens Implémentation de la méthode proposée [8] Le simulateur C-BGP La version modiée de C-BGP Développement Installation Méthode d'installation et erreurs résolues Analyse de l'implémentation de la méthode Analyse du programme en détail Le jeton Blanc Critiques sur le code Résolution d'erreurs Les diérentes erreurs de segmentation Nos diérentes méthodes pour résoudre les erreurs Discussion sur la méthode et son fonctionnement Objectifs et résultats Conclusion Annexe Installation de C-BGP Installation de la libgds Installation de C-BGP : Commandes C-BGP Topologie du réseau (chier.topo) Script C-BGP (chier.cli) Extraits de code Adresses Statique Code implémentant Jeton Blanc Structure dans le routeur stockant le jeton blanc Structure du Message transportant le jeton blanc Fonctions relative au mécanisme du jeton blanc Dans le chier as.c Dans le chier maintien.c Dans le chier message.c Dans le chier peer.c

3 Table des gures 1.1 BAD-GADGET. Problème sans solution stable BAD-GADGET composé de 5AS Échange de jeton dû à une oscillation du chemin Illustration d'une panne dans un BAD GADGET à 6 sommets Interprétation de la topologie par C-BGP

4 Chapitre 1 Introduction L'Internet est composé d'un ensemble de systèmes autonomes reliés entre eux, un système autonome (AS) est un réseau dirigé par une administration unique, ayant ses propres politiques de routage. En plus du routage interne, qui fait appel à diérents protocoles tels OSPF ou RIP, les AS communiquent entre eux via un protocole de routage externe nommé BGP (Border Gateway Protocol). Ce protocole a pour objectif de fournir à un AS local le meilleur chemin vers un AS distant tout en respectant sa propre politique de routage, dénie en interne. Cette politique peut tenir compte d'une situation politique, d'un impératif économique...et est condentielle. Ce secret empêche donc d'avoir une vue d'ensemble du réseau et des choix de routes, et est un obstacle à une résolution simple du problème du routage. Du fait de ces politiques de routage secrètes, le protocole n'est pas toujours stable. En eet, l'attribution de degré de préférence à un chemin vers une destination donnée (politique interne) peut causer une oscillation au niveau des tables de routage de BGP en provoquant des changements de route répétitifs. Les diérentes solutions existantes proposées pour résoudre ces oscillations étant plus ou moins abouties, une solution qui consiste à détecter et à traiter les oscillations dans le protocole BGP et faisant usage de jetons, et cela tout en respectant la condentialité des informations et préférences locales a été proposée (voir [8]). 3

5 1.1 Le protocole BGP BGP (Border Gateway Protocol) est le protocole de routage externe utilisé dans l'internet. Il permet d'échanger des données entre AS, qui sont chacun un ensemble de réseaux et de routeurs sous une administration unique. Chaque AS fait appel à des protocoles de routage interne, tels RIP ou OSPF, ainsi qu'à une politique de routage externe. Chaque AS ne contient pas forcément un unique routeur BGP. Tous les routeurs d'un AS appliquent la même politique de routage externe dénie par l'as (pour une destination donnée, les routeurs utilisent les mêmes chemins externes). Cette politique, c'est-à-dire la décision de privilégier, si possible une route par rapport à une autre, peut être dénie selon des critères commerciaux, de performance, de sécurité,...bgp a été conçu pour laisser libre choix aux AS d'appliquer leur propre politique, tout en gardant celle-ci secrète : seul le routeur qui l'applique la connaît. BGP doit répondre à plusieurs attentes. La première consiste à essayer de satisfaire au mieux les exigences imposées par les politiques. Les politiques pouvant être d'origine sécuritaire, économique, ou autre, une seconde attente consiste à respecter le principe de condentialité de ces politiques. Les routeurs BGP ne doivent pas communiquer des informations permettant à des AS de reconstruire la politique d'un autre AS. Cependant, ce libre choix peut entraîner globalement des incohérences entre ces politiques laissant apparaître des oscillations de routes. Dans ce cas, nous sommes en présence d'instabilités inter AS. BGP est un protocole à vecteur de chemins. À la diérence d'un protocole à vecteur de distance tel que RIP, les routeurs impliqués dans un tel protocole communiquent à tous leurs voisins les destinations qu'ils peuvent atteindre en associant non pas seulement la distance qui les sépare d'elles mais le chemin intégral pour atteindre ces destinations. Ainsi, la gestion des boucles devient facile puisqu'il sut à un routeur BGP recevant une route de vérier s'il n'apparaît pas déjà dans cette route ; le cas échéant, il déduit qu'il n'y a pas de boucle sinon il ignore la route Annonce des routes dans BGP Un réseau désirant se faire connaître informe ses voisins BGP de son existence. Les voisins peuvent ignorer ou prendre en compte cette information. Dans le cas où un voisin la prend en compte, il l'annoncera à tous ses voisins. Si un AS annonce une route, il s'engage à accepter le trac vers cette destination. Sinon il ne l'annonce pas. An de diminuer la taille des tables de routage, BGP a la possibilité d'agréger des routes lors de l'annonce d'une route. Par exemple, si un AS est en charge de tous les réseaux ayant les préxes jusqu'à , il peut les agréger et annoncer seulement Une annonce d'une route est composée d'attributs : - AS_PATH : indique la route suivant une liste ordonnée ; - NEXT_HOP : indique l'adresse IP du prochain routeur BGP ; - LOCAL_PREF : attribut interne à l'as utilisé pour le routage externe. Il n'est pas communiqué aux autres AS. Il permet d'accorder un degré de préférence à chaque route ; - ATOMIC_AGGREGATE : indique s'il y a eu agrégation de routes ; - AGGREGATOR : indique l'as ainsi que l'adresse IP du routeur qui a eectué l'agrégation ; - MULTI_EXIT_DISC (MED) : permet, lorsque deux AS sont interconnectés à l'aide de plusieurs liens, d'en discriminer en associant à chaque lien un degré de préférence. Cet attribut est la cause d'oscillations internes aux AS. Pour plus de détails voir : [6] et [11]) Processus de sélection Le protocole BGP est composé de deux sous-parties. Chaque AS ne contient pas un unique routeur BGP. La gestion des communications entre les routeurs internes à l'as se fait par ibgp. Les communications entre les routeurs externes des diérents AS sont gérées par ebgp. Un AS peut avoir plusieurs routes pour une même destination. Le processus de sélection permet de faire le meilleur choix parmi ces chemins en fonction de la politique de l'as. Le processus se déroule de la façon suivante et s'arrête dès qu'il ne reste plus qu'un chemin : - choisir les routes ayant le plus grand LOCAL_PREF ; - choisir les routes traversant le moins d'as ; - pour chaque voisin, sélectionner les routes qui ont le plus petit MED ; - s'il reste au moins une route ebgp, c'est-à-dire annoncée par un AS voisin et non un routeur du même AS, éliminer toutes les routes qui passent au travers de l'as (route annoncée en ibgp). Cette étape permet d'éviter la surcharge de son propre réseau ; 4

6 - utiliser une information déterministe (par exemple : choisir la route qui a la plus grande adresse IP dans NEXT_HOP) Politique de ltrage des annonces Le protocole BGP maintient à jour trois tables appelées RIB (Routing Information Base) : - Adj-RIBs-In contient les informations de routage apprises par les routeurs BGP voisins ; - Loc-RIB contient les informations de routage que le routeur BGP a sélectionné suivant des politiques locales parmi les informations contenues dans Adj-RIBs-In ; - Adj-RIBs-Out contient les informations de routage qui peuvent être communiquées à un autre routeur BGP spécique. Les annonces de routes reçues par un routeur sont ltrées. Seules les annonces respectant la politique de l'as seront placées dans la table Adj-RIBs-In. Le processus de sélection est alors exécuté avec en entrée les données de la table Adj-RIBs-In. Les nouveaux chemins sont mis dans la table Loc-RIB. Ensuite, ces nouveaux chemins subiront un nouveau ltrage pour savoir lesquels d'entre eux vont être réannoncés aux voisins. Ce ltrage s'eectue une nouvelle fois en fonction de la politique de l'as et les chemins sélectionnés seront placés dans la table Adj-RIBs-Out pour être réannoncés Oscillations dans BGP Nous avons vu que les politiques de routages des AS sont privées, ainsi il est impossible qu'une autorité quelconque impose quelque règle que ce soit. En conséquence, chaque AS dénit la règle qui lui convient sans se soucier de ce que cela peut engendrer. C'est à cause de ces politiques que des oscillations, c'est à dire une "non-convergence" du protocole BGP vers un état stable, peuvent apparaître. S'il y a oscillation, BGP est donc incapable d'arriver à une solution stable et peut créer des situations problématiques et même incohérentes. Ces oscillations ont pour conséquences, entre autres, la surcharge des routeurs BGP et du réseau lui-même, la perte de paquets... C'est ce que l'on appelle le Stable Path Problem (SPP). Le SPP nous donne une vision simpliée des problèmes d'instabilité des chemins dans les protocoles de routage comme BGP. Introduit par Grin dans [5], il permet de se focaliser sur les points essentiels causant les instabilités et de séparer les fonctionnalités de BGP qui ne jouent aucun rôle dans ce problème (par exemple le MED ou l'agrégation de routes,...). Soit G=(V,E) un graphe tel que les éléments de V et les éléments de E représentent respectivement les systèmes autonomes et les liens BGP. Chaque AS détermine une liste de chemins ordonnés par ordre de préférence. Une solution à SPP est un assignement d'un chemin pour chaque AS, tel que le rang de préférence de ces chemins soit le plus haut possible. Grin a montré dans [4] que SPP est un problème NP-complet. La gure 1.1 est une instance du problème SPP. Il s'agit d'un exemple classique d'oscillation appelé BAD GADGET très largement diusé. Nous supposerons dans tout ce qui suit que les AS cherchent à choisir un chemin allant à la destination 1. Fig. 1.1 BAD-GADGET. Problème sans solution stable. 5

7 Voici une simulation possible du protocole BGP à partir de la gure 1.1 : au départ, tous les AS choisissent soit un chemin direct, soit un chemin vide noté ε. L'AS 2 ne connaît pas le choix des chemins de ses voisins. Il choisit le chemin 21 et le fait savoir à ses voisins. L'AS 3 prend connaissance de cette information et choisit 321 ; lui aussi fait suivre l'information à l'as 4. La route 31 n'étant pas disponible, l'as 4 choisit la route 41. Lorsque l'as 2 en sera informé il pourra choisir la route 241 qu'il préfère provoquant la perte de 321,... Le processus ne s'arrêtera jamais. Cet exemple est une illustration d'une oscillation ou d'une instabilité du protocole BGP. Des cas identiques d'oscillations ont déjà été détectés dans l'internet et il est primordial d'implanter une méthode de résolution d'oscillation rapidement car avec l'explosion du nombre de routeurs dans le monde et un trac qu'on pourrait qualier de fonction d'ackermann, il est impossible de se contenter du routage Internet actuel. Pour plus d'informations sur le protocole BGP, consultez [10] ou [9]. 6

8 1.2 Principe de la solution proposée Maintien de l'état des chemins Voici le principe de la solution proposée dans [8]. Certaines solutions proposées s'appuyaient sur un historique ; malheureusement le principe de condentialité n'était pas respecté et l'utilisation d'un historique nécessitait des ressources trop importantes sur un AS (voir [8] et [11]). La solution proposée dans [8] se base sur une gestion locale. Tous les chemins démarrent en ayant l'état '*'. Le principe général est, lorsqu'un nouveau chemin est sélectionné on aecte un nouvel état dans les cas suivants : Si le nouveau chemin sélectionné a une préférence locale supérieure à l'ancien alors son nouvel état est '+' ; Si le nouveau chemin sélectionné a une préférence locale inférieure à l'ancien alors l'état de l'ancien chemin passe à '-'. La méthode proposée dans [8] montre que si un chemin passe d'un état '+' à un état '-', alors c'est que ce chemin subit une oscillation. Le tableau 1.1 représente une exécution séquentielle du maintien d'état pour le BAD GADGET à 5 AS de la gure 1.2. Le champ Rib-in correspond au chemin actuellement choisi pour un AS donné, les '+' et '-' dans les colonnes des chemins représentent les états correspondants au cours du temps. Ainsi, on peut savoir pour un chemin, s'il a permis d'améliorer le routage de l'as par rapport à l'ancien chemin choisi ('+'), ou bien s'il a été abandonné au prot d'un chemin moins bon ('-'). Ce n'est pas représentatif de la réalité car normalement l'échange des messages se fait de façon asynchrone. Nous verrons par la suite comment gérer le cas asynchrone à l'aide d'un jeton Fig. 1.2 BAD-GADGET composé de 5AS. AS2 AS3 AS4 AS5 step rib-in rib-in rib-in rib-in 1 * * 21 * * 31 * * 4531 * * * * 21 + * 321 * * 4531 * * * * 21 + * 321 * * * ɛ 4 * * 21 + * * 41 - * ɛ 5 + * * * * * 31 - * * * 31 - * * * 31 + * * 21 - * 31 + * Tab. 1.1 Exemple de maintien de l'état des chemins pour BAD GADGET Détection et Résolution des oscillations La méthode proposée dans [8] nous permet maintenant de détecter correctement les chemins oscillants. Il est nécessaire maintenant d'identier les chemins appartenant à un circuit et en interdire un pour le rompre. La méthode retenue consiste à utiliser un jeton qui déterminera si un chemin, ayant subi une oscillation, appartient à un circuit oscillant. On peut noter que cette méthode n'ajoute pas de messages complémentaires mais complète les messages prévus par BGP (annonces d'un nouveau chemin) avec un jeton. Nous allons maintenant décrire comment fonctionne cette méthode. 7

9 Un AS 'A' qui détecte une oscillation sur un de ses chemins 'X', grâce au maintien de l'état des chemins, génère un jeton, 'j.h(x)' ( h étant une fonction de hachage), associé à ce chemin 'X' et l'expédie avec l'annonce de son nouveau chemin 'Y', en y ajoutant son identiant d'as (attribué par une autorité et unique dans l'internet) à la liste des AS concernés par cette route et l'information OK qui indique que le jeton est prioritaire pour lui. Cette notion de priorité est basée arbitrairement sur la comparaison lexicographique entre deux jetons ; celui qui est inférieur pour cet ordre est désigné comme prioritaire. Lorsque l'as 'B' reçoit l'annonce d'un nouveau chemin avec un jeton, deux cas se présentent : si 'B' ne doit faire aucune modication suite à l'annonce il jette le jeton, sinon : tout dépend du jeton : s'il n'est pas prioritaire pour lui il désactivera le jeton en lui ajoutant l'information NOK, se rajoutera à la liste des AS concernés et retransmettra le jeton, sinon si 'B' modie son chemin suite à cette réception et que le jeton reçu est prioritaire, il transmettra son nouveau chemin (comme prévu par BGP) et fera suivre le jeton 'j.h(x)' en laissant le champ à OK et en se rajoutant aussi à la liste des AS concernés et ainsi de suite...notons que si un AS reçoit un jeton ayant déjà l'information NOK alors l'as fera suivre ce jeton mais ne modiera pas cette information ; il se rajoutera lui aussi à la liste des AS concernés. Lorsque 'A' reçoit un message contenant le chemin 'Z' en provenance d'un de ses voisins, avec le jeton 'j.h(x)' associé. Si 'Z' entraine le choix de X et que le jeton reçu est toujours à OK alors l'as 'A' peut conclure que 'X' ( qui était à l'origine de la création du jeton j.h(x)) appartient à un circuit. Ainsi 'A' va interdire son chemin 'X' et garder les numéros des AS concernés par cette route dans une table associative. Dans les deux cas (OK,NOK), les AS générateurs de jetons, connaissent les identiants de tous les AS impliqués dans la même oscillation (cela sera utile pour la gestion des pannes et apparitions de liens). Remarque : L'utilisation d'une fonction de hachage qui aectera une valeur au jeton en fonction du chemin oscillant permet de ne pas dévoiler le chemin oscillant. Ainsi la condentialité est respectée. Seul l'as générateur du jeton, 'A', est capable de retrouver le chemin à l'origine de la création de ce jeton. La gure 1.3 est un exemple de transmission de jeton dans le cas du BAD GADGET de la gure 1.1. Voici le déroulement de cette transmission de jeton. L'AS 3 détecte une oscillation du chemin 321, l'as 4 sur le chemin 431 et l'as 2 sur le chemin 241. L'AS 3 génère alors un jeton associé à ce chemin (j321) et envoie son nouveau chemin (31, j321, OK) en joignant le jeton. L'AS 2 et l'as 4 font de même. À la réception du jeton j321, l'as 4 modie son chemin en adoptant 431, et fait donc suivre le jeton avec l'annonce (431, j321, OK). A la réception du jeton j431, l'as 2 désactive le jeton et le retransmet avec l'annonce (21, j431, NOK). A la réception du jeton j241, l'as 3 modie son chemin en adoptant 321, et fait donc suivre le jeton avec l'annonce (321, j241, OK). Ainsi de suite, le jeton j321 sera aussi désactivé car non prioritaire pour l'as 2 (son jeton est inférieur pour l'ordre lexicographique à celui de l'as 2). Au nal, 2 jetons auront été désactivés et il ne restera plus que le jeton j241. L'AS 2 reçoit alors le jeton qu'il avait précedemment émis, et le chemin associé entraine le choix de 241. Donc 241 est considéré comme un mauvais chemin. L'interdiction de ce chemin aboutira à une solution (41, j431, OK) (21, j241, OK) (41, j241, OK) (21, j321, NOK) 1 (431, j321, OK) 1 (21, j431, NOK) (31, j321, OK) (321, j241, OK) (321, j431, NOK) Fig. 1.3 Échange de jeton dû à une oscillation du chemin

10 1.3 Pannes et apparitions de liaisons entre routeurs BGP Principe BGP est un protocole autostable, c'est-à-dire que quelque soit la conguration dans laquelle se trouve le réseau, les AS vont s'échanger leurs chemins jusqu'à arriver à stabilité (si les politiques sont cohérentes entre elles, cf. chapitre sur BGP). Donc en cas de modication de la topologie, BGP converge vers un état stable. Il existe deux sortes de pannes : les pannes de routeurs et les pannes de liaisons. Nous nous intéresserons à la gestion des pannes de liaisons car elle s'étend facilement à celle des pannes de routeurs. Les apparitions des liens peuvent se produire lorsqu'un AS apparaît pour la première fois dans le réseau ou bien lorsqu'un lien est rétabli à la suite d'une panne. Lorsqu'une panne de liaison ou une apparition d'un lien se produit, il est possible qu'un chemin préalablement interdit puisse être réhabilité. La gestion des pannes et apparitions de liaisons est similaire : tout d'abord les AS touchés par ce changement (par exemple les AS situés aux extrémités de la liaison en panne) vont détecter la panne, puis vont avertir tous les AS concernés (grâce à la sauvegarde de leurs identiants, voir chapitre sur le principe de la solution proposée) du changement sur ce lien. Si un AS, possédant un chemin interdit, reçoit cette information, il lance le processus de test de réhabilitation sur ce chemin an de savoir s'il peut être réhabilité ou non Panne de liaison Lorsqu'une panne de liaison se produit, les deux AS à l'extrémité de cette liaison vont s'en rendre compte. Si ces AS avaient généré un jeton suite à une oscillation, ils savent que l'interdiction du chemin qui avait eu lieu pour résoudre cette oscillation peut être maintenant illégitime. Malheureusement, BGP n'impose aucune annonce si aucun changement de route n'a lieu. Donc ces AS se doivent d'en informer les autres AS an de réhabiliter éventuellement ce chemin. C'est l'as possédant le plus petit identiant entre les deux qui se chargera d'annoncer cette information (ce choix est totalement arbitraire, il permet de transmettre une seule fois l'information). Grâce aux identiants joints avec le jeton, il connaît tous les AS impliqués et les prévient en leur envoyant un message les informant de la panne. Les AS, possédant des chemins interdits, vont lancer le processus de test de réhabilitation sur ces chemins et réhabiliteront ceux ayant réussi le test. Le processus de test consiste à tester si un chemin peut être réhabilité ou non en simulant sa réhabilitation. Il génère un jeton blanc et l'envoie avec sa route à tester. Lorsqu'un AS reçoit un message contenant un jeton blanc, il ne met pas sa table de routage à jour mais simule un nouveau choix de route à l'arrivée d'un message de mise à jour de route. Dans ce cas si sa route n'est pas modiée, il acquite le message reçu, si au contraire elle est modiée, il retransmet le jeton avec sa "nouvelle route" simulée. Lors du parcours du jeton blanc, il n'y a jamais de modication eective de route. Lors de cette simulation, si aucune oscillation n'est générée, le processus de test a réussi et le chemin est réhabilité. Prenons l'exemple de la gure 1.4 a). Il s'agit d'un BADGADGET (exemple de réseau provoquant des oscillations du protocole) avec six AS où la méthode a abouti à l'interdiction du chemin 241. Supposons que le lien reliant les AS 5 et 6 tombe en panne(cf. gure 1.4 b)). Lorsque les AS 5 et 6 prennent connaissance de la panne, l'as 5 avait généré un jeton dû à l'oscillation du chemin 531. Il annonce l'information de la panne à tous les AS qui étaient impliqués dans cette oscillation (cf. gure 1.4 c)). Les AS 3 et 4 ne possèdent pas de chemin interdit. Par contre l'as 2 lance le processus de test de réhabilition sur le chemin 241 : l'as 2 génère un jeton blanc associé à 241 (jb241), envoie ce jeton avec le chemin 241 (241,jB241) (cf. gure 1.4 d)) et conserve l'information (N IL, jb241, 2) où le premier champ est l'as "père", le deuxième contient le jeton et le troisième le nombre de liaisons auxquelles on a transmis le jeton. L'AS 3 et 4 recevant cette information, se rendent compte qu'il s'agit d'une simulation grâce au jeton blanc et regardent si le chemin 241 les feraient changer de chemin. L'AS 4 n'aurait aucune modication à faire et par conséquent, envoie un accusé de réception à l'as 2 qui décrémente son compteur de messages envoyés. Par contre, l'as 3 a adopté le chemin 321 donc il modierait son chemin en choisissant 31. Il fait suivre le jeton blanc avec le chemin 31 (31,jB241) (cf. gure 1.4 e)) et conserve l'information (2, jb241, 1). L'AS 5 reçoit cette information et pourrait ainsi prendre 531 mais il n'a plus de voisin donc il envoie un accusé de réception à l'as 3 qui décrémente son compteur valant maintenant zéro ((cf. gure 1.4 f)). Lui aussi envoie un accusé de réception à l'as 2 qui décrémente son compteur et réhabilite la route 241 puisque le compteur vaut zéro. De cette manière le système, aboutira aux choix des chemins suivants : ( ). Si le jeton était revenu à l'as 2, le chemin n'aurait pas été réhabilité. 9

11 (j241; 3,5,6,4; OK) (j321; 5,6,4,2; NOK) (j46531; 5,6,4,2; NOK) a) (j6531; 5,6,4,2; NOK) (j531; 6,4,2,3; NOK) b) c) (NIL,jB241,2) (241, jb241) (NIL, jb241,1) (AR, jb241) 2 1 (2, jb241,1) (NIL, jb241,1) (31, jb241) (2, jb241,0) (AR, jb241) (NIL, jb241,0) (AR, jb241) (2, jb241,0) d) e) f) g) Fig. 1.4 Illustration d'une panne dans un BAD GADGET à 6 sommets Apparitions ou rétablissements de liens Intéressons nous maintenant aux cas des apparitions de liens. Si un AS A, ayant généré un jeton pour un chemin X lors d'une oscillation précédente, est amené grâce à l'apparition d'un nouveau lien, à choisir un chemin Y. Si Y est préféré à X, il sait que l'interdiction qui s'était produite pour résoudre cette oscillation n'est peut être plus légitime. Il utilise le processus d'annonce décrit précédemment pour avertir tous les AS concernés par l'oscillation. La suite du déroulement est identique à celle de la panne de liaison. 10

12 1.4 Implémentation de la méthode proposée [8] Le simulateur C-BGP Le simulateur C-BGP vise à simuler le routage BGP dans un réseau d'as déni par l'utilisateur. Les stagiaires des années précédentes ont fait le choix de choisir ce simulateur car très complet et open-source. Autre raison motivant leur choix, l'ensemble du projet du simulateur est codé en C. C-BGP est développé par l'université catholique de Louvain en Belgique et plus particulièrement par Bruno QUOITIN. Il simule le comportement des AS, le processus de sélection de chemins, ainsi que les politiques des AS (vus précédemment) pour le protocole BGP et est compatible avec de nombreux systèmes d'exploitation. Ce simulateur implémente ebgp (exterior Border Gateway Protocol), ibgp (interior Border Gateway Protocol), supporte des réseaux complexes et permet de renseigner précisément les politiques de routage de chacun des routeurs dénis soit de façon interactive, soit dans un chier passé en paramètre. Preuve de sa complexité, C-BGP est compatible notamment avec les commandes développées pour les routeurs Cisco : rien ne semble avoir été oublié, pas même les plus courts chemins ou les suggestions de routes avec Multi-Exit-Discriminator. La complexité de ce simulateur est à la fois un avantage et un inconvénient. En eet, il permet d'étudier le fonctionnement dans un environnement très réaliste, prenant en charge le routage interne, le routage externe,...d'un autre côté, le simulateur est lourd. Sa compilation relativement longue représente un handicap car obligatoire dès que des modications sont apportées au code. Le volume des sources qu'il représente est également un désavantage, car il est irréaliste d'en connaître l'ensemble, et est donc un obstacle, notamment lors des phases de déboguage. De plus, l'installation du simulateur n'est pas aisée, notamment lorsque l'utilisateur n'est pas administrateur sur la machine, ce qui a été le cas pour nous à l'université. En eet, faute d'avoir les droits susants, il est nécessaire de modier les dossiers de destination lors de l'installation, ce qui n'est pas évident pour une première installation sous linux (autre que rpm) La version modiée de C-BGP Dans le simulateur qui nous a été fourni, une partie du code de C-BGP a été modié, de manière à ajouter un greon implémentant la solution proposée pour résoudre les oscillations dans BGP. Le principe de résolution des oscillations est le suivant : - tout d'abord, détecter l'oscillation potentielle ; - chercher à vérier son existence réelle par l'envoi d'un jeton associé à cette route ; - interdire un et un seul des chemins impliqués dans cette oscillation an de la résoudre ; - faire des tests à intervalles réguliers an d'essayer de réhabiliter ce chemin si l'oscillation a disparu. 11

13 Chapitre 2 Développement 2.1 Installation Méthode d'installation et erreurs résolues Méthode d'installation Nous avons rencontré beaucoup de problèmes dans la phase d'installation que nous avons surmonté, cependant ces dicultés nous ont empêché de nous en tenir à l'emploi du temps prévu en nous contraignant à reporter le coeur de notre travail. Deux versions du simulateur C-BGP existent : la version de base de l'université de Louvain, et celle modiée par les soins des stagiaires du LIRMM où est implémentée la méthode de résolution avec utilisation des jetons. L'installation de la version la plus récente du simulateur de base a été relativement simple, même si l'obstacle des droits a été problématique au début. La solution a consisté à passer en paramètre le dossier de destination lors de l'installation. Cependant, l'installation de la version modiée, base de notre travail, s'est avérée plus ardue : en eet, des centaines d'erreurs faisaient obstacle à la compilation du code du simulateur. Après analyse, il s'est trouvé que l'option de compilation -Werror utilisée dans la plupart des Makele (générés automatiquement pendant l'exécution du script système congure) empêchait le projet de compiler : en eet, cette option, qui est l'acronyme de Warning error en anglais, interrompt la compilation du code source en C et empêche le compilateur C (gcc) de créer le chier exécutable en achant toute les mises en garde (warning). Il a donc été nécessaire de modier manuellement chacun des Makele an de supprimer l'option -Werror. Cela n'a pas sut à permettre l'installation : les warning, étant bloquants, masquaient des erreurs de compilation, auparavant invisibles. En eet, plusieurs chiers impératifs à la compilation du simulateur étaient manquants. Les chiers gds.h, gds.c, gds.lo, gds.plo, patricia-tree.h, patricia-tree.c, patricia-tree.lo et nalement patricia-tree.plo, inclus par le code C, ne se trouvaient pas dans le projet. Il a fallu les importer depuis la version de libgds, puis à nouveau modier tous les Makele à la main an de les compiler. L'installation enn réussie, nous avons pu eectuer un premier lancement du simulateur, ce qui nous a permis de nous plonger dans le travail demandé à proprement parler. Nous joignons donc en annexe un guide détaillé d'installation de la version modiée de C-BGP. 12

14 2.2 Analyse de l'implémentation de la méthode La technique de passage de jetons est une solution proposée par Mr Clément SAAD dans sa méthode présentée précédemment. Son implémentation logicielle dans le code de la version du simulateur C-BGP avec méthode de résolution des oscillations est essentiellement présente dans le chier maintien.c. Ce chier a été codé par Julien CHAMP (cf. [1]) et Joseph EMERAS (cf. [2]). Il a donc été important de s'attarder sur le rôle de chacune des fonctions de ce chier. Nous allons donc voir les modications apportées au code source pour implémenter les jetons, comme par exemple à la création d'un routeur Analyse du programme en détail Création du jeton Dans le programme, le jeton est une simple structure dénie par un champ path contenant l'ensemble du chemin par lequel le jeton va passer et un champ state indiquant les diérents états d'un jeton (cf. Annexe). Les diérents états d'un jeton sont : - 0 : le jeton est créé mais pas encore envoyé ; - 1 : le jeton est envoyé mais pas encore revenu à son émetteur ; - 2 : le jeton est envoyé et puis revenu à son expéditeur. Le jeton est retourné par la fonction : etatjeton(listejeton lj, char* path) en parcourant une liste de jetons à partir de son identiant, qui n'est autre que son chemin. Il existe donc un seul jeton par chemin, cela évite les doublons. On peut mettre l'état d'un jeton à jour grâce à la fonction : majetatjeton(). L'état d'un jeton, déni plus haut, permet de connaître l'évolution de son parcours sur le réseau. Les AS stockent leurs jetons dans une liste de type ListeJetons, à savoir un tableau de jetons et le nombre d'éléments contenus (cf. Annexe). Le jeton est créé dans la fonction detectoscillation(), si une oscillation est détectée sur une route. Par défaut, lors de sa création le jeton est positionné à l'état 0. Par ailleurs, le routeur (référencé dans le programme par une variable prouter), positionne un indicateur (ag jetonexiste) dans sa structure pour indiquer qu'un jeton existe. La fonction emetjeton(char* path) permet, comme son nom l'indique, d'émettre un jeton pour un chemin. En fait, elle se contente de copier le path en paramètre et de le retourner. Cette fonction a probablement été implémentée pour gérer le cryptage du jeton avant son envoi. Circulation du jeton Nous avons vu précédément un rappel sur la méthode de résolution et surtout sur la politique du choix du jeton dans sa circulation. Ce choix se fait grâce à la fonction choixjeton(). Dans la liste de jetons (créés), la fonction va chercher le premier jeton non encore envoyé. Si le jeton d'état 0 est trouvé dans la liste, alors : Si le jeton reçu est NULL, alors on renvoie le chemin du jeton crée ayant l'état 0 dans la liste ; Si le jeton reçu a un chemin d'as plus long que le jeton de la liste, on retourne ce dernier ; Si le jeton reçu a un chemin d'as plus court que le jeton de la liste, alors on le retourne ; Si les jetons ne sont pas départagés, on se base sur la valeur numérique ; Sinon on retourne le jeton reçu ; Sinon on retourne le jeton reçu. D'autre part, le test de circulation du jeton est assuré par la fonction testcirculationjeton(), permettant de retourner le jeton élu par un AS. Cette fonction a le même algorithme que la fonction choixjeton(), selon un ordre lexicographique, sauf que l'on cherche dans notre liste de jeton, le jeton envoyé mais pas revenu (avec un état à 1). Autres fonctions sur les jetons et listes de jetons La fonction razetats(listejetons* lj) sert d'après son nom à mettre tous les états des jetons à zéro. Hors elle fait plus que ça, vu qu'elle positionne le pointeur Jeton de la liste de jetons à NULL. Donc elle vide la liste de jeton. La fonction yatilunjeton(listejetons *lj) permet de savoir si une listejeton contient au moins un jeton d'état 0 (créé mais non envoyé). 13

15 2.2.2 Le jeton Blanc Le jeton blanc est un jeton spécique utilisé dans la méthode de résolution des oscillations. Il permet de tester si la réhabilitation d'un chemin interdit précédemment est réalisable. Nous allons voir comment ce jeton blanc a été implémenté (cf as.c, maintien.c, as_t.h, maintien.h, peer.c). Il est créé à la suite d'une demande de test de réhabilitation (cf testderehabilitation()) provoqué par un ajout de lien ou un ajout d'as. Lors du test de réhabilitation, chaque routeur va transmettre le jeton blanc. Pour ce faire, ces derniers vont stocker le passage du jeton dans un structure nommée jetonblancrouteur (cf annexe). La fonction bgp_router_decision_process_disseminate_white_token() permet de diuser le jeton blanc. Celui-ci circule sur le réseau dans un message BGP de type UPDATE avec un indicateur blanc positionné (cf white dans la structure SBGPMsgUpdate). Chaque routeur le traite dans la fonction peer_handle_message() (cf annexe) : pour gérer le nombre d'accusés de réception, sa retransmission et aussi savoir si un jeton est revenu à son destinataire. Quand le routeur émetteur récupère autant d'accusés de réception que son nombre d'envois de jeton blanc, le routeur positionne un indicateur de réhabilitation (cf champ réhabilitation dans la structure SBGPRouter, voir annexe 4.3). Ainsi, toujours dans la même fonction, la réhabilitation se fait grâce au traitement d'un message UPDATE. La route à réhabiliter va être récuperée dans la liste des chemins interdits stockée dans le routeur. Puis, elle sera réactivée grâce à une aectation de son ancienne préférence locale (localpref ) dans la politique de l'as Critiques sur le code Au cours de la lecture du code, nous avons pu remarquer quelques éléments étant la cause de bogues du programme. Problème de l'adresse de destination statique Dans la méthode proposée, l'as de destination est commun à tous les AS de la topologie. Celui-ci est xé, dans le code source, à l'as 1. Ainsi dans nos tests où le sommet 1 n'était pas présent ou n'était pas "sommet de destination", le programme ne fonctionnait pas. De plus, le générateur de topologies oscillantes fournit par les étudiants en Master 2 Informatique, nous fabriquait des topologies de diverses tailles mais avec comme petit défaut de xer le sommet de destination de tous les chemins de chaque AS, à la valeur de l'identiant le plus grand. Par exemple, sur une topologie 10 sommets générés, le sommet de destination est le sommet 10. Ceci pose donc un problème de compatibilité avec la valeur xée dans le code source. Par ailleurs, l'exécution dière selon le sommet de destination choisi. Une solution proposée est de passer cette adresse en paramètre du programme ou de la récupérer dans celui-ci lors des parsages des chiers de topologies. Comment vérier qu'une topologie est bien oscillante? Il est clair qu'il est plutôt facile de vérier si une topologie à 4-6 sommets est oscillante, il sut d'en tracer l'exécution à la main. Mais le problème devient plus complexe et surtout fastidieux sur des topologies plus grandes. La solution employée pour tester l'existence d'une oscillation consiste simplement à vérier que la topologie concernée boucle sur la version originale du simulateur. Cascade d'erreurs de segmentations Nous avons déjà expliqué les modications à mettre en oeuvre pour résoudre l'erreur de segmentation qui se produisait dès la première exécution après l'installation. Par la suite, chaque erreur de segmentation résolue en révélait une autre. Par conséquent, nous avons fait appel à un logiciel de déboguage : valgrind. Le constat est, selon les rapports d'analyse, qu'il y a une mauvaise gestion de la mémoire : en eet, énormement de blocs mémoires ne sont pas désalloués et des écritures ont été eectuées hors des zones réservées. Ces faits entraînent des arrêts brusques du programme, avec à leur origine, une gestion de la mémoire incertaine (cf. Annexe 4.3). La gestion de la mémoire en langage C est une tâche assez subtile, proche du système. Elle requiert du programmeur une rigueur dans sa gestion des zones mémoires. La diculté est accrue par l'utilisation de pointeurs. Ceux-ci donnent certes une grande liberté de manipulation de données mais s'avèrent être souvent à l'origine des erreurs de segmentation. 14

16 2.3 Résolution d'erreurs Les diérentes erreurs de segmentation Avec le jeu de test inclus dans la version avec jetons du simulateur, celui-ci fonctionnait correctement, mais les tests eectués avec d'autres chiers entraînaient des erreurs de segmentation. Il a donc été nécessaire d'ajouter un grand nombre d'achages disséminés dans le code source an d'obtenir une trace de l'exécution du programme, et de déterminer l'origine de ces erreurs. Exemple d'erreur rencontrée : les jetons, qui contiennent un chemin, de longueur variable en fonction du nombre d'as impliqués dans l'oscillation, étaient stockés dans un tableau de taille xe et très limitée (le jeu de test se limitait à des topologie très restreintes : Bad-Gadget à 4 AS par exemple). La deuxième erreur pendant l'exécution de C-BGP est la mauvaise gestion de mémoire (vu préc demment dans les critiques du code). En fait, à plusieurs reprises dans le code, les espaces alloués en mémoire ne sont pas bien gérés, c'est-à-dire que ceux qui sont alloués avec la commande malloc ne sont pas libérés par l'utilisation de l'appel système free. Beaucoup d'eorts ont été consacrés à la résolution de ce problème, mais l'imbrication de cette erreur dans le simulateur C-BGP lui-même l'a rendu impossible à corriger. La troisième erreur ést la présence d'une boucle innie lors de l'exécution pour la plupart des topologies lancées. Seules deux topologies fournit par Joseph EMERAS fonctionnent, ceux qui présage une mauvaise implémentation de la méthode. Nous avons travaillé sur la résolution de ces boucles innes en eectuant des traces (voir chapitre suivant). Enn, la dernière erreur se produit à cause de la non-compatibilité entre les chiers script (.topo et.cli) fournis et la version modiée du simulateur. Dans C-BGP, l'as de départ est désigné de façon statique dans le code ( ) mais dans les topologies, fournies par le générateur de Aurélien et David (cf. [3]), c'est toujours le dernier AS dans la liste qui est la cible. Cet incompatibilité déclenchait une erreur de segmentation. Ce problème a été résolu et nous avons mis en place une macro dans les entêtes an de changer plus facilement l'adresse de destination Nos diérentes méthodes pour résoudre les erreurs parsage d'informations Après avoir étudié en détail les codes sources des stagiaires des années précédentes, nous avons analysé les données pouvant nous apporter le plus d'information sur le fonctionnement du simulateur C-BGP modié an de détecter la provenance des erreurs. Tout d'abord, avant d'observer l'oscillation des chemins, il est nécessaire de connaître l'ordre de préférence de l'ensemble des chemins de chaque AS, ainsi que la préférence pour chacun d'entre eux. La politique de routage des AS est dénie dans les chiers.cli au lancement du simulateur. Un premier parseur a donc été développé dans le but de récupérer dans ce chier les couples (local pref - chemin) pour chaque AS. Ensuite, nous avons pu nous intéresser au parsage des chemins oscillants. Celui-ci ne s'avère pas d'une grande utilité. Nous constatons bien sûr des oscillation mais sans autre donnée que les chemins, nous ne pouvons donc pas en tirer de plus amples informations. Enn, nous nous sommes intéressés au parsage des jetons. C'est à ce dernier point que nous nous sommes le plus consacré. Il a fallu séparer les informations des jetons pour la détection d'oscillation de celles pour la réhabilitation des chemins. Pour chaque AS, nous pouvons ainsi voir, avec les données récupérées par ce nouveau parseur et les diérents états des jetons (vu dans le chapitre 2.2.1) sur chaque AS. Ainsi nous pouvons ainsi observer, la circulation d'un jeton sur le réseau et voir l'évolution de son état (création, suivi et destruction) sur chaque AS. Ces trois parseurs nous permettent d'avoir une vue des états globaux du système réparti (les AS), au cours d'une exécution. traces d'exécution Premièrement, une fois l'installation du simulateur modié réussie, nous avons eectué des traces avec les topologies fournies par Joseph EMERAS. Il y avait, dans son archive (dossier workspace/sample), un BADGADGET à 4 AS, un autre à 6 AS et enn un à 10 AS. Le simulateur, implémentant les jetons, arrive à résoudre ces 3 topologies. Quand on lance ces topologies, il s'arrête et ache les tables RIB de chaque AS. Satisfaits du résultat, nous avons donc testé le simulateur, directement, sur de grosses topologies avec 20 et 30 AS. Nous sommes tombés alors sur des erreurs de segmentations et de dépassement de la pile (voir préc demment) dont certaines ont été résolues. C'est là que nous avons programmé nos parseurs. Il s'avère que, lors de l'exécution de telles topologies pendant 2 à 3 secondes, les calculs des jetons pour la résolution des oscillations dépend de la performance de la machine. Ces calculs se font donc extrêmemment vite et nous donne des traces de plusieurs milliers de lignes. Ce 15

17 qui rendait les traces illisibles. Nous avons donc testé avec des graphes de plus petites topologies, notamment un simple GADGADGET de 4 AS écrit à la main et bouclant sur le simulateur C-BGP version 1.3 récupé en ligne. Par précaution, nous avons multiplié des essais avec des topologies écrites à la main et d'autres fournies par le générateur des Master 2, celles-ci oscillaient toutes sur le simulateur C-BGP, aucune n'a été résolu sur le simulateur modié. Nous avons donc remis en cause l'implémentation de la méthode. Avec les informations récupérées des jetons, nous nous sommes aperçus que lors de la détection d'une oscillation (fonction detectoscillation() dans le chier maintien.c), un jeton est bien généré pour un chemin oscillant mais celui ne semble pas être traité par l'as (voir la fonction majmaintienbest() dans le chier as.c). Par ailleurs, le censé BADGADGET à 10 AS fournit par Joseph EMERAS ne l'est pas. Sur le simulateur C-BGP, celui s'arrête alors qu'il devrait boucler. Il est possible qu'il ait eu une erreur par mégarde dans les préférences du chier.cli. Cependant, les achages des tables RIB des BADGADGET à 4 AS et à 6 AS de Joseph EMERAS sont eectués en dur dans le chier.cli. Cela nous laisse dubitatifs sur l'implémentation de la méthode. Ces faits se constatent lors de créations et envois de jetons. En séparant la partie réhabilitation des chemins de la détection des oscillations, nous nous sommes apercus que le même jeton est envoyé plusieurs fois. Beaucoup de ces jetons sont perdus. 16

18 Chapitre 3 Discussion sur la méthode et son fonctionnement 3.1 Objectifs et résultats L'objectif xé au départ était de valider la méthode de résolution d'oscillation pour le protocole BGP élaboré par Mr Ehoud AHRONOVITZ et Mr Clément SAAD. Il était demandé de reprendre le travail eectué par Julien CHAMP et Joseph EMERAS sur le simulateur C-BGP. Ces derniers sont arrivés en conclusion de leur stage à valider sur de petites topologies (voir gure 1.1) la méthode proposée en [8]. La complète validation de la méthode doit passer par des tests sur des topologies de tailles réelles avec beaucoup plus d'as. Il était aussi demandé d'eectuer un ensemble de statistiques an d'envisager de diverses heuristiques selon les topologies. Par contre, il nous pas été demandé de multiplier le nombre d'as de destination. Pour réaliser notre objectif, il nous fallait donc : - connaître parfaitement la méthode proposée en [8] ; - installer le simulateur des stagiaires précédents ; - s'approprier leur code et celui du simulateur en passant par une longue phase d'apprentissage ; - vérier que les choix d'implémentation étaient cohérents et fonctionnaient ; - se lancer sur de grosses topologies en ayant probablement à gérer des problèmes de mémoires, comme sur tous les projets de cette envergure ; - en dernier lieu, valider la méthode si tout passait. Fâce aux problèmes causés par l'installation et les premières exécutions, qui nous ont occupé un bon mois, nous avons dû revoir notre objectif initial, en accord avec nos tuteurs. Le fait d'utiliser un simulateur C-BGP rendait le projet conséquent. Le code des stagiaires précédents était un peu brouillon : absences de commentaires, incohérences dans le choix des noms de fonctions et variables, incohérence de programmation, non structuré. Tout cela rendait dicile la lecture du code, et pause des soucis de perennité pour les futurs stagiaires. Il nous a donc été demandé de déboguer et d'optimiser le travail eectué. Après les problèmes rencontrés à l'installation, nous avons soucieusement fait un manuel d'installation pour l'avenir, chose qui nous a manqué et pénalisé dans le temps. Les parties de code les plus abstraites et les utiles à la compréhension ont été mises en annexe. D'autre part, tous nos autres commentaires sur le code seront mis à disposition. Il nous semble que notre objectif second a été réalisé. Nous avons surmonté la masse de code que représente le projet (près de lignes) et résolus de nombreuses erreurs. Il nous aura certainement manqué du temps pour eectuer plus de traces sur le fonctionnement du code, le déboguage ayant pris une grande partie de notre temps. 17

19 3.2 Conclusion Ce projet nous a permis de nous rendre compte à quel point il est dicile de reprendre le code de quelqu'un d'autre et de le maintenir, mais également de travailler sur des projets conséquents qui nécessitent organisation et rigueur. Il n'a pas été évident de répartir le travail, la phase de compréhension étant individuelle an de pouvoir déboguer au mieux le programme, nous nous sommes répartis sur l'analyse des chiers. Pour le reste, nous nous sommes répartis par paire. La première paire, Pierre et Eltaf, a plus travaillé sur la gestion de la mémoire et l'optimisation du code, la deuxième paire Jonathan et Vincent a plus travaillé sur le parsage d'informations et l'analyse des traces. Ainsi organisés, nous avions chaque fois, au moins deux points de vue diérents sur une situation. On restait tout de même à jour sur ce que faisait l'autre paire en se consultant régulièrement. Bien que l'objectif initial ait été revu en cours de travail, il nous semble aujourd'hui réalisable contrairement au commencement. Cependant, cela doit passer par une validation de la méthode sur de petites topologies chose qui ne semble pas avoir été réalisé par les stagiaires précédents. Le manque de temps nous aura fait défaut. D'ici la soutenance, nous aurons malgré tout sûrement le temps d'obtenir plus de résultats. 18

20 Chapitre 4 Annexe 4.1 Installation de C-BGP Installation de la libgds Faire le congure avec le prex./congure prex=" /cbgp" Attention : les adresses sont données comme adresses absolues et non relatives Copie des chiers : gds.* et patricia-tree.* Ces chiers sont présents dans la version de libgds (/libgds rc2/src/libgds/). Les copier dans le dossier où la librairie gds a été installée (/libgds-1.1.7/src/libgds/) Modier le makele du dossier où la librairie a été installée (libgds-1.1.7/src/libgds/makele) : - à la ligne 99 selon le système ou sinon dans le ag de compilation : libgdsinclude_headers : rajouter patricia-tree.h et gds.h - à la ligne 120 selon le système ou sinon dans le ag de compilation : libgds_la_sou RCES : rajouter patricia-tree.c et gds.c ainsi que : patricia-tree.h et gds.h. - à la ligne 150 selon le système ou sinon dans le ag de compilation : am_libgds_la_object S : rajouter patricia-tree.lo et gds.lo. - à la ligne 169 selon le système ou sinon dans le ag de compilation : DEP_F ILES : rajouter a la suite./$(depdir)/gds.plo et./$(depdir)/patricia-tree.plo - supprimer le -Werror Supprimer les -Werror dans les autres makeles (/libgds-1.1.7/src/check/makele) (tous les faire par sécurité) : Faite un make clean Faite un make Faite un make install L'installation de libgds est enn terminée Installation de C-BGP : Copier dans un niveau au dessus le dossier CBGP le sortir du dossier workspace : /cbgp2/workspace/cbgp/ -> /cbgp/cbgp/ Se positionner dans le dossier : /cbgp/cbgp/ Faire un./congure avec prex et endroit ou sont les librairies :./congure prex=" /cbgp2" with-libgds-dir=" /cbgp2" Ouvrir tous les makeles (il y en 12), et enlever tous les -Werror 19

21 Corriger l'erreur de Julien dans le chier maintien.c cbgp/cbgp/src/bgp/maintien.c, ligne 490 Mettre 16 pour la taille de tmpunumber. Faire un make clean Faire un make Faire un make install Fin de l'installation de C-BGP! 20

22 4.2 Commandes C-BGP Topologie du réseau (chier.topo) Ce chier décrit la topologie du réseau. Il permet de dénir rapidement les AS du réseau, ainsi que les liens entre chacun d'entre eux. Chaque ligne de ce chier sera composée ainsi : ASX ASY REL. ASX et ASY correspondent à un numéro d'as et REL à la relation entre les précédents AS. Si REL vaut 0 cela signie que c'est une relation de pair-à-pair. SI REL vaut 1 cela signie que c'est une relation Fournisseur-Client (ASX est le fournisseur, ASY le client). (voir les dénitions de pair-à-pair et Fournisseur-Client dans la partie sur BGP) An de créer la topologie du réseau BAD GADGET voici le chier badgadget.topo correspondant : La gure 4.1 correspond à l'interprétation que C-BGP fera du chier de topologie Fig. 4.1 Interprétation de la topologie par C-BGP. Maintenant que la topologie du réseau est décrite, il reste à créer le chier de script pour faire une simulation avec C-BGP Script C-BGP (chier.cli) Ce chier permet de dénir le comportement du simulateur, de charger une topologie, de xer les politiques des AS,... Nous allons décrire les commandes principalement utilisées, pour plus de détails vous pouvez vous référer au manuel [7]. Premièrement, an d'utiliser une topologie existante, il sut de la charger au lancement du simulateur : bgp topology load "badgadget.topo" Ainsi le simulateur charge la topologie décrite dans le chier badgadget.topo. C-BGP construit un réseau ou chaque domaine est composé d'un unique routeur. Pour tout numéro d'as, C-BGP attribue une adresse IP. Par exemple : L'AS 1 sera composé du routeur ayant pour adresse IP L'AS 250 sera composé du routeur ayant pour adresse IP L'AS 7018 sera composé du routeur ayant pour adresse IP C-BGP congure aussi les sessions BGP entre les routeurs. Le chargement de badgadget.topo aura donc pour eet de créer le réseau vu sur la gure 4.1. Maintenant que le réseau du BAD GADGET est correctement créé, il ne reste plus qu'à xer les politiques locales. Les politiques de chaque AS peuvent être dénies selon un grand nombre de critères, pour de plus amples renseignements vous pouvez vous référer à la section Filters de [7]. 21

23 Nous allons voir comment dénir les préférences locales d'un AS du BAD GADGET, il sut de procéder de manière similaire pour dénir les autres AS. Prenons par exemple l'as 2. Pour cet AS nous voulons accorder une préférence plus haute au chemin 241 qu'au chemin direct 21. Voici comment procéder sur le routeur , correspondant à l'as 2, pour xer la préférence sur la route 241 à 66 : bgp router peer filter in add-rule match "prefix is 0.1/16" match "path \"^4 1$\"" action "local-pref 66" exit Maintenant, sur le même routeur nous xons la préférence de la route 21 à 33 : bgp router peer filter in add-rule match "prefix is 0.1/16" match "path \"^1$\"" action "local-pref 33" exit Ces quelques lignes pour dénir les préférences locales auront donc pour eet sur l'as 2 que son processus de sélection choisira de préférence le chemin 241 au chemin direct 21. (les valeurs des préférences locales auraient pu être autres que 66 et 33, du moment que le chemin 241 a une préférence locale supérieure au chemin 21) Remarque : Le chemin dont on veut xer la préférence locale est déni à l'aide d'une expression régulière. Pour nir de xer correctement les préférences locales il sut de faire la même chose sur l'as 3 et l'as 4. Maintenant que le réseau est correctement décrit, et que les préférences locales sont xées, la simulation va pouvoir être lancée. bgp topology run Cette commande permet d'établir les sessions BGP entre tous les routeurs dénis dans le chier de topologie(cette commande doit donc être utilisée si on a précédemment utilisé bgp topology load). sim run Cette commande lance la simulation, qui ne s'arrêtera que lorsque il n'y aura plus d'élémements à traiter. A la n de simulation, il est possible de demander au simulateur d'acher les tables RIB (vues dans la section traitant de BGP). Celle qui nous intéresse principalement est la table RIB-in. Elle contient la liste des chemins éligibles lors du processus de sélection du meilleur chemin. A la n de la simulation du BAD GADGET (après avoir implémenté la méthode pour résoudre les oscillations), nous pouvons par exemple demander l'achage de la table RIB-IN de l'as 2 pour tous les chemins à destination de l'as 1. bgp router show rib-in * Voila la table RIB-in résultante de la commande précédente, à la suite d'une simulation qui a été arrétée par la commande sim stop at X (arret de la simulation apres X passages dans le processus de séléction), sachant que la ligne qui commence par *> permet de connaître le chemin sélectionné à l'arrêt de la simulation : 22

24 ----- Rib in AS * / i *> / i * / i L'essentiel à retenir pour nous est que cette table nous permet d'apprendre que c'est le chemin 241 qui est choisi par l'as 2 au moment ou le simulateur a été arrété. Les détails de l'achage résultant de la commande précédente sont traités dans la section Commands Reference de [7]. Pannes et Ajout de liaisons Pannes Exemple de panne de lien bidirectionnel entre les routeurs 2 et 3 : net link down net link down net node spf-prefix 0.3/16 net node spf-prefix 0.2/16 bgp domain 3 rescan bgp domain 2 rescan sim run On déclare que le lien entre les adresses et voit son etat passer à "DOWN". Puis comme avant on déclare le prexe des adresses modiées et on met à jour leur domaine. Enn on relance la simulation. Ajouts Exemple de rétablissement de lien bidirectionnel entre les routeurs 2 et 3 : net link up net link up net node spf-prefix 0.3/16 net node spf-prefix 0.2/16 bgp domain 2 detecte_ajout_lien bgp domain 3 detecte_ajout_lien bgp domain 3 rescan bgp domain 2 rescan sim run On déclare que le lien entre les adresses et voit son etat passer à "UP". On appelle la methode detecte_ajout_lien qui force la detection du nouveau lien auprès des routeurs concernés. Puis comme avant on déclare le prexe des adresses modiées et on met à jour leur domaine. Enn on relance la simulation. 23

25 4.3 Extraits de code Structure d'un jeton : Structure d'une ListeJeton : Exemple de gestion de la mémoire (extrait du chier /src/bgp/message.c) : MALLOC est une macro dénie dans une librairie qu'a intégré Bruno QUOITIN à son simulateur. Elle renvoie un pointeur sur la zone mémoire allouée. Dans notre cas, il s'agit d'un espace mémoire de la taille d'un pointeur de caractère. Mais la ligne suivante aecte la valeur NULL au pointeur qui référençait la zone mémoire. Celle-ci, qui était accessible via ce pointeur, est perdue. De plus, sa désallocation devient impossible. Ce cas de gure étonnant est répété à plusieurs reprises dans le code, et semble être une cause de fuite mémoire. 24

26 4.4 Adresses Statique Voici les diérents endroits où sont déclarés les adresses de destinations des chemins en statique. ligne 1230 : chier as.c : adresse en xe net a ddr t addrdstroute = ip d otted t o a ddress(0, 1, 0, 0); ligne 1730 : chier as.c : adresse en xe if(strcmp( /16, ip p refix d ump s tring(sp refix)) == 0) ligne 1879 : chier as.c : adresse en xe if(strcmp( /16, ip p refix d ump s tring(sp refix)) == 0) 25

27 4.5 Code implémentant Jeton Blanc Structure dans le routeur stockant le jeton blanc Structure du Message transportant le jeton blanc 26