Rapport de TER Résolution des oscillations du protocole BGP

Dimension: px
Commencer à balayer dès la page:

Download "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

RAPPORT DE STAGE. Implémentation dans un simulateur de réseau BGP d'une méthode de résolution des oscillations RICM 2. Ecole Polytechnique De Grenoble

RAPPORT DE STAGE. Implémentation dans un simulateur de réseau BGP d'une méthode de résolution des oscillations RICM 2. Ecole Polytechnique De Grenoble Ecole Polytechnique De Grenoble RICM 2 RAPPORT DE STAGE Implémentation dans un simulateur de réseau BGP d'une méthode de résolution des oscillations eectué au LIRMM du 01 Juin au 31 Août 2006 par Joseph

Plus en détail

Routage dans l Internet Partie 3 (BGP)

Routage dans l Internet Partie 3 (BGP) Topologie Internet Routage dans l Internet Partie 3 () EGP IGP Isabelle CHRISMENT ichris@loria.fr Avec des supports de Nina Taft (Sprint) et Luc Saccavini (INRIA Grenoble) Internal Gateway Protocol : utiliser

Plus en détail

Compte-rendu de projet de Système de gestion de base de données

Compte-rendu de projet de Système de gestion de base de données Compte-rendu de projet de Système de gestion de base de données Création et utilisation d'un index de jointure LAMBERT VELLER Sylvain M1 STIC Université de Bourgogne 2010-2011 Reponsable : Mr Thierry Grison

Plus en détail

Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée

Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée sous réserve du respect des conditions de la licence Texte

Plus en détail

TP : Le jeu de Bataille. 1 Le jeu de bataille. 2 Programmation du jeu. Algorithmes et Programmation Impérative 2

TP : Le jeu de Bataille. 1 Le jeu de bataille. 2 Programmation du jeu. Algorithmes et Programmation Impérative 2 Univ. Lille1 - Licence Informatique 2ème année 2012-2013 Algorithmes et Programmation Impérative 2 TP : Le jeu de Bataille Objectifs : Réaliser un programme utilisant les structures de piles et de les.

Plus en détail

TER Master 1 (FMIN 200) Cahier des charges: Oracle Lexical

TER Master 1 (FMIN 200) Cahier des charges: Oracle Lexical TER Master 1 (FMIN 200) Cahier des charges: Oracle Lexical VEYSSIER Julien, BISQUERT Pierre PAIVA LIMA DA SILVA Bruno, BELMONTE Remy - Encadrant : Mathieu Lafourcade 6 février 2009 Université Montpellier

Plus en détail

Télécom Nancy Année 2013-2014

Télécom Nancy Année 2013-2014 Télécom Nancy Année 2013-2014 Rapport 1A Ajout du langage C dans la Programmer's Learning Machine GIANNINI Valentin Loria 615, rue du Jardin Botanique 54600, Villers-Lès-Nancy Maître de stage : QUINSON

Plus en détail

TP4-5 : Authentication Java

TP4-5 : Authentication Java TP4-5 : Authentication Java V. Danjean V. Marangozova-Martin Résumé Le but de ce TP est double : se familiariser avec le mécanisme classique d'authentication en Java ; apprendre à utiliser la documentation

Plus en détail

RES240 / RES223 TP RoutingSim Addressage et routage IP statique par simulation

RES240 / RES223 TP RoutingSim Addressage et routage IP statique par simulation RES240 / RES223 TP RoutingSim Addressage et routage IP statique par simulation N. Boukhatem, D. Rossi Ressources: http://www.enst.fr/~drossi La note finale de RES240/RES223 sera une moyenne ponderée de

Plus en détail

Routage dynamique et protocoles de routage. Claude Chaudet Xavier Misseri

Routage dynamique et protocoles de routage. Claude Chaudet Xavier Misseri Routage dynamique et protocoles de routage Claude Chaudet Xavier Misseri Principe du routage Configurer les tables de routage (des routeurs) afin que les paquets empruntent le meilleur chemin disponible

Plus en détail

TP : Jouons au Poker

TP : Jouons au Poker Univ. Lille1 - Licence Informatique 2ème année 2014-15 Algorithmes et Programmation Impérative 2 TP : Jouons au Poker Objectifs : Programmation modulaire Manipulation de types somme Filtrage de motifs

Plus en détail

Projet Système Distribué : Implémentation d'un serveur générateur de certicats. BEUQUE Eric, CORNEVAUX Sébastien, MOUTENET Cyril 13 janvier 2009

Projet Système Distribué : Implémentation d'un serveur générateur de certicats. BEUQUE Eric, CORNEVAUX Sébastien, MOUTENET Cyril 13 janvier 2009 Projet Système Distribué : Implémentation d'un serveur générateur de certicats BEUQUE Eric, CORNEVAUX Sébastien, MOUTENET Cyril 13 janvier 2009 1 Table des matières 1 Sujet 3 2 Analyse 4 3 Création clé

