Démystification du protocole OSPF (partie 1)

Dans cette série d’articles, nous allons démystifier le protocole OSPF afin de mieux comprendre son fonctionnement interne, comment il a été pensé par ses concepteurs dans les années 80, le rôle ainsi que les fonctions des LSA (Link State Advertisement), et aussi quelques bonnes pratiques en terme de design et d’implémentation.

La version actuelle d’OSPFv2 est décrite dans la RFC 2328 en 1997, une nouvelle RFC 5340 existe depuis 2008 qui prend en compte le support du protocole IPv6. (IPv6 supporté initialement en 1999 à travers la RFC 2740).

L’objectif final de ces articles est de familiariser le lecteur avec la base de données OSPF LSDB (Link State DataBase) consultable en IOS avec la commande « show ip ospf database », en effet, durant mes différents projets chez différents clients, très peu de personnes savent vraiment lire cette base de données riche en informations, identifier les types de LSA et finalement faire du troubleshooting avancé en cas d’incident sur ce protocole.

Introduction

Le protocole OSPF est un standard développé par  l’IETF (Internet Engineering Task Force) qui ne fonctionne sur la couche de transport IP (IPv4 et IPv6), par conséquent, il n’est pas possible d’implémenter ce protocole sur un autre média que l’IP. (contrairement au protocole ISIS qui embarque sa propre couche de transport).

Les protocoles OSPF et ISIS appartiennent à la famille des protocoles à état de lien « Link State Protocol », il existe beaucoup de points en commun entre ces deux protocoles, cependant, l’OSPF est souvent implémenté en Entreprise et l’ISIS chez les opérateurs « Service Provider ». pour plus d’informations, un article de notre blog permet de comparer ces deux protocoles, il est accessible à partir de ce lien.

Initialisation

Pour que le processus OSPF puisse être initialiser sur un routeur Cisco, il faut au préalable :

1. Définir un numéro de process entre 1 et 65535 : à noter que ce numéro reste local au routeur et que deux routeurs peuvent établir une adjacence OSPF ensemble même si le numéro de process n’est pas similaire. (contrairement aux protocoles  de routage EIGRP et BGP ou le numéro de process définit aussi par défaut le numéro d’AS).
2. Disposer au moins d’une adresse IP configuré sur le routeur : si aucune adresse IP n’est configuré sur le routeur, on obtient le message d’erreur :

%OSPF-4-NORTRID: OSPF process 1 failed to allocate unique router-id and cannot start

Ce message d’erreur indique que le process OSPF n’a pas réussi à démarrer par ce qu’il n’a pas réussi à allouer son identifiant « router-id », ce dernier permet d’identifier d’une façon unique un routeur (noeud) dans une arborescence OSPF, il peut être soit :

1. Définit manuellement avec la commande « router-id x.x.x.x » exécutée au sein du process OSPF.
2. Calculé automatiquement (mode par défaut) en suivant les règles suivantes :
   •  Adresse IP de la plus grande interface loopback.
   • Si aucune loopback n’est configurée alors c’est la plus grande adresse IP configurée sur le routeur.

En terme d’implémentation, les bonnes pratiques pour le router-id est de le fixer manuellement ce qui permet de sécuriser sa valeur et avoir toujours la même en cas de redémarrage du process (exemple ajout d’une nouvelle interface loopback avec un id plus grand).

Dans notre premier exemple, nous allons démarrer le process OSPF (process 1) sur un routeur Cisco R1 disposant d’une configuration IP très simple : une seule interface loopback lo0 avec l’adresse IP 1.1.1.1/32.

R1:
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
router ospf 1
router-id 1.1.1.1

Pour vérifier que le process a bien démarré avec l’identifiant « router-id » associé :

LSA : Link State Advertisement

Comme indiqué en introduction, le protocole OSPF appartient à la famille des protocoles de routage à état de lien (Link State), cela signifie que l’ensemble des routeurs au sein d’une même aire doivent avoir la même vision de la topologie du réseau et la même connaissance de l’ensemble des liens de l’aire.

Chaque routeur alimente la base de donnée de l’état des liens Link-State Database (LSDB) à l’aide de LSA « Link-State Advertisements », ensuite cette base de donnée est synchronisée pour être identique sur l’ensemble des routeurs au sein d’une même aire.

Dans notre premier exemple, aucun lien n’est encore annoncé en OSPF, par conséquent, la base de données LSDB est vide :

OSPF LSA Type 1

Les LSA Type 1 (ou LSA router) sont générés par chaque routeur appartenant à une aire OSPF pour annoncer l’ensemble des liens sur lesquels il est raccordé, il peut s’agir d’interface loopback, d’interface en point à point (ex Serial), ou interface Ethernet.

Dans la suite, nous allons nous intéresser à chaque type d’interface et voir comment cela se représente dans la base LSDB.

Commençons d’abord par annoncer l’interface loopback0 dans l’aire OSPF 0 comme représenté sur le schéma ci-dessous :

En terme de configuration, pour annoncer l’interface loopback0 dans l’aire 0 en LSA Type 1, on peut le faire de deux façons sur un routeur Cisco :

Méthode 1 : au niveau de l’interface :

interface Loopback0
ip ospf 1 area 0

Méthode 2 : au niveau du process OSPF avec un mask réseau inversé (wildcard)  :

router ospf 1
network 1.1.1.1 0.0.0.0 area 0

Observons le contenu de la database OSPF dans cette configuration :

=> La base LSDB ne contient qu’un seul LSA type 1 (Router link LSA) annoncé par le routeur 1.1.1.1.

Pour avoir plus de détails sur les LSA Type 1 annoncé par le routeur 1.1.1.1 :

Number of Links : indique le nombre liens OSPF sur lesquelles le routeur R1 est connecté.

Stub Network : indique que le routeur est seul sur le lien, aucune adjacence OSPF n’est établit sur ce lien.

=> La base de donnée LSDB est alimentée avec un LSA type 1 correspondant au lien 1.1.1.1/32 (interface loopback).

=> Le metric par défaut associé à une interface de type loopback est 1.

Nous allons ajouter une deuxième interface serial se2/0 (10.10.12.1/24) et l’annoncer dans l’OSPF comme indiqué dans le schéma ci-dessous :

En terme de configuration :

interface serial2/0
ip address 10.10.12.1 255.255.255.0
ip ospf 1 area 0
no shut

Observons maintenant le contenu de la database OSPF dans cette configuration :

=> La base LSDB ne contient toujours que des LSA type 1 (Router link LSA) annoncé par le routeur 1.1.1.1.
=> Le routeur 1.1.1.1 est raccordé sur 2 liens (loopback et serial).

Pour avoir plus de détails sur les LSA Type 1 annoncé par le routeur 1.1.1.1 :

=> La base de donnée LSDB est alimentée avec un nouveau LSA type 1 associé au nouveau lien 10.10.12.0/24.
=> Le metric par défaut associé à une interface de type Serial est 64, ce dernier est calculé par défaut à partir de la bande passante associé à l’interface (exemple pour Serial : 1544 Kbit/sec)
=> La liaison Serial 2/0 est annoncée en « Stub Network » dans la base LSDB : aucune adjacence OSPF n’est encore établi sur ce lien.

Nous allons rajouter une troisième interface FastEthernet0/0 (10.10.134.1/24) et l’annoncer dans l’OSPF  comme indiqué dans le schéma ci-dessous :

En terme de configuration :

interface FastEthernet0/0
ip address 10.10.134.1 255.255.255.0
ip ospf 1 area 0
no shut

Observons le contenu de la database OSPF dans cette configuration :

=> La base LSDB ne contient toujours que des LSA type 1 (Router link LSA) annoncés par le routeur 1.1.1.1
=> Le routeur 1.1.1.1 est raccordé sur 3 liens (loopback, Serial et FastEthernet).

Pour avoir plus de détails sur les LSA Type 1 annoncé par le routeur 1.1.1.1 :

=> La base de donnée LSDB est alimentée avec un nouveau LSA type 1 associé au nouveau lien 10.10.134.0/24.
=> Le metric par défaut associé à une interface de type FastEthernet est 1, ce dernier est calculé par défaut à partir de la bande passante associé à l’interface (exemple pour FastEthernet : 100 Mbit/sec)
=> La liaison FastEthernet0/0 est annoncée en « Stub Network » dans la base LSDB : aucune adjacence OSPF n’est encore établi sur ce lien.

Etablissement des relations d’adjacences OSPF

Pour échanger les LSA entre les routeurs, ces derniers établissent des relations d’adjacence avec leur voisins directement connectés en envoyant des message hello à intervalle régulier, la fréquence des envois dépend de la nature du média (exemple sur un réseau Broadcast ou Serial (hello 10 sec, dead 40 sec). Ces valeurs par défaut restent cependant totalement configurables.

Ces LSA sont propagés ensuite de proche en proche à tous les routeurs appartenant à la même aire, la base de données LSDB est ainsi construite et synchronisée sur l’ensemble de ces routeurs.

Chaque routeur exécute ensuite l’algorithme de Djisktra : Shortest Path First (SPF) pour déterminer la route la plus courte en terme de métrique vers chaque réseau connu dans la base de donnée.

Dans la suite, nous allons configurer un routeur R2 raccordé en serial avec R1 et implémenter le protocole OSPF sur ces interfaces lo0 (2.2.2.2/32) et se2/0 (10.10.12.2/24) :

En terme de configuration :

R2 :

interface loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface serial2/0
ip address 10.10.12.2 255.255.255.0
ip ospf 1 area 0
no shut
!
router ospf 1
router-id 2.2.2.2

Pour vérifier les paramètres OSPF associés à une interface :

Les messages hellos sont envoyés toutes les 10 secondes sur l’adresse multicast 224.0.0.5 (IP-PROTO 89)  comme le montre le debug ci-dessous :

Pour vérifier que les adjacences OSPF sont bien opérationnelles entre R1 et R2 :

=> Le routeur R2 (2.2.2.2) est voisin du routeur R1 sur le lien Serial2/0 (10.10.12.0/24).

Observons de nouveau le contenu de la database OSPF dans ce cette configuration :

=> La base LSDB ne contient toujours que des LSA type 1 (Router link LSA) annoncé par les routeur R1(1.1.1.1) et R2 (2.2.2.2).

Pour avoir plus de détails sur les LSA Type 1 annoncé par le routeur 1.1.1.1 :

=> Sur un lien point à point, il existe un seul point de sortie, par conséquent, le lien serial (10.10.12.0/24) reste affiché dans la base LSDB en état « Stub Network ».
=> La base de donnée LSDB est alimentée avec un nouveau LSA type 1 « another Router (point-to-point) », ce LSA très spécial est un LSA de vérification et de validation, il permet en effet de vérifier l’identité des routeurs connectés sur un lien point à point (p2p) : chaque routeur génère ce LSA « extra » pour indiquer son IP de raccordement ainsi que l’identité de son unique voisin sur ce lien, par ce mécanisme, il est ainsi possible de vérifier l’identité des routeurs connectés en point à point dans une topologie OSPF.
=> Ce LSA de validation est aussi appelé un « LSA Type 1 neighbor ».

Dans la suite, nous allons maintenant raccorder le routeur R1 sur un média broadcast (LAN) et établir des adjacences OSPF sur l’aire 0 avec deux nouveaux voisins R3 et R4 comme indiqué dans le schéma ci-dessous :

En terme de configuration :

R3:

interface loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 10.10.134.3 255.255.255.0
ip ospf 1 area 0
no shut
!
router ospf 1
router-id 3.3.3.3

R4:

interface loopback0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 10.10.134.4 255.255.255.0
ip ospf 1 area 0
no shut
!
router ospf 1
router-id 4.4.4.4

Pour vérifier que les adjacences OSPF sont bien opérationnelles entre R1 et R3 et R4 :

Sur un support broadcast, si plusieurs routeurs établissent des adjacences OSPF entre eux et que chaque routeur doit ensuite annoncer ses LSA à l’ensemble de ses voisins, cela qui peut générer beaucoup d’échanges « control plane » et impacter fortement les performances du réseau.

Pour optimiser et diminuer ces échanges de contrôle protocolaire, un routeur du lien broadcast est élu DR (Designated Router) et aura pour mission de relayer les échanges LSA entre les différents voisins, un BDR (Backup Designated Router) est aussi élu en secours du DR si indisponibilité de ce dernier.

Par conséquent, les voisins « DR Other » établissent des relations d’adjacence OSPF uniquement avec les « DR » et « BDR« .

La cinématique des échanges est la suivante :

1. Le voisin envoi les LSU (LS Update) vers le DR sur l’adresse multicast 224.0.0.6.
2. Le DR relai ces LSU aux autres voisins sur l’adresse multicast 224.0.0.5
3. Les acquittements de bonne réception des LSA (LSA Acknowledge) sont envoyés sur l’adresse multicast 224.0.0.5

Observons de nouveau le contenu de la database OSPF dans cette configuration :

=> La base LSDB contient des nouveaux LSA type 1 « Router link LSA » annoncés par les routeurs R3(3.3.3.3) et R4 (4.4.4.4).
=> Un nouveau LSA type 2 « Net Link States » est présent dans la base, nous reviendrons sur ce LSA plus loin dans cet article.

Nous allons voir plus de détails sur les LSA Type 1 annoncé par le routeur 1.1.1.1 :

=> Le lien 10.10.134.0/24 contient maintenant de nouveaux voisins OSPF (R1, R3 et R3), par conséquent, il n’est plus affiché dans la LSDB en « Stub Network », il passe à « Transit Network ».
=> Sur un lien de type « Transit Network », il y a toujours un DR responsable de relayer les LSA type 1 entre les voisins sur ce même lien.

Les LSA Type 1 annoncé par le routeur 3.3.3.3 :

Le routeur R3 annonce deux LSA Type 1:
=> Un LSA « Stub Network » associé à son interface loopback 3.3.3.3/32
=> Un LSA « Transit Network » associé à son interface FastEthernet0/0 (10.10.134.3/24)

Les LSA Type 1 annoncé par le routeur 4.4.4.4 :

Le routeur R4 annonce deux LSA Type 1:
=> Un LSA « Stub Network » associé à son interface loopback 4.4.4.4/32
=> Un LSA « Transit Network » associé à son interface FastEthernet0/0 (10.10.134.4/24).

OSPF LSA Type 2

On a vu  dans les sections précédentes que pour les liens en « point à point », un LSA de validation de Type 1 « LSA neighbor » est généré par chaque routeur de la liaison afin d’indiquer son IP de raccordement ainsi que l’identité de son voisin unique sur ce lien.

Sur un média de type broadcast ou plusieurs routeurs établissent des adjacences OSPF, il faut aussi avoir ce mécanisme de vérification et de validation du lien, il faut être en mesure d’identifier l’ensemble des routeurs d’une liaison de type « Transit Network », si on reconduit le même principe que les liaisons en point à point, on va se retrouver avec un nombre très important de « LSA Type 1 neighbor » ou chaque voisin doit indiquer son IP sur la liaison ainsi que l’ensemble des voisins dont il a connaissance sur cette liaison, cette méthode n’est pas optimale.

Pour permettre d’apporter cette validation de voisins sur un lien de type « Transit Network », les concepteurs du protocole OSPF ont défini un nouveau LSA de Type 2 « Network », ce LSA est généré uniquement par le Designated Routeur (DR) et a pour mission de valider l’ensemble des routeurs connectés sur un lien.

Pour avoir plus d’informations sur le LSA Type 2 dans la base de données LSDB :

Contrairement au LSA Type 1 qui structure l’arborescence du réseau en indiquant l’ensemble des liens raccordés sur un routeur, le LSA Type 2 est tout simplement un LSA de vérification et de validation généré par le DR et qui permet d’indiquer l’ensemble des routeurs attachés sur un lien.

D’autre part, le LSA de Type 2 n’est nécessaire que pour les liaisons broadcast disposant de plusieurs routeurs (>2), sur les liaisons Ethernet (/30 ou /31) disposant uniquement de deux routeurs, il n’est pas nécessaire de disposer d’un LSA de type 2.

En terme d’implémentation et de design, il est très recommandé de changer le mode par défaut des liaisons Ethernet de « Broadcast » à « point to point » si cette liaison ne dispose que de deux adjacences OSPF et ne sera pas amener dans le futur à accueillir de nouveaux voisins (exemple liaison Ethernet en /30 ou /31), cela permet d’apporter les avantages suivants :

• Suppression des mécanismes d’élection de DR/BDR, ce qui permet d’établir les adjacences OSPF plus vite et construire l’arborescence OSPF rapidement (meilleure convergence du réseau).
• Optimisation de la table LSDB par la suppression des LSA Type 2.

Conclusions

Pour conclure cette première série d’articles sur le protocole OSPF, les points importants à noter sont :

• Sur une liaison de type point à point (exemple Serial), uniquement des LSA Type 1 « Router Link States » sont présents dans la LSDB, en effet, chaque routeur génère deux LSA type 1 pour cette liaison :
  • Un LSA « Stub Network » permettant d’indiquer le lien sur lequel il est raccordé avec le métrique associé.
  • Un LSA « Neighbor » de validation permettant au router d’indiquer son IP sur la liaison ainsi que l’identité de son voisin direct.
• Sur une liaison de type broadcast (exemple Ethernet), les LSA Type 1 « Router Link States » et LSA Type 2 « Net Link States » sont présents dans la LSDB :
  
  • Un LSA Type 1 en « Transit Network » généré par chaque routeur et permettant d’indiquer son IP sur ce lien avec le métrique OSPF associé.
  • Un LSA Type 2 « Net Link States » généré uniquement par le DR et permettant de valider l’ensemble des voisins disponible sur la liaison.

J’espère qu’avec cet article, les LSA OSPF Type 1 et Type 2 n’ont plus de mystère pour vous, dans les prochains articles nous allons aborder le reste des LSA ( 3,4,5 et 7) et expliquer leur rôle et comment ils sont générés dans une architecture OSPF.

Si vous avez des questions, n’hesitez pas à laisser un message ou nous contacter à l’adresse : contact@mhd-experts.com.