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

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

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

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

Chapitre 4 : Le routage. Support des services et serveurs

Chapitre 4 : Le routage. Support des services et serveurs SI 5 BTS Services Informatiques aux Organisations 1 ère année Chapitre 4 : Support des services et serveurs Objectifs : Le routage Comprendre les mécanismes complexes de routage statique et dynamique.

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

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

RAPPORT DE CONCEPTION UML :

RAPPORT DE CONCEPTION UML : Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang RAPPORT DE CONCEPTION UML : Bamboo Ch@t Projet GM4 Juin 2006 Table des matières 1 Introduction 2 2 Présentation du logiciel 3 2.1 Précisions

Plus en détail

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours 0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage 3- Organisation du cours Le présent cours constitue une introduction pour situer le langage C++, beaucoup des concepts

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

RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005

RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005 Oussama ELKACHOINDI Wajdi MEHENNI RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005 Sommaire I. Préliminaire : Notice d exécution et mode opératoire...4 II. Architecture globale de l application...5

Plus en détail

INF-130 Travail Pratique #2

INF-130 Travail Pratique #2 École de technologie supérieure INF-30 Travail Pratique #2 Travail individuel Tracé d un métro Francis Bourdeau, Frédérick Henri et Patrick Salois Remise à la 0 e semaine. Objectifs - Amener l étudiant

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

Quelques éléments de compilation en C et makefiles

Quelques éléments de compilation en C et makefiles Quelques éléments de compilation en C et makefiles Guillaume Feuillade 1 Compiler un programme C Le principe de la compilation consiste à passer d un ensemble de fichiers de code à un programme exécutable

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

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

TP Maîtrise Statistique des Procédés

TP Maîtrise Statistique des Procédés TP Maîtrise Statistique des Procédés Vous allez utiliser un programme informatique «SIMDI Tour» qui simule (sommairement) le fonctionnement d un tour à commande numérique. Pendant ce TP, qui se déroule

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

Clément MILVILLE / Edouard SIMON. Projet CodeWar. Enseignant tuteur: Michaël Hauspie 1/17

Clément MILVILLE / Edouard SIMON. Projet CodeWar. Enseignant tuteur: Michaël Hauspie 1/17 Projet CodeWar Enseignant tuteur: Michaël Hauspie 1/17 2/17 Remerciements: Nous tenons à remercier tout particulièrement notre tuteur M. Michaël HAUSPIE pour son aide, ses conseils, ses avis et sa disponibilité

Plus en détail

BGP Le routage inter-domaine

BGP Le routage inter-domaine BGP Le routage inter-domaine Bernard Cousin Plan Présentation de BGP Le protocole BGP Les attributs de BGP Quelques particularités de BGP ibgp Border Gateway Protocol 2 1 BGP version 4 Le protocole pour

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

2B La résolution de modèles linéaires par Excel 2010

2B La résolution de modèles linéaires par Excel 2010 2B La résolution de modèles linéaires par Excel 2010 Nous reprenons ici, de façon plus détaillée, la section où est indiqué comment utiliser le solveur d'excel 2010 pour résoudre un modèle linéaire (voir

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

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

Le protocole TCP /IP

Le protocole TCP /IP Le protocole TCP /IP Définition d'une URL : URL : ( Uniform Ressource Locator ) Http:// www. wanadoo.fr / public / index.htm Protocole Nom d ordinateur Sous domaine Domaine racine répertoire Fichier Prococole

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

Compte-rendu de projet de Cryptographie

Compte-rendu de projet de Cryptographie Compte-rendu de projet de Cryptographie Chirement/Déchirement de texte, d'images de sons et de vidéos LAMBERT VELLER Sylvain M1 STIC Université de Bourgogne 2010-2011 Reponsable : Mr Pallo Table des matières

Plus en détail

La hiérarchie du système DNS

La hiérarchie du système DNS LA RÉSOLUTION DE NOMS 1. PRÉSENTATION DU SYSTÈME DNS 1.1 INTRODUCTION À LA RÉSOLUTION DE NOMS Pour pouvoir communiquer, chaque machine présente sur un réseau doit avoir un identifiant unique. Avec le protocole

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

La comptabilisation dans la ligne Crésus Le module de comptabilisation

