Evaluation de l`implémentation du protocole OSPF

Transcription

Evaluation de l’implémentation du
protocole OSPF de Quagga
–
Marion BAURES
Nicolas WULLENS
IENAC 07 S/TR
Ecole Nationale de l’Aviation Civile
–
Maı̂tre de projet : Fabien Garcia
Département Communication Navigation Surveillance
Subdivision Recherche
ENAC
2009/2010
Contents
1 Introduction
4
2 Gestion de projet
5
1
Plan de projet au lancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2
Après les premiers essais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3
A la fin du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3 Quagga
1
9
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Les protocoles de routage dynamique
9
10
1
RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2
OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3
Différences majeures RIP-OSPF . . . . . . . . . . . . . . . . . . . . . . . . . .
17
5 Exemples de structures d’autonomous systems
18
1
AS 2200 : RENATER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2
AS20965 : GEANT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3
AS 1239: SPRINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
6 Evaluation d’OSPFv3
25
1
Plan d’adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2
Analyse des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3
Changement de topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2
7 Evaluation d’OSPFv2
37
1
Plan d’adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
2
Mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
8 Conclusion
42
9 Annexes
43
1
Utilisation d’un pont réseau avec Marionnet . . . . . . . . . . . . . . . . . . . .
43
2
Configuration des routers Quagga . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3
Plan d’adressage de Geant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4
Trace des paquets capturés lors du démarage d’un réseau . . . . . . . . . . . .
50
5
Table de routage d’Italie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6
Tables de routage d’Allemagne . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Introduction
Bien qu’il soit de nos jours beaucoup utilisé, le protocole OSPF reste difficile à mettre en
place. Il est cependant supporté par des logiciels de routage tels que Quagga (pour les routeurs
linux), dans ses deux versions: OSPFv2 (ipv4) et OSPFv3 (ipv6). Au cours de ce projet nous
allons étudier les fonctionnalités OSPF(v2 et 3) offertes actuellement par Quagga.
Dans un premier temps, nous effectuerons une recherche documentaire afin de comprendre le
fonctionnement d’OSPF et de décrire l’architecture de Quagga. Afin d’effectuer des tests, il
nous faudra créer un réseau en se rapprochant le plus possible d’une topologie pouvant exister.
Enfin, l’outil qui nous servira à tester Quagga est le logiciel de simulation de réseaux Marionnet
dont nous exploiterons les nombreuses possibilités.
4
Gestion de projet
Dans cette partie, nous allons voir l’évolution des plans prévisionnels du projet tout au
long de celui-ci.
1
Plan de projet au lancement
Figure 2.1: Tableau récapitulatif du projet au démarage
2
Après les premiers essais
La découverte de Quagga ayant pris plus de temps que prévu, nous avons redéfini les temps
pour la suite du projet.
3
A la fin du projet
5
Figure 2.2: Diagramme de Gantt au lancement du projet
Figure 2.3: Tableau récapitulatif après les premiers essais
Figure 2.4: Diagramme de Gantt après les premiers essais
Figure 2.5: Tableau récapitulatif à la fin du projet
Figure 2.6: Diagramme de Gantt à la fin du projet
Quagga
Quagga est une suite de logiciels de routage pour TCP/IP permettant d’utiliser les principaux algorithmes de routage dynamique actuels. Elle fournit notamment une implémentation
de RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3 et BGP-4. Quagga supporte aussi les fonctionalités IPv6. Réalisée par Kunihiro Ishiguro, cette suite a été conçue pour fonctionner sur les
plates-formes UNIX (FreeBSD, GNU/Linux, Solaris and NetBSD)[2].
1
Architecture
Quagga est constituée d’un ensemble de démons fonctionnant ensemble pour fournir le
service demandé (créer la table de routage).
Il existe un démon central nommé zebra qui est le gestionnaire du noyau de la suite. Ensuite
chaque protocole possède son propre démon qui permet son fonctionnement :
• ospfd pour l’implémentation d’OSPFv2
• ripd pour l’implémentation de RIP v1 et v2
• ospf6d pour l’implémentation d’OSPFv3 (pour IPv6)
• ripngd pour l’implémentation RIPng (pour IPv6)
• bgpd pour l’implémentation de BGPv4 (inclut la gestion des familles d’adresses pour le
multicast et IPv6)
[11]
Dans ce projet, nous allons nous concentrer sur le protocole OSPF dans sa version IPv6 :
OSPFv3 (implémente la RFC2740).
9
Les protocoles de routage dynamique
Les protocoles de routage dynamique permettent d’adapter le routage à la topologie du
réseau. Il existe plusieurs protocoles dynamiques. Nous étudierons ici les différences entre les
protocoles RIP et OSPF.
Le réseau internet est organisé en une collection de systèmes autonomes (AS, Autonomous
System). Chaque système autonome possède un administrateur et sa propre technologie de
routage. Tous les routeurs d’un AS sont connectés les uns avec les autres. Un protocole différent
est utilisé pour faire l’interface entre les systèmes autonomes. Un protocole de routage interne
à un AS est appelé IGP (Interior Gateway Protocole), tandis que le protocole de routage utilisé
entre deux routeurs d’AS différents est un EGP (Exterior Gateway Protocole).
1
RIP
1.1
Le fonctionnement de RIP
RIP (Routing Information Protocol) fait parti des protocoles de routage interne basés sur
les algorithmes ”‘Distance-Vecteur”’. Ces algorithmes utilisent l’algorithme de Bellman-Ford.
Il permet à chaque routeur de communiquer aux autres routeurs la métrique, c’est-à-dire la
distance qui les sépare du réseau IP (le nombre de sauts qui les sépare). Ainsi, lorsqu’un
routeur reçoit un de ces messages, il incrémente cette distance de 1 et communique le message
aux routeurs directement accessibles[3].
Une route est composée de:
• l’adresse du réseau destinataire
• L’adresse du routeur pour atteindre le réseau de destination (next hop)
• la métrique qui représente le nombre de routeurs à traverser pour atteindre le réseau de
destination
En réception, le routeur compare les routes reçues avec les siennes et met sa propre table
à jour si:
• une route reçue est meilleure
• une route reçue est nouvelle
10
Il informe ses voisins immédiats des éventuelles nouvelles routes découvertes.
Le nom de Distance-Vecteur vient du fait qu’il est possible de calculer des routes optimales
avec seulement l’échange de la liste des distances. Ces informations sont échangées entre les
entités d’un même réseau.
Résumons le rôle d’un routeur ou d’un hôte R: pour chaque destination du réseau, R garde
une métrique estimée égale au coût total permettant de l’atteindre ainsi que le nom de ses
voisins sur lesquels la métrique est basée.
La route conservée permettant de faire suivre un message est optimale: le routeur conserve
l’adresse du routeur suivant dans sa table de routage, choisi de manière à ce que le nombre de
sauts permettant d’atteindre la destination soit minimal.
Les routes sont mises à jour toutes le 30 secondes: les routeurs envoient leurs tables de
routage et, si des changements ont eu lieu, améliorent les routes et les métriques en fonction
de ce qu’ils ont reçu. (cf RFC2453 3.8)
1.2
Les limites
Pour éviter les boucles de routage, le nombre de sauts est limité à 15. Au-delà, les paquets
sont supprimés.
RIP ne prend en compte que la distance entre deux machines en terme de saut, mais il ne
considère pas l’état de la liaison afin de choisir la meilleure bande passante possible. Si l’on
considère un réseau composé de trois routeurs A, B et C, reliés en triangle, alors RIP préférera
passer par la liaison directe A-B même si la bande passante n’est que de 56 kbps alors qu’elle
est de 20 Mbps entre A et C et C et B.
La convergence est lente pour des grands réseaux, l’information échangée étant proportionnelle
au nombre de routeurs.
2
OSPF
Le protocole suivant est plus complexe (notamment du point de vu de la métrique), mais il
permet de gérer des domaines plus importants et possède un temps de convergence plus faible.
Il repose sur l’état des liens[4].
2.1
Résumé
Dans OSPF, chaque routeur établit des relations d’adjacence avec ses voisins immédiats
en envoyant des messages hello à intervalle régulier. Chaque routeur communique ensuite
la liste des réseaux auxquels il est directement connecté par des messages LSA (Link-State
Advertisements) propagés de proche en proche à tous les routeurs du réseau. L’ensemble des
LSA forme la base de données des liens Link-State Database (LSDB), qui est identique pour
tous les routeurs participants, et peut être représentée par un graphe valué. Chaque routeur
utilise ensuite l’algorithme de Dijkstra, Shortest Path First, pour déterminer la route la plus
courte vers chacun des réseaux de la base commune. Chaque réseau établit donc sa table de
routage à partir de la LSDB.
2.2
Le protocole Hello
Il a pour rôle d’établir et de maintenir les relations de voisinage. Des paquets hello sont
envoyés périodiquement par un routeur à travers toutes ses interfaces en service. Chaque
paquet hello envoyé par un routeur contient entre autre la liste des voisins dont ce routeur
a déjà reçu un paquet hello. Si un routeur A qui envoie des paquets à un routeur B reçoit
également des paquets hello de B contenant son identifiant dans la liste des voisins, c’est qu’une
relation est établie dans les deux sens entre A et B. Après qu’un voisin ait été découvert et
que la communication dans les deux sens ait été annoncée possible, il faut décider si une
relation d’adjacence entre les deux est possible. L’autorisation de ces relations dépend en fait
du statut du routeur s’il fait parti d’un réseau à accès multiples: dans ce cas particulier, un
routeur désigné et un routeur de secours sont choisis[5].
Un routeur qui cherche à entrer en communication avec un voisin peut se trouver dans l’un
des états suivants:
1. Down: état initial, aucune information n’a été récemment transmise.
2. Init: un paquet hello a récemment été reçu, cependant la communication ne se fait pas
encore dans l’autre sens.
3. 2-Way: la communication est bidirectionnelle.
4. ExStart: première étape de la création d’une adjacence. Choix d’un maı̂tre entre les
deux routeurs.
5. Exchange: le routeur décrit sa base d’état des liens à l’autre.
6. Loading: le routeur envoie des paquets LSR (Link State Request) demandant les annonces les plus récemment découvertes dans l’état Exchange (si elles n’ont pas encore
été reçues).
7. Full: les deux routeurs sont totalement adjacents. Cette adjacence apparaı̂t alors dans
la base des liens.
Le message Hello que nous venons de décrire permet d’établir des adjacences entre les
entités communicantes (routeurs,...). Une fois ces relations établies, les routeurs vont pouvoir
s’échanger des informations en s’envoyant des paquets tels que:
1. Description de la base de données (Database Description Packet): paquets envoyés
lorsqu’une adjacence entre deux entités a été initialisée. Ils décrivent le contenu de la
topologie. L’expéditeur est le maı̂tre, les destinataires les esclaves, ces derniers doivent
acquitter la réception des paquets. (Pour l’envoi et la réception: cf RFC 2328[5] § 10.8
et 10.6)
2. Demande d’état des liens (Link State Request Packet): un routeur qui estime qu’une
partie de sa base de données est périmée peut envoyer un tel message. Le format de ce
paquet lui permet de demander à ses voisins de lui envoyer la partie de base de données
qu’il souhaite mettre à jour. (Envoi et réception: cf RFC 2328[5] § 10.9 et 10.7)
3. Mise à jour de l’état des liens (Link State Update Packet): ces paquets contiennent un
ou plusieurs LSA et fournissent le mécanisme qui permet de transmettre ces LSA de leur
origine au saut suivant (leur destination) de manière fiable.
4. Accusé de réception (Link State Acknowledgment Packet): ils acquittent la réception
d’un LSA pour assurer la fiabilité du protocole. Plusieurs LSA peuvent être acquittés
par un seul accusé de réception. (Envoi/Réception: RCF 2328[5] § 13.5 et 13.7)
En cas de changement de topologie, de nouveaux LSA sont propagés de proche en proche,
et l’algorithme SPF est exécuté à nouveau sur chaque routeur. L’avantage d’OSPF par rapport
à RIP réside dans le fait que seule la partie de la base de données modifiée est diffusée, et non
l’intégralité de la base. Ces envois ne sont effectués que lors d’un changement ou au bout d’un
intervalle relativement long: s’il n’y a pas de changement au bout de 30 minutes, un nouveau
LSA est envoyé. Rappelons que RIP envoie des mises à jour toutes les 30 secondes.
2.3
Qu’est-ce qu’un LSA?
C’est un message envoyé par un routeur. (Un routeur peut en envoyer plusieurs.) L’ensemble
des LSA décrit la topologie de l’état des liens. La dernière version d’OSPF (OSPF pour IPv6)
précise la portée du flux dans le paquet LSA. Il peut y avoir trois types de portées:
• portée de lien local: le LSA est diffusé seulement sur le lien local (link-LSA)
• portés d’aire: le LSA est diffusé à travers une unique aire (routers-LSA, network-LSA,
inter-area-prefix-LSA, inter-area-router-LSA and intra-area-prefix-LSA)
• portée d’AS: le LSA est diffusé à travers tout un AS (AS-external-LSA)
Décrivons un peu plus précisément ces types de LSA:
• LSA routeur (router-LSA) diffusés par un routeur uniquement dans l’aire à laquelle
appartient le routeur.
• LSA réseau (Network-LSA) diffusé par un routeur désigné appartenant à un réseau pour
tous les routeur appartenant à ce réseau. Chaque lien qui supporte du broadcast et
chaque lien NBMA (définition: cf RFC 2328[5] 1.2) possédant au moins deux routeurs
adjacents diffusent ce genre de LSA.
• LSA préfixes inter-aire (Inter-Area-Prefix-LSA) équivalents au LSA résumé de la version
ipv4. Générés par les routeurs de bordure d’aire, ils décrivent les routes à destination
d’éléments possédant des préfixes d’adresses ipv6 appartenant à des aires différentes. Ils
contiennent également un résumé des informations de routage (l’information est condensée).
• LSA routeur inter-aire (Inter-Area-Router-LSA) équivalents au LSA résumé de la version
ipv4, mais à la différence des précédents, ils décrivent des routes vers des routeurs limites
d’AS des autres aires. L’utilité de ces routes est décrite dans la RFC 2328[5], 16.4.
• LSA d’AS externe (AS-External-LSA) générés par les routeurs de limite d’AS, ils décrivent
les routes externes à l’AS.
• LSA d’aire NSSA(NSSA-LSA) décrit un chemin vers une destination externe à l’AS.
C’est un LSA dont la portée est restreinte à une seule aire NSSA.
• LSA lien (Link-LSA) diffusé sur un lien local supportant un ou plusieurs routeurs. Un
routeur peut appartenir à plusieurs liens locaux; dans ce cas il diffusera des Link-LSA
différents sur chacun de ces liens.
• LSA préfixe intra-aire (Intra-Area-Prefix-LSA) diffusés à travers une aire.
Pour plus de détails concernant ces différentes portées de LSA, cf RFC 2740[6] et 5340[7], §
4.4.3.
Les LSA constituent une base de donnée commune à tout le réseau. Chaque routeur établit
ensuite sa propre table de routage en appliquant l’algorithme de Dijkstra à la base de donnée.
OSPF utilise une métrique numérique simple, basée sur un coût additif. La valeur par
défaut du coût d’un lien est de 108/bande passante du lien en bit/s. Un lien de 10 Mbit/s
aura par exemple un coût de 10. Pour tenir compte des connexions à très haute vitesse (1
Gbit/s et plus), on peut fixer manuellement le coût de chaque lien, ou bien fixer une bande
passante de référence supérieure à celle par défaut.
2.4
L’algorithme de Dijkstra
L’approche consiste à constituer une route la plus courte possible petit à petit en comparant
les différents possibilités. Lorsqu’un noeud est sélectionné, il offre de nouveaux noeuds (ses
voisins qui n’ont pas encore été sélectionnés) pour avancer. Un noeud sélectionné est entouré
et on ne l’explore qu’une fois. On calcule ensuite les nouvelles routes possibles. Puis on
selectionne un nouveau noeud, non encore exploré, dont le chemin depuis l’origine est le plus
court.
2.4.1
exemple
On cherche à calculer le plus court chemin entre le routeur A et le routeur G.
1. Les trois prochains sauts possibles en sortie de A sont: B, C et F.
2. On sélectionne celui dont la route est la moins coûteuse: B. (poids: 7).
Les nouveaux routeurs accessibles sont alors C via B, D et E de coûts respectifs depuis
A: 17 (moins bon que 11, donc non gardé), 23 et 21.
La route la moins coûteuse est alors la directe A-C de poids 11.
3. On sélectionne donc C, les nouveaux routeurs accessibles sont alors E via C (de poids
20, meilleur que celui de la route passant par B, donc gardé)et F via C (non gardé car
le poids est moins bon que celui déjà connu de A-F direct).
La route la moins coûteuse est alors la directe A-F de poids 13.
4. On sélectionne donc F, les nouveaux routeurs accessibles sont alors E (de poids 21>20
via C, donc non gardé) et G de poids 31.
La route la moins coûteuse est alors la A-E via C de poids 20.
5. On sélectionne donc E, le nouveau routeur accessible est alors D (de poids 25>23 via B,
donc non gardé).
La route la moins coûteuse est alors la A-D via B de poids 23.
6. On sélectionne donc D, le nouveau routeur accessible est alors G (de poids 28<31 via F,
donc gardé).
2.5
Structure d’une table de routage
Une table de routage contient toutes les informations nécessaires pour faire suivre un paquet
IP jusqu’à sa destination. Elle contient plusieurs entrées que nous allons maintenant décrire:
• Type de destinataire: le destinataire peut être un réseau, un routeur de bordure de
domaine (area border router) ou un routeur inter-AS (AS boundary router).
• ID du destinataire: pour un réseau il s’agit de son adresse IP, les autres types de destinataire sont identifiés par leur identifiant OSPF.
• Masque d’adresse: pour les réseaux seulement.
• Capacités optionnelles: supportées par le routeur destinataire (si le destinataire est un
routeur).
• Type de chemin: intra-aire, inter-aire, type externe 1 et type externe 2. Ces deux derniers
désignent des chemins externes à l’AS.
• Coût: coût du chemin jusqu’à la destination. Pour les chemins de type externe 2 il s’agit
du coût de la portion interne à l’AS.
• Coût de type 2: pour les chemins de type externe 2. Il s’agit du coût de la portion de
chemin externe à l’AS.
• Origine de l’état des liens: LSA routeur ou LSA réseau qui est à l’origine de la ligne
produite dans la table. Si par exemple il s’agit d’une route vers une adresse ipv6, ce
champ contiendra l’émetteur de la route.
• Prochain saut: l’interface du routeur suivant à utiliser pour faire suivre un paquet. (Un
des routeurs adjacents).
• Routeur d’annonce: pour les chemins inter-aires ou externes aux AS. ID du routeur de
sortie de l’AS qui conduit à ce chemin externe.
OSPF est capable de répartir la charge sur plusieurs liens, pour autant que la métrique soit
exactement identique pour chaque destination. Il est économe en bande passante : en régime
nominal, seuls de courts messages hello sont envoyés, et en cas de changement de topologie,
seuls les LSA modifiés sont envoyés aux voisins.
2.6
Notion de type de service
Une première version d’OSPF, (OSPF pour IPv4), prenait en compte le type de service et
établissait des chemins différents en fonction du type de service. On trouve donc dans la RFC
2328[5] les différents types de service codés par un entier entre 0 et 30. Quelques exemples:
• 0: service normal
• 2: coût minimisé
• 4: fiabilité maximale
• 8: débit maximum
• 16: délai minimal
Ce code est inclut dans l’en-tête IP des LSA. Cette solution a été remplacée dans la version
avec IPv6 par le champ ”traffic class” d’IP.
3
Différences majeures RIP-OSPF
1. Dans OSPF, la table informant sur l’état des liens est unique et partagée par tous les
routeurs d’une aire. Les routeurs ont donc une visibilité globale de l’ensemble du réseau
tandis que ceux de RIP ont une visibilité partielle (autour d’eux).
2. Dans OSPF, l’algorithme de Dijkstra est appliqué à cette unique table par chaque routeur
pour déterminer la route optimale lui permettant de joindre un sous réseau. Pour RIP,
chaque routeur met à jour sa propre table dès qu’un changement lui est signalé par
un voisin. La diffusion des changements est donc étendue à tout le domaine OSPF et
seulement aux voisins immédiats des routeurs RIP.
3. Les mises à jour interviennent lors d’un changement dans la topologie du réseau utilisant
OSPF, et seule la partie modifiée de la base est diffusée. Pour le réseau utilisant RIP,
des mises à jour régulières sont effectuées (toutes les 30s) et elles consistent pour chaque
routeur à envoyer leur table de routage en entier.
4. Les métriques sont différentes. OSPF tient compte de la vitesse (le coût, métrique
utilisée, est basé sur la bande passante) tandis que RIP ne prend en compte que le
nombre de passerelles traversées. De ce fait, OSPF est plus performant puisqu’il prend
en compte l’état réel du réseau (il fera passer par un chemin éventuellement plus long en
terme de sauts mais plus rapide en terme de temps).
5. Contrairement à RIP, les tables de routage ne sont pas diffusées régulièrement dans le
protocole OSPF. OSPF utilise donc moins de bande passante pour la gestion du réseau.
6. Le temps de convergence d’OSPF est particulièrement rapide, de l’ordre de quelques
secondes, tandis que RIP peut converger plus lentement.
7. RIP se limite aux réseaux de taille inférieure à 15 routeurs (problème de passage à
l’échelle). Au delà, il considère que les réseaux et routeurs sont inaccessibles. OSPF n’a
pas de limite de taille.
8. RIP sélectionne un chemin vers un réseau en ajoutant l’un des nombres de sauts indiqués
par un voisin. Il compare les nombres de sauts pour atteindre une destination et sélectionne le chemin de plus petit nombre de sauts; il repose donc sur un algorithme simple,
il ne requiert pas beaucoup de mémoire. L’algorithme d’OSPF est plus complexe: tous
les routeurs OSPF doivent obtenir des informations complètes sur les réseaux de chaque
routeur pour calculer le plus court chemin. Par conséquent, il requiert des routeurs plus
puissants et davantage de mémoire et de puissance de calcul.
9. RIP utilise une topologie linéaire: les routeurs d’une région RIP échangent des informations avec tous les routeurs. OSPF fait appel à la notion de zone: de cette façon il limite
le trafic à l’intérieur de ces zones sans affecter les performances de tout un réseau.
Exemples de structures d’autonomous
systems
Pour pouvoir évaluer la suite Quagga, nous allons utiliser un outil de simulation des réseaux.
Cet outil, Marionnet, repose sur la technologie VNUML et permet de construire une topologie
réseau puis de la simuler en utilisant des machines virtuelles. Afin de construire la topologie qui
sera ensuite simulée avec Marionnet, nous avons décidé de rechercher des systèmes autonomes
existants pour nous rapprocher au maximum de la réalité.
1
AS 2200 : RENATER
L’AS sur lequel on peut le plus facilement obtenir des informations est RENATER, le
REseau NATional de l’Enseignement et de la Recherche. Cet AS public, que nous utilisons
très régulièrement, possède un statut particulier. Il est utilisé de deux façons différentes :
• interconnecter les différents établissements de l’enseignement et de la recherche français
• effectuer des recherches sur les réseaux (métrologie, déploiement d’IPv6...)
Ce statut a pour conséquence que beaucoup d’informations sur RENATER sont publiées et
notamment sa topologie (figure 5.1).
Ce réseau possède une topologie assez variée avec :
• des boucles : Paris-Rouen-Caen-Rennes-Nantes-Bordeaux-Poitiers-Orléans
• des redondances : Paris-Lyon
• des antennes : Marseilles-Corte
Renater permet aussi de se placer à différentes échelles si on le regarde au niveau national
ou au niveau régional. Nous allons voir les exemples des réseaux Ile de France (section 1.1) et
Midi-Pyrénées (section 1.2).
1.1
AS1309 : RERIF
RERIF est l’AS de Renater pour la région Ile de France.
Ce réseau est organisé autour d’une boucle centrale : Aubervilliers-Orsay-Cachan-Jussieu.
Les principales interconnexions avec d’autres réseaux sont directement faites sur cette boucle
centrale. Quantité d’autres liens moins capacitifs permettent d’offrir le service de Renater à
tous les établissements d’Ile de France et assurent une redondance.
18
Figure 5.1: Réseau fibre optique (10Gb/s) de Renater[14]
Figure 5.2: Réseau Renater Ile de France[13]
1.2
AS1715 : REMIP2000
REMIP est l’AS de Renater pour la région Midi-Pyrénées.
Figure 5.3: Réseau REMIP2000[12]
REMIP est essentiellement constitué d’une boucle de laquelle partent des liens permettant
d’étendre le réseau vers les différents utilisateurs.
1.3
Situation de Renater au sein d’autres AS
Après avoir observé différents AS de RENATER, nous avons regardé les réseaux qui s’y
rattachent.
D’après la figure 5.4, nous avons choisi de nous concentrer d’une part sur GEANT, l’AS qui
interconnecte les differents réseaux de recherche européens et sur le réseau d’interconnexion
Sprint[8] pour avoir un réseau privé.
2
AS20965 : GEANT
GEANT est le réseau européen en charge d’interconnecter les différents réseau de recherche
nationaux (dont RENATER pour la France).
2.1
AS 766: REDIRIS
REDIRIS est le réseau de la recherche en Espagne.
Réseau espagnol REDIRIS[9]
Figure 5.4: Situation de RENATER[15]
Figure 5.5: Le réseau européen GEANT[10]
3
AS 1239: SPRINT
Le réseau Sprint[8] est un réseau commercial permettant l’interconnexion d’autres réseaux
à l’echelle mondiale.
Figure 5.6: Réseau Sprint en Europe
4
Conclusion
On ne retrouve que peu de choses d’un AS à l’autre. Elle est le plus souvent dictée par des
considérations géographiques : où a-t-on la plus grande quantité d’utilisateurs? Cependant,
on peut souvent repérer un noeud ou un ensemble de noeuds centraux sur lequel vient se
connecter l’ensemble du réseau.
Figure 5.7: Réseau Sprint en Amérique du nord
Figure 5.8: Réseau Sprint en Amérique du sud
Figure 5.9: Réseau Sprint en Australie
Figure 5.10: Réseau Sprint en Asie
Figure 5.11: Réseau Sprint en Afrique
Evaluation d’OSPFv3
Dans cette partie, il est question d’évaluer les possibilités de l’implémentation du protocole
OSPFv3 de la suite Quagga. Dans la documentation de Quagga, cette implémentation est
annoncée non terminée. Les principales parties manquantes sont :
• la gestion de la qualité de service, comme pour OSPFv2
• la gestion des aires de routage
Le fait que la gestion des aires ne soit pas implémentée nous oblige à ne définir qu’une
seule aire, l’aire 0.0.0.0 (backbone). D’autre part, cela nous pousse à réduire la taille du réseau
sur lequel nous allons travailler. Nous avons choisi de réaliser l’évaluation d’OSPFv3 sur une
reproduction du réseau d’interconnexion européen GEANT. Le réseau que nous avons construit
comprend les douze routeurs principaux du réseau GEANT ainsi que ses liens 10Gbps. Voici
comment nous avons construit le plan d’adressage.
1
Plan d’adressage
Nous travaillons en ipv6, il nous faut donc configurer des adresses ipv6. Nous avons choisi
comme préfixe celui qui est utilisé par les réseaux de recherche: 1FFE (exemple: le 6-bone).
Ce préfixe sera suivi d’une suite de zéros. Cela donne un prefixe commun à tout le réseau en
1FFE::0:0/96. L’avant dernier mot fera référence au numéro du lien et le dernier ne pourra
être qu’1 ou 2 pour désigner une des deux extrémités du lien. Les mots de 16 bits seront
notés en hexadécimal (d’où le E et le F du préfixe) et le masque sera /112. Ce masque est
le masque du sous-réseau représenté par la liaison entre deux routeurs[1]. Exemple: pour le
routeur Espagne qui possède deux interfaces : 1FFE::1:1/112 -> pour le lien avec le routeur
France et 1FFE::B:1/112 -> pour le lien avec le routeur Italie.
1.1
Procédure de configuration des routeurs sous Marionnet
• entrée dans quagga: vtysh
• configuration des interfaces:
configure terminal
interface ethX
ipv6 address 1FFE::X:Y/112
exit
exit
25
• sauvegarde des fichiers de configuration: write
Ne pas oublier de sauver le projet avant de le quitter, sinon les fichiers de configurations ne
seront pas sauvegardés.
1.2
Plan d’adressage de GEANT en IPv6
Figure 6.1: Plan d’adressage de GEANT pour l’évaluation d’OSPFv3
2
Analyse des paquets
2.1
Les messages HELLO
Après avoir lancé la simulation sur Géant, nous avons capturé les échanges effectués par
le routeur Hongrie. Rappelons que ce dernier est relié au routeur Autriche par le lien 15.
Notons que les adresses utilisées par OSPFv3 sont les adresses de lien local (non routables) qui
sont configurées automatiquement. Pour voir le plan d’adresse correspondant, voir l’annexe
3. Les adresses de lien local sont, sur le lien 15, fe80::4:6ff:fe00:2f/64 pour Autriche et
fe80::4:6ff:fe00:34/64 pour Hongrie. Voici les premiers messages capturés:
09:23:58.413646 IP6 (hlim 64, next-header: OSPF (89), length: 36) fe80::4:6ff:fe00:2f >
ff02::5: OSPFv3-hello 36: rtrid 192.168.0.11 backbone V6/E/R ifid 0.0.0.3 pri 1 int 10 dead
40 dr 192.168.0.11 nbrs
Analysons cette trame en détail:
• 09:23:58.413646: date de capture
• IP6 (hlim 64, next-header: OSPF (89), length: 36)
• fe80::4:6ff:fe00:2f > ff02::5: adresse de l’émetteur (ici Autriche) > adresse du destinataire
(ici adresse multicast pour joindre le groupe OSPF: tous les voisins qui fonctionnent
reçoivent ce message).
• OSPFv3-hello: type du paquet
• 36: longueur du paquet (en octets)
• rtrid 192.168.0.11: ID du routeur émetteur (Autriche)
• backbone V6/E/R: aire sur laquelle circule le paquet (une seule aire: Géant. V6: ospfv6,
E et R sont des options supportées par les voisins appartenant à l’aire )
• ifid 0.0.0.3: ID de l’interface de l’émetteur (également renommée automatiquement)
• pri 1: priorité du routeur émetteur
• int 10 dead 40: intervalle entre l’émission de deux paquets HELLO: 10s, un lien est
déclaré corrompu s’il ne fonctionne pas au bout de 40s (pas de réponse à un paquet
HELLO).
• dr 192.168.0.11: routeur désigné pour le réseau
• nbrs: voisins adjacents (pour l’instant aucune adjacence n’a été établie)
La trame suivante donne:
09:23:59.558710 IP6 (hlim 64, next-header: OSPF (89), length: 36) fe80::4:6ff:fe00:34 >
40 nbrs
L’émetteur est ici le routeur Hongrie qui envoie un message HELLO à tout le groupe OSPF
(seuls ses voisins le recevront). Il n’a pas encore établi d’adjacence. Le protocole est fidèle à
celui décrit dans la RFC: la première étape de configuration du réseau consiste à découvrir ses
voisins et établir des adjacences.
40 dr 192.168.0.11 nbrs 192.168.0.12
Ce message est envoyé par Autriche au groupe OSPF, 10 secondes après sa première émission. D’ailleurs on remarque que des messages HELLO sont émis toutes les 10 secondes pendant
toute la durée de la simulation. Ce temps respecte le délai d’envoi décrit dans la RFC. A la
différence du premier paquet envoyé par ce routeur, une relation d’adjacence a été établie avec
le routeur Hongrie dont on voit apparaı̂tre l’identifiant dans le dernier champ. En effet, après
avoir envoyé un premier paquet HELLO, Autriche a reçu une ”‘réponse”’: un paquet HELLO
provenant de Hongrie, lui signalant que la liaison entre les deux pouvait être établie. Une
relation d’adjacence s’est alors créée. De plus, le routeur Hongrie s’est déclaré comme étant
le ”‘designated router”’ (dr), soit le routeur désigné (responsable) sur ce réseau. Hongrie sera
alors le ”‘backup designated router”’(bdr), le routeur de réserve.
40 dr 192.168.0.11 bdr 192.168.0.12 nbrs 192.168.0.11
Le paquet HELLO ci-dessus, émis par Hongrie, est détecté 10secondes après son premier
envoi. On observe par la suite que les paquets HELLO sont émis à intervalles de 10 secondes.
(cf annexe 4)
2.2
Database Description Packet
Après les trois premiers paquets HELLO, c’est-à-dire une fois la relation d’adjacence établie
entre Autriche et Hongrie, on observe le message suivant:
fe80::4:6ff:fe00:2f: OSPFv3-dd 28: rtrid 192.168.0.12 backbone V6/E/R I/M/MS mtu 1500 S
4B541AA8
Analysons cette trame en détail:
• 09:24:08.444681: date de capture
• IP6 (hlim 64, next-header: OSPF (89), length: 28)
• fe80::4:6ff:fe00:34 > fe80::4:6ff:fe00:2f:adresse de l’émetteur (Hongrie) > adresse du destinataire (Autriche).
• OSPFv3-dd: type de message (Database Description Packet)
• 28: longueur du paquet (en octets)
• rtrid 192.168.0.12: ID du routeur émetteur (Hongrie)
• backbone V6/E/R aire sur laquelle circule le paquet (une seule aire: Géant. V6: ospfv6,
E et R sont des options supportées par les voisins appartenant à l’aire )
• I: Init bit, indique que ce paquet est le premier de la séquence de description de base de
données à transmettre.
• M: More bit, indique que d’autres paquets permettant de décrire la base suivent.
• MS: Master/Slave bit, indique que le routeur émetteur est le maı̂tre durant le processus
d’échange de la base de données.
• mtu 1500: nombre d’octets dans une trame
• 4B541AA8: numéro de séquence, s’incrémente à chaque nouvel envoi jusqu’à ce que
toutes les données soient transmises.
Puis:
fe80::4:6ff:fe00:34: OSPFv3-dd 988: rtrid 192.168.0.11 backbone V6/E/R mtu 1500 S 4B541AA8
Ce message est envoyé par Autriche en réponse au précédent: notons que la taille du message est nettement plus importante (988 octets): Hongrie est seulement relié à Autriche tandis
qu’Autriche est relié au reste du réseau. Autriche possède donc une base de donnée sur les
états de liens plus importante. Le More bit est à 0: aucun paquet ne suit. MS est aussi à 0:
l’émetteur est l’esclave du transfert. Le numéro de séquence est identique au précédent. Là
encore, le format du paquet respecte la RFC.
Un peu plus tard, on observe une autre trame de type Database Description Packet:
09:24:08.477004 IP6 (hlim 64, next-header: OSPF (89), length: 68) fe80::4:6ff:fe00:34
> fe80::4:6ff:fe00:2f: OSPFv3-dd 68: rtrid 192.168.0.12 backbone V6/E/R MS mtu 1500 S
4B541AA9
Ce message est envoyé par Hongrie à Autriche, le numéro de séquence a été incrémenté: il
s’agit d’une nouvelle séquence d’envoi de données, Hongrie reste le maı̂tre.
L’envoi de tels paquets correspond à la deuxième étape, après établissement des adjacences,
selon la RFC. Cette étape est donc bien respectée par quagga.
2.3
Link State Request Packet
Après les deux premiers paquets Database Description, on relève le paquet suivant:
> fe80::4:6ff:fe00:2f: OSPFv3-ls req 580: rtrid 192.168.0.12 backbone linklocal-link 0.0.0.3
rtr 192.168.0.11 linklocal-link 0.0.0.4 rtr 192.168.0.12 [|ospf ]
Ce paquet est envoyé par Hongrie à destination d’Autriche. Nous ne nous attarderons pas
sur les premiers champs de ce paquet qui sont analogues à ceux des paquets décrits dans les
paragraphes précédents. La différence à analyser réside dans les derniers champs:
• linklocal-link 0.0.0.3 rtr 192.168.0.11 : partie de sa base de données que l’émetteur
souhaite mettre à jour. Il y en a deux ici.
• linklocal-link: type de LS requis
• 0.0.0.3: ID du LS
• rtr 192.168.0.11: routeur à l’origine du LSA requis et dont l’update est recherché
Rappelons que ce type de message est sensé être envoyé par un routeur qui souhaite obtenir
des informations sur une partie de sa base qu’il estime périmée. Ici Hongrie demande à Autriche
de lui retransmettre la partie concernant le lien entre Autriche et Hongrie: la fonction de ce
type de paquets décrite dans la RFC est respectée.
2.4
Link State Update Packet
En réponse à un Link State Request Paquet, un Link State Update Packet est envoyé.
09:24:08.486073 IP6 (hlim 64, next-header: Fragment (44), length: 1456) fe80::4:6ff:fe00:2f
> fe80::4:6ff:fe00:34: frag (0x00000002:0|1448) OSPFv3-ls upd 1448: [len 1484]
Il s’agit très probablement de la réponse au paquet étudié précédemment, puisque l’émetteur
de ce paquet est Autriche et le destinataire Hongrie et qu’il arrive juste après. Nous n’avons
pas d’informations suffisantes sur le contenu du paquet: cela ne nous permet pas de conclure
sûrement sur le respect de la RFC, mais vu la logique de l’enchaı̂nement des trames, on peut
raisonnablement penser que quagga y est fidèle.
• 1448: longueur du paquet
Le paquet suivant est encore envoyé par Autriche, il s’agit d’un Update qui ne correspond
à aucune demande de mise à jour. La RFC précise que lors d’un changement de topologie, les
mises à jour sont propagées dans tout le réseau automatiquement, c’est bien ce que fait quagga.
fe80::4:6ff:fe00:34: OSPFv3-ls upd 852: rtrid 192.168.0.11 backbone S 80000001 age 11:25
area-intra-area-prefix 0.0.0.2 rtr 192.168.0.2 [|ospf ]
• 80000001: numéro de séquence du LSA
• age 11:25: age du LSA en secondes
• area-intra-area-prefix: type de LSA
• 0.0.0.2: ID du lien
• rtr 192.168.0.2: routeur à l’origine du LSA
La séquence décrite ci-dessus est en fait le header du LSA envoyé. Ce type de message
respecte, là encore, le format décrit dans la RFC.
2.5
Link State Acknowledgement Packet
Ces paquets permettent d’acquitter la réception d’un ou plusieurs LSA. Cependant, on n’en
observe pas un par LSA envoyé: en effet, la RFC précise que les acquittement peuvent s’opérer
implicitement dans les Updates Packets. Regardons de plus près ces paquets d’acquittement:
fe80::4:6ff:fe00:34: OSPFv3-ls ack 36: rtrid 192.168.0.11 backbone S 80000003 age 2 linklocallink 0.0.0.4 rtr 192.168.0.12
• S 80000003 age 2 linklocal-link 0.0.0.4 rtr 192.168.0.12 : header du LSA acquitté.
Il s’agit de l’acquittement envoyé par Hongrie en réponse au Update envoyé par Autriche
0.05s auparavant.
2.6
Conclusion sur l’analyse des paquets
Les trames étudiées nous permettent de conclure que la RFC est bien respectée: le format
des trames est quasiment identique et on retrouve toutes les données requises. Le ”‘quasiment”’
vient du fait que parfois l’ordre des données dans la trame est légèrement modifié. C’est le
cas des headers LSA: le numéro de séquence se situe au début et non en 3ème place, après
l’advertising router comme il est décrit dans la RFC.
On retrouve bien tous les types de messages: HELLO, LS Request, LS Update et LS Acknowledgement qui remplissent tous les rôles décrits dans la RFC.
Il nous manque cependant quelques données (notamment le contenu des LSA envoyés, nous
n’avons que les headers et la description de la base de donnée) pour conclure que quagga est
fidèle à 100% à la RFC. Mais le système fonctionne globalement bien comme il est décrit dans
la norme, on peut donc penser que ces données sont proches de celles qui sont décrites dans la
RFC.
3
Changement de topologie
3.1
3.1.1
Calcul du plus court chemin en fonction du débit
Introduction
Rappelons que, contrairement à RIP, la métrique d’OSPF est basée sur le coût du lien (qui
représente en fait sa capacité). Par conséquent, si Quagga respecte la RFC, le changement de
coût de liens peut entraı̂ner une mise à jour des tables de routage. Ainsi entre deux chemins
ayant un nombre de sauts différent, celui qui possède le plus de sauts peut être choisi si le coût
total de ce chemin est le meilleur.
Le test décrit ci-dessous va nous permettre de vérifier que cette fonctionnalité est bien respectée.
Pour cela, nous avons modifié les valeurs des coûts des liens 11, 12 et 13. Nous avons ensuite
relevé la table de routage du routeur Italie et regardé comment Italie joignait le lien 1. (cf
figure : 5 )
3.1.2
Commentaires
1er cas: c(11)=1, c(12)=1, c(13)=1 Pour joindre le lien 1, Italie passe par Espagne.
Ce chemin correspond au coût minimum: deux liens de coût 1 (11 et 1) => metric = 2.
2ème cas: c(11)=100, c(12)=1, c(13)=2 Cette fois, Italie joint le lien 1 par Allemagne.
Le coût minimum est alors de 1+1+1 => metric = 3 (3liens à 1).
3ème cas: c(11)=100, c(12)=2, c(13)=1 Le lien 1 est joint par Suisse. Le coût minimum
est de 1+1+1 => metric = 3 (3liens à 1)
3.2
Les tables de routage
Les tests concernant les tables de routage ont été réalisés sur le routeur Allemagne car
celui-ci est le routeur central du réseau et permet de voir beaucoup de choses. Pour une bonne
compréhension ce qui suit, il est conseillé de disposer du plan d’adressage construit de GEANT
(figure : 6.1) et de celui créé automatiquement par le protocol IPv6 (figure : 9.1). Voici la
partie de la table de routage d’Allemagne qui nous intéresse au démarrage du réseau complet.
La table complète est disponible dans l’annexe 6.
3.2.1
Le réseau complet
Kernel IPv6 routing table
Destination
Flags Metric Ref
Use Iface
1ffe::1:0/112
UG
2
1ffe::2:0/112
UG
2
1ffe::3:0/112
UG
2
1ffe::4:0/112
U
256
1ffe::5:0/112
U
256
1ffe::6:0/112
UG
2
1ffe::7:0/112
U
256
1ffe::8:0/112
UG
2
1ffe::9:0/112
U
256
1ffe::a:0/112
UG
2
1ffe::b:0/112
UG
2
1ffe::c:0/112
Next Hop
fe80::4:6ff:fe00:7
0
0 eth2
0
0 eth2
fe80::4:6ff:fe00:7
fe80::4:6ff:fe00:e
0
0 eth0
0
0 eth2
::
::
0
0 eth0
0
0 eth1
fe80::4:6ff:fe00:19
::
0
0 eth1
fe80::4:6ff:fe00:19
0
0 eth1
::
0
0 eth3
fe80::4:6ff:fe00:7
0
0 eth2
fe80::4:6ff:fe00:2c
0
0 eth4
::
U
256
1ffe::d:0/112
UG
2
1ffe::e:0/112
UG
3
1ffe::f:0/112
UG
4
0
0 eth4
0
0 eth4
fe80::4:6ff:fe00:2c
fe80::4:6ff:fe00:2c
0
0 eth4
0
0 eth4
fe80::4:6ff:fe00:2c
Dans cette table, la première chose que l’on peut voir, c’est que tous les réseaux qui sont
définis par le plan sont joignables (le flag U indique une route active) dans cette table de
routage. Ensuite tous les réseaux qui sont directement liés à une interface du routeur sont
indiqués comme tels : ils sont liés à l’interface en question et il n’y a pas de next hop. Les
réseaux qui ne sont pas directement joignables sont marqués comme tels (le flag G indique une
route dont le prochain saut est une gateway) et leurs métriques sont réduite (le maximum ici
est 4 sachant que le diamètre du réseau est de 6 pour joindre Pologne depuis Hongrie).
On peut aussi s’apercevoir que cette table de routage ne correspond pas à la RFC (paragraphe 6). Les champs qui n’apparaissent pas sont :
• Le type de destinataire vu que l’on a que des réseaux en destination (cela est spécifié
dans la RFC)
• Les capacités optionnelles pour les mêmes raisons
• Le type de chemin
• Le coût de type 2
• L’origine de l’état des liens
• Le routeur d’annonce
En fait, la table de routage est sous une forme classique où l’on a les information habituelles
: adresse destination, prochain saut, métrique, interface utilisée...
Nous avons maintenant coupé les liens C4 et C7 pour voir l’évolution de la table.
3.2.2
Sans les liens C4 et C7
Ici nous n’avons laissé que certaines routes car c’est la comparaison avec la table précédente
est intéressante. La table complète est disponible en annexe 2.5.
Destination
Flags Metric Ref
1ffe::1:0/112
UG
3
0
1ffe::8:0/112
UG
4
0
Next Hop
Use Iface
fe80::4:6ff:fe00:2c
0 eth4
fe80::4:6ff:fe00:e
0 eth0
Les routes que nous tenons à comparer sont celles qui partent d’Allemagne vers le réseau
1 (France-Espagne) et le réseau 8 (Suède-Pologne).
Lorsque le réseau était complet, Allemagne joignait le réseau 1 en passant par fe80::4:6ff:fe00:7
(France) et cela avec une métrique de 2. En fait, avec un traceroute, on s’aperçoit que cette
route part d’Allemagne et passe seulement par France pour joindre le réseau 1. En enlevant le
lien C4, cette route est modifiée. Allemagne envoie dorénavant les paquets à Italie et ce chemin
a une métrique de 3. Le traceroute nous donne la route Allemagne-Italie-Espagne-Réseau1.
On peut faire la même constatation sur la route Allemagne vers réseau 8 qui passe de
Allemagne-Suède-Réseau8 à Allemagne-PaysBas-Angleterre-Suède-Réseau8.
Le protocole OSPF a donc bien adapté la structure de la table de routage au changement
de la topologie du réseau.
4
Conclusion
Dans ce chapitre, nous nous sommes aperçu que l’implémentation d’OSPFv3 fonctionne
mais qu’elle n’est pas terminée. De plus, il arrive que certaines parties ne répondent pas
précisément à la RFC 5340[7]. C’est notamment le cas de la structure de la table de routage.
Parmis les parties non encore implémentées, on retrouve :
• la gestion de la qualité de service
• la gestion des aires de routage
Evaluation d’OSPFv2
La valeur ajoutée de cette partie par rapport à la précédente réside dans la gestion des aires
de routage. Il est question ici d’évaluer le fonctionnement du protocole OSPFv2 de Quagga.
Les tests sont effectués sur Renater qui possède un nombre de routeurs beaucoup plus important que Géant (30, Géant en possède 12). Il est donc nécessaire de définir des aires afin
d’optimiser le routage en divisant le réseau en sous-réseaux de plus petite taille plus faciles à
gérer.
La taille du réseau étant trop importante pour être raisonnablement supportée par une
seule machine, nous avons réparti les routeurs sur deux machines. Pour cela, nous avons
divisé la France en deux: une partie Ouest et une partie Est. La partie qui suit décrit plus
précisément la configuration du réseau sur Marionnet.
1
Plan d’adressage
1.1
Répartition du réseau sur deux machines
Le réseau est divisé en deux groupes:
36
Répartition des routeurs: partie OUEST
Répartition des routeurs: partie EST
Ces deux groupes sont reliés par des ponts. Le principe du pont est expliqué en annexe.
1.2
Attribution des adresses
A la différence d’OSPFv3, les adresses suivent le format d’ipv4: quatre octets. Les deux
premiers octets seront communs à toutes les interfaces: 192.168, il s’agit du préfixe utilisé pour
les sous-réseaux (ici Renater). L’octet suivant désigne le numéro du lien dont l’interface est
l’extremité. Le dernier octet aura la valeur 1 ou 2 pour désigner une des deux extrémités du
lien. Le masque sera en /24 qui est le masque de chaque sous-réseau représenté par un lien
entre deux noeuds.
Plan d’adressage de RENATER pour l’évaluation d’OSPFv2
1.3
Définition des aires
Nous avons défini 5 aires en procédant ainsi:
• Aire 0: représente le backbone, aire centrale qui contient le plus de noeuds (14 routeurs).
• Aires 1,2,3,4,5: ensembles de noeuds qui se raccrochent au backbone, regroupent chacune
entre 3 et 7 routeurs. Nous les avons rassemblés selon les groupes qui se sont formés
visuellement lors de la définition de la topologie sur Marionnet.
2
Mise en oeuvre
Nous avons rencontré quelques problèmes lors de la configuration des routeurs de la partie
OUEST: certains se bloquaient au démarrage. Ceci nous a contraint à redéfinir la répartition
en transférant Bordeaux, Pau, Toulouse, Clermont de la machine supportant l’OUEST à celle
qui supporte l’EST. Nous avons modifié en conséquence la configuration des ponts: br4 relie
Bordeaux à Nantes, br5 relie Clermont à Limoges et br6 Poitiers à Bordeaux. Ces changements
sont à appliquer au plan initial théorique donné ci-dessous:
Configuration des ponts
Lors de la configuration des ponts, nous avons:
1. créé les 5 interfaces eth0.X
2. créé les 5 ponts brX
3. donné une adresse à chaque pont
4. attaché chaque pont à une interface
5. attaché chaque pont à une prise virtuelle
Conclusion
L’ensemble des tests réalisés nous permettent de conclure que les fonctionnalités OSPF implémentées sur QUAGGA répondent dans l’ensemble aux exigences de la RFC. Notons quand
même que toutes les fonctionnalités d’OSPFv3 ne sont pas encore implémentées, QUAGGA
est encore en développement de ce côté-là.
Outre la découverte et l’évaluation d’un logiciel de routage, ce projet a été l’occasion pour
nous d’enrichir notre culture en réseau. Les recherches documentaires sur OSPF, l’exploration
de la technique du pontage logiciel et la définition des plans d’adressage nous ont permis
d’approfondir les connaissances acquises au cours de notre formation à l’ENAC.
Enfin, nous avons pu exploiter les possibilités offertes par l’outil logiciel Marionnet pour simuler
des réseaux réels de taille relativement importante. Ce travail a permis de produire des topologies et de définir les processus de configuration des routeurs. Une des possibilités intéressantes
exploitée a été la répartition du réseau sur deux machines. Le résultat produit pourra être
réutilisé à posteriori, ce qui peut s’avérer très intéressant dans le cadre de simulations sur des
réseaux réels.
41
Annexes
1
Utilisation d’un pont réseau avec Marionnet
Avec 12 routeurs, Marionnet met déjà plus de vingt minutes pour lancer le réseau GEANT.
RENATER comprenant 30 routeurs, nous voulions utiliser plusieurs ordinateurs pour simuler
ce réseau. Nous devions donc réussir à relier deux liens d’un réseau virtuel à travers un réseau
réelle. Pour cela, nous avons utilisé les sorties Ethernet de Marionnet ainsi qu’un pont pour
lier celle-ci à l’interface physique de la machine.
Sur cette image, nous avons aussi utilisé des VLANs afin de pouvoir faire passer plusieurs
liens virtuels à travers une seule interface physique. Pour des raisons de clarté, nous allons
commencé par détailler la procédure pour la création du pont.
1.1
Création d’un pont réseau
Le pont réseau permet d’attacher deux interfaces afin quelle n’en paraissent plus qu’une
vis-à-vis du réseau (i.e. tous les paquets à destination du pont seront diffusés sur toutes les
interfaces qui lui sont attachées). Ainsi, à partir d’une interface virtuelle de Marionnet, nous
pourrons attaquer l’interface physique de l’ordinateur. Voici la procédure que nous avons suivie
(Marionnet 1.2/ Ubuntu 9.10):
1. Configuration de l’interface eth0 :
ifconfig eth0 0.0.0.0 promisc up
42
Cette commande permet d’empêcher l’interface eth0 d’acquérir une adresse (cette interface ne doit pas être visible sur le réseau : seul le réseau Marionnet compte). La
commande promisc permet d’empêcher la résolution des adresses MAC. En effet, il ne
faut pas que eth0 filtre les messages qui arrivent sur le pont et qui n’ont pas son adresse
MAC (message à destination de Marionnet).
2. Création du pont br0 :
brctl addbr br0
ATTENTION : Au démarrage de ses prises Ethernet, Marionnet recherche un pont
du nom de br0 afin des les attacher dessus. Si vous utilisez plusieurs de ces prises
simultanément, il est déconseillé d’utiliser le nom br0. Il vaut mieux démarrer ces prises
une par une et les attacher à la main aux pont souhaité.
3. Attachement de l’interface physique au pont :
brctl addif br0 eth0
4. Configuration du pont br0 :
ifconfig br0 XXX.XXX.XXX.XXX/YY up
Donner au pont l’adresse voulue.
5. Démarrer les prises Marionnet et les attacher au pont (si l’on utilise pas br0)
brctl addif brX tapYYYY
De cette façon, la prise Ethernet de Marionnet sera liée à votre interface physique. En test,
vous pouvez essayer d’envoyer des messages sur le pont depuis Marionnet et vous les recevrez
sur votre interface physique.
1.2
Les virtual networks
Un autre problème s’est alors posé à nous. Pour diviser RENATER en deux, il fallait
couper plusieurs liens. Nous ne pouvions donc pas directement attacher une prise ethernet
de Marionnet à l’interface physique de l’ordinateur (ou alors il nous fallait plusieurs interfaces
physiques). La solution à ce problème est venue des VLANs. Nous avons scindé notre interface
physique en plusieurs interfaces virtuelles afin de créer plusieurs VLANs et ainsi disposer de
plusieurs réseaux virtuels sur un seul réseau physique. Ainsi nous pouvons ainsi avoir plusieurs
liens virtuels indépendants passant par un seul lien physique.
Pour créer nos VLANs sur Ubuntu 9.10, nous avons utilisé le package vconfig :
1. Il suffit alors d’une seule commande pour ajouter des interfaces virtuelles :
vconfig add eth0 2
Pour ajouter une interface qui s’appellera eth0.2.
ATTENTION : les réseaux virtuels doivent être les mêmes sur les deux machines. Si
vous choisissez d’utiliser le VLAN 2 (comme ici) d’un coté, il faudra aussi utiliser le
VLAN 2 de l’autre coté.
2. Créer les ponts avec ces interfaces virtuelles comme si c’était des interfaces réelles.
1.3
Plan des VLANs pour RENATER
Voici le plan d’adressage que nous avons utilisé pour diviser RENATER selon un axe
Nord-Sud :
ATTENTION : Marionnet configure les adresses MAC des machines virtuelles automatiquement et séquentiellement. Si vous essayer de relier les réseaux de deux machines physiques
en le laissant faire vous allez au devant de gros problèmes. En effet, dans ce cas l’unicité des
adresses MAC n’est plus assurée avec tous les problèmes qui en découlent. Avant de relier les
deux machines, il faut donc prendre garde à modifier les adresses MAC de l’une des machines
(dans l’onglet interface).
2
Configuration des routers Quagga
Pour que les routers fonctionnent de façon nomimale sous Marionnet, certaines modifications doivent être apportées quand à leur configuration.
2.1
Sauvegarde des fichiers de configuration Quagga
Lorsque l’on utilise le terminal vtysh pour configurer les routers quagga, la commande write
permet de sauvegarder cette configuration[2]. Cependant, les droits d’accès sur les fichiers de
configuration Quagga des routers ne permettent pas de faire cette sauvegarde. Il existe deux
méthodes pour palier à cela.
2.1.1
Téléchargement des fichiers de configuration
Cette méthode est la plus compliquée. Elle n’est pas conseillée car elle ne résout pas foncièrement le problème mais peut-être utilisée dans certains cas. Ici, on se base sur l’utilisation
des ponts réseau décrite dans la section 1.1. Une fois un pont installé, on peut communiquer
entre la machine physique et le réseau virtuel. Le principe est donc d’utiliser scp pour copier
des fichiers de configuration que l’on a préalablement écrits à la main (demande une bonne
connaissance de Quagga).
Voici la procédure à suivre :
1. Ecrire les fichiers de configuration et les organiser par dossier pour chaque router (dans
l’example on utilisera ~/router1/quagga/)
2. Démarer le réseau virtuel
3. Créer le pont réseau1.1
4. Télécharger les fichiers de configuration dans le router (le router a pour adresse 192.168.0.1).
spc -r ~/router1/quagga 192.168.0.1:/etc/
root (mot de passe du router)
Cette commande peut être inversée pour récupérer les fichiers de configuration du router
sur la machine physique.
2.1.2
Changement des droits d’accès
Pour commencer, il est conseillé de désactiver la commande service integrated-vtysh-config
du fichier vtysh.conf pour ne pas utiliser le fichier intégré Quagga.conf mais la méthode de
configuration classique de Quagga. Normalement, cette commande est désactivée par défaut.
Voici la procédure pour changer les droits d’accès des fichiers Quagga.
1. Démarer le router (identifiant : root, mot de passe : root)
2. Changer le propriétaire des fichiers Quagga
chown -R quagga.quaggavty /etc/quagga
L’option -R permet de modifier récursivement le propriétaire de tous les fichiers du
dossier Quagga. Dorénavant, les fichiers appartiennent à l’utilisateur quaggavty du
groupe quagga.
3. Changer les droits d’accès sur les fichiers
chmod -R 770 /etc/quagga
L’option -R permet de modifier récursivement le propriétaire de tous les fichiers du dossier
Quagga.
Cela doit être réaliser sur tout les routers du réseau. N’oubliez pas de sauvegarder le projet
Marionnet après sous peine de devoir tout recommencer.
2.2
En IPv6
L’option forwarding des routers n’est pas activée par défaut en IPv6, il faut donc le faire
manuellement sur chaque router. Cela se fait avec la commande :
echo ’1’ > /proc/sys/net/ipv6/conf/all/forwarding
Malheuresement, cette modification n’est pas conservée lors de l’enregistrement du projet
Marionnet. Il faut donc le refaire à chaque démarage.
3
Plan d’adressage de Geant
Avec IPv6, certaines adresses sont générées automatiquemant au lancement des interfaces.
C’est notamment le cas pour les adresses de lien local. OSPFv3 utilisant ces adresses pour
fonctionner, nous avons reporté sur le shéma ci-dessous le plan d’adresses constitué automatiquement pour une meilleur compréhension de l’évaluation d’OSPFv3.
Figure 9.1: Plan des adresses de lien local de GEANT
4
Trace des paquets capturés lors du démarage d’un réseau
Voici les paquets bruts capturés lors du lancement des routers Hongrie et Autriche sur le
réseau Géant. Les paquets concernant OSPF sont en rouge et les autres en vert.
40 dr 192.168.0.11 nbrs
40 nbrs
09:23:59.718281 IP6 (hlim 1, next-header: Options (0), length: 36) fe80::4:6ff:fe00:34 >
ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] ICMP6, multicast listener report v2,
length 28, 1 group record(s) [ga ddr ff02::5 to ex ]
40 dr 192.168.0.11 nbrs 192.168.0.12
09:24:08.443180 IP6 (hlim 255, next-header: ICMPv6 (58), length: 32) fe80::4:6ff:fe00:34 >
ff02::1:ff00:2f: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::4:6ff:fe00:2f
source link-address option (1), length 8 (1): 02:04:06:00:00:34 0x0000: 0204 0600 0034
09:24:08.443300 IP6 (hlim 255, next-header: ICMPv6 (58), length: 32) fe80::4:6ff:fe00:2f >
fe80::4:6ff:fe00:34: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::4:6ff:fe00:2f,
Flags [router, solicited, override] destination link-address option (2), length 8 (1): 02:04:06:00:00:2f
0x0000: 0204 0600 002f
fe80::4:6ff:fe00:2f: OSPFv3-dd 28: rtrid 192.168.0.12 backbone V6/E/R I/M/MS mtu 1500 S
4B541AA8
09:24:08.468434 IP6 (hlim 64, next-header: OSPF (89), length: 988) fe80::4:6ff:fe00:2f
> fe80::4:6ff:fe00:34: OSPFv3-dd 988: rtrid 192.168.0.11 backbone V6/E/R mtu 1500 S
4B541AA8
fe80::4:6ff:fe00:2f: OSPFv3-ls req 580: rtrid 192.168.0.12 backbone linklocal-link 0.0.0.3 rtr
192.168.0.11 linkloca l-link 0.0.0.4 rtr 192.168.0.12 [|ospf]
> fe80::4:6ff:fe00:2f: OSPFv3-dd 68: rtrid 192.168.0.12 backbone V6/E/R MS mtu 1500 S
4B541AA9
09:24:08.486073 IP6 (hlim 64, next-header: Fragment (44), length: 1456) fe80::4:6ff:fe00:2f
> fe80::4:6ff:fe00:34: frag (0x00000002:0|1448) OSPFv3-ls upd 1448: [len 1484]
09:24:08.487226 IP6 (hlim 64, next-header: Fragment (44), length: 44) fe80::4:6ff:fe00:2f >
fe80::4:6ff:fe00:34: frag (0x00000002:1448|36)
area-intra-area-prefix 0.0.0.2 rtr 192.168.0.2 [|ospf]
09:24:08.491382 IP6 (hlim 64, next-header: OSPF (89), length: 28) fe80::4:6ff:fe00:2f
> fe80::4:6ff:fe00:34: OSPFv3-ls req 28: rtrid 192.168.0.11 backbone area-intra-area-prefix
0.0.0.0 rtr 192.168.0.12
fe80::4:6ff:fe00:34: OSPFv3-dd 28: rtrid 192.168.0.11 backbone V6/E/R mtu 1500 S 4B541AA9
> fe80::4:6ff:fe00:2f: OSPFv3-ls req 208: rtrid 192.168.0.12 backbone area-intra-area-prefix
0.0.0.2 rtr 192.168.0.2 a rea-intra-area-prefix 0.0.0.3 rtr 192.168.0.2 [|ospf]
> ff02::5: OSPFv3-ls upd 156: rtrid 192.168.0.12 backbone S 80000003 age 1 linklocal-link
0.0.0.4 rtr 192.168.0.12 [|osp f]
ff02::5: OSPFv3-ls upd 72: rtrid 192.168.0.12 backbone S 80000001 age 1:00:00 area-intraarea-prefix 0.0.0.4 rtr 192.168. 0.12 [|ospf]
> fe80::4:6ff:fe00:2f: OSPFv3-ls upd 156: rtrid 192.168.0.12 backbone S 80000002 age 10
fe80::4:6ff:fe00:34: OSPFv3-ls ack 36: rtrid 192.168.0.11 backbone S 80000003 age 2 linklocallink 0.0.0.4 rtr 192.168.0. 12
ff02::5: OSPFv3-ls upd 212: rtrid 192.168.0.11 backbone S 80000004 age 1 area-rtr 192.168.0.11
[|ospf]
ff02::5: OSPFv3-ls upd 112: rtrid 192.168.0.12 backbone S 80000002 age 1 area-rtr 192.168.0.12
[|ospf]
> fe80::4:6ff:fe00:2f: OSPFv3-ls ack 316: rtrid 192.168.0.12 backbone S 80000001 age 11:26
area-intra-area-prefix 0.0.0.2 rtr 192.168.0.2
ff02::5: OSPFv3-ls upd 72: rtrid 192.168.0.12 backbone S 80000001 age 1:00:00 area-intraarea-prefix 0.0.0.4 rtr 192.168. 0.12 [|ospf]
fe80::4:6ff:fe00:34: OSPFv3-ls ack 36: rtrid 192.168.0.11 backbone S 80000001 age 1:00:00
area-intra-area-prefix 0.0.0.4 rtr 192.168.0.12
40 dr 192.168.0.11 bdr 192.168. 0.12 nbrs 192.168.0.11
ff02::5: OSPFv3-ls ack 996: rtrid 192.168.0.12 backbone S 80000002 age 9:46 linklocal-link
0.0.0.3 rtr 192.168.0.11
ff02::5: OSPFv3-ls ack 116: rtrid 192.168.0.11 backbone S 80000003 age 5 linklocal-link 0.0.0.4
rtr 192.168.0.12
09:24:13.445801 IP6 (hlim 255, next-header: ICMPv6 (58), length: 32) fe80::4:6ff:fe00:2f >
fe80::4:6ff:fe00:34: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::4:6ff:fe00:34
source link-address option (1), length 8 (1): 02:04:06:00:00:2f 0x0000: 0204 0600 002f
09:24:13.448149 IP6 (hlim 255, next-header: ICMPv6 (58), length: 24) fe80::4:6ff:fe00:34 >
fe80::4:6ff:fe00:2f: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::4:6ff:fe00:34,
Flags [router, solicited]
fe80::4:6ff:fe00:2f: OSPFv3-ls upd 112: rtrid 192.168.0.12 backbone S 80000002 age 6 area-rtr
192.168.0.12 [|ospf]
fe80::4:6ff:fe00:34: OSPFv3-ls upd 76: rtrid 192.168.0.11 backbone S 80000004 age 6 area-rtr
192.168.0.11 [|ospf]
ff02::5: OSPFv3-ls ack 56: rtrid 192.168.0.11 backbone S 80000002 age 10 area-rtr 192.168.0.12
ff02::5: OSPFv3-ls ack 36: rtrid 192.168.0.12 backbone S 80000004 age 10 area-rtr 192.168.0.11
09:24:18.424566 IP6 (hlim 64, next-header: OSPF
ff02::5: OSPFv3-hello 40: rtrid 192.168.0.11 backbone
40 dr 192.168.0.11 bdr 192.168. 0.12 nbrs 192.168.0.12
40 dr 192.168.0.11 bdr 192.168. 0.12 nbrs 192.168.0.11
40 dr 192.168.0.11 bdr 192.168. 0.12 nbrs 192.168.0.12
40 dr 192.168.0.11 bdr 192.168. 0.12 nbrs 192.168.0.11
40 dr 192.168.0.11 bdr 192.168. 0.12 nbrs 192.168.0.12
(89), length: 40) fe80::4:6ff:fe00:2f >
V6/E/R ifid 0.0.0.3 pri 1 int 10 dead
(89), length: 40) fe80::4:6ff:fe00:34 >
(89), length: 40) fe80::4:6ff:fe00:2f >
(89), length: 40) fe80::4:6ff:fe00:34 >
(89), length: 40) fe80::4:6ff:fe00:2f >
5
Table de routage d’Italie
1er cas:
eth2 cout=1 et eth3 cout=1 et eth0 cout=1
Italie:~# route -A inet6
Destination
Flags Metric Ref
Use Iface
::1/128
U
0
9
1 lo
1ffe::1:0/112
UG
2
0
0 eth2
1ffe::2:0/112
UG
3
0
0 eth3
1ffe::3:0/112
UG
3
0
0 eth3
1ffe::4:0/112
UG
2
0
0 eth3
1ffe::5:0/112
UG
2
0
0 eth3
1ffe::6:0/112
UG
3
0
0 eth3
1ffe::7:0/112
UG
2
0
0 eth3
1ffe::8:0/112
UG
3
0
0 eth3
1ffe::9:0/112
UG
2
0
0 eth3
1ffe::a:0/112
UG
2
0
0 eth0
1ffe::b:0/128
U
0
0
2 lo
1ffe::b:2/128
U
0
0
1 lo
1ffe::b:0/112
U
256
0
0 eth2
1ffe::c:0/128
U
0
0
2 lo
1ffe::c:2/128
U
0
0
1 lo
1ffe::c:0/112
U
256
0
0 eth3
1ffe::d:0/128
U
0
0
2 lo
1ffe::d:2/128
U
0
0
1 lo
Next Hop
::
fe80::4:6ff:fe00:2
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:28
::
::
::
::
::
::
::
::
1ffe::d:0/112
U
256
0
0 eth0
1ffe::e:0/112
UG
2
0
0 eth0
1ffe::f:0/112
UG
3
0
0 eth0
1ffe::10:0/112
UG
4
0
0 eth0
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::4:6ff:fe00:29/128
U
0
56
1 lo
fe80::4:6ff:fe00:2a/128
U
0
0
1 lo
fe80::4:6ff:fe00:2b/128
U
0
55
1 lo
fe80::4:6ff:fe00:2c/128
U
0
38
1 lo
fe80::4042:aff:fe74:edc0/128
U
0
0
1 lo
fe80::/64
U
256
0
0 eth0
fe80::/64
U
256
0
0 eth1
fe80::/64
U
256
0
0 eth2
fe80::/64
U
256
0
0 eth3
ff02::2/128
UC
0
3
3 eth3
ff02::5/128
UC
0
2557
0 eth0
ff02::5/128
UC
0
2605
0 eth2
ff02::5/128
UC
0
2562
0 eth3
ff00::/8
U
256
0
0 eth0
ff00::/8
::
fe80::4:6ff:fe00:28
fe80::4:6ff:fe00:28
fe80::4:6ff:fe00:28
::
::
::
::
::
::
::
::
::
::
::
::
::
::
ff02::2
ff02::5
ff02::5
ff02::5
::
::
U
256
ff00::/8
U
256
ff00::/8
U
256
0
0 eth1
0
0 eth2
::
::
0
0 eth3
Pour joindre le reseau 1, italie passe par espagne
2ème cas: eth2 cout=100 et eth3 cout=1 et eth0 cout=2}
Destination
Flags Metric Ref
Use Iface
::1/128
U
0
9
1 lo
1ffe::1:0/112
UG
3
0
0 eth3
1ffe::2:0/112
UG
3
0
0 eth3
1ffe::3:0/112
UG
3
0
0 eth3
1ffe::4:0/112
UG
2
0
0 eth3
1ffe::5:0/112
UG
2
0
0 eth3
1ffe::6:0/112
UG
3
0
0 eth3
1ffe::7:0/112
UG
2
0
0 eth3
1ffe::8:0/112
UG
3
0
0 eth3
1ffe::9:0/112
UG
2
0
0 eth3
1ffe::a:0/112
UG
3
0
0 eth3
1ffe::b:0/128
U
0
0
2 lo
1ffe::b:2/128
U
0
0
1 lo
1ffe::b:0/112
U
256
0
0 eth2
1ffe::c:0/128
U
0
0
2 lo
1ffe::c:2/128
U
0
0
1 lo
1ffe::c:0/112
Next Hop
::
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
::
::
::
::
::
::
U
256
0
0 eth3
1ffe::d:0/128
U
0
0
2 lo
1ffe::d:2/128
U
0
0
1 lo
1ffe::d:0/112
U
256
0
0 eth0
1ffe::e:0/112
UG
3
0
0 eth0
1ffe::f:0/112
UG
4
0
0 eth0
1ffe::10:0/112
UG
5
0
0 eth0
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::4:6ff:fe00:29/128
U
0
56
1 lo
fe80::4:6ff:fe00:2a/128
U
0
0
1 lo
fe80::4:6ff:fe00:2b/128
U
0
55
1 lo
fe80::4:6ff:fe00:2c/128
U
0
38
1 lo
fe80::4042:aff:fe74:edc0/128
U
0
0
1 lo
fe80::/64
U
256
0
0 eth0
fe80::/64
U
256
0
0 eth1
fe80::/64
U
256
0
0 eth2
fe80::/64
U
256
0
0 eth3
ff02::2/128
UC
0
3
3 eth3
ff02::5/128
UC
0
2597
0 eth0
ff02::5/128
UC
0
2647
0 eth2
::
::
::
fe80::4:6ff:fe00:28
fe80::4:6ff:fe00:28
fe80::4:6ff:fe00:28
::
::
::
::
::
::
::
::
::
::
::
::
::
::
ff02::2
ff02::5
ff02::5
ff02::5/128
UC
0
ff00::/8
U
256
ff00::/8
U
256
ff00::/8
U
256
ff00::/8
U
256
ff02::5
2603
0 eth3
::
0
0 eth0
::
0
0 eth1
::
0
0 eth2
0
0 eth3
::
Il passe par l’allemagne
3ème cas: eth2 cout=100 et eth3 cout=2 et eth0 cout=2
Destination
Flags Metric Ref
Use Iface
::1/128
U
0
9
1 lo
1ffe::1:0/112
UG
3
0
0 eth0
1ffe::2:0/112
UG
3
0
0 eth0
1ffe::3:0/112
UG
4
0
0 eth3
1ffe::4:0/112
UG
3
0
0 eth3
1ffe::5:0/112
UG
3
0
0 eth3
1ffe::6:0/112
UG
4
0
0 eth3
1ffe::7:0/112
UG
3
0
0 eth3
1ffe::8:0/112
UG
4
0
0 eth3
1ffe::9:0/112
UG
3
0
0 eth3
1ffe::a:0/112
UG
2
0
0 eth0
1ffe::b:0/128
U
0
0
2 lo
1ffe::b:2/128
U
0
0
1 lo
1ffe::b:0/112
U
256
0
0 eth2
Next Hop
::
fe80::4:6ff:fe00:28
fe80::4:6ff:fe00:28
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:15
fe80::4:6ff:fe00:28
::
::
::
1ffe::c:0/128
U
0
0
2 lo
1ffe::c:2/128
U
0
0
1 lo
1ffe::c:0/112
U
256
0
0 eth3
1ffe::d:0/128
U
0
0
2 lo
1ffe::d:2/128
U
0
0
1 lo
1ffe::d:0/112
U
256
0
0 eth0
1ffe::e:0/112
UG
2
0
0 eth0
1ffe::f:0/112
UG
3
0
0 eth0
1ffe::10:0/112
UG
4
0
0 eth0
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::/128
U
0
0
2 lo
fe80::4:6ff:fe00:29/128
U
0
56
1 lo
fe80::4:6ff:fe00:2a/128
U
0
0
1 lo
fe80::4:6ff:fe00:2b/128
U
0
55
1 lo
fe80::4:6ff:fe00:2c/128
U
0
38
1 lo
fe80::4042:aff:fe74:edc0/128
U
0
0
1 lo
fe80::/64
U
256
0
0 eth0
fe80::/64
U
256
0
0 eth1
fe80::/64
U
256
0
0 eth2
fe80::/64
U
256
0
0 eth3
ff02::2/128
::
::
::
::
::
::
fe80::4:6ff:fe00:28
fe80::4:6ff:fe00:28
fe80::4:6ff:fe00:28
::
::
::
::
::
::
::
::
::
::
::
::
::
::
ff02::2
UC
0
ff02::5/128
UC
0
ff02::5/128
UC
0
ff02::5/128
UC
0
ff00::/8
U
256
ff00::/8
U
256
ff00::/8
U
256
ff00::/8
U
256
3
3 eth3
ff02::5
2655
0 eth0
ff02::5
2711
0 eth2
2664
0 eth3
ff02::5
::
0
0 eth0
::
0
0 eth1
::
0
0 eth2
::
0
0 eth3
Il passe par la suisse
6
6.1
Tables de routage d’Allemagne
Réseau complet
Allemagne:~# route -A inet6
Destination
Flags Metric Ref
Use
::1/128
U
0
9
1
1ffe::1:0/112
UG
2
0
0
1ffe::2:0/112
UG
2
0
0
1ffe::3:0/112
UG
2
0
0
1ffe::4:0/128
U
0
0
2
1ffe::4:2/128
U
0
0
1
1ffe::4:0/112
U
256
0
0
1ffe::5:0/128
U
0
0
2
1ffe::5:2/128
U
0
0
1
1ffe::5:0/112
U
256
0
0
1ffe::6:0/112
UG
2
0
0
1ffe::7:0/128
U
0
0
2
1ffe::7:1/128
U
0
0
1
1ffe::7:0/112
U
256
0
0
1ffe::8:0/112
UG
2
0
0
1ffe::9:0/128
U
0
0
2
1ffe::9:1/128
U
0
0
1
1ffe::9:0/112
U
256
0
0
1ffe::a:0/112
UG
2
0
0
1ffe::b:0/112
Next Hop
Iface
::
lo
fe80::4:6ff:fe00:7
eth2
fe80::4:6ff:fe00:7
eth2
fe80::4:6ff:fe00:e
eth0
::
lo
::
lo
::
eth2
::
lo
::
lo
::
eth0
fe80::4:6ff:fe00:19
eth1
::
lo
::
lo
::
eth1
fe80::4:6ff:fe00:19
eth1
::
lo
::
lo
::
eth3
fe80::4:6ff:fe00:7
eth2
fe80::4:6ff:fe00:2c
UG
2
0
1ffe::c:0/128
U
0
0
1ffe::c:1/128
U
0
0
1ffe::c:0/112
U
256
0
1ffe::d:0/112
UG
2
0
1ffe::e:0/112
UG
3
0
1ffe::f:0/112
UG
4
0
1ffe::10:0/112
UG
5
0
fe80::/128
U
0
0
fe80::/128
U
0
0
fe80::/128
U
0
0
fe80::/128
U
0
0
fe80::/128
U
0
0
fe80::/128
U
0
0
fe80::/128
U
0
0
fe80::/128
U
0
0
fe80::/128
U
0
0
fe80::4:6ff:fe00:11/128
U
0
114
fe80::4:6ff:fe00:12/128
U
0
112
fe80::4:6ff:fe00:13/128
U
0
31
fe80::4:6ff:fe00:14/128
U
0
73
fe80::4:6ff:fe00:15/128
U
0
41
fe80::4:6ff:fe00:16/128
U
0
0
fe80::4:6ff:fe00:17/128
U
0
0
0 eth4
::
2 lo
::
1 lo
::
0 eth4
fe80::4:6ff:fe00:2c
0 eth4
fe80::4:6ff:fe00:2c
0 eth4
fe80::4:6ff:fe00:2c
0 eth4
fe80::4:6ff:fe00:2c
0 eth4
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
1 lo
::
1 lo
::
1 lo
::
1 lo
::
1 lo
::
1 lo
::
1 lo
fe80::4:6ff:fe00:18/128
U
0
0
1 lo
fe80::4042:a3ff:fe05:b381/128
U
0
0
1 lo
fe80::/64
U
256
0
0 eth0
fe80::/64
U
256
0
0 eth1
fe80::/64
U
256
0
0 eth2
fe80::/64
U
256
0
0 eth3
fe80::/64
U
256
0
0 eth4
fe80::/64
U
256
0
0 eth5
fe80::/64
U
256
0
0 eth6
fe80::/64
U
256
0
0 eth7
ff02::5/128
UC
0
1877
0 eth4
ff02::5/128
UC
0
1857
0 eth1
ff02::5/128
UC
0
1861
0 eth2
ff02::5/128
UC
0
1853
0 eth0
ff02::5/128
UC
0
1776
0 eth3
ff00::/8
U
256
0
0 eth3
ff00::/8
U
256
0
0 eth2
ff00::/8
U
256
0
0 eth0
ff00::/8
U
256
0
0 eth1
ff00::/8
U
256
0
0 eth4
ff00::/8
U
256
0
0 eth5
ff00::/8
U
256
0
0 eth6
ff00::/8
U
256
0
0 eth7
::
::
::
::
::
::
::
::
::
::
ff02::5
ff02::5
ff02::5
ff02::5
ff02::5
::
::
::
::
::
::
::
::
6.2
Sans C7 et C4
Allemagne:~# route -A inet6
Destination
Flags Metric Ref
::1/128
U
0
9
1ffe::1:0/112
UG
3
0
1ffe::2:0/112
UG
3
0
1ffe::3:0/112
UG
2
0
1ffe::4:0/128
U
0
0
1ffe::4:2/128
U
0
0
1ffe::4:0/112
U
256
0
1ffe::5:0/128
U
0
0
1ffe::5:2/128
U
0
0
1ffe::5:0/112
U
256
0
1ffe::6:0/112
UG
3
0
1ffe::7:0/128
U
0
0
1ffe::7:1/128
U
0
0
1ffe::7:0/112
U
256
0
1ffe::8:0/112
UG
4
0
1ffe::9:0/128
U
0
0
1ffe::9:1/128
U
0
0
1ffe::9:0/112
U
256
0
1ffe::a:0/112
UG
3
0
1ffe::b:0/112
UG
2
0
1ffe::c:0/128
Next Hop
Use Iface
::
1 lo
fe80::4:6ff:fe00:2c
0 eth4
fe80::4:6ff:fe00:e
0 eth0
fe80::4:6ff:fe00:e
0 eth0
::
2 lo
::
1 lo
::
0 eth2
::
2 lo
::
1 lo
::
0 eth0
fe80::4:6ff:fe00:e
0 eth0
::
2 lo
::
1 lo
::
0 eth1
fe80::4:6ff:fe00:e
0 eth0
::
2 lo
::
1 lo
::
0 eth3
fe80::4:6ff:fe00:2c
0 eth4
fe80::4:6ff:fe00:2c
0 eth4
::
U
0
0
U
0
0
U
256
0
UG
2
0
UG
3
0
UG
4
0
UG
5
0
U
0
0
U
0
0
U
0
0
U
0
0
U
0
0
1ffe::c:1/128
1ffe::c:0/112
1ffe::d:0/112
1ffe::e:0/112
1ffe::f:0/112
1ffe::10:0/112
fe80::/128
fe80::/128
fe80::/128
fe80::/128
fe80::/128
fe80::/128
U
0
0
fe80::/128
U
0
0
U
0
0
U
0
fe80::4:6ff:fe00:11/128
U
0
fe80::4:6ff:fe00:12/128
U
0
fe80::4:6ff:fe00:13/128
U
0
fe80::4:6ff:fe00:14/128
U
0
fe80::4:6ff:fe00:15/128
U
0
fe80::4:6ff:fe00:16/128
U
0
fe80::4:6ff:fe00:17/128
U
0
fe80::4:6ff:fe00:18/128
U
0
0
fe80::/128
fe80::/128
114
114
31
73
41
0
0
0
2 lo
::
1 lo
::
0 eth4
fe80::4:6ff:fe00:2c
0 eth4
fe80::4:6ff:fe00:2c
0 eth4
fe80::4:6ff:fe00:2c
0 eth4
fe80::4:6ff:fe00:2c
0 eth4
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
2 lo
::
1 lo
::
1 lo
::
1 lo
::
1 lo
::
1 lo
::
1 lo
::
1 lo
::
1 lo
fe80::4042:a3ff:fe05:b381/128
U
0
0
fe80::/64
U
256
0
fe80::/64
U
256
0
fe80::/64
U
256
0
fe80::/64
U
256
0
fe80::/64
U
256
0
fe80::/64
U
256
0
fe80::/64
U
256
0
fe80::/64
U
256
0
ff02::5/128
UC
0
2106
ff02::5/128
UC
0
2045
ff02::5/128
UC
0
2045
ff02::5/128
UC
0
2086
ff02::5/128
UC
0
2003
ff00::/8
U
256
0
ff00::/8
U
256
0
ff00::/8
U
256
0
ff00::/8
U
256
0
ff00::/8
U
256
0
ff00::/8
U
256
0
ff00::/8
U
256
0
ff00::/8
U
256
0
::
1 lo
::
0 eth0
::
0 eth1
::
0 eth2
::
0 eth3
::
0 eth4
::
0 eth5
::
0 eth6
::
0 eth7
ff02::5
0 eth4
ff02::5
0 eth1
ff02::5
0 eth2
ff02::5
0 eth0
ff02::5
0 eth3
::
0 eth3
::
0 eth2
::
0 eth0
::
0 eth1
::
0 eth4
::
0 eth5
::
0 eth6
::
0 eth7
Bibliography
[1] Gisèle Cizault. IPV6. O’REILLY, 1998.
[2] Kunihiro Ishiguro et al. Quagga, juillet 2006.
[3] Christian HUITEMMA. Le routage dans l’internet. Eyrolles, 1995.
[4] John T. MOY. OSPF. Addison-Wesley, 1998.
[5] John T. MOY. Rfc2328-ospf version 2. Technical report, IETF, 1998.
[6] John T. MOY R. COLTUN, D. FERGUSON. Rfc2740-ospf for ipv6. Technical report,
IETF, 2008.
[7] John T. MOY A. LINDEM R. COLTUN, D. FERGUSON. Rfc5340-ospf for ipv6. Technical report, IETF, 2008.
[8] http://sprint.net, 16 décembre 2009.
[9] http://www.cesca.es/comunicacions/rediris.html, 16 décembre 2009.
[10] http://www.ces.net/doc/2003/research/geant.html, 16 décembre 2009.
[11] http://www.quagga.net.
[12] http://www.remip.prd.fr/doku.php?id=architecture_du_reseau, 16 décembre 2009.
[13] http://www.renater.fr/spip?article302, 16 décembre 2009.
[14] http://www.renater.fr/spip?article70, 16 décembre 2009.
[15] http://www.robtex.com/as/as2200.html#graph, 16 décembre 2009.
65

Evaluation de l`implémentation du protocole OSPF

Transcription

Documents pareils

Où couper un mot à la fin d`une ligne

Lire la suite - Ville de Pont à Marcq

Crème de Tartre Pure PatisFrance

19 mai 2014 Auvergne : Le Projet d`Aménagement certifié ISO

13 février 2015 Le Crédit Agricole Centre France choisit le

Mes compétences essentielles au niveau primaire

TOILETTES SÈCHES - Les Amis de la Terre

Le cours ≪ Hacking IPv6

Indien au Saloon - Francois Sittler

Vulnérabilité des réseaux Wifi: Comment cracker une clé WEP ?