A la découverte du protocole de routage OSPF
icone comprendre
Signature :
GNU/Linux Magazine
Sommaire de l'article :

Retrouvez cet article dans : Linux Magazine 92

 

Cet article a pour objectif de décrire le fonctionnement de l’un des protocoles de routage interne les plus utilisés actuellement : OSPF (Open Shortest Path First). Après un bref rappel de la notion de routage, nous verrons pourquoi OSPF s’impose aujourd’hui comme le protocole de routage de prédilection et comment il peut vous aider à augmenter la fiabilité de votre réseau.

 

1. Vue d’ensemble

Avant d’aborder le fonctionnement détaillé d’OSPF, il est nécessaire de bien comprendre le rôle fondamental du routage. Cette technique est l’action d’acheminer correctement, et de façon optimale, les paquets à travers différents réseaux. Le routage est effectué par les routeurs et ce sont ces derniers qui implémentent les différents protocoles. Il existe deux techniques de routage, à savoir le routage dit " statique " et le routage " dynamique ". La différence entre ces deux modes est la façon dont ils acheminent les paquets. Le premier se base sur des routes entrées une à une par l’administrateur réseau et le second utilise un protocole de routage pour déterminer quel est le meilleur chemin à utiliser. Au sein même des protocoles de routage, nous dénombrons deux familles : les protocoles de routage à vecteur de distance et les protocoles de routage à états de liens. OSPF fait partie de la deuxième famille. Les protocoles de routage à états de liens utilisent l’algorithme du plus court chemin (SPF pour Shortest Path First). Contrairement aux protocoles de routage à vecteur de distance (RIPv1, RIPv2 pour les plus connus), les protocoles de routage à états de liens possèdent une vue complète de la topologie du réseau. Ils ont une vue détaillée sur les routeurs distants et les réseaux qui leur sont connectés. Bien entendu, il existe de nombreuses autres différences, que nous allons découvrir au fur et à mesure de cet article, tout en étudiant OSPF.

2. Les origines d’OSPF

Conçu vers la fin des années 80, le protocole OSPF a été développé dans le but de pallier les défauts de RIP. Bien que très simple à implémenter, RIP possède de grosses lacunes, à savoir :
  • un temps de convergence élevé (temps au bout duquel tous les routeurs ont une vue cohérente du réseau) ;
  • un nombre de sauts limité à 15 qui le cantonne à des réseaux de petites et moyennes tailles (le nombre de sauts est le nombre de routeurs qu’un paquet peut traverser avant d’être considéré comme perdu) ;
  • une consommation excessive de bande passante puisque, à chaque mise à jour (par défaut, toutes les 30 secondes), un routeur RIP diffuse la totalité de sa table de routage.
OSPF corrige tous ces défauts, mais présente un inconvénient majeur : celui d’être relativement complexe à mettre en œuvre. En outre, OSPF est également gourmand en termes de ressources matérielles. En effet, de par la complexité des algorithmes mis en jeux (algorithme du plus court chemin), il nécessite plus de ressource CPU et consomme également plus de RAM.

3. Le fonctionnement d’OSPF

3.1 La notion de zones

Un réseau OSPF est divisé en plusieurs zones. Ces zones sont réparties autour d’une unique et même zone fédératrice (la zone 0) également appelée le backbone. L’ensemble de ces zones décrit un système autonome (AS pour Autonomous System). Plus généralement, un système autonome est le regroupement de plusieurs réseaux implémentant le même protocole de routage interne (IGP pour Interior Gateway Protocol).

 

/img-articles/lm/92/art-3/fig-1.jpg

L’intérêt majeur de la division en différentes zones est de limiter le trafic de routage. En effet, un routeur d’une zone n’aura connaissance que des routeurs se trouvant dans la même zone. Ainsi, sa table de routage sera plus petite, les calculs par l’algorithme SPF en seront diminués, et la convergence accélérée. Maintenant, il se pose le problème suivant : si les routeurs d’une zone n’ont connaissance que de la topologie de cette même zone, comment peuvent-ils communiquer avec les zones adjacentes ?

3.2 La hiérarchie

Nous venons de voir qu’un routeur OSPF, au sein d’une zone, n’a la connaissance que des routeurs de cette même zone. Pour permettre le dialogue avec les zones adjacentes, OSPF met en place une hiérarchie complexe, et certains routeurs vont devoir accomplir des tâches supplémentaires.
  • Le routeur de bordure de zone (ABR pour Area Boundary Router) est le routeur connecté au backbone. De par sa position privilégiée, c’est lui qui annonce les routes extérieures à la zone.
  • Le routeur de bordure de système autonome (ASBR pour Autonomous System Boundary Router) est le routeur chargé de la communication avec les autres systèmes autonomes. Il implémente, en plus d’OSPF, un protocole de routage externe (EGP pour Exterior Gateway Protocol) tel que BGP.
  • Le routeur désigné (DR pour Designated Router) est un routeur élu dans chacune des zones OSPF. Nous verrons par la suite son mode d’élection. Retenons pour le moment qu’il a pour rôle de centraliser l’information de routage au sein de sa zone. Il envoie périodiquement un message d’annonce d’état de lien (LSA pour Link State Advertisements) aux autres routeurs de sa zone. Si un routeur quelconque détecte une discontinuité sur le réseau, il en informe le DR, qui se chargera d’inonder le réseau de cette information. Ainsi, les échanges inter-routeurs sont limités, ce qui a pour effet de préserver la bande passante et d’accélérer considérablement la convergence.
  • Le routeur désigné de secours (BDR pour Backup Designated Router) est, comme son nom l’indique, le routeur qui aura pour rôle de remplacer le DR si celui-ci venait à tomber.

3.3 Les sous-protocoles utilisés par OSPF

Le protocole Hello

 

/img-articles/lm/92/art-3/t1.jpg

Il intervient lors de :

  • L’élection du routeur désigné et du routeur désigné de secours. Celle-ci se fait en comparant la priorité des routeurs (par défaut de 1, elle peut être manuellement configurée de 0 à 255). Le routeur ayant la plus grande priorité sera élu DR, le BDR sera le routeur avec la priorité immédiatement plus faible. En cas d’égalité, c’est le champ ID du routeur qui départagera les concurrents (l’ID la plus élevée assure l’élection du routeur). Le DR et le BRD garderont leurs rôles jusqu’à leur défaillance, même si un nouveau routeur avec une priorité plus élevée arrive sur le réseau.
  • La vérification de la connectivité entre deux routeurs voisins. Un paquet Hello est émis par défaut, et par chaque routeur, toutes les 30 secondes. Dans le cas où un routeur ne recevrait plus de paquets Hello de son voisin, pendant un intervalle de temps défini (appelé intervalle de mort), la liaison silencieuse serait déclarée comme rompue, et il en informerait ses autres voisins ainsi que le DR. D’autre part, lors de l’initialisation d’un routeur, celui-ci informe de sa présence et découvre ses voisins via ce protocole.
Les paquets HELLO sont émis sur l’adresse multicast 224.0.0.5. Le protocole d’échange Il est utilisé  lors de l’initialisation des routeurs. Une fois les voisins découverts, nous l’avons vu, grâce au protocole HELLO, un routeur doit initialiser sa base de données topologique. Cette initialisation se fait en plusieurs étapes :
  • ExStart : tout d’abord les routeurs négocient le mode de transfert. Qui sera le maître (master) et qui sera l’esclave (slave). Cette négociation s’effectue avec des messages OSPF de type 1 (HELLO packet)
  • ExChange : le routeur demande à ses voisins ou au DR de décrire leurs bases de données d’états de liens. Cette demande se fait par un message OSPF de type 2 (DBD pour DataBase Description packet) :

 

/img-articles/lm/92/art-3/t2.jpg

 

  • Loading : si le routeur n’a pas connaissance d’une (ou plusieurs) route(s) que l’on vient de lui envoyer, ou si le champ " Âge " est trop vieux, il construit une liste de demandes d’états de liens. Cette liste va servir au routeur pour demander des informations plus précises que celles qu’il vient de recevoir. Cette requête se fait par un message OSPF de type 3 (LSR pour Link State Request) :

 

 

/img-articles/lm/92/art-3/t3.jpg

 

La réponse à un LSR est un message OSPF de type 4 (LSU pour Link State Update) :

 

 

 

/img-articles/lm/92/art-3/t4.jpg

 

Les LSU contiennent eux-mêmes des messages d’annonce de l’état d’une liaison (LSA pour Link State Advertisement) :

 

 

 

 

/img-articles/lm/92/art-3/t5.jpg

 

Les LSA sont ensuite acquittés par des messages OSPF de type 5 (LSAck pour Link State Acknowledgment) qui reprennent uniquement les en-têtes de chacun d’eux :

 

 

 

 

/img-articles/lm/92/art-3/t6.jpg

 

  • Full Adjency : (complète adjacence) à la fin du Loading.
Voici un schéma pour clarifier les différentes étapes de l’initialisation d’un routeur OSPF :

 

 

 

 

/img-articles/lm/92/art-3/fig-2.jpg

 

Le protocole d’inondation (ou flooding) Ce protocole est utilisé par un routeur OSPF lorsqu’il détecte un changement d’état de lien. Le routeur en charge de l’annonce (celui qui détecte ce changement) notifie le DR et le BDR de ce changement (sur l’adresse 224.0.0.6). Le routeur désigné inondera la zone dont il a la charge par un LSU contenant l’information. Cette annonce se fait sur l’adresse multicast 224.0.0.5. La réception d’une telle annonce par un routeur OSPF entraîne un nouveau calcul du plus court chemin (SPF).

Conclusion

À travers cet article, nous avons vu qu’OSPF était un protocole relativement complexe, nécessitant non seulement des ressources matérielles importantes, mais également de bonnes connaissances et une bonne maîtrise de son fonctionnement avant de pouvoir être implémenté. En dépit de cette complexité de mise en œuvre, il augmentera sensiblement les performances, la stabilité et la fiabilité de votre réseau. OSPF est aujourd’hui l’un des protocoles de routage interne les plus utilisés, de par sa force et sa robustesse dont nous venons de parler, mais également grâce à sa licence basée sur des normes ouvertes, qui lui confère un avantage sur des protocoles propriétaires tel que l’EIGRP de Cisco.

 

 Liens

 

Retrouvez cet article dans : Linux Magazine 92

Il y a : 0 commentaire(s)

Donnez votre avis

Vous devez avoir ouvert une session pour écrire un commentaire.

Brèves
Édito : Linux Pratique Essentiel N°24
Édito : Linux Pratique HS N°23
Édito : GNU/Linux Magazine 146
Édito : GNU/Linux Magazine HS N°58
Édito : Open Silicium N°5
Communication
Linux Pratique HS 23 – Communiqué de presse
Linux Pratique Essentiel N°24 – Communiqué de presse
Gnu/Linux Magazine sponsor et partenaire de PROLOGIN
Linux Essentiel partenaire des Rencontres du Libre de Lion sur Mer (Normandie)
GNU/Linux Magazine HS 58 – Communiqué de presse
prochainement moteur de recherches des articles
 
:
:
Jours heures minutes secondes
En kiosque
Le tout nouveau Linux Pratique Essentiel est disponible dès maintenant chez votre marchand de journaux et sur notre site...

Lire la suite...

Le tout nouveau Linux Pratique est disponible dès maintenant chez votre marchand de journaux et sur notre site...

Lire la suite...

Le tout nouveau GNU/Linux Magazine est disponible dès maintenant chez votre marchand de journaux et sur notre site...

Lire la suite...

Le tout nouveau GNU/Linux Magazine HS est disponible dès maintenant chez votre marchand de journaux et sur notre site...

Lire la suite...

Le tout nouveau Open Silicium est disponible dès maintenant chez votre marchand de journaux et sur notre site...

Lire la suite...

Le tout nouveau Linux Pratique est disponible dès maintenant chez votre marchand de journaux et sur notre site...

Lire la suite...

Le tout nouveau Misc est disponible dès maintenant chez votre marchand de journaux et sur notre site...

Lire la suite...

Le tout nouveau GNU/Linux Magazine est disponible dès maintenant chez votre marchand de journaux et sur notre site...

Lire la suite...