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

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

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

Chapitre 1 : Introduction aux bases de données

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

Plus en détail

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

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

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

Plus en détail

Cours Langage C/C++ Programmation modulaire

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

Plus en détail

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

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

Plus en détail

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

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

Plus en détail

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

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

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

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

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

Plus en détail

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

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

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

Plus en détail

EXAMEN BLANC CCNA CORRECTION

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

Plus en détail

Diagrammes de décisions binaires

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

Plus en détail

Introduction aux Systèmes Distribués. Introduction générale

Introduction aux Systèmes Distribués. Introduction générale Introduction aux Systèmes Distribués Licence Informatique 3 ème année Introduction générale Eric Cariou Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Plan

Plus en détail

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

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

Plus en détail

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

PROBLEMES D'ORDONNANCEMENT AVEC RESSOURCES

PROBLEMES D'ORDONNANCEMENT AVEC RESSOURCES Leçon 11 PROBLEMES D'ORDONNANCEMENT AVEC RESSOURCES Dans cette leçon, nous retrouvons le problème d ordonnancement déjà vu mais en ajoutant la prise en compte de contraintes portant sur les ressources.

Plus en détail

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

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

Plus en détail

1 Le code ASCII et le code Latin-1

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

Plus en détail

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

Faculté Polytechnique de Mons

Faculté Polytechnique de Mons Faculté Polytechnique de Mons Génération d'un site Web automatiquement à partir d'une base de données relationnelle : Utilisation de XML Projet de 3 e Informatique et Gestion Année académique 2007-2008

Plus en détail

Recherche dans un tableau

Recherche dans un tableau Chapitre 3 Recherche dans un tableau 3.1 Introduction 3.1.1 Tranche On appelle tranche de tableau, la donnée d'un tableau t et de deux indices a et b. On note cette tranche t.(a..b). Exemple 3.1 : 3 6

Plus en détail

Votre appareil est configuré en usine pour permettre d'envoyer immédiatement des SMS.

Votre appareil est configuré en usine pour permettre d'envoyer immédiatement des SMS. Généralités SMS (messages texte) Votre appareil est configuré en usine pour permettre d'envoyer immédiatement des SMS. Conditions : u La présentation du numéro associée à votre ligne téléphonique est active.

Plus en détail

SweetyPix, mode d'emploi

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

Plus en détail

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

Firewall : Pourquoi et comment?

Firewall : Pourquoi et comment? Firewall : Pourquoi et comment? En ai-je besoin? Internet, bien que très utile et pratique, est parsemé d'embuches. Parmi elles : les virus et les troyens. Un virus est un programme créé pour modifier

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

CONNECTEUR PRESTASHOP VTIGER CRM

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

Plus en détail

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

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

Plus en détail

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

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

Plus en détail

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

Vers un réseau déterministe

Vers un réseau déterministe Vers un réseau déterministe 1ere partie : Généraliste: Notions et définitions 2eme partie et 3eme partie : - MPLS et compagnie (RSVP, OSPF, BGP, TE, FR, VPLS...) - Topologie : Intégration du paramètre

Plus en détail

Manuel d'installation et d'utilisation Jetro 4.2

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

Plus en détail

DA MOTA Anthony - Comparaison de technologies : PhoneGap VS Cordova

DA MOTA Anthony - Comparaison de technologies : PhoneGap VS Cordova DA MOTA Anthony - Comparaison de technologies : PhoneGap VS Cordova I. Introduction Dans une période où la plasticité peut aider à réduire les coûts de développement de projets comme des applications mobile,

Plus en détail

S inscrire dans l application.

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

Plus en détail

1 TD 2 : Construction d'une chier Acrobat et envoi par email

1 TD 2 : Construction d'une chier Acrobat et envoi par email 1 TD 2 : Construction d'une chier Acrobat et envoi par email (correction page??) Un professeur de maths a instauré une coutume lors de la dernière séance de la semaine. Le vendredi est consacré à la correction

Plus en détail

Structures de données non linéaires

Structures de données non linéaires Structures de données non linéaires I. Graphes Définition Un graphe (simple) orienté G est un couple (S, A), où : S est un ensemble dont les éléments sont appelés les sommets. A est un ensemble de couples

Plus en détail

Les stratégies de restrictions Logicielles