Plus en détail

Haute disponibilité et répartition de charge avec Sympa

Haute disponibilité et répartition de charge avec Sympa Haute disponibilité et répartition de charge avec Sympa David Verdin RENATER c/o Centre de Ressources Informatiques 263 Avenue du General Leclerc CS 74205 Campus de Beaulieu 35042 Rennes CEDEX Serge Aumont

Plus en détail

Une mosaïque de photos

Une mosaïque de photos Département IMA / 3A (S5) Programmation Structurée 2011/2012 Sujet proposé par J. Dequidt http://laure.gonnord.org/pro/teaching/ Une mosaïque de photos Premier Projet de Développement Logiciel en C Lire

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 1 : Introduction aux bases de données Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données

Plus en détail

PG 110: Sujet de projet

PG 110: Sujet de projet PG 110: Sujet de projet 2012-2013 L'objectif de ce projet de programmation est la réalisation d'un jeu 2D en C. 1 Principes du jeu Nous voulons donner une dimension de jeu d'aventure à un jeu de type Bomberman

Plus en détail

TP : Shell Scripts. 1 Remarque générale. 2 Mise en jambe. 3 Avec des si. Systèmes et scripts

TP : Shell Scripts. 1 Remarque générale. 2 Mise en jambe. 3 Avec des si. Systèmes et scripts E3FI ESIEE Paris Systèmes et scripts B. Perret TP : Shell Scripts 1 Remarque générale Lorsque vous cherchez des informations sur Internet, n'oubliez pas que langage de shell script que nous avons vu correspond

Plus en détail

Cisco Certified Network Associate

Cisco Certified Network Associate Cisco Certified Network Associate Version 4 Protocoles et concepts de routage Chapitre 4 Quel événement peut-il occasionner une mise à jour déclenchée? Expiration d un minuteur de routage de mises à jour

Plus en détail

Sauvegardes sous Windows c 2003 serveur

Sauvegardes sous Windows c 2003 serveur Sauvegardes sous Windows c 2003 serveur Louis-Maurice De Sousa ~ Fabrice Lemoine ~ Jackie Daon 27 mars 2006 Table des matières 1 Introduction 3 2 NTbackup 3 2.1 La sauvegarde...........................

Plus en détail

TD : Routage inter-domaine avec BGP

TD : Routage inter-domaine avec BGP TD : Routage inter-domaine avec BGP Principes de fonctionnement du protocole Le protocole de routage BGP (Border Gateway Protocol) est un protocole permettant de communiquer des informations de routages

Plus en détail

Cours Langage C/C++ Programmation modulaire

Cours Langage C/C++ Programmation modulaire Cours Langage C/C++ Programmation modulaire Thierry Vaira BTS IRIS Avignon tvaira@free.fr «v0.1 Rappel Programmation modulaire (1/2) Le découpage d'un programme en sous-programmes est appelée programmation

Plus en détail

Interconnexion des réseaux - Routage

Interconnexion des réseaux - Routage Interconnexion des réseaux - Routage Concept de l interconnexion Équipement de la couche 3 - Domaine de broadcast Détermination du chemin Routage Table de routage Algorithmes de routage statiques et dynamiques

Plus en détail

RapidMiner. Data Mining. 1 Introduction. 2 Prise en main. Master Maths Finances 2010/2011. 1.1 Présentation. 1.2 Ressources

RapidMiner. Data Mining. 1 Introduction. 2 Prise en main. Master Maths Finances 2010/2011. 1.1 Présentation. 1.2 Ressources Master Maths Finances 2010/2011 Data Mining janvier 2011 RapidMiner 1 Introduction 1.1 Présentation RapidMiner est un logiciel open source et gratuit dédié au data mining. Il contient de nombreux outils

Plus en détail

1 Exercice 1 Question de cours (4 points)

1 Exercice 1 Question de cours (4 points) Info32B Systèmes d'exploitation année 2013-2014 Examen (1ère session) 16 décembre 2014 N. Sabouret L'épreuve dure 2h30. Tous les documents sont autorisés. Les exercices sont indépendants. 1 Exercice 1

Plus en détail

UE 503 L3 MIAGE. TD6 : Adressage IP. A. Belaïd

UE 503 L3 MIAGE. TD6 : Adressage IP. A. Belaïd UE 503 L3 MIAGE TD6 : Adressage IP A. Belaïd abelaid@loria.fr http://www.loria.fr/~abelaid/ Année Universitaire 2011/2012 Adressage IP Objectifs Si l on veut interconnecter des réseaux, on ne peut pas

Plus en détail

Gestion d'un entrepôt

Gestion d'un entrepôt Gestion d'un entrepôt Épreuve pratique d'algorithmique et de programmation Concours commun des écoles normales supérieures Durée de l'épreuve: 3 heures 30 minutes Juin/Juillet 2010 ATTENTION! N oubliez

Plus en détail

TP2 - Conguration réseau et commandes utiles. 1 Généralités. 2 Conguration de la machine. 2.1 Commande hostname

TP2 - Conguration réseau et commandes utiles. 1 Généralités. 2 Conguration de la machine. 2.1 Commande hostname Département d'informatique Architecture des réseaux TP2 - Conguration réseau et commandes utiles L'objectif de ce TP est d'une part de vous présenter la conguration réseau d'une machine dans l'environnement

Plus en détail

1.1 Remote Procedure Call (RPC)

1.1 Remote Procedure Call (RPC) 1.1 Remote Procedure Call (RPC) Le modèle Client-Serveur est un modèle simple à utiliser pour la structuration des systèmes répartis. Mais ce modèle s appuie sur des communications de type entrée/sortie

Plus en détail

Projet OpNet. Spécialité Réseaux 2003/2004 Yannick GRENZINGER Loic JAQUEMET

Projet OpNet. Spécialité Réseaux 2003/2004 Yannick GRENZINGER Loic JAQUEMET Projet OpNet Spécialité Réseaux 2003/2004 Yannick GRENZINGER Loic JAQUEMET 1Présentation...3 1.1Le besoin de mobilité...3 1.2Le protocole IP Mobile...4 1.3Opnet...5 1.4Le projet...6 2La réalisation du

Plus en détail

TP Interconnexion : Routage Externe

TP Interconnexion : Routage Externe 1/14 1. TP Interconnexion : Routage Externe Le but de ce TP est d étudier le protocole de routage Externe (BGP). De voir les mécanismes de peering, de filtrage des annonces et les politiques de routage.

Plus en détail

Sauvegarder ses données avec Syncback

Sauvegarder ses données avec Syncback Sauvegarder ses données avec Syncback D.Mouchené, ATICE Tarentaise - nov. 2015 Une fausse manœuvre, un virus, un incident matériel peuvent causer la destruction de fichiers informatiques et donc la perte

Plus en détail

1 Mise en forme des SELECT

1 Mise en forme des SELECT Table des matières Utilitaire SQL*PLUS 1 Mise en forme des SELECT 1 2 Commandes utilitaires de SQL*PLUS 2 2.1 Éditeur de la machine hôte.................... 2 2.2 Commande RUN, commande /.................

Plus en détail

1. Introduction... 2. 2. Création d'une macro autonome... 2. 3. Exécuter la macro pas à pas... 5. 4. Modifier une macro... 5

1. Introduction... 2. 2. Création d'une macro autonome... 2. 3. Exécuter la macro pas à pas... 5. 4. Modifier une macro... 5 1. Introduction... 2 2. Création d'une macro autonome... 2 3. Exécuter la macro pas à pas... 5 4. Modifier une macro... 5 5. Création d'une macro associée à un formulaire... 6 6. Exécuter des actions en

Plus en détail

UFR STAPS Informatique de Gestion 2007/2008. Support de cours

UFR STAPS Informatique de Gestion 2007/2008. Support de cours UFR STAPS Informatique de Gestion 2007/2008 Support de cours Farah Benamara-Zitoune benamara@irit.fr Tel: 0561557705 SOMMAIRE Fenêtre principale du tableur Excel... 3 Mise en forme des données... 3 Validation

Plus en détail

Guide pour la conception d'une application en C

Guide pour la conception d'une application en C Guide pour la conception d'une application en C Ph. Preux DESS IMST, ULCO Novembre 1999 1 Principes généraux Une application informatique, dès qu'elle dépasse une centaine de lignes de code, doit impérativement

Plus en détail

Semaine 4 : le protocole IP

Semaine 4 : le protocole IP Semaine 4 : le protocole IP Séance 1 : l adressage... 1 Séance 2 : le protocole IP... 8 Séance 3 : l adresse IP... 16 Séance 1 : l adressage Introduction Au cours de cette séance, nous allons parler de

Plus en détail

Programmation de robots

Programmation de robots Programmation de robots 1 Le robot Le but de ces séances d'initiation est de vous apprendre les bases de la programmation du robot en quelques heures. Pour arriver au plus vite au c ur du sujet, nous avons

Plus en détail

Conservatoire National des Arts et Métiers FOD Ile de France UE NFA051 LE ROUTAGE INTERNET

Conservatoire National des Arts et Métiers FOD Ile de France UE NFA051 LE ROUTAGE INTERNET Conservatoire National des Arts et Métiers FOD Ile de France UE NFA051 LE ROUTAGE INTERNET Version Auteur Commentaires 10 octobre 2004 Emile Geahchan Version Initiale 15 octobre 2005 Emile Geahchan Modifications

Plus en détail

1. Introduction...2. 2. Création d'une requête...2

1. Introduction...2. 2. Création d'une requête...2 1. Introduction...2 2. Création d'une requête...2 3. Définition des critères de sélection...5 3.1 Opérateurs...5 3.2 Les Fonctions...6 3.3 Plusieurs critères portant sur des champs différents...7 3.4 Requête

Plus en détail

LA GESTION DE FICHIERS

LA GESTION DE FICHIERS CHAPITRE 6 : LA GESTION DE FICHIERS Objectifs spécifiques Connaître la notion de fichier, ses caractéristiques Connaître la notion de répertoires et partitions Connaître les différentes stratégies d allocation

Plus en détail

Cours : Réseaux 3 Routage avancé

Cours : Réseaux 3 Routage avancé ons épartement de Télécommunicatio Dé Cours : Réseaux 3 Routage avancé Prof. A. Dahbi Cycle Ingénieur 2011 1 Objectifs Les objectifs sont : Décrire le rôle des protocoles de routage dynamique. Identifier

Plus en détail

CONNECTEUR PRESTASHOP VTIGER CRM

CONNECTEUR PRESTASHOP VTIGER CRM CONNECTEUR PRESTASHOP VTIGER CRM Page 1 / 14 Vtiger CRM - Prestashop Connector Pour PRESTASHOP version 1.4.x et 1.5.x Pour vtiger CRM version 5.1, 5.2.0, 5.2.1, 5.3 et 5.4 Introduction En tant que gérant

Plus en détail

2.3.3 Protocole CDP (Cisco Discovery Protocol)

2.3.3 Protocole CDP (Cisco Discovery Protocol) 2.3.3 Protocole CDP (Cisco Discovery Protocol) Examinez la présentation. Quels sont les deux réseaux, auxquels sont destinés les paquets, qui nécessitent que le routeur effectue une recherche récursive?

Plus en détail

Exemple de projet. «Gestion de contacts»

Exemple de projet. «Gestion de contacts» Université Paul Valéry Montpellier 3 Antenne universitaire de Béziers L3 AES parcours MISASHS ECUE «Logiciels spécialisés» Exemple de projet «Gestion de contacts» G. Richomme Table des matières 1. Introduction...

Plus en détail

ASSEMBLAGE ET ÉDITION DES LIENS

ASSEMBLAGE ET ÉDITION DES LIENS ASSEMBLAGE ET ÉDITION DES LIENS Mewtow 11 novembre 2015 Table des matières 1 Introduction 5 2 La chaine d assemblage 7 2.1 Résolution des symboles.............................. 7 2.2 Relocation.....................................

Plus en détail

Microsoft OSQL OSQL ou l'outil de base pour gérer SQL Server

Microsoft OSQL OSQL ou l'outil de base pour gérer SQL Server Microsoft OSQL OSQL ou l'outil de base pour gérer SQL Server Suite à mon précédent article concernant MSDE, je me suis rendu compte à partir des commentaires que de nombreux utilisateurs avaient des problèmes

Plus en détail

1 Le code ASCII et le code Latin-1

1 Le code ASCII et le code Latin-1 USTL - Licence ST-A 1ère année 2006-2007 Algorithmes et Programmation Impérative 1 Objectifs du TP 1. travailler la mise en forme d'un achage. TP 1 : Table de caractères ASCII 1 Le code ASCII et le code

Plus en détail

GESTION D'UNE BASE DE DONNEES DOCUMENTAIRE

GESTION D'UNE BASE DE DONNEES DOCUMENTAIRE GESTION D'UNE BASE DE DONNEES DOCUMENTAIRE PAR Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 1 INTRODUCTION Le but du projet est la mise en place d'une application distribué : une bibliothèque.

Plus en détail

Consultation publique sur la portabilité des numéros

Consultation publique sur la portabilité des numéros Consultation publique sur la portabilité des numéros Table des matières 1 Préambule 2 2 Cadre réglementaire 2 3 Dénitions 4 4 Système de portabilité des numéros 4 4.1 Modes de routage.................................

Plus en détail

TP Réseaux Département Télécommunications 3A TP Routage interne Zebra OSPF

TP Réseaux Département Télécommunications 3A TP Routage interne Zebra OSPF TP Réseaux Département Télécommunications 3A TP Routage interne Zebra OSPF Martin Heusse Les manipulations décrites dans ce document portent sur le routage au sein d un système autonome. Elles visent également

Plus en détail

Plan de cette partie. Implantation des SGBD relationnels. Définition et fonctionnalités. Index. Coûts pour retrouver des données

Plan de cette partie. Implantation des SGBD relationnels. Définition et fonctionnalités. Index. Coûts pour retrouver des données Implantation des SGBD relationnels Université de Nice Sophia-Antipolis Version 3.4 25//06 Richard Grin Plan de cette partie Nous allons étudier (très rapidement!) quelques éléments de solutions utilisés

Plus en détail

BAC PRO Système Electronique Numérique. Nom : Le routage Date : LE ROUTAGE

BAC PRO Système Electronique Numérique. Nom : Le routage Date : LE ROUTAGE 1. Sommaire LE ROUTAGE 1. Sommaire... 1 2. Un routeur, pour quoi faire?... 1 3. Principe de fonctionnement du routage.... 2 4. Interfaces du routeur... 3 4.1. Côté LAN.... 3 4.2. Côté WAN.... 3 5. Table

Plus en détail

Méthodes d optimisation pour un problème de co-voiturage couplé aux transports en commun

Méthodes d optimisation pour un problème de co-voiturage couplé aux transports en commun Méthodes d optimisation pour un problème de co-voiturage couplé aux transports en commun Aziz Amnay Encadrant : Nadia Brauner Responsable Ensimag : Florence MARANINCHI Grenoble, le 16 mai 2012 Table des

Plus en détail

Environnement de programmation

Environnement de programmation Environnement de programmation 1.La programmation Les ordinateurs sont stupides! à un point dont on n'a pas idée. Ils ne réagissent ni ne répondent qu'à des situations ou à des données anticipées par le

Plus en détail

Fonctionnement du serveur Z39.50

Fonctionnement du serveur Z39.50 Fonctionnement du serveur Z39.50 Table des matières 1 Configuration du serveur...2 1.1 Comportement du serveur...2 1.2 Configuration de la traduction z39.50 -> base de données...2 1.3 Configuration du

Plus en détail

Réseaux locaux virtuels : VLAN

Réseaux locaux virtuels : VLAN Réseaux locaux virtuels : VLAN I. Historique Les premiers réseaux Ethernet (on se situe donc en couche 2) étaient conçus à base de câbles coaxiaux raccordés entre eux et connectés aux ordinateurs, si bien

Plus en détail

Les types somme. 1 Préparation du TP. 2 Interface du module Carte. Algorithmes et Programmation Impérative 2. 2.1 Les types de donnees

Les types somme. 1 Préparation du TP. 2 Interface du module Carte. Algorithmes et Programmation Impérative 2. 2.1 Les types de donnees Univ. Lille1 - Licence Informatique 2ème année 2014-15 Algorithmes et Programmation Impérative 2 Les types somme 1 Préparation du TP Dans le prochain TP, vous allez réaliser un programme de jeu de poker

Plus en détail

TP 2 et 3 Introduction à C

TP 2 et 3 Introduction à C TP 2 et 3 Introduction à C Partie A : prise en main de gcc et makefile L'objectif de cette partie est de vous familiariser avec le langage C et sa chaîne de développement basée sur le compilateur gcc,

Plus en détail

Routage IP: Protocoles. Page 1. 1994: création Bernard Tuy Modifications. 1995 Bernard Tuy 1997 Bernard Tuy 1998 Bernard Tuy

Routage IP: Protocoles. Page 1. 1994: création Bernard Tuy Modifications. 1995 Bernard Tuy 1997 Bernard Tuy 1998 Bernard Tuy Routage IP: Protocoles 1994: création Bernard Tuy Modifications 1995 Bernard Tuy 1997 Bernard Tuy 1998 Bernard Tuy Page 1 Plan Les protocoles de Routage IP Généralités RIP (2) IGRP OSPF EGP (2) BGP CIDR

Plus en détail

IP Office IP Office Manuel de l'utilisateur de la messagerie vocale intégrée

IP Office IP Office Manuel de l'utilisateur de la messagerie vocale intégrée Manuel de l'utilisateur de la messagerie vocale intégrée 15-604067 Version 11a - (29/04/2011) 2011 AVAYA Tous droits réservés. Note Bien que tous les efforts nécessaires aient été mis en œuvre en vue de

Plus en détail

Manuel d'installation et d'utilisation Jetro 4.2

Manuel d'installation et d'utilisation Jetro 4.2 Manuel d'installation et d'utilisation Jetro 4.2 version 1.0 Table des matières 1. AVANT DE DEMARRER L'INSTALLATION... 3 2. INSTALLATION DU JETRO COCKPIT CLIENT 4.2:... 4 3. DEMARRER POUR LE PREMIERE FOIS

Plus en détail

Algorithmique et programmation. Cours d'algorithmique illustré par des exemples pour le picbasic

Algorithmique et programmation. Cours d'algorithmique illustré par des exemples pour le picbasic Algorithmique et programmation Cours d'algorithmique illustré par des exemples pour le picbasic Même s'il est possible d'écrire un programme petit à petit par touches successives, le résultat est souvent

Plus en détail

Le compilateur NAZE. Table des matières. 1 Présentation du sujet. Alexandre LHUILLIER FIPA 2 21 juin 2011. 1 Présentation du sujet 1 1.1 But...

Le compilateur NAZE. Table des matières. 1 Présentation du sujet. Alexandre LHUILLIER FIPA 2 21 juin 2011. 1 Présentation du sujet 1 1.1 But... Le compilateur NAZE Alexandre LHUILLIER FIPA 2 21 juin 2011 Table des matières 1 Présentation du sujet 1 11 But 2 2 Manuel d'utilisation 2 21 Fichier d'entrée 2 22 Champs obligatoires 3 23 Champs communs

Plus en détail

Programmation Objet - Cours II

Programmation Objet - Cours II Programmation Objet - Cours II - Exercices - Page 1 Programmation Objet - Cours II Exercices Auteur : E.Thirion - Dernière mise à jour : 05/07/2015 Les exercices suivants sont en majorité des projets à

Plus en détail

Introduction à MPLS F. Nolot 2009 1

Introduction à MPLS F. Nolot 2009 1 Introduction à MPLS 1 Introduction à MPLS Introduction 2 Introduction Les fournisseurs d'accès veulent Conserver leur infrastructure existante ET Ajouter de nouveaux services non supportés par la technologie

Plus en détail

Afin d'assouplir l'usage, lorsqu'aucun mot-clé n'est fourni l'outil considère que c'est un joueur qui s'adresse à ses entraîneurs-éducateurs.

Afin d'assouplir l'usage, lorsqu'aucun mot-clé n'est fourni l'outil considère que c'est un joueur qui s'adresse à ses entraîneurs-éducateurs. Carnet partagé d'adresses mail et de numéro de téléphone portable (sms) Guide Utilisateur Vous êtes membre d'un club sportif amateur ou d'une association à but non lucratif? Plus besoin, pour les joindre,

Plus en détail

Examen final LOG3000 Hiver 2014

Examen final LOG3000 Hiver 2014 Examen final LOG3000 Hiver 2014 Lundi le 28 avril 2014. Durée : 13h30 à 16h00 (total 2h30). Local : A-532. Total des points : 20. Pondération de l'examen dans la note finale : 40%. Sans documentation.

Plus en détail

EXAMEN BLANC CCNA CORRECTION

EXAMEN BLANC CCNA CORRECTION EXAMEN BLANC CCNA CORRECTION BLOG : WWW.REUSSIRSONCCNA.FR CONTACT : REUSSIRSONCCNA@GMAIL.COM CLIQUEZ ICI POUR TELECHARGEZ LE TEST BLANC QUESTION 1 C est le protocole TCP Transport Control Protocol qui

Plus en détail

Module SMS pour Microsoft Outlook MD et Outlook MD Express. Guide d'aide. Guide d'aide du module SMS de Rogers Page 1 sur 40 Tous droits réservés

Module SMS pour Microsoft Outlook MD et Outlook MD Express. Guide d'aide. Guide d'aide du module SMS de Rogers Page 1 sur 40 Tous droits réservés Module SMS pour Microsoft Outlook MD et Outlook MD Express Guide d'aide Guide d'aide du module SMS de Rogers Page 1 sur 40 Table des matières 1. Exigences minimales :...3 2. Installation...4 1. Téléchargement

Plus en détail

Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée

Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée sous réserve du respect des conditions de la licence Texte

Plus en détail

Résolution des problèmes de fax. Questions fréquentes sur les télécopies... 2. Résolution des problèmes d'envoi de télécopies... 3

Résolution des problèmes de fax. Questions fréquentes sur les télécopies... 2. Résolution des problèmes d'envoi de télécopies... 3 1 fax Questions fréquentes sur les télés.............. 2 Résolution des problèmes d'envoi de télés..... 3 Résolution des problèmes de réception de télés.. 5 Erreurs d'envoi de télés.......................

Plus en détail

Rapport de TP n 4 Compression Estimation de mouvement

Rapport de TP n 4 Compression Estimation de mouvement Rapport de TP n 4 Compression Estimation de mouvement Master 1 Audiovisuel et Multimédia (ISIS) François Soulier et Romain Laisne Clément Faure-Brac et Clément Follet Professeur : Mme Bacquet 1 mai 008

Plus en détail

REPRÉSENTATION DES NOMBRES EN MACHINE

REPRÉSENTATION DES NOMBRES EN MACHINE Info 2 REPRÉSENTATION DES NOMBRES EN MACHINE Problématique Dans la mémoire d'un ordinateur, les données sont représentées sous forme de séquences de 0 et de 1. Par conséquent, toute information mémorisée

Plus en détail

Check-list de maintenance du système Instructions impératives pour l'utilisateur du système Dernière mise à jour 09 juin 2011

Check-list de maintenance du système Instructions impératives pour l'utilisateur du système Dernière mise à jour 09 juin 2011 ANNEXE 3 Check-list de maintenance du système Instructions impératives pour l'utilisateur du système Dernière mise à jour 09 juin 2011 Généralités Afin de pouvoir garantir un support sûr et efficace du

Plus en détail

Table des matières. Historique... 2. Droits d'auteurs et de reproductions... 3

Table des matières. Historique... 2. Droits d'auteurs et de reproductions... 3 Table des matières Historique... 2 Droits d'auteurs et de reproductions... 3 Introduction... 4 Objectifs du document... 4 Portée du produit/document... 4 Définitions... 5 Document de références... 5 Aperçu

Plus en détail

Java - TP3. Nicolas Baudru, Carine Guivier-Curien, Laurent Vallet. Année 2008-2009

Java - TP3. Nicolas Baudru, Carine Guivier-Curien, Laurent Vallet. Année 2008-2009 Java - TP3 Nicolas Baudru, Carine Guivier-Curien, Laurent Vallet Année 2008-2009 Le but de ce TD est d'écrire une application client/serveur de type msn : 1. Des clients se connectent à un serveur 2. Un

Plus en détail

M2 TIIR (2013-2014) Bilel Derbel

M2 TIIR (2013-2014) Bilel Derbel M2 TIIR (2013-2014) Bilel Derbel Notre but est de concevoir une application générique sur grid5000 qui permet de déployer des calculs parallèles de façon transparente Plus précisément, nous nous plaçons

Plus en détail

Érasme : soutien aux initiatives locales WiFi. Projet WiFi de la Maison des Jeunes de Pomeys

Érasme : soutien aux initiatives locales WiFi. Projet WiFi de la Maison des Jeunes de Pomeys Érasme : soutien aux initiatives locales WiFi Projet WiFi de la Maison des Jeunes de Pomeys compte rendu des travaux d'avril à septembre 2003 (document extrait de mon rapport de stage d'iup Génie Informatique,

Plus en détail

Administration Réseau

Administration Réseau M1 Réseaux Informatique et Applications Administration Réseau Date: 02/04/07 Auteurs: Alexis Demeaulte, Gaël Cuenot Professeurs: Patrick Guterl Table des matières 1Introduction...3 2HP OPENVIEW...3 3Les

Plus en détail

Les patrons de conception décrivent des solutions standards pour répondre à des problèmes d'architecture et de conception des logiciels.

Les patrons de conception décrivent des solutions standards pour répondre à des problèmes d'architecture et de conception des logiciels. Design Pattern En génie Logiciel, un patron de conception (design pattern en anglais) est un concept destiné à résoudre les problèmes récurrents suivant le paradigme objet. En français on utilise aussi

Plus en détail

S inscrire dans l application.

S inscrire dans l application. Table of Contents S inscrire dans l application.... 2 Introduire une demande d'autorisation... 3 A. Informations générales... 7 B. Type de véhicule... 10 C. Toutes les caractéristiques du véhicule complet....

Plus en détail

TD 2 Chapitre 4 : Support des Services et Serveurs. Objectifs : Maîtriser l'exploitation des tables de routage dynamique.

TD 2 Chapitre 4 : Support des Services et Serveurs. Objectifs : Maîtriser l'exploitation des tables de routage dynamique. SI 5 BTS Services Informatiques aux Organisations 1 ère année TD 2 Chapitre 4 : Support des Services et Serveurs Le routage dynamique Objectifs : Maîtriser l'exploitation des tables de routage dynamique.

Plus en détail

LE PROBLEME DU FLOT MAXIMAL

LE PROBLEME DU FLOT MAXIMAL LE PROBLEME DU FLOT MAXIMAL I Exemple d introduction Deux châteaux d'eau alimentent 3 villes à travers un réseau de canalisations au sein duquel se trouvent également des stations de pompage. Les châteaux

Plus en détail

Diagrammes de décisions binaires

Diagrammes de décisions binaires Diagrammes de décisions binaires Épreuve pratique d'algorithmique et de programmation Concours commun des écoles normales supérieures Durée de l'épreuve: 3 heures 30 minutes Juillet 2009 ATTENTION! N oubliez

Plus en détail

1) La messagerie académique (XXX@ac-toulouse.fr) est la seule utilisée par l'administration et le courrier administratif.

1) La messagerie académique (XXX@ac-toulouse.fr) est la seule utilisée par l'administration et le courrier administratif. 1) La messagerie académique (XXX@ac-toulouse.fr) est la seule utilisée par l'administration et le courrier administratif. 2) Il existe 2 façons de gérer son courrier électronique. Le webmail : Aller sur

Plus en détail

LISTES DE DISTRIBUTION GÉRÉ PAR SYMPA DOCUMENT EXPLICATIF DE ÉCOLE POLYTECHNIQUE

LISTES DE DISTRIBUTION GÉRÉ PAR SYMPA DOCUMENT EXPLICATIF DE ÉCOLE POLYTECHNIQUE LISTES DE DISTRIBUTION GÉRÉ PAR SYMPA DOCUMENT EXPLICATIF DE L'INTERFACE WEB À L'INTENTION DES GESTIONNAIRES DE LISTES ÉCOLE POLYTECHNIQUE JANVIER 2002 Le présent document est un aide mémoire pour la gestion

Plus en détail

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU LANDPARK NETWORK IP Avril 2014 LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU Landpark NetworkIP est composé de trois modules : Un module Serveur, que l'on installe sur n'importe

Plus en détail

Raja Bases de données distribuées A Lire - Tutoriel

Raja Bases de données distribuées A Lire - Tutoriel Université des Sciences de Montpellier Master 2 Semestre 1 Unité d'enseignement FMIN306 Raja Bases de données distribuées A Lire - Tutoriel 26 janvier 2011 Audrey Novak Romain Maneschi Jonathan Fhal Aloys

Plus en détail

Chapitre 5. Communication interprocessus. 5.1 Introduction

Chapitre 5. Communication interprocessus. 5.1 Introduction Communication interprocessus 5.1 Introduction Dans une activité parallèle (ou pseudo parallèle), un ensemble de processus séquentiels s exécutent en parallèle. Cette exécution résulte deux types de relations

Plus en détail

Cours n 9. Trunking - VTP Inter-VLAN

Cours n 9. Trunking - VTP Inter-VLAN Cours n 9 Trunking - VTP Inter-VLAN 1 Sommaire Agrégation (Trunking) VTP Inter-VLAN routing 2 Définition L'apparition de l'agrégation (trunking) remonte aux origines des technologies radio et de téléphonie.

Plus en détail

Routage Statique. Protocoles de Routage et Concepts. Version 4.0. 2007 Cisco Systems, Inc. All rights reserved. Cisco Public 1

Routage Statique. Protocoles de Routage et Concepts. Version 4.0. 2007 Cisco Systems, Inc. All rights reserved. Cisco Public 1 Routage Statique Protocoles de Routage et Concepts Version 4.0 1 Objectifs Définir le rôle général d'un routeur dans les réseaux. Décrire les réseaux directement connectés et les différentes interfaces

Plus en détail

SweetyPix, mode d'emploi

SweetyPix, mode d'emploi Université de Nice Sophia-Antipolis Master 1 STIC Informatique SweetyPix, mode d'emploi Edouard Jan Mendher Merzoug Anne-Laure Radigois Amaury Tinard 2005-2006 Université de Nice Sophia-Antipolis Master

Plus en détail

Tutorial : Partitionner son disque dur avec Partition Magic

Tutorial : Partitionner son disque dur avec Partition Magic Tutorial : Partitionner son disque dur avec Partition Magic INTRODUCTION : Le but de ce tutorial n'est pas de faire un descriptif détaillé de toutes les fonctions de Partition Magic mais seulement d'apprendre

Plus en détail

Principe de fonctionnement du contrôleur de domaine

Principe de fonctionnement du contrôleur de domaine MODULE UTILISATION DES ESPACES DE STOCKAGE (source :prise en main du contrôleur de domaine Solaere) Préambule Vos stations sont configurées et intégrées dans le domaine. Principe de fonctionnement du contrôleur

Plus en détail

Principes de DHCP. Le mécanisme de délivrance d'une adresse IP à un client DHCP s'effectue en 4 étapes : COMMUTATEUR 1. DHCP DISCOVER 2.

Principes de DHCP. Le mécanisme de délivrance d'une adresse IP à un client DHCP s'effectue en 4 étapes : COMMUTATEUR 1. DHCP DISCOVER 2. DHCP ET TOPOLOGIES Principes de DHCP Présentation du protocole Sur un réseau TCP/IP, DHCP (Dynamic Host Configuration Protocol) permet d'attribuer automatiquement une adresse IP aux éléments qui en font

Plus en détail

Projet Bases de Donnée

Projet Bases de Donnée Projet Bases de Donnée Téo Mazars Kévin Polisano Alejandro Bluementals Victor Sabatier Table des matières 1 Analyse du problème 2 2 Conception Entités/Associations 3 3 Traduction en relationnel 4 4 Analyse

Plus en détail

Rappel de cours Learning Tree 466 Introduction aux routeurs Cisco

Rappel de cours Learning Tree 466 Introduction aux routeurs Cisco Rappel de cours Learning Tree 466 Introduction aux routeurs Cisco Présentation du routeur Le fonctionnement du routeur nécessite : un système d'exploitation : IOS, qui contrôle le routeur une configuration,

Plus en détail