La comptabilisation dans la ligne Crésus Le module de comptabilisation Note La comptabilisation dans la ligne Crésus Le module de comptabilisation Ce document présente le fonctionnement du module de comptabilisation qui prend la relève entre les programmes de facturation

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

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

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

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

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

Présentation. Logistique. Résumé de la 1e Partie. Mise en place du système

Présentation. Logistique. Résumé de la 1e Partie. Mise en place du système Présentation Diapo01 Je m appelle Michel Canneddu. Je développe avec 4D depuis 1987 et j exerce en tant qu indépendant depuis 1990. Avant de commencer, je tiens à remercier mes parrains Jean-Pierre MILLIET,

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

Claude Delannoy. Exercices C++ en langage. 3 e édition. Groupe Eyrolles, 1997, 1999, 2007, ISBN : 978-2-212-12201-5

Claude Delannoy. Exercices C++ en langage. 3 e édition. Groupe Eyrolles, 1997, 1999, 2007, ISBN : 978-2-212-12201-5 Claude Delannoy Exercices en langage C++ 3 e édition Groupe Eyrolles, 1997, 1999, 2007, ISBN : 978-2-212-12201-5 Chapitre 3 Les fonctions Rappels Généralités Une fonction est un bloc d instructions éventuellement

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

1.1- Compiler et exécuter un premier programme en C++

1.1- Compiler et exécuter un premier programme en C++ 1.1- Compiler et exécuter un premier programme en C++ 1- Un premier programme en C++ 2- Compilation et exécution 1- Un premier programme en C++ Le premier programme que propose le cours consiste à afficher

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

Réseau ISO-Raisin. Surveillance des. Infections du Site Opératoire. (Surveillance des interventions prioritaires)

Réseau ISO-Raisin. Surveillance des. Infections du Site Opératoire. (Surveillance des interventions prioritaires) Réseau ISO-Raisin Surveillance des Infections du Site Opératoire (Surveillance des interventions prioritaires) Guide d utilisation de l application WEBISO Année 2015 Sommaire Guide utilisateur - Application

Plus en détail

Vtiger CRM - Prestashop Connector

Vtiger CRM - Prestashop Connector Vtiger CRM - Prestashop Connector Pour PRESTASHOP version 1.4.x Pour vtiger CRM version 5.1, 5.2.0 et 5.2.1 Introduction En tant que gestionnaire d'une boutique en ligne, vous cherchez constamment de meilleurs

Plus en détail

Programmation C++ (débutant)/les tableaux statiques

Programmation C++ (débutant)/les tableaux statiques Programmation C++ (débutant)/les tableaux statiques 1 Programmation C++ (débutant)/les tableaux statiques Le cours du chapitre 6 : les tableaux statiques Les tableaux Une variable entière de type int ne

Plus en détail

Apprendre la dichotomie avec Colobot

Apprendre la dichotomie avec Colobot Apprendre la dichotomie avec Colobot CHABALIER Nicolas MONCEL Arnaud Année Universitaire 2014 2015 1 Apprendre la dichotomie avec Colobot Présenté par CHABALIER Nicolas et MONCEL Arnaud Tuteur : Jacques

Plus en détail

TCSMP - Time-Cost Stamped Mail Protocol

TCSMP - Time-Cost Stamped Mail Protocol Projet de Master Informatique M1 Université Paris-Est Marne-la-Vallée Session TCSMP Time-Cost Stamped Mail Protocol TCSMP - Time-Cost Stamped Mail Protocol Documentation utilisateur,,, Introduction...

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

RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS

RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS Université Joseph Fourier Département Licence Sciences & Technologie RAPPORT DE STAGE GENERATION DE TESTS POUR AMELIORER DES OUTILS DE CALCUL DE TEMPS D'EXECUTION PIRE CAS Laboratoire d'accueil : Verimag

Plus en détail

ACTIVITE de FORMATION ACTIVITE : CISCO PACKET TRACER : SIMULATION DU FONCTIONNEMENT D UN RESEAU INFORMATIQUE

ACTIVITE de FORMATION ACTIVITE : CISCO PACKET TRACER : SIMULATION DU FONCTIONNEMENT D UN RESEAU INFORMATIQUE ACTIVITE de FORMATION ACTIVITE : CISCO PACKET TRACER : SIMULATION DU FONCTIONNEMENT D UN RESEAU INFORMATIQUE @ CONDITIONS D EXERCICE - Moyens et Ressources TAXONOMIE 1 2 3 4 Internet Logiciel Doc. PC Outillages

Plus en détail

L3 ASR Projet 1: DNS. Rapport de Projet

L3 ASR Projet 1: DNS. Rapport de Projet L3 ASR Projet 1: DNS Rapport de Projet Table des matières I. Maquette de travail...1 II. Configuration des machines...2 III. Type de zone...3 IV. Délégation de zone...3 V. Suffixes DNS...4 VI. Mise en

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

Rapport de projet. Animation de diagrammes d'état - CHAMPION Adrien - ETIENNE Thibaut RIZZI Thibaut 1A - INFO - Groupe EF - G36.

Rapport de projet. Animation de diagrammes d'état - CHAMPION Adrien - ETIENNE Thibaut RIZZI Thibaut 1A - INFO - Groupe EF - G36. Rapport de projet Animation de diagrammes d'état - CHAMPION Adrien - ETIENNE Thibaut RIZZI Thibaut 1A - INFO - Groupe EF - G36 Juin 2008 2 Table des matières 1 Introduction...5 1.1 - Objectif...5 1.2 Choix

Plus en détail

TP4 : Firewall IPTABLES

TP4 : Firewall IPTABLES Module Sécurité TP4 : Firewall IPTABLES Ala Rezmerita François Lesueur Le TP donnera lieu à la rédaction d un petit fichier texte contenant votre nom, les réponses aux questions ainsi que d éventuels résultats

Plus en détail

Introduction aux systèmes d exploitation

Introduction aux systèmes d exploitation Introduction aux systèmes d exploitation Le système d exploitation est un ensemble de logiciels qui pilotent la partie matérielle d un ordinateur. Les principales ressources gérées par un système d exploitation

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

Master d'informatique 1ère année. Réseaux et protocoles. Architecture : les bases

Master d'informatique 1ère année. Réseaux et protocoles. Architecture : les bases Master d'informatique 1ère année Réseaux et protocoles Architecture : les bases Bureau S3-203 Mailto : alexis.lechervy@unicaen.fr D'après un cours de Jean Saquet Réseaux physiques LAN : Local Area Network

Plus en détail

Tutorial Ophcrack. I) Ophcrack en API. (ou comment utiliser Ophcrack pour recouvrir un mot de passe sous Windows XP et Windows Vista)

Tutorial Ophcrack. I) Ophcrack en API. (ou comment utiliser Ophcrack pour recouvrir un mot de passe sous Windows XP et Windows Vista) Tutorial Ophcrack (ou comment utiliser Ophcrack pour recouvrir un mot de passe sous Windows XP et Windows Vista) Ophcrack est un utilitaire gratuit permettant de cracker les mots de passe des sessions

Plus en détail

La Clé informatique. Formation Access XP Aide-mémoire

La Clé informatique. Formation Access XP Aide-mémoire La Clé informatique Formation Access XP Aide-mémoire Septembre 2003 Définitions de termes Base de données : Se compare à un énorme classeur ayant plusieurs tiroirs où chacun d eux contient des informations

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

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

INTERNET CONTROL MESSAGE PROTOCOL

INTERNET CONTROL MESSAGE PROTOCOL Issu de la RFC 792 INTERNET CONTROL MESSAGE PROTOCOL SPECIFICATIONS Crédits : Jon Postel / ISI Traduction : V.G. FREMAUX Simplification et ajouts pour utilisation élève : B. JEZEQUEL / Lycée La Providence

Plus en détail

Classes et templates C++

Classes et templates C++ Classes et templates C++ Ce TP propose une application des classes, des templates et du polymorphisme au travers du design de classes permettant de gérer des courbes de Bézier. Contents 1 Bézier unidimensionnelle

Plus en détail

SAS BI DASHBOARD 4.3 : POUR LE MEILLEUR ET POUR LE FILTRE

SAS BI DASHBOARD 4.3 : POUR LE MEILLEUR ET POUR LE FILTRE SAS BI DASHBOARD 4.3 : POUR LE MEILLEUR ET POUR LE FILTRE En tant qu outils d aide à la décision, les tableaux de bord doivent répondre rapidement. Pour participer à cet effort de réactivité en termes

Plus en détail

Gestion du parc informatique matériel et logiciel de l Ensicaen. Rapport de projet. Spécialité Informatique 2 e année. SAKHI Taoufik SIFAOUI Mohammed

Gestion du parc informatique matériel et logiciel de l Ensicaen. Rapport de projet. Spécialité Informatique 2 e année. SAKHI Taoufik SIFAOUI Mohammed 6, bd maréchal Juin F-14050 Caen cedex 4 Spécialité Informatique 2 e année Rapport de projet Gestion du parc informatique matériel et logiciel de l Ensicaen SAKHI Taoufik SIFAOUI Mohammed Suivi ENSICAEN

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

TP de Temps Réel : Prise en main d'une cible embarquée sous Linux

TP de Temps Réel : Prise en main d'une cible embarquée sous Linux TP de Temps Réel : Prise en main d'une cible embarquée sous Linux ENSIBS 2 eme année, Spécialité Informatique 1 Objectif Ce TP fais partie des TP de Temps-Réel et vise à prendre en main une cible embarquée.

Plus en détail

A.-M. Cubat PMB - Import de notices à partir d un tableur Page 1 Source : http://amcubat.be/docpmb/import-de-notices

A.-M. Cubat PMB - Import de notices à partir d un tableur Page 1 Source : http://amcubat.be/docpmb/import-de-notices A.-M. Cubat PMB - Import de notices à partir d un tableur Page 1 Comme beaucoup de personnes, j'ai voulu récupérer les notices de mon ancien logiciel de gestion de bibliothèque. Vu qu'il ne prévoyait pas

Plus en détail

Pratiquons ensemble Outlook 2003 fonctions avancées - Laurent DUPRAT - Pratiquons ensemble

Pratiquons ensemble Outlook 2003 fonctions avancées - Laurent DUPRAT - Pratiquons ensemble Pratiquons Pratiquons Outlook 2003 fonctions avancées - - ensemble Outlook 2003 - Pratiquons ensemble ensemble Outlook 2003 fonctions avancées - - Pratiquons Support ensemble Outlook 2003 fonctions de

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

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

Utiliser Access ou Excel pour gérer vos données

Utiliser Access ou Excel pour gérer vos données Page 1 of 5 Microsoft Office Access Utiliser Access ou Excel pour gérer vos données S'applique à : Microsoft Office Access 2007 Masquer tout Les programmes de feuilles de calcul automatisées, tels que

Plus en détail

TRAITEMENTS DE FIN D ANNEE

TRAITEMENTS DE FIN D ANNEE TRAITEMENTS DE FIN D ANNEE GENERALITES Le nouvel exercice peut être ouvert dès la fin de l année courante. Ainsi vous pourrez commencer la saisie des écritures concernant la nouvelle année tout en continuant

Plus en détail

Cours admin 200x serveur : DNS et Netbios

Cours admin 200x serveur : DNS et Netbios LE SERVICE DNS Voici l'adresse d'un site très complet sur le sujet (et d'autres): http://www.frameip.com/dns 1- Introduction : Nom Netbios et DNS Résolution de Noms et Résolution inverse Chaque composant

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

Logiciel de gestion de l'école de musique de Fontaine. Manuel utilisateur

Logiciel de gestion de l'école de musique de Fontaine. Manuel utilisateur Logiciel de gestion de l'école de musique de Fontaine Manuel utilisateur Mon Jun 4 14 :20 :45 2007 Table des matières 1 Présentation du logiciel 1 1.1 Introduction................................... 1

Plus en détail

Guide d intégration. Protection de logiciels 4D avec DinkeyPRO/FD. Contact Commercial : Tél. : 02 47 35 70 35 Email : com@aplika.

Guide d intégration. Protection de logiciels 4D avec DinkeyPRO/FD. Contact Commercial : Tél. : 02 47 35 70 35 Email : com@aplika. Guide d intégration Protection de logiciels 4D avec DinkeyPRO/FD Contact Commercial : Tél. : 02 47 35 70 35 Email : com@aplika.fr Contact Technique : Tél. : 02 47 35 53 36 Email : support@aplika.fr Version

Plus en détail

Le service FTP. M.BOUABID, 04-2015 Page 1 sur 5

Le service FTP. M.BOUABID, 04-2015 Page 1 sur 5 Le service FTP 1) Présentation du protocole FTP Le File Transfer Protocol (protocole de transfert de fichiers), ou FTP, est un protocole de communication destiné à l échange informatique de fichiers sur

Plus en détail

Algorithmique Distribuée Communication de groupes

Algorithmique Distribuée Communication de groupes Algorithmique Distribuée Communication de groupes Laurent PHILIPPE Master 2 Informatique UFR des Sciences et Techniques 2013/2014 Laurent PHILIPPE Communication de groupes 1 / 58 Les outils Les groupes

Plus en détail

Guide d utilisation de l outil d audit de sécurité. AUDITSec. Version 3.0

Guide d utilisation de l outil d audit de sécurité. AUDITSec. Version 3.0 Guide d utilisation de l outil d audit de sécurité AUDITSec Version 3.0 Mai 2011 Historique du document Version Date Auteur Description 1.0 6 novembre 2010 Éric Clairvoyant http://ca.linkedin.com/pub/ericclairvoyant/7/ba/227

Plus en détail

Guide de rapports ADT Sélecte

Guide de rapports ADT Sélecte Guide de rapports ADT Sélecte ADT Sélecte est un service qui permet à nos clients de requêter, ou planifier, leurs propres rapports. De la page de réception ADT Sélecte, cliquez sur Ouvrir une session

Plus en détail

1. Installation du Module

1. Installation du Module 1 sur 10 Mise en place du Module Magento V 1.5.7 1. Installation du Module Vous pouvez installer le module de deux façons différentes, en passant par Magento Connect, ou directement via les fichiers de

Plus en détail

Système. Introduction aux systèmes informatiques

Système. Introduction aux systèmes informatiques Introduction aux systèmes informatiques Système Un système est une collection organisée d'objets qui interagissent pour former un tout Objets = composants du système Des interconnexions (liens) entre les

Plus en détail

BAAN IVc. Guide de l'utilisateur BAAN Data Navigator

BAAN IVc. Guide de l'utilisateur BAAN Data Navigator BAAN IVc Guide de l'utilisateur BAAN Data Navigator A publication of: Baan Development B.V. B.P. 143 3770 AC Barneveld Pays-Bas Imprimé aux Pays-Bas Baan Development B.V. 1997 Tous droits réservés. Toute

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

Median SR04 - Automne 2007 Les documents ne sont pas autorisés

Median SR04 - Automne 2007 Les documents ne sont pas autorisés Median SR04 - Automne 2007 Les documents ne sont pas autorisés - Utiliser le verso en cas de besoin Exercice 1 (1,5pts) : soit le réseau suivant dont l'adresse réseau est 130.252.0.0 : Segment 1.10.34.10.35.10.36

Plus en détail

Ebauche Rapport finale

Ebauche Rapport finale Ebauche Rapport finale Sommaire : 1 - Introduction au C.D.N. 2 - Définition de la problématique 3 - Etat de l'art : Présentatio de 3 Topologies streaming p2p 1) INTRODUCTION au C.D.N. La croissance rapide

Plus en détail

Compte-rendu du TP n o 4

Compte-rendu du TP n o 4 Qiao Wang Charles Duchêne 18 décembre 2013 Compte-rendu du TP n o 4 Document version 1.0 F2R UV301B Routage : peering BGP Sommaire 1. PLAN D ADRESSAGE 2 2. CONFIGURATION DU BANC 2 3. IBGP 4 1 Salle 27,

Plus en détail

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium dans le cadre du projet JASMINe Avril 2008 Table des matières 1 Introduction 3 1.1 Rappel sur JASMINe.......................................

Plus en détail

Guide de l'utilisateur Doc App

Guide de l'utilisateur Doc App Page 1 Introduction Bienvenue chez ML6! Nous avons créé Doc App à la demande d'un ami qui désirait faciliter la documentation des ses activités RS et DE. Elle s'est avérée très utile et a suscité d'excellents

Plus en détail

Tutoriel d'utilisation de Wireshark

Tutoriel d'utilisation de Wireshark Tutoriel d'utilisation de Wireshark Ce tutoriel présente les principales fonctions de Wireshark nécessaires à une utilisation basique et se destine principalement à un public néophyte. Nous invitons le

Plus en détail

TP 1.1.7 Utilisation des commandes ping et tracert à partir d une station de travail

TP 1.1.7 Utilisation des commandes ping et tracert à partir d une station de travail TP 1.1.7 Utilisation des commandes ping et tracert à partir d une station de travail Objectif Apprendre à utiliser la commande TCP/IP ping (Packet Internet Groper) à partir d une station de travail Apprendre

Plus en détail

ETNA Projet de Fin d Étude 2005-2007 RimElse Cahier des charges. c Copyleft 2006, ELSE Team

ETNA Projet de Fin d Étude 2005-2007 RimElse Cahier des charges. c Copyleft 2006, ELSE Team ETNA Projet de Fin d Étude 2005-2007 RimElse Cahier des charges c Copyleft 2006, ELSE Team 18 avril 2006 Table des matières 1 Introduction 2 2 Présentation du projet 3 2.1 Une distribution Évolulable..................

Plus en détail

CH.2 CODES CORRECTEURS

CH.2 CODES CORRECTEURS CH.2 CODES CORRECTEURS 2.1 Le canal bruité 2.2 La distance de Hamming 2.3 Les codes linéaires 2.4 Les codes de Reed-Muller 2.5 Les codes circulaires 2.6 Le câblage des codes circulaires 2.7 Les performances

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

GESTION DE STOCKS AVEC CIEL GESTION COMMERCIALE

GESTION DE STOCKS AVEC CIEL GESTION COMMERCIALE GESTION DE STOCKS AVEC CIEL GESTION COMMERCIALE La gestion de stocks est complexe. Deux questions illustrent cette complexité : Première question : en supposant que le stock d un article comprenne 2 unités

Plus en détail

1 sur 5 10/06/14 13:10

1 sur 5 10/06/14 13:10 Time Machine est un outil proposé par Mac OS depuis sa version 10.5 (Leopard) et qui permet d'effectuer des sauvegardes de votre disque dur de manière régulière. Mais au-delà de la simple sauvegarde périodique,

Plus en détail

Partie windows Elements de correction: Question 1 : acces partage cd1 station1 station2 station1 station1 station2 Elements de correction:

Partie windows Elements de correction: Question 1 : acces partage cd1 station1 station2 station1 station1 station2 Elements de correction: Partie windows les éléments de correction ne sont pas un corrigé exhaustif. Ils se contentent de reprendre les points clefs de chaque exercice. Question 1 : acces partage Contexte: un domaine avec un contrôleur

Plus en détail

Utilisation du logiciel OpMat Ce logiciel effectue des opérations élémentaires sur les lignes d une matrice avec des entrées rationnelles

Utilisation du logiciel OpMat Ce logiciel effectue des opérations élémentaires sur les lignes d une matrice avec des entrées rationnelles Utilisation du logiciel OpMat Ce logiciel effectue des opérations élémentaires sur les lignes d une matrice avec des entrées rationnelles Michel Bouchard, enseignant retraité, Département de mathématiques,

Plus en détail

SOSI 4.1 Defi Wifi. Finalement, le problème était du au fait que le réseau n'était pas en activité lorsque nous essayions de le pirater.

SOSI 4.1 Defi Wifi. Finalement, le problème était du au fait que le réseau n'était pas en activité lorsque nous essayions de le pirater. SOSI 4.1 Defi Wifi Objectifs généraux Le defi WIFI de cette SOSI avait de nombreux objectids. Avant tout, le but de ce projet était de cracker une clef WEP. Pour cela, nous disposions d'un ordinateur portable

Plus en détail

Algorithmes de tri. 1 Introduction

Algorithmes de tri. 1 Introduction Algorithmes de tri L objectif de ce document est de présenter plusieurs algorithmes classiques de tri. On commence par présenter chaque méthode de manière intuitive, puis on détaille un exemple d exécution

Plus en détail