Les stratégies de restrictions Logicielles Les stratégies de restrictions Logicielles Guillaume DESFARGES Laboratoire Supinfo des Technologies Microsoft The Moderator Présentation Dans un environnement d'entreprise, les utilisateurs sont rarement

Plus en détail

Arbres binaires Version prof Version prof

Arbres binaires Version prof Version prof Arbres binaires Version prof Version prof types /* déclaration du type t_element */ t_arbrebinaire = t_noeudbinaire t_noeudbinaire = enregistrement t_element cle t_arbrebinaire fg, fd n enregistrement

Plus en détail

Processus de décision répartis

Processus de décision répartis Processus de décision répartis Florent Matignon Renato Matuzaki Honda Miguel Robles 30 mars 2010 Table des matières I Introduction 2 Système réparti 2 II L'état global 2 1 Introduction 2 1.1 La problématique.........................................

Plus en détail

Mise en place d'un Réseau Privé Virtuel

Mise en place d'un Réseau Privé Virtuel Travaux Pratiques Trucs utiles : tail f /var/log/syslog pour tous les logs de la machine et notamment les cartes ethernet d'une machine. /etc/init.d/nom_du_démon (re)start pour le démarrer ou le redémarrer.

Plus en détail

BD Avancées TRAVAUX DIRIGÉS. UFR Sciences et Techniques. IUP Blois Master SIR 1 année

BD Avancées TRAVAUX DIRIGÉS. UFR Sciences et Techniques. IUP Blois Master SIR 1 année UFR Sciences et Techniques IUP Blois Master SIR 1 année BD Avancées TRAVAUX DIRIGÉS Enseignant Jean-Yves ANTOINE (Jean-Yves.Antoine AT univ-tours.fr) Sécurité des données CONTRÔLE DES ACCES CONCURRENTS

Plus en détail

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

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

Plus en détail

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

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

Plus en détail

1.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

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

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

Plus en détail

Titre: Version: Dernière modification: Auteur: Statut: Licence:

Titre: Version: Dernière modification: Auteur: Statut: Licence: Titre: Mise en œuvre de mod_webobjects Version: 2.0 Dernière modification: 2010/09/06 20:00 Auteur: Aurélien Minet Statut: version finale Licence: Creative Commons

Plus en détail

IN411-TP1 Conception d'une zone démilitarisée

IN411-TP1 Conception d'une zone démilitarisée IN411-TP1 Conception d'une zone démilitarisée RENOUX Charles ROUESSARD Julien TARRALLE Bruno ROHAUT Fanny SCHAPIRA Boris TEA Christophe le 16 Octobre 2005 Table des matières Introduction 2 1 Routage Classique

Plus en détail

Seance 2: En respectant la méthode de programmation par contrat, implémentez les autres fonctions de jeu.

Seance 2: En respectant la méthode de programmation par contrat, implémentez les autres fonctions de jeu. Seance 2: Complétion du code de jeu. (durée max: 2h) Mot clé const et pointeurs: En respectant la méthode de programmation par contrat, implémentez les autres fonctions de jeu. Implémentez jeu_recupere_piece

Plus en détail

Administration Réseau

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

Plus en détail

Publication d'application

Publication d'application Publication d'application Vue d'ensemble JetClouding supporte 3 types de publication d'application: Microsoft Remote Desktop: L'utilisateur verra le Bureau à distance Windows dans la session. Le contrôle

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

Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère

Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère L'héritage et le polymorphisme en Java Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère En java, toutes les classes sont dérivée de la

Plus en détail

Client Kiwi Backup : procédures d'installation et de mise à jour. Gilles Arnoult, Clément Varaldi

Client Kiwi Backup : procédures d'installation et de mise à jour. Gilles Arnoult, Clément Varaldi Client Kiwi Backup : procédures d'installation et de mise à jour Gilles Arnoult, Clément Varaldi 10 juin 2005 Première partie Installation du client Kiwi Backup 1 Chapitre 1 Sous Windows 1.1 Avant toutes

Plus en détail

TAGREROUT Seyf Allah TMRIM

TAGREROUT Seyf Allah TMRIM TAGREROUT Seyf Allah TMRIM Projet Isa server 2006 Installation et configuration d Isa d server 2006 : Installation d Isa Isa server 2006 Activation des Pings Ping NAT Redirection DNS Proxy (cache, visualisation

Plus en détail

Conventions d écriture et outils de mise au point

Conventions d écriture et outils de mise au point Logiciel de base Première année par alternance Responsable : Christophe Rippert Christophe.Rippert@Grenoble-INP.fr Introduction Conventions d écriture et outils de mise au point On va utiliser dans cette

Plus en détail

Cryptographie. Master de cryptographie Architectures PKI. 23 mars 2015. Université Rennes 1

Cryptographie. Master de cryptographie Architectures PKI. 23 mars 2015. Université Rennes 1 Cryptographie Master de cryptographie Architectures PKI 23 mars 2015 Université Rennes 1 Master Crypto (2014-2015) Cryptographie 23 mars 2015 1 / 17 Cadre Principe de Kercho : "La sécurité d'un système

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

réseaux virtuels (VLAN) définition intérêt

réseaux virtuels (VLAN) définition intérêt réseaux virtuels (LN) définition intérêt motivations relier plusieurs réseaux locaux Pourquoi plusieurs réseaux locaux? pour relier des réseaux locaux internes qui se sont développés indépendamment, é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

Module M3102 TP5. MPLS : LDP et L3-VPN

Module M3102 TP5. MPLS : LDP et L3-VPN Module M3102 TP5 MPLS : LDP et L3-VPN Ce qu'on veut faire dans ce TP : Permettre à l'isp d'établir un VPN de couche 3 entre les sites distants de chaque client (3 clients ici, donc 3 VPNs). Pourquoi :

Plus en détail

Sage CRM. 7.2 Guide de Portail Client

Sage CRM. 7.2 Guide de Portail Client Sage CRM 7.2 Guide de Portail Client Copyright 2013 Sage Technologies Limited, éditeur de ce produit. Tous droits réservés. Il est interdit de copier, photocopier, reproduire, traduire, copier sur microfilm,

Plus en détail

NetSupport Notify (v2.01) Guide de démarrage. Tous droits réservés. 2009 NetSupport Ltd

NetSupport Notify (v2.01) Guide de démarrage. Tous droits réservés. 2009 NetSupport Ltd NetSupport Notify (v2.01) Guide de démarrage Tous droits réservés 2009 NetSupport Ltd NETSUPPORT NOTIFY : PRÉSENTATION GÉNÉRALE NetSupport Notify est une solution mise au point spécifiquement pour permettre

Plus en détail

processus fonction main() l'image binaire contexte d'exécution un contexte mémoire. en même temps

processus fonction main() l'image binaire contexte d'exécution un contexte mémoire. en même temps 1 2 Dans une première approche, on peut dire qu'un processus représente une "application" qui tourne en mémoire. Il sera donc chargé en mémoire par le noyau et commencera son exécution; du point de vue

Plus en détail

Réseau : Interconnexion de réseaux, routage et application de règles de filtrage.

Réseau : Interconnexion de réseaux, routage et application de règles de filtrage. TD réseau - Réseau : interconnexion de réseau Réseau : Interconnexion de réseaux, routage et application de règles de filtrage. Un réseau de grande importance ne peut pas seulement reposer sur du matériel

Plus en détail

Programmation Objet - Cours II

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

Plus en détail

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

Manuel MSDS+ Système de programmes pour l'impression et la gestion des fiches de données de sécurité. DR-software GmbH

Manuel MSDS+ Système de programmes pour l'impression et la gestion des fiches de données de sécurité. DR-software GmbH Manuel MSDS+ Système de programmes pour l'impression et la gestion des fiches de données de sécurité DR-software GmbH Table des matières INSTALLATION ET ACTUALISATION 1 INSTALLATION DU PROGRAMME... 2 INSTALLATION

Plus en détail

ETI/Domo. Français. www.bpt.it. ETI-Domo Config 24810150 FR 10-07-144

ETI/Domo. Français. www.bpt.it. ETI-Domo Config 24810150 FR 10-07-144 ETI/Domo 24810150 www.bpt.it FR Français ETI-Domo Config 24810150 FR 10-07-144 Configuration du PC Avant de procéder à la configuration de tout le système, il est nécessaire de configurer le PC de manière

Plus en détail

Installation de Windows 2003 Serveur

Installation de Windows 2003 Serveur Installation de Windows 2003 Serveur Introduction Ce document n'explique pas les concepts, il se contente de décrire, avec copies d'écran, la méthode que j'utilise habituellement pour installer un Windows

Plus en détail

PFE Télécommunications. Pré-rapport à l'issue des 6 premières semaines de stage. Page 1 sur 5 1 %

PFE Télécommunications. Pré-rapport à l'issue des 6 premières semaines de stage. Page 1 sur 5 1 % PFE Télécommunications Pré-rapport à l'issue des 6 premières semaines de stage!"!"#$%&' ()*()!")+")# (#),()-,)*)"-./0 1 ()*()!")+-)# % 23 &0 )14) 56 7$8797%77:7' '72 Page 1 sur 5 Contexte Les centres de

Plus en détail

1 - Clients 2 - Devis 3 - Commandes 4 - Livraisons 5 - Factures 6 - Avoirs 7 - Modèles

1 - Clients 2 - Devis 3 - Commandes 4 - Livraisons 5 - Factures 6 - Avoirs 7 - Modèles 1 - Clients 2 - Devis 3 - Commandes 4 - Livraisons 5 - Factures 6 - Avoirs 7 - Modèles Page 1/16 1 - Clients Un client est un tiers qui vous passe des commandes, où pour lequel vous faîtes des devis, des

Plus en détail

Rappel. Analyse de Données Structurées - Cours 12. Un langage avec des déclaration locales. Exemple d'un programme

Rappel. Analyse de Données Structurées - Cours 12. Un langage avec des déclaration locales. Exemple d'un programme Rappel Ralf Treinen Université Paris Diderot UFR Informatique Laboratoire Preuves, Programmes et Systèmes treinen@pps.univ-paris-diderot.fr 6 mai 2015 Jusqu'à maintenant : un petit langage de programmation

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

Tutorial : Partitionner son disque dur avec Partition Magic

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

Plus en détail

1.5 0.5 -0.5 -1.5 0 20 40 60 80 100 120. (VM(t i ),Q(t i+j ),VM(t i+j ))

1.5 0.5 -0.5 -1.5 0 20 40 60 80 100 120. (VM(t i ),Q(t i+j ),VM(t i+j )) La logique oue dans les PME/PMI Application au dosage de l'eau dans les bétons P.Y. Glorennec INSA de Rennes/IRISA glorenne@irisa.fr C. Hérault Hydrostop christophe@hydrostop.fr V. Hulin Hydrostop vincent@hydrostop.fr

Plus en détail

LE PROBLEME DU PLUS COURT CHEMIN

LE PROBLEME DU PLUS COURT CHEMIN LE PROBLEME DU PLUS COURT CHEMIN Dans cette leçon nous définissons le modèle de plus court chemin, présentons des exemples d'application et proposons un algorithme de résolution dans le cas où les longueurs

Plus en détail

Installation du client Cisco VPN 5 (Windows)

Installation du client Cisco VPN 5 (Windows) Documentation pour tout utilisateur mise à jour le 20.06.2007, a été réalisée par Kurt Tornare Installation du client Cisco VPN 5 (Windows) Attention : la réexportation de ce logiciel cryptographique est

Plus en détail

Systèmes Binaires. V. Langlet

Systèmes Binaires. V. Langlet Systèmes Binaires V. Langlet Niveau : De la Terminale aux Maths du supérieur Diculté : De plus en plus dur au l des exercices. Durée : Environ deux heures, suivant la compréhension du sujet. Rubrique(s)

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

Charte informatique. Ce document n est qu un exemple. Il doit être adapté à chaque entreprise selon ses moyens et ses nécessités.

Charte informatique. Ce document n est qu un exemple. Il doit être adapté à chaque entreprise selon ses moyens et ses nécessités. Charte informatique Ce document n est qu un exemple. Il doit être adapté à chaque entreprise selon ses moyens et ses nécessités. Préambule L'entreprise < NOM > met en œuvre un système d'information et

Plus en détail

CISCO CCNA Semestre 2. Support de cours. Protocole de routage EIGRP

CISCO CCNA Semestre 2. Support de cours. Protocole de routage EIGRP LICENCE PRO ASUR (Administration et SécUrité des Réseaux) SESSION 2012-2013 CISCO CCNA Semestre 2 Support de cours Protocole de routage EIGRP EIGRP est l'acronyme de Enhanced Interior Gateway Routing Protocol.

Plus en détail

Situation présente et devis technique

Situation présente et devis technique Situation présente et devis technique Système de gestion des membres actuel Le système de gestion des membres actuel sert principalement à stocker des informations sur les architectes et les stagiaires.

Plus en détail

Les entrées/sorties Java (sérialisation, accès aux chiers et connexion réseau)

Les entrées/sorties Java (sérialisation, accès aux chiers et connexion réseau) Année 2008-2009 Les entrées/sorties Java (sérialisation, accès aux chiers et connexion réseau) Nicolas Baudru mél : nicolas.baudru@esil.univmed.fr page web : nicolas.baudru.perso.esil.univmed.fr 1 Introduction

Plus en détail

Installation d'un serveur DHCP sous Windows 2000 Serveur

Installation d'un serveur DHCP sous Windows 2000 Serveur Installation d'un serveur DHCP sous Windows 2000 Serveur Un serveur DHCP permet d'assigner des adresses IP à des ordinateurs clients du réseau. Grâce à un protocole DHCP (Dynamic Host Configuration Protocol),

Plus en détail

Les messages d erreur d'applidis Client

Les messages d erreur d'applidis Client Fiche technique AppliDis Les messages d erreur d'applidis Client Fiche IS00313 Version document : 1.00 Diffusion limitée : Systancia, membres du programme Partenaires AppliDis et clients ou prospects de

Plus en détail

Création d'un questionnaire (sondage)

Création d'un questionnaire (sondage) Création d'un questionnaire (sondage) Le but de ce petit tuto est d'avoir les séquences pas à pas pour la création d'un questionnaire de façon à ne pas devoir rechercher la manière de procéder si l'outil

Plus en détail

TP 1 : prise en main de C#. Net sous Visual Studio 2010

TP 1 : prise en main de C#. Net sous Visual Studio 2010 Année universitaire : 2014-2015 Responsable : Sonia LAJMI Niveau Matière 2 ème année MPIM Management des Contenus Multimédia TP 1 : prise en main de C#. Net sous Visual Studio 2010 Dans ce tout premier

Plus en détail

TP : installation de services

TP : installation de services TP : installation de services Ce TP a été rédigé rapidement. Il ne donne certainement pas toutes les explications nécessaires à la compréhension des manipulations. Assurez vous de bien comprendre ce que

Plus en détail

PARAGON SYSTEM BACKUP 2010

PARAGON SYSTEM BACKUP 2010 PARAGON SYSTEM BACKUP 2010 Paragon System Backup 2010 2 Manuel d'utilisation SOMMAIRE 1 Introduction...3 1.1 Comment System Backup protège mon ordinateur?...3 1.1.1 Emplacement du stockage des clichés...

Plus en détail

Présentation d'un Réseau Eole +

Présentation d'un Réseau Eole + Présentation d'un Réseau Eole + Le Pourquoi du comment... Comprendre les différents types de documentation fournit avec la solution Eole Plus. Novice Confirmé Expert Version 1.0 Mai 2006 Permission est

Plus en détail

Installation de Windows 2000 Serveur

Installation de Windows 2000 Serveur Installation de Windows 2000 Serveur Introduction Ce document n'explique pas les concepts, il se contente de décrire, avec copies d'écran, la méthode que j'utilise habituellement pour installer un Windows

Plus en détail

Petit guide des sous-réseaux IP

Petit guide des sous-réseaux IP Petit guide des sous-réseaux IP Robert Hart, hartr@interweft.com.au version française par Laurent Caillat-Vallet, caillat@univ-lyon1.fr v1.0, 31 Mars 1997 Ce document décrit pourquoi et comment découper

Plus en détail

Année Universitaire 2009/2010 Session 2 de Printemps

Année Universitaire 2009/2010 Session 2 de Printemps Année Universitaire 2009/2010 Session 2 de Printemps DISVE Licence PARCOURS : CSB4 & CSB6 UE : INF 159, Bases de données Épreuve : INF 159 EX Date : Mardi 22 juin 2010 Heure : 8 heures 30 Durée : 1 heure

Plus en détail

Installation du client Cisco VPN 5 (Windows)

Installation du client Cisco VPN 5 (Windows) Documentation pour tout utilisateur mise à jour le 17.03.2008, a été réalisée par Kurt Tornare Installation du client Cisco VPN 5 (Windows) Attention : la réexportation de ce logiciel cryptographique est

Plus en détail

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

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

Plus en détail