Protocole OSPF à zone unique

Protocole OSPF à zone unique

Le protocole OSPF (Open Shortest Path First) est un protocole de routage à état de liens qui
a été développé pour remplacer le protocole de routage à vecteur de distance RIP. Le
protocole RIP était un protocole de routage acceptable au tout début des réseaux et
d'Internet. Cependant, le fait que protocole RIP se basait uniquement sur le nombre de sauts
comme seule métrique pour déterminer la meilleure route est rapidement devenu
problématique. L'utilisation du nombre de sauts n'est pas adaptée aux réseaux de grande
taille avec plusieurs chemins de vitesses variables. Le protocole OSPF présente des avantages
considérables par rapport au protocole RIP car il offre une convergence plus rapide et
s'adapte mieux aux réseaux de plus grande taille.

OSPF est un protocole de routage sans classe qui utilise le concept de zones pour son
évolutivité. Ce chapitre décrit l'implémentation et la configuration de base d'OSPF à zone
unique.

Exercice : Les sous-marins peuvent-ils nager ?

Scénario

Edsger Wybe Dijkstra était un programmeur et un physicien théoricien de renom. L'une de

ses citations les plus célèbres était : « Se demander si les ordinateurs sont capables de
réfléchir, ça revient à se demander si les sous-marins peuvent nager ». Les travaux de
Dijkstra ont été appliqués, entre autres, aux protocoles de routage. Il a créé l'algorithme SPF
pour le routage de réseau.
Ouvrez à présent le fichier PDF fourni pour cet exercice et répondez aux questions de
réflexion. Enregistrez votre travail.

Comparez vos réponses avec deux autres participants.

Au terme de cet exercice, avez-vous une idée de la façon dont le protocole OSPF
fonctionne ?

Exercice en classe : les sous-marins peuvent-ils nager ? Instructions

Caractéris
tiques du protocole OSPF
Open Shortest Path First
Comme illustré dans la Figure 1, la version 2 du protocole OSPF (OSPFv2) est disponible pour
IPv4 tandis que la version 3 (OSPFv3) est disponible pour IPv6.

Cliquez sur les dates dans la Figure 2 pour consulter les événements historiques liés au
protocole OSPF.

Le développement initial du protocole OSPF a débuté en 1987, mené par le groupe de travail
OSPF de l'IETF (Internet Engineering Task Force). À cette époque, Internet était un réseau
dédié à l'enseignement et à la recherche fondé par le gouvernement des États-Unis.
En 1989, la spécification du protocole OSPFv1 fut publiée dans le document RFC 1131. Deux
mises en œuvre furent rédigées. L'une fut développée pour s'exécuter sur des routeurs,
l'autre sur des stations de travail UNIX. Cette dernière devint par la suite un processus UNIX
très répandu connu sous le nom de GATED. OSPFv1 était un protocole de routage
expérimental qui ne fut jamais déployé.

En 1991, OSPFv2 fut présenté dans le document RFC 1247 par John Moy. Ce protocole offrait
des améliorations techniques significatives par rapport à OSPFv1. Il est sans classe par
conception ; par conséquent, il prend en charge VLSM et CIDR.

Au même moment, alors que le protocole OSPF faisait son apparition, ISO travaillait sur un
protocole de routage à état de liens de leur cru, le protocole IS-IS (Intermediate System-to-
Intermediate System). IETF choisit OSPF comme protocole IGP (Interior Gateway Protocol)
recommandé.

En 1998, la spécification OSPFv2 fut mise à jour dans le document RFC 2328, qui est toujours
le document RFC d'actualité pour le protocole OSPF.

En 1999, OSPFv3 pour IPv6 a été publié dans le document RFC 2740. Le protocole OSPF pour
IPv6, créé par John Moy, Rob Coltun et Dennis Ferguson, n'est pas seulement une nouvelle
implémentation de protocole pour IPv6, mais également une réécriture importante du
fonctionnement du protocole.

En 2008, OSPFv3 a été mis à jour dans le document RFC 5340 comme protocole OSPF pour
IPv6.

Remarque : dans ce chapitre, sauf lorsqu'il est explicitement identifié comme OSPFv2 ou
OSPFv3, le terme OSPF est utilisé pour indiquer les concepts qui sont partagés par les deux.

Les caractéristiques du protocole OSPF, comme illustré dans la Figure 1, incluent :

  Sans classe - Il est sans classe par conception ; par conséquent, il prend en charge
VLSM et CIDR.

 Efficace - Les changements de routage déclenchent des mises à jour de routage (pas
de mises à jour régulières). Il utilise l'algorithme SPF pour déterminer le meilleur
chemin.

 Convergence rapide - Il diffuse rapidement les modifications apportées au réseau.

 Évolutif - Il fonctionne bien sur les petits et grands réseaux. Les routeurs peuvent
être regroupés en zones pour prendre en charge un système hiérarchique.

 Sécurisé - Il prend en charge l'authentification MD5 (Message Digest 5). Une fois
activés, les routeurs OSPF acceptent uniquement les mises à jour de routage chiffrées
des homologues avec le même mot de passe pré-partagé.

La distance administrative (AD) correspond à la fiabilité (ou préférence) de l'origine de la

route. OSPF a une distance administrative par défaut de 110. Comme illustré
dans la Figure 2, le protocole OSPF est préférable à IS-IS et RIP.

Tous les protocoles de routage partagent des composants similaires. Ils utilisent tous des
messages de protocole de routage pour échanger les informations de routage. Les messages
permettent de renforcer les structures de données, qui sont ensuite traitées au moyen d'un
algorithme de routage.
Les trois composants principaux du protocole de routage OSPF incluent :

Structures des données

Le protocole OSPF crée et met à jour trois bases de données : (voir la Figure 1).

 Base de données de contiguïté - Crée la table de voisinage

 Base de données d'états de liens (LSDB) - Crée la table topologique

 Base de données de réacheminement - Crée la table de routage

Ces tables contiennent une liste des routeurs voisins permettant d'échanger les informations

de routage, et elles sont conservées et mises à jour dans la mémoire

vive.
Messages des protocoles de routage

Le protocole OSPF échange des messages permettant de transmettre des informations de

routage au moyen de cinq types de paquets. Ces paquets, comme illustré dans la Figure 2,
sont les suivants :

 Paquet Hello

 Paquet DBD de description de base de données

 Paquet LSR de demande d'état de liens

 Paquet LSU de mise à jour d'état de liens

 Paquet LSAck d'accusé de réception d'état de liens

Ces paquets servent à détecter les routeurs voisins et à échanger des informations de
routage pour garantir l'exactitude des informations relatives au réseau.

Algorithme

Le processeur traite les tables devoisinage et de topologie à l'aide de

l'algorithme SPF de Dijkstra. L'algorithme SPF est basé sur le coût cumulé permettant
d'atteindre une destination.

L'algorithme SPF crée une arborescence SPF en plaçant chaque routeur à la racine de
l'arborescence et en calculant le plus court chemin vers chaque nœud. L'arborescence SPF
est ensuite utilisée pour calculer les meilleures routes. Le protocole OSPF insère les
meilleures routes dans la base de données de réacheminement, qui est utilisée pour créer la
table de routage.
Pour mettre à jour les informations de routage, les routeurs OSPF effectuent le processus de
routage à état de liens générique qui suit afin d'atteindre un état de convergence :

1. Établir les contiguïtés de voisinage (Figure 1) - Les routeurs compatibles OSPF doivent se
reconnaître mutuellement sur le réseau avant de pouvoir partager des informations. Un
routeur compatible OSPF envoie des paquets Hello à partir des interfaces compatibles OSPF
pour déterminer si des voisins se trouvent sur ces liens. Si un voisin est présent, le routeur
compatible OSPF tente d'établir une contiguïté de voisinage avec celui-ci.

2. Échanger des paquets LSA (Link-State Advertisement) (Figure 2) - Une fois que les
contiguïtés ont été établies, les routeurs échangent ensuite des paquets LSA. Les LSA
contiennent l'état et le coût de chaque lien connecté directement. Les routeurs transmettent
leurs LSA aux voisins contigus. Les voisins contigus recevant des LSA les diffusent
immédiatement aux autres voisins connectés directement, jusqu'à ce que tous les routeurs
de la zone aient tous les LSA.

3. Établir la table topologique (Figure 3) - Une fois les paquets LSA reçus, les routeurs
compatibles OSPF créent la table topologique (LSDB) sur base des paquets LSA reçus. Cette
base de données se retrouve alors à stocker toutes les informations relatives à la topologie
du réseau.
4. Exécuter l'algorithme SPF (Figures 4 et 5) - Les routeurs exécute ensuite l'algorithme SPF.
Les engrenages dans la figure sont utilisés pour indiquer le fonctionnement de
l'algorithme SPF. L'algorithme SPF crée l'arborescence SPF.

Le contenu de l'arborescence SPF de R1 est illustré dans la Figure 6.

Les meilleurs chemins sont insérés dans la table de routage à partir de l'arborescence SPF.
Les décisions de routage sont prises en fonction des entrées de la table de routage.

Pour une efficacité et une évolutivité supérieures, le protocole OSPF prend en charge le
routage hiérarchique à l'aide de zones. Une zone OSPF est un groupe de routeurs qui
partagent les mêmes informations d'état de liens dans leurs LSDB.

La téléphonie OSPF peut être mise en œuvre de deux manières différentes :

 OSPF à zone unique - Dans la Figure 1, tous les routeurs sont situés dans une zone
appelée zone fédératrice (zone 0).

 OSPF multizone - Dans la Figure 2, le protocole OSPF est mis en œuvre à l'aide de
plusieurs zones, de façon hiérarchique. Toutes les zones doivent se connecter à la
zone de réseau fédérateur (zone 0). Les routeurs reliant les zones sont appelés
routeurs ABR (Area Border Router).

Avec le protocole OSPF multizone, OSPF peut diviser un grand système autonome (AS) en
zones plus petites, pour prendre en charge le routage hiérarchique. Avec le routage
hiérarchique, le routage s'effectue toujours entre les zones (routage interzone), alors que la
plupart des opérations de routage exigeant beaucoup de temps du processeur, comme le
recalcul de la base de données, sont conservées dans une zone.

Par exemple, chaque fois qu'un routeur reçoit de nouvelles informations relatives à une
modification topologique dans la zone (notamment l'ajout, la suppression ou la modification
d'un lien), le routeur doit relancer l'algorithme SPF, créer une nouvelle arborescence SPF et
mettre à jour la table de routage. L'algorithme SPF est exigeant en temps processeur et le
temps qu'il prend pour le calcul dépend de la taille de la zone.

Remarque : les modifications de topologie sont distribuées aux routeurs des autres zones
dans un format de vecteur de distance. En d'autres termes, ces routeurs mettent
uniquement à jour leurs tables de routage et ne doivent pas réexécuter l'algorithme SPF.

Un nombre excessif de routeurs dans une zone rendrait les LSDB très volumineuses et
augmenterait la charge sur le processeur. Par conséquent, l'organisation des routeurs en
zones partitionne efficacement une base de données potentiellement volumineuse en bases
de données plus petites et plus faciles à gérer.

Les possibilités de topologie hiérarchique du protocole OSPF multizone présentent les

avantages suivants :

 Réduction de la taille des tables de routage - Moins d'entrées dans la table de

routage parce que les adresses réseau peuvent être récapitulées entre les zones. La
récapitulation de route n'est pas activée par défaut.

 Réduction de la surcharge liée aux mises à jour d'état de liens - Réduit les exigences
de traitement et de mémoire.

 Réduction de la fréquence des calculs SPF - Recherche l'impact d'une modification

topologique au sein d'une zone. Par exemple, l'impact des mises à jour de routage
est limité parce que l'inondation des paquets LSA s'arrête à la limite de zone.

La Figure 3 illustre ces avantages.

Par exemple, R2 est un routeur ABR pour la zone 51. En tant que routeur ABR, il
récapitulerait les routes de la zone 51 dans la zone 0. Lorsque l'un des liens récapitulés
échoue, les paquets LSA sont échangés au sein de la zone 51 uniquement. Les routeurs de la
zone 51 doivent exécuter de nouveau l'algorithme SPF pour identifier les meilleures routes.
Cependant, les routeurs de la zone 0 et de la zone 1 ne reçoivent aucune mise à jour ; par
conséquent, ils n'exécutent pas l'algorithme SPF.

Ce chapitre porte sur le protocole OSPF à zone unique.

Messages OSPF
Les messages OSPF transmis sur un lien Ethernet contiennent les informations suivantes :

 En-tête de trame Ethernet de liaison de données - Identifie les adresses MAC de

multidiffusion de destination 01-00-5E-00-00-05 ou 01-00-5E-00-00-06. (Figure 1)
  En-tête de paquet IP - Identifie le champ 89 du protocole IPv4 qui indique qu'il s'agit
d'un paquet OSPF. Il identifie également l'une des deux adresses de
multidiffusion OSPF : 224.0.0.5 ou 224.0.0.6 OSPF. (Figure 2)

 En-tête de paquet OSPF - Identifie le type de paquet OSPF, l'ID du routeur et l'ID de
zone. (Figure 3)

 Données spécifiques au type de paquet OSPF - Contient des informations sur le type
de paquet OSPF. Le contenu varie en fonction du type de paquet. Dans ce cas, il s'agit
d'un en-tête IPv4. (Figure 4)

Le

protocole OSPF utilise des paquets LSP (Link-State Packet) pour établir et maintenir des
contiguïtés de voisinage, ainsi que pour échanger des mises à jour de routage.

La figure illustre les cinq types de paquets LSP utilisés par le protocole OSPF. Chacun d'eux a
un objectif spécifique dans le processus de routage OSPF :

 Type 1 : paquet Hello - Permet d'établir et de maintenir la contiguïté avec d'autres

routeurs OSPF.

 Type 2 : paquet DBD (Database Description) - Contient une liste abrégée de la LSDB
du routeur expéditeur et est utilisé par les routeurs destinataires à des fins de
comparaison avec la LSDB locale. La LSDB doit être identique sur tous les routeurs à
état de liens au sein d'un secteur pour créer une arborescence SPF précise.

 Type 3 : paquet LSR (Link-State Request) - Les routeurs destinataires peuvent alors
demander plus d'informations sur une entrée quelconque dans la description de base
de données en envoyant un paquet LSR.

 Type 4 : paquet LSU (Link-State Update) - Utilisé pour répondre aux paquets LSRs et
pour annoncer de nouvelles informations. Les paquets LSU contiennent sept types de
paquets LSA.
  Type 5 : paquet LSAck (Link-State Acknowledgment) - Lorsqu'un paquet LSU est
reçu, le routeur envoie un paquet LSAck pour confirmer la réception du paquet LSU.
Le champ de données du paquet LSAck est vide.

Paquet Hello

Le paquet de type 1 du protocole OSPF correspond au paquet Hello. Les paquets Hello sont
utilisés pour :

 Détecter les voisins OSPF et établir des contiguïtés

 Annoncer les paramètres sur lesquels les deux routeurs doivent s'accorder pour
devenir voisins

 Définir le routeur désigné (DR) et le routeur désigné de secours (BDR) sur les réseaux
à accès multiple, de type Ethernet et Frame Relay Les liens point-à-point ne
nécessitent pas de routeur DR ou BDR.

La figure affiche les champs contenus dans les paquets Hello de type 1. Les champs
importants indiqués dans le schéma incluent :

 Type - Identifie le type de paquet. Un (1) indique un paquet Hello. La valeur 2

identifie un paquet DBD, 3 un paquet LSR, 4 un paquet LSU et 5 un paquet LSAck.

 ID du routeur - Valeur 32 bits exprimée en notation décimale à point (une

adresse IPv4) utilisée pour identifier le routeur d'origine de façon unique.

 ID de zone - Zone d'où provient le paquet.

  Masque réseau - Masque de sous-réseau associé à l'interface émettrice.

 Intervalle Hello - Indique la fréquence en secondes à laquelle un routeur envoie des

paquets Hello. L'intervalle Hello par défaut sur des réseaux à accès multiple est de
10 secondes. Ce minuteur doit être identique sur les routeurs voisins. Dans le cas
contraire, aucune contiguïté n'est établie.

 Priorité du routeur - Utilisé dans une sélection DR/BDR. La priorité par défaut pour
tous les routeurs OSPF correspond à 1, mais elle peut être changée manuellement en
une valeur comprise entre 0 et 255. Plus la valeur est élevée, plus le routeur devient
le routeur désigné sur le lien.

 Intervalle Dead - Durée en secondes pendant laquelle le routeur attend des

informations d'un voisin avant de le déclarer hors service. Par défaut, l'intervalle
Dead du routeur est quatre fois plus long que l'intervalle Hello. Ce minuteur doit être
identique sur les routeurs voisins. Dans le cas contraire, aucune contiguïté n'est
établie.

 Routeur désigné (DR) - ID du routeur désigné.

 Routeur désigné de secours (BDR) - ID du routeur désigné de secours.

 Liste des voisins - Liste qui identifie les ID de routeur de tous les routeurs adjacents.

Cliquez sur chacun des champs en surbrillance dans la figure pour plus d'informations.
Comme illustré dans la figure, les paquets Hello du protocole OSPF sont transmis à l'adresse
de multidiffusion 224.0.0.5 dans IPv4 et FF02::5 dans IPv6 (tous les routeurs OSPF) toutes
les :

 10 secondes (valeur par défaut dans les réseaux à accès multiple et point à point)

 30 secondes (valeur par défaut sur les réseaux à accès multiple sans diffusion
[NBMA] ; par exemple, à relais de trames)

L'intervalle Dead correspond au laps de temps pendant lequel le routeur attend de recevoir
un paquet Hello avant de déclarer le voisin hors service. Si l'intervalle Dead arrive à
échéance avant que les routeurs ne reçoivent un paquet Hello, le protocole OSPF supprime
le voisin de sa LSDB. Le routeur diffuse vers la LSDB les informations concernant le voisin
hors service vers toutes les interfaces compatibles OSPF.

Cisco utilise par défaut le quadruple de l'intervalle Hello :

 40 secondes (valeur par défaut dans les réseaux à accès multiple et point à point)

 120 secondes (valeur par défaut sur les réseaux NBMA ; par exemple, à relais de
trames)

Les routeurs échangent initialement des paquets DBD de type 2, ce qui correspond à une
liste abrégée de la LSDB du routeur expéditeur qui est utilisée par les routeurs destinataires
à des fins de vérification sur base de la LSDB locale.
Un paquet LSR de type 3 est utilisé par les routeurs destinataires pour demander plus
d'informations sur une entrée dans la DBD.

Le paquet LSU de type 4 est utilisé pour répondre à un paquet LSR.

Les paquets LSU sont également utilisés pour transmettre des mises à jour de routage OSPF,
telles que des modifications de liens. Plus spécifiquement, un paquet LSU peut contenir
11 types différents de paquets LSA OSPFv2, comme indiqué dans la figure. OSPFv3 a
renommé plusieurs de ces paquets LSA et comporte également deux paquets LSA
supplémentaires.

Remarque : la différence entre les termes LSU et LSA n'est pas évidente, car ils sont souvent
utilisés l'un pour l'autre. Toutefois, un paquet LSU contient un ou plusieurs paquets LSA.
Fonctionnement d'OSPF
Lorsqu'un routeur OSPF est initialement connecté à un réseau, il tente de :

 Créer des contiguïtés avec ses voisins

 Procéder à l'échange des informations de routage

 Calculer les meilleures routes

 Converger

OSPF passe par plusieurs états en tentant d'atteindre la convergence :

 État Down

 État Init

 État Two-Way

 État ExStart

 État Exchange

 État Loading

 État Full

Cliquez sur les zones bleues dans la figure pour plus d'informations.
 L
orsque le protocole OSPF est activé sur une interface, le routeur doit déterminer s'il existe
un autre voisin OSPF sur le lien. Pour ce faire, le routeur transmet un paquet Hello qui
contient son ID de routeur à partir de toutes les interfaces compatibles OSPF. L'ID de routeur
OSPF est utilisé par le processus OSPF pour identifier de façon unique chaque routeur de la
zone OSPF. Un ID de routeur est une adresse IP qui permet d'identifier un routeur spécifique
parmi ses homologues OSPF.

Lorsqu'un routeur voisin compatible OSPF reçoit un paquet Hello avec un ID de routeur qui
ne figure pas dans sa liste de voisins, le routeur destinataire tente d'établir une contiguïté
avec le routeur initiateur.

Voir R1 dans la Figure 1. Lorsqu'OSPF est activé, l'interface compatible Gigabit Ethernet 0/0
passe de l'état Down à l'état Init. R1 commence à envoyer des paquets Hello à partir de
toutes les interfaces compatibles OSPF pour détecter les voisins OSPF et développer des
contiguïtés avec ceux-ci.

Dans la Figure 2, R2 reçoit le paquet Hello de R1 et ajoute l'ID du routeur R1 à sa liste de

voisins. R2 envoie un paquet Hello à R1. Le paquet contient l'ID du routeur R2 et l'ID du
routeur R1 dans sa liste de voisins sur la même interface.
Dans la Figure 3, R1 reçoit le paquet Hello et ajoute l'ID du routeur R2 dans sa liste de voisins
OSPF. Il remarque également son propre ID de routeur dans la liste de voisins du
paquet Hello. Lorsqu'un routeur reçoit un paquet Hello avec son ID de routeur répertorié
dans la liste des voisins, le routeur passe de l'état Init à l'état Two-Way.

L'action effectuée dans l'état Two-Way dépend du type d'interconnexion entre les routeurs
adjacents :

 Si les deux voisins contigus sont interconnectés via un lien point à point, alors ils
passent immédiatement de l'état Two-Way à la phase de synchronisation de base de
données.

 Si les routeurs sont interconnectés via un réseau Ethernet commun, alors un routeur
désigné (DR) et un routeur désigné de secours (BDR) doivent être choisis.

Étant donné que R1 et R2 sont interconnectés via un réseau Ethernet, une sélection du
routeur DR et du routeur BDR a lieu. Comme illustré dans la Figure 4, R2 devient le
routeur DR et le routeur R1 est le routeur BDR. Ce processus se produit uniquement sur les
réseaux à accès multiple tels que les réseaux locaux (LAN) Ethernet.

Les paquets Hello sont continuellement échangés pour mettre à jour les informations
relatives au routeur.

Pourquoi une sélection du routeur DR et du routeur BDR est-elle nécessaire ?

Les LSA sur les réseaux à accès multiple peuvent présenter deux difficultés pour OSPF :

 Création de contiguïtés multiples - Les réseaux Ethernet pourraient éventuellement

interconnecter de nombreux routeurs OSPF via un lien commun. La création de
 contiguïtés avec chaque routeur est inutile et non souhaitée. Elle se traduirait par un
nombre excessif de paquets LSA circulant entre les routeurs du même réseau.

 Diffusion massive de paquets LSA - Les routeurs à état de liens diffusent leurs
paquets LSA chaque fois que le protocole OSPF est initialisé, ou lorsqu'une
modification topologique se produit. Cette diffusion peut devenir excessive.

Pour mieux appréhender le problème des contiguïtés multiples, nous devons étudier une
formule :

Pour un nombre quelconque de routeurs (indiqué par n) sur un réseau à accès multiples, il y
a n (n – 1) / 2 contiguïtés.

La Figure 1 illustre une topologie à cinq routeurs, tous rattachés au même réseau à accès
multiple Ethernet. S'il n'existe aucun mécanisme permettant de réduire le nombre de
contiguïtés, ces routeurs formeront, ensemble, 10 contiguïtés :

5 (5 – 1) / 2 = 10

Cela peut sembler peu, mais à mesure que des routeurs sont ajoutés au réseau, le nombre
de contiguïtés augmente de façon considérable, comme illustré dans la Figure 2.

Pour comprendre le problème lié à la diffusion massive de paquets LSA, lancez l'animation
de la Figure 3. Dans l'animation, R2 envoie un paquet LSA. Cet événement déclenche chez
tous les routeurs l'envoi d'un paquet LSA. L'animation ne montre pas les accusés de
réception renvoyés pour chaque paquet LSA reçu. Si chaque routeur d'un réseau à accès
multiple devait envoyer un paquet LSA, puis accuser réception de tous les paquets LSA qu'il a
reçus pour tous les routeurs de ce réseau à accès multiple, le trafic réseau deviendrait
chaotique.

La solution pour gérer le nombre de contiguïtés et la diffusion des paquets LSA sur un réseau
à accès multiple est le routeur DR. Sur les réseaux à accès multiple, le protocole OSPF
sélectionne un routeur DR comme point de collecte et de distribution des paquets LSA
envoyés et reçus. Un routeur BDR est également choisi au cas où le routeur DR est défaillant.
Tous les autres routeurs deviennent des DROthers. Un DROther est un routeur qui n'est ni le
routeur DR ni le routeur BDR.

Lancez l'animation de la Figure 4 pour voir le rôle du routeur DR.

Après l'état Two-Way, les routeurs passent aux états de synchronisation de base de
données. Tandis que le paquet Hello était utilisé pour établir des contiguïtés de voisinage, les
quatre autres types de paquets OSPF sont utilisés au cours du processus d'échange et de
synchronisation des LSDB.

Dans l'état ExStart,une relation maître/esclave est créée entre

chaque routeur et ses routeurs DR et BDR adjacents. Le routeur dont l'ID est le plus élevé fait
office de maître pour l'état Exchange. Dans la Figure 1, R2 devient le maître.

Dans l'état Exchange, les routeurs maître et esclave échangent un ou plusieurs paquets DBD.
Un paquet DBD comprend des informations sur l'en-tête d'entrée LSA qui apparaît dans la
LSDB du routeur. Les entrées peuvent concerner un lien ou un réseau. Chaque en-tête
d'entrée LSA contient des informations sur le type d'état de liens, l'adresse du routeur
expédiant les annonces, le coût du lien et le numéro d'ordre. Le routeur utilise le numéro
d'ordre pour déterminer la date des informations d'état de liens reçues.

Dans la Figure 2, R2 envoie un paquet DBD à R1. Lorsque R1 reçoit le paquet DBD, il exécute
les actions suivantes :

1. Il accuse réception du paquet DBD au moyen du paquet LSAck.

2. R1 envoie ensuite des paquets DBD à R2.

3. R2 reconnaît R1.

R1 compare les informations reçues aux informations dont il dispose dans sa propre LSDB. Si
le paquet DBD comprend une entrée d'état de liens plus récente, le routeur passe à l'état
Loading.

Par exemple, dans la Figure 3, R1 envoie un paquet LSR lié au réseau 172.16.6.0 à R2. R2
répond avec des informations complètes sur 172.16.6.0 dans un paquet LSU. De nouveau,
lorsque R1 reçoit un paquet LSU, il envoie un paquet LSAck. R1 ajoute ensuite les nouvelles
entrées d'état de liens dans sa LSDB.

Une fois que tous les paquets LSR ont été envoyés pour un routeur donné, les routeurs
adjacents sont considérés comme étant synchronisés et ayant l'état Full.

Tant que les routeurs voisins continuent de recevoir des paquets Hello, le réseau dans les
paquets LSA transmis reste dans la base de données topologique. Une fois que les bases de
données topologiques sont synchronisées, des mises à jour (paquets LSU) sont envoyées
uniquement aux voisins dans les cas suivants :

 Une modification est perçue (mises à jour incrémentielles)

 Toutes les 30 minutes

81.36 demonstration video observation de communication via le protocole ospf

ID de routeur OSPF
Introduit en 1991, OSPFv2 est un protocole de routage à état de liens pour IPv4. Le
protocole OSPF a été conçu comme alternative à un autre protocole de routage IPv4, le
protocole RIP.

La figure montre la topologie utilisée pour configurer le protocole OSPFv2 dans cette section.
Les types de ports série et leurs bandes passantes associées ne correspondent pas
nécessairement aux types de connexions plus courantes figurant sur les réseaux actuels. Les
bandes passantes des liens série utilisés dans cette topologie ont été choisies pour expliquer
le calcul des métriques du protocole de routage et le processus de sélection du meilleur
chemin.

Les routeurs de la topologie disposent d'une configuration initiale, qui inclut les adresses
d'interface. Aucun routage statique ou dynamique n'est actuellement configuré sur l'un des
routeurs. Toutes les interfaces des routeurs R1, R2 et R3 (sauf le bouclage sur R2) se
trouvent dans la zone de réseau fédérateur OSPF. Le routeur du FAI est utilisé comme
passerelle du domaine de routage pour accéder à Internet.

Remarque : dans cette topologie, l'interface de bouclage est utilisée pour simuler le lien de
réseau étendu donnant accès à Internet.
 L
a Figure 1 représente la topologie de référence pour cette rubrique. OSPFv2 est activé au
moyen de la commande de mode de configuration globale router ospf process-
id. La valeur process-id est un nombre compris entre 1 et 65 535 choisi par
l'administrateur réseau. La valeur process-id s'applique localement, ce qui signifie qu'il ne
doit pas s'agir de la même valeur que sur les autres routeurs OSPF pour pouvoir établir des
contiguïtés avec ces voisins.

La Figure 2 présente un exemple d'accès au mode de configuration OSPF de routeur sur R1.

Remarque : la liste de commandes a été modifiée pour afficher uniquement celles qui sont
utilisées dans ce chapitre. Pour obtenir une liste complète de commandes, utilisez les
contrôleurs de syntaxe dans la Figure 3.

Utilisez le contrôleur de syntaxe dans la Figure 3 pour passer en mode de configuration de

routeur OSPF sur R2 et pour obtenir la liste des commandes disponibles à l'invite.
Chaque routeur doit disposer d'un ID de routeur pour pouvoir participer à un
domaine OSPF. L'ID de routeur peut être défini par un administrateur ou attribué
automatiquement par le routeur. L'ID de routeur est utilisé par le routeur compatible OSPF
pour :

 Identifier uniquement le routeur - L'ID de routeur est utilisé par d'autres

routeurs pour identifier de façon unique chaque routeur au sein du domaine OSPF
ainsi que tous les paquets provenant de ceux-ci.

 Participer à la sélection du routeur désigné (DR) -

Dans un environnement de réseau local (LAN) à accès multiple, le choix du routeur
désigné s'effectue lors de l'établissement initial du réseau OSPF. Lorsque les liens
OSPF deviennent actifs, le périphérique de routage configuré avec la priorité la
plus élevée devient le routeur désigné. En supposant qu'aucune priorité ne soit
configurée, ou qu'il y ait un ex aequo, le routeur dont l'ID est le plus élevé
devient le routeur désigné. Le périphérique de routage dont l'ID est le deuxième plus
élevé devient le routeur désigné de secours (BDR).
Mais comment le routeur détermine-t-il l'ID du routeur ? Comme illustré dans la figure,
les routeurs Cisco créent l'ID de routeur en fonction de l'un des trois critères ci-dessous,
dans l'ordre préférentiel suivant :

 L'ID de routeur est configuré de façon explicite au moyen de la commande du mode

de configuration de routeur OSPF router-id rid. La valeur rid correspond à toute
valeur 32 bits exprimée sous forme d'adresse IPv4. C'est la méthode recommandée
pour attribuer un ID de routeur

 Si l'ID de routeur n'est pas configuré de façon explicite, le routeur choisit

l'adresse IPv4 la plus élevée parmi celles des interfaces de bouclage configurées.
C'est la meilleure solution hormis l'attribution d'un ID de routeur.

 Si aucune interface de bouclage n'est configurée, le routeur choisit l'adresse IPv4

active la plus élevée parmi ses interfaces physiques. C'est la méthode qui est la moins
recommandée car il est alors plus difficile pour les administrateurs de distinguer des
routeurs spécifiques.

Si le routeur utilise l'adresse IPv4 la plus élevée pour l'ID de routeur, l'interface n'a pas
besoin d'être compatible OSPF. Cela signifie que l'adresse d'interface n'a pas besoin d'être
incluse dans l'une des commandes network du protocole OSPF pour que le routeur utilise
cette adresse IP comme ID de routeur La seule exigence est que l'interface soit active et
qu'elle se trouve dans l'état up.

Remarque : l'ID de routeur ressemble à une adresse IP, mais il n'est pas routable et, par
conséquent, n'est pas inclus dans la table de routage, à moins que le processus de routage
OSPF ne choisisse une interface (physique ou de bouclage) qui est correctement définie par
une commande network.
Utilisez la commande du mode de configuration de routeur router-id rid pour affecter
manuellement une valeur 32 bits exprimée sous forme d'adresse IPv4 à un routeur. Un
routeur OSPF s'identifie auprès des autres routeurs au moyen de cet ID de routeur.

Comme illustré dans la Figure 1, R1 est configuré avec l'ID de routeur 1.1.1.1, R2 avec 2.2.2.2
et R3 avec 3.3.3.3.

Dans la Figure 2, l'ID de routeur 1.1.1.1 est attribué à R1. Utilisez la commande show ip
protocols pour vérifier l'ID de routeur.

Remarque : R1 n'avait jamais été configuré avec un ID de routeur OSPF. Si c'était le cas, l'ID
du routeur devrait être modifié.

Si l'ID de routeur est identique sur deux routeurs voisins, le routeur affiche un message
d'erreur similaire à celui-ci :

%OSPF-4-DUP_RTRID1: Detected router with duplicate router ID.

Pour corriger ce problème, configurez tous les routeurs de manière à ce qu'ils aient un ID
OSPF unique.

Utilisez le contrôleur de syntaxe dans la Figure 3 pour attribuer l'ID de routeur à R2 et R3.
Parfois, un ID de routeur doit être modifié, par exemple, lorsqu'un administrateur réseau
définit un nouveau modèle d'ID de routeur pour le réseau. Cependant, une fois qu'un
routeur sélectionne un ID de routeur, un routeur OSPF actif n'autorise pas la modification de
l'ID de routeur tant que le routeur n'a pas été redémarré ou que le processus OSPF n'a pas
été effacé.

Dans la Figure 1, notez que l'ID de routeur actuel est 192.168.10.5. L'ID de routeur doit être
1.1.1.1.

Dans la Figure 2, l'ID de routeur 1.1.1.1 est attribué à R1. Remarquez l'affichage du message
d'information indiquant que le processus OSPF doit être effacé ou que le routeur doit être
redémarré. La raison de ceci est que R1 dispose déjà de contiguïtés avec d'autres voisins
utilisant l'ID de routeur 192.168.10.5. Les contiguïtés doivent être renégociées en utilisant la
nouvelle adresse IP de routeur 1.1.1.1.

Pour réinitialiser l'ID de routeur, il est préférable de supprimer le processus OSPF.

Dans la Figure 3, le processus de routage OSPF est supprimé à l'aide de la commande du

mode d'exécution privilégié clear ip ospf process. Cela oblige OSPF sur R1 à
effectuer une transition vers les états Down et Init. Notez que la contiguïté change les
messages de Full à Down, puis de Loading à Full. La commande show ip protocols vérifie que
l'ID de routeur a changé.

Utilisez le contrôleur de syntaxe dans la Figure 4 pour modifier l'ID de routeur de R1.
Un ID de routeur peut également être affecté au moyen d'une interface de bouclage.

L'adresse IPv4 de l'interface de bouclage doit être configurée avec un masque de sous-
réseau 32 bits (255.255.255.255) . Cette méthode permet de créer une
route d'hôte de façon efficace. Une route d'hôte 32 bits n'est pas annoncée comme route
aux autres routeurs OSPF.

L'exemple de la figure indique comment configurer une interface de bouclage avec une
route d'hôte sur R1. R1 utilise la route d'hôte comme ID de routeur, à supposer qu'aucun ID
de routeur n'ait été explicitement configuré ou appris précédemment.

Remarque : certaines versions antérieures de l'IOS ne reconnaissent pas la commande

router-id ; par conséquent, le meilleur moyen de définir l'ID du routeur sur ces
routeurs est d'utiliser une interface de bouclage.
Configuration d'OSPFv2 à zone unique
La commande network détermine quelles interfaces participent au processus de routage
pour une zone OSPF. Toute interface de routeur qui correspond à l'adresse réseau dans la
commande network est activée pour envoyer et recevoir des paquets OSPF. Par conséquent,
l'adresse réseau (ou sous-réseau) de l'interface est incluse dans les mises à jour de routage
OSPF.

La syntaxe de base de la commande est la suivante : network network-address

wildcard-mask area area-id.
La syntaxe area area-id fait référence à la zone OSPF. Lors de la configuration du
protocole OSPF à zone unique, la commande network doit être configurée avec la même
valeur area-id sur tous les routeurs. Bien qu'il soit possible d'utiliser n'importe
quel ID de zone, le fait d'utiliser 0 dans un protocole OSPF à zone unique constitue une
pratique saine. Cette convention simplifie les choses si le réseau est modifié par la suite pour
prendre en charge le protocole OSPF multizone.

La figure illustre la topologie de référence.

Le protocole OSPFv2 utilise la combinaison d'arguments network-address wildcard-mask
pour activer OSPF sur les interfaces. Le protocole OSPF est sans classe par conception ; par
conséquent, le masque générique est toujours obligatoire. Lors de l'identification des
interfaces qui participent à un processus de routage, le masque générique est généralement
l'inverse du masque de sous-réseau configuré sur cette interface.

Un masque générique est une chaîne de 32 chiffres binaires utilisés par le routeur pour
déterminer quels bits de l'adresse examiner afin d'établir une correspondance. Dans un
masque de sous-réseau, le
chiffre binaire 1 équivaut à une correspondance
et le chiffre binaire 0 n'est pas une correspondance. Dans un masque
générique, l'inverse est également vrai :

 Bit 0 de masque générique : permet de vérifier la valeur du bit correspondant dans

l'adresse.

 Bit 1 de masque générique : permet d'ignorer la valeur du bit correspondant dans

l'adresse.

La méthode la plus simple pour calculer un masque générique consiste à soustraire le

masque de sous-réseau de 255.255.255.255.

L'exemple de la Figure 1 calcule le masque générique à partir de l'adresse réseau

192.168.10.0/24. Pour cela, le masque de sous-réseau 255.255.255.0 est soustrait de
255.255.255.255, ce qui donne le résultat 0.0.0.255. Par conséquent, 192.168.10.0/24
correspond à 192.168.10.0 avec le masque générique 0.0.0.255.
L'exemple de la Figure 2 calcule le masque générique à partir de l'adresse réseau
192.168.10.64/26. À nouveau, le masque de sous-réseau 255.255.255.192 est soustrait de
255.255.255.255, ce qui donne le résultat 0.0.0.63. Par conséquent, 192.168.10.0/26
correspond à 192.168.10.0 avec le masque générique 0.0.0.63.

Il existe plusieurs façons d'identifier les interfaces qui participeront au processus de routage
OSPFv2.

La Figure 1 indique les commandes obligatoires pour déterminer quelles interfaces sur R1
participent au processus de routage OSPFv2 pour une zone. Notez l'utilisation de masques
génériques afin d'identifier les interfaces respectives en fonction de leur adresse réseau.
Comme il s'agit d'un réseau OSPF zone unique, tous les ID de zone sont
définis sur 0.
Une autre solution consiste à activer OSPFv2 au moyen de la commande de mode de
configuration de routeur network intf-ip-address 0.0.0.0 area area-id.

La Figure 2 fournit un exemple de spécification de l'adresse IPv4 avec un masque générique

à quatre zéros. La saisie de network 172.16.3.1 0.0.0.0 area 0 sur R1 indique au routeur
d'activer l'interface Serial0/0/0 pour le processus de routage. Par conséquent, le processus
OSPFv2 annonce sur le réseau qu'il se trouve sur cette interface (172.16.3.0/30).

L'avantage de la spécification de l'interface est que le calcul du masque générique n'est pas
nécessaire. OSPFv2 utilise l'adresse et le masque de sous-réseau de l'interface pour
déterminer le réseau à annoncer.

Certaines versions d'IOS autorisent la saisie du masque de sous-réseau au lieu du masque

générique. L'IOS convertit ensuite le masque de sous-réseau au format de masque
générique.
Utilisez le contrôleur de syntaxe dans la Figure 3 pour annoncer les réseaux connectés à R2.

Remarque : pendant que vous complétez le contrôleur de syntaxe, observez les messages
d'informations décrivant la contiguïté entre R1 (1.1.1.1) et R2 (2.2.2.2). Le modèle
d'adressage IPv4 utilisé pour l'ID de routeur facilite l'identification du voisin.

Par défaut, les messages OSPF sont acheminés à partir de toutes les interfaces compatibles
OSPF. Cependant, ces messages ne doivent réellement être envoyés qu'à partir des
interfaces connectées aux autres routeurs compatibles OSPF.

Consultez la topologie dans la figure. Les messages OSPF sont acheminés à partir de
l'interface G0/0 de l'ensemble des trois routeurs même si aucun voisin OSPF ne se trouve sur
ce réseau local. L'envoi de messages inutiles sur un réseau local a trois effets néfastes sur le
réseau :

 Utilisation inefficace de la bande passante - La bande

passante disponible est monopolisée par le transport de messages inutiles. Les
messages sont à diffusion multiple ; par conséquent, les commutateurs acheminent
également les messages à partir de tous les ports.

 Utilisation inefficace des ressources - Tous les périphériques du réseau local doivent
traiter le message, voire éventuellement le supprimer.

 Risques de sécurité accrus - L'annonce de mises à jour sur un réseau de diffusion

constitue un risque de sécurité. Les messages OSPF peuvent être interceptés par un
logiciel d'analyse de paquets. Les mises à jour de routage peuvent être modifiées et
retournées au routeur avec des métriques fausses qui altèrent la table de routage et
provoquent l'acheminement incorrect du trafic.
Utilisez la commande du mode de configuration du routeur passive-interface pour

empêcher la transmission de messages de routage via une interface de

routeur, mais permettre que le réseau soit annoncé aux autres routeurs, comme illustré
dans la Figure 1. En particulier, la commande interrompt l'envoi de messages de routage à
partir de l'interface spécifiée. Toutefois, le réseau auquel appartient l'interface spécifiée
continuera d'être annoncé dans les messages de routage envoyés via d'autres interfaces.

Par exemple, il est inutile que R1, R2 et R3 transfèrent des messages OSPF à partir de leurs
interfaces de réseau local (LAN). La configuration identifie l'interface G0/0 de R1 comme
étant passive.

Il est important de savoir qu'une contiguïté de voisinage ne peut pas être établie via une
interface passive. La raison en est que les paquets LSP ne peuvent pas être envoyés ou reçus.

La commande show ip protocols est ensuite utilisée pour vérifier que l'interface
Gigabit Ethernet était passive, comme illustré dans la Figure 2. Notez que l'interface G0/0
figure désormais dans la section Passive Interface(s). Le réseau 172.16.1.0 est encore
répertorié sous Routing for Networks, ce qui signifie que ce réseau est encore inclus en tant
qu'entrée de route dans les mises à jour OSPF envoyées à R2 et R3.

Remarque : OSPFv2 et OSPFv3 prennent tous deux en charge la commande passive-

interface.
Utilisez le contrôleur de syntaxe dans la Figure 3 pour configurer l'interface LAN comme
interface passive sur R2.

Toutes les interfaces peuvent également être rendues passives à l'aide de la commande
passive-interface default. Les interfaces qui ne doivent pas être passives
peuvent être réactivées à l'aide de la commande no passive-interface.
Continuez à utiliser le contrôleur de syntaxe dans la Figure 3 et configurez l'interface LAN
comme interface passive sur R3.

Remarque : pendant que vous complétez le contrôleur de syntaxe, remarquez les messages
d'état d'informations OSPF lorsque les interfaces sont toutes rendues passives et que les
deux interfaces série sont rendues non passives.

Exo pka et pdf 82.27

Coût OSPF
Rappelez-vous qu'un protocole de routage utilise une métrique pour déterminer le meilleur
chemin d'un paquet sur un réseau. Une métrique donne une indication de la surcharge
nécessaire pour envoyer des paquets via une interface particulière. Le protocole OSPF utilise
le coût comme métrique. Un coût plus faible indique un meilleur chemin qu'un coût plus
élevé.

Le coût d'une interface est inversement proportionnel à la bande passante de l'interface. Par
conséquent, une bande passante plus élevée indique un coût plus faible. Une surcharge et
des délais supplémentaires correspondent à un coût supérieur. Ainsi, une ligne Ethernet
10 Mbit/s présente un coût plus élevé qu'une ligne Ethernet 100 Mbit/s.

La formule utilisée pour calculer le coût OSPF est la suivante :

 Coût = bande passante de référence / bande passante de l'interface

La bande passante de référence par défaut correspond à 10^8 (100 000 000) ; par
conséquent, la formule est la suivante :

 Coût = 100 000 000 bits/s / bande passante de l'interface en bits/s

Reportez-vous à la table de la figure pour une décomposition du calcul de coût. Notez que
les interfaces FastEthernet, Gigabit Ethernet et 10 GigE partagent le
même coût, étant donné que la valeur de coût OSPF doit être un entier. Par conséquent,
étant donné que la bande passante de référence par défaut est définie sur 100 Mbit/s,
tous les liens qui sont plus rapides que Fast Ethernet ont également un coût de 1.

Le coût d'une route OSPF est la valeur cumulée depuis un routeur jusqu'au réseau de
destination.

Par exemple, dans la Figure 1, le coût permettant d'atteindre le réseau local de R2

172.16.2.0/24 à partir de R1 devrait être comme suit :

 Coût du lien série entre R1 et R2 = 64

 Coût du lien Gigabit Ethernet sur R2 = 1

 Coût total jusqu'à 172.16.2.0/24 = 65

La table de routage de R1 dans la Figure 2 confirme que la métrique pour atteindre le réseau
local du routeur R2 a un coût de 65.

OSPF utilise une bande passante de référence de 100 Mbit/s pour tout lien égal ou
supérieur à une connexion Fast Ethernet. Par conséquent, le coût attribué à une interface
Fast Ethernet avec une bande passante d'interface de 100 Mbit/s correspondrait au
nombre 1.

Coût = 100 000 000 bits/s / 100 000 000 = 1

Bien que ce calcul fonctionne pour les interfaces Fast Ethernet, il est problématique pour les
liens plus rapides que 100 Mbit/s, étant donné que la métrique OSPF utilise uniquement des
entiers comme coût final d'un lien. Si un élément inférieur à un entier est calculé, OSPF
arrondit à l'entier le plus proche. Pour cette raison, du point de vue du protocole OSPF, une
interface avec une bande passante d'interface de 100 Mbit/s (coût de 1) a le même coût
qu'une interface disposant d'une bande passante de 100 Gbit/s (coût de 1).
Pour aider le protocole OSPF à déterminer le chemin exact, la bande passante de référence
doit être remplacée par une valeur supérieure pour prendre en compte les réseaux
disposant de liens plus rapides que 100 Mbit/s.

Réglage de la bande passante de référence

La modification de la bande passante de référence n'affecte pas réellement la capacité de la
bande passante sur le lien ; en revanche, cela affecte simplement le calcul utilisé pour
déterminer la métrique. Pour modifier la bande passante de référence, utilisez la commande
de configuration de routeur auto-cost reference-bandwidth Mbit/s.
Cette commande doit être configurée sur chaque routeur du domaine OSPF. Notez que la
valeur est exprimée en Mbit/s ; par conséquent, pour modifier les coûts pour :

 Gigabit Ethernet - auto-cost reference-bandwidth 1000

 10 Gigabit Ethernet - auto-cost reference-bandwidth 10000

Pour revenir à la bande passante de référence par défaut, utilisez la commande auto-cost
reference-bandwidth 100.

La table de la Figure 1 indique le coût OSPF si la bande passante de référence est définie sur
Gigabit Ethernet. Bien que les valeurs de métriques augmentent, le protocole OSPF effectue
de meilleurs choix car il peut désormais distinguer les liens FastEthernet des liens
Gigabit Ethernet.

La Figure 2 indique le coût OSPF si la bande passante de référence est modifiée pour prendre
en compte les liens 10 Gigabit Ethernet. La bande passante de référence doit être modifiée
chaque fois qu'il existe des liens plus rapides que FastEthernet (100 Mbit/s).

Remarque :les coûts sont des nombres entiers qui ont été arrondis vers le bas.

Dans la Figure 3, tous les routeurs ont été configurés pour prendre en compte le lien Gigabit
Ethernet avec la commande de configuration de routeur auto-cost reference-bandwidth
1000. Nouveau coût cumulé pour atteindre le réseau local de R2 172.16.2.0/24 à partir de
R1 :

 Coût du lien série entre R1 et R2 = 647

 Coût du lien Gigabit Ethernet sur R2 = 1

 Coût total jusqu'à 172.16.2.0/24 = 648

Utilisez la commande show ip ospf interface s0/0/0 pour vérifier le coût OSPF
actuel affecté à l'interface série 0/0/0 de R1, comme illustré dans la Figure 4. Remarquez que
le coût affiché est de 647.

La table de routage de R1 dans la Figure 5 confirme que la métrique pour atteindre le réseau
local du routeur R2 a un coût de 648.
Toutes les interfaces ont des valeurs de bande passante par défaut qui leur sont affectées.
Comme pour la bande passante de référence, les valeurs de bande passante des interfaces
n'affectent pas réellement la vitesse ou la capacité du lien. Au lieu de cela, elles sont utilisées
par le protocole OSPF pour calculer la métrique de routage. Par conséquent, il est important
que la valeur de bande passante reflète la vitesse réelle du lien, afin que la table de routage
contienne des informations de chemin précises.

Bien que les valeurs de bande passante des interfaces Ethernet correspondent généralement
à la vitesse des liens, ce n'est peut-être pas le cas pour d'autres interfaces. Par exemple, la
vitesse réelle des interfaces série est souvent différente de celle de la
bande passante par défaut. Sur les routeurs Cisco, la bande passante par défaut de
la plupart des interfaces série est réglée sur 1,544 Mbit/s.
Remarque : les interfaces série plus anciennes peuvent afficher une vitesse par défaut de
128 Kbit/s.

Consultez l'exemple dans la Figure 1. Notez que le lien entre :

  R1 et R2 doivent être définis sur 1 544 Kbit/s (la valeur par défaut)

 R2 et R3 doivent être définis sur 1 024 Kbit/s

 R1 et R3 doivent être définis sur 64 Kbit/s

Utilisez la commande show interfaces pour afficher le paramètre de bande passante des
interfaces. La Figure 2 indique les paramètres de l'interface série 0/0/0 de R1. Le paramètre
de bande passante est correct et donc l'interface série ne doit pas être modifiée.

La Figure 3 présente les paramètres de l'interface série 0/0/1 de R1. Elle confirme également
que l'interface utilise la valeur par défaut de 1 544 Kbit/s pour la bande passante des
interfaces. Selon la topologie de référence, cette valeur doit être définie sur 64 Kbit/s. Par
conséquent, l'interface série 0/0/1 de R1 doit être modifiée.

La Figure 4 indique une métrique de coût résultant de 647, qui est basée sur la bande
passante de référence définie sur 1 000 000 000 Bit/s et la bande passante d'interface par
défaut de 1,544 Kbit/s (1 000 000 000/1 544 000).

Réglage de la bande passante des interfaces

Pour modifier la bande passante des interfaces, utilisez la commande de configuration
d'interface bandwidth kilobits. Utilisez la commande no bandwidth pour restaurer la
valeur par défaut.
L'exemple de la Figure 1 modifie la bande passante de l'interface série 0/0/1 de R1 sur
64 Kbit/s. Une vérification rapide permet de confirmer que le paramètre de bande passante
de l'interface correspond désormais à 64 Kbit/s.

La bande passante doit être modifiée à chaque extrémité des liens série, donc :

 R2 requiert la modification de son interface S0/0/1 sur 1 024 Kbit/s.

 R3 requiert la modification de son interface série 0/0/0 sur 64 Kbit/s et de son

interface série 0/0/1 sur 1 024 Kbit/s.

Utilisez le contrôleur de syntaxe de la Figure 2 pour modifier l'interface série de R2 et R3.

Remarque : les participants qui commencent tout juste leur formation sur les réseaux et sur
Cisco IOS font souvent l'erreur de penser que la commande bandwidth modifie la bande
passante physique du lien. La commande ne change que la métrique de bande passante
utilisée par EIGRP et OSPF. La commande ne modifie pas la bande passante réelle du lien.

Comme alternative à la définition de la bande passante d'interface par défaut, le coût peut
être configuré manuellement sur une interface en utilisant la commande de configuration
d'interface ip ospf cost value.
Un avantage de la configuration d'un coût par rapport à la définition de la bande passante
d'une interface est que le routeur ne doit pas calculer la métrique lorsque le coût est
configuré manuellement. En revanche, lorsque la bande passante de l'interface est
configurée, le routeur doit calculer le coût OSPF sur base de la bande passante. La
commande ip ospf cost est très utile dans les environnements avec plusieurs fournisseurs,
lorsque des routeurs d'une autre marque que Cisco utilisent une autre métrique que la
bande passante pour calculer les coûts OSPF.

Les commandes d'interface bandwidth et ip ospf cost produisent toutes deux le même
résultat : elles fournissent une valeur précise qu'OSPF utilise pour déterminer la meilleure
route.

Par exemple, dans l'exemple de la Figure 1, la bande passante de l'interface série 0/0/1 est
réinitialisée sur la valeur par défaut et le coût OSPF est manuellement défini sur 15 625. Bien
que la bande passante des interfaces soit redéfinie sur la valeur par défaut, le coût OSPF est
défini comme si la bande passante était toujours calculée.

La Figure 2 indique les deux possibilités de modification de coût des liens série dans la
topologie. Sur le côté droit de la figure se trouve la commande ip ospf cost équivalente aux
commandes bandwidth sur la gauche.

Vérification du protocole OSPF

La Figure 1 illustre la topologie de référence.

Utilisez la commande show ip ospf neighbor pour vérifier qu'une contiguïté

est bien établie entre le routeur et ses routeurs voisins. Si l'ID de routeur du routeur voisin
ne s'affiche pas, ou qu'il n'affiche pas l'état FULL, les deux routeurs n'ont pas établi de
contiguïté OSPF.

Lorsque deux routeurs n'établissent pas de contiguïté, les informations d'état de liens ne
sont pas échangées. Une LSDB incomplète peut entraîner des erreurs dans les arborescences
SPF et les tables de routage. Les routes vers les réseaux de destination peuvent ne pas
exister, ou peuvent ne pas être les meilleurs chemins.

La Figure 2 illustre la contiguïté des voisins de R1. Pour chaque voisin, cette commande
affiche les éléments suivants :

 Neighbor ID : ID de routeur voisin.

 Pri : priorité OSPF de l'interface. Cette valeur est utilisée pour le choix du routeur
désigné (DR) et du routeur désigné de secours (BDR).

 State : état OSPF de l'interface. L'état FULL signifie que le routeur et son voisin ont
des LSDB OSPF identiques. Sur les réseaux à accès multiple, tels que l'Ethernet, deux
routeurs contigus peuvent afficher l'état 2WAY. Le tiret indique qu'aucun DR ou BDR
n'est requis en raison du type de réseau.

 Dead Time : durée de temps pendant laquelle le routeur attend un paquet Hello
OSPF du voisin avant de déclarer le voisin hors service. Cette valeur est réinitialisée
lorsque l'interface reçoit un paquet Hello.

 Address : adresse IPv4 de l'interface du voisin à laquelle ce routeur est connecté

directement.

 Interface : interface sur laquelle ce routeur a établi une contiguïté avec son voisin.

Utilisez le contrôleur de syntaxe dans la Figure 3 pour vérifier les voisins R2 et R3 au moyen
de la commande show ip opsf neighbor.

Deux routeurs ne peuvent pas établir une contiguïté OSPF si :

 Les masques de sous-réseau ne correspondent pas, plaçant ainsi les routeurs sur des
réseaux séparés

 Les compteurs OSPF Hello ou les compteurs d'arrêt ne correspondent pas

 Les types de réseau OSPF ne correspondent pas

 La commande OSPF network est manquante ou incorrecte.

Comme illustré dans la Figure 1, la commande show ip protocols est un moyen rapide de
vérifier les informations de configuration OSPF de base. Cela comprend l'ID de processus
OSPF, l'ID du routeur, les réseaux annoncés par le routeur, les voisins dont le routeur reçoit
les mises à jour et la distance administrative par défaut, à savoir 110 pour OSPF.

Utilisez le contrôleur de syntaxe de la Figure 2 pour vérifier les paramètres de

protocole OSPF de R2 et R3 en utilisant la commande show ip protocols.
La commande show ip ospf peut également être utilisée pour examiner l'ID de routeur et
l'ID de processus OSPF, comme illustré dans la Figure 1. Cette commande affiche les
informations de zone OSPF et la dernière fois où l'algorithme SPF a été calculé.

Utilisez le contrôleur de syntaxe de la Figure 2 pour vérifier le processus OSPF de R2 et R3 en

utilisant la commande show ip ospf.
Le moyen le plus rapide de vérifier les paramètres d'interface OSPF est d'utiliser la
commande show ip opsf interface. Cette commande fournit une liste détaillée de chaque
interface utilisant OSPF. Cette commande est utile pour déterminer si les instructions
network ont été correctement composées.

Pour obtenir un résumé des interfaces compatibles OSPF, utilisez la commande show ip ospf
interface brief, comme illustré dans la Figure 1.

Utilisez le contrôleur de syntaxe de la Figure 2 pour extraire et afficher un résumé des

interfaces compatibles OSPF sur R2 en utilisant la commande show ip ospf interface brief.
Remarquez que la spécification du nom d'interface comme dans la commande show ip ospf
interface serial 0/0/1 permet d'obtenir des informations OSPF détaillées.

Continuez à utiliser le contrôleur de syntaxe de la Figure 2 pour obtenir un résumé des

interfaces compatibles OSPF sur R3 en utilisant la commande show ip ospf interface brief.
Récupérez et affichez des informations supplémentaires pour l'interface série 0/0/0 au
moyen de la commande show ip ospf interface serial 0/0/0.

Au cours de ce TP, vous aborderez les points suivants :

 Partie 1 : création du réseau et configuration des paramètres de périphérique de

base

 Partie 2 : configuration et vérification du routage OSPF

 Partie 3 : modification des attributions d'ID de routeur

 Partie 4 : configuration des interfaces OSPF passives

 Partie 5 : modification des métriques OSPF

Travaux pratiques : configuration d'une zone unique OSPFv2 de base

TP 82.45 pdf
Comparaison des protocoles OSPFv2 et OSPFv3
OSPFv3 est l'équivalent OSPFv2 pour l'échange de préfixes IPv6. Rappelez-vous que dans
IPv6, l'adresse réseau est considérée comme étant le préfixe et le masque de sous-réseau
est appelé la longueur de préfixe.

De la même façon que son homologue IPv4, OSPFv3 échange les informations de routage
pour insérer les préfixes distants dans la table de routage IPv6, comme illustré dans la figure.

Remarque : grâce à la fonctionnalité de familles d'adresses OSPFv3, OSPFv3 prend en charge

à la fois les protocoles IPv4 et IPv6.

OSPFv2 s'exécute sur la couche réseau IPv4, communique avec d'autres homologues OSPF
IPv4 et annonce uniquement les routes IPv4.

OSPFv3 dispose des mêmes fonctionnalités qu'OSPFv2, à la différence près qu'il utilise IPv6
comme transport de couche réseau, en communiquant avec les homologues OSPFv3 et en
annonçant les routes IPv6. OSPFv3 utilise également l'algorithme SPF comme moteur de
calcul pour déterminer les meilleurs chemins dans l'ensemble du domaine de routage.

Comme avec tous les protocoles de routage IPv6, OSPFv3 a des processus distincts par
rapport à son homologue IPv4. Les processus et les opérations sont fondamentalement les
mêmes que dans le protocole de routage IPv4, mais ils fonctionnent indépendamment.
OSPFv2 et OSPFv3 ont chacun des tables de contiguïté, des tables topologiques OSPF et des
tables de routage IP différentes, comme illustré dans la figure.

Les commandes de configuration et de vérification OSPFv3 sont similaires à celles utilisées

dans OSPFv2.
Comme illustré dans la figure, voici les similitudes entre OSPFv2 et OSPFv3 :

 État de liens - OSPFv2 et OSPFv3 sont tous les deux des protocoles de routage à état
de liens sans classe.

 Algorithme de routage - OSPFv2 et OSPFv3 utilisent l'algorithme SPF pour prendre

des décisions de routage.

 Métrique - Les documents RFC pour OSPFv2 et OSPFv3 définissent la métrique en

tant que coût d'envoi de paquets via l'interface. OSPFv2 et OSPFv3 peuvent être
modifiés en utilisant la commande de mode de configuration de routeur auto-cost
reference-bandwidth ref-bw . La commande influence uniquement la métrique OSPF
où elle a été configurée. Par exemple, si la commande a été entrée pour OSPFv3, elle
n'affecte pas les métriques de routage OSPFv2.

 Zones - Le concept de zones multiples dans OSPFv3 est identique dans OSPFv2. Les
zones multiples réduisent les diffusions de paquets à état de liens et offrent une
meilleure stabilité avec le domaine OSPF.

 Types de paquets OSPF - OSPFv3 utilise les mêmes cinq types de paquets de base
qu'OSPFv2 (Hello, DBD, LSR, LSU et LSAck).

 Mécanisme de détection de voisins - La machine d'état des voisins, y compris la liste

des états et des événements de voisinage OSPF, reste inchangée. OSPFv2 et OSPFv3
utilisent le mécanisme Hello pour en savoir plus sur les routeurs voisins et former des
contiguïtés. Cependant, dans OSPFv3, les sous-réseaux correspondants ne doivent
 pas obligatoirement former des contiguïtés de voisinage. La raison en est que les
contiguïtés de voisinage sont formées au moyen d'adresses link-local, et non à partir
d'adresses de monodiffusion globales.

 Processus de sélection de DR/BDR - Le processus de sélection de routeur désigné

(DR)/routeur désigné de secours (BDR) reste inchangé dans OSPFv3.

 ID du routeur - OSPFv2 et OSPFv3 utilisent tous deux un nombre 32 bits pour l'ID de
routeur représenté par une notation décimale à point. Il s'agit généralement d'une
adresse IPv4. La commande router-id d'OSPF doit être utilisée pour configurer l'ID de
routeur Le processus de détermination de l'ID de routeur 32 bits est identique pour
les deux protocoles. Utilisez un ID de routeur configuré explicitement ; sinon,
l'adresse IPv4 de bouclage la plus élevée devient l'ID de routeur

La figure illustre les différences entre OSPFv2 et OSPFv3 :

 Annonces - OSPFv2 annonce les routes IPv4, tandis qu'OSPFv3 annonce les routes
pour IPv6.

 Adresse source - Les messages OSPFv2 proviennent de l'adresse IPv4 de l'interface

de sortie. Dans le protocole OSPFv3, les messages OSPF sont fournis à l'aide de
l'adresse link-local de l'interface de sortie.

 Adresses de multidiffusion tous les routeurs OSPF - OSPFv2 utilise 224.0.0.5 ; tandis
qu'OSPFv3 utilise FF02::5.
  Adresse de multidiffusion DR/BDR - OSPFv2 utilise 224.0.0.6 ; tandis qu'OSPFv3
utilise FF02::6.

 Annonce des réseaux - OSPFv2 annonce les réseaux au moyen de la commande de

configuration de routeur network ; tandis qu'OSPFv3 utilise la commande de
configuration d'interface ipv6 ospf process-id area area-id.

 Routage monodiffusion IP - Activé par défaut dans IPv4 ; tandis que la commande de
configuration globale ipv6 unicast-routing doit être configurée.

 Authentification - OSPFv2 utilise l'authentification en clair ou l'authentification MD5.

OSPFv3 utilise l'authentification IPv6.

L
es routeurs exécutant un protocole de routage dynamique, tel qu'OSPF, échangent des
messages entre voisins sur le même sous-réseau ou lien. Les routeurs doivent uniquement
envoyer et recevoir des messages de protocole de routage avec leurs voisins connectés
directement. Ces messages sont toujours envoyés depuis l'adresse IPv4 source du routeur
effectuant le transfert.

Les adresses link-local IPv6 sont idéales à cet égard. Une adresse link-local IPv6 permet à un
périphérique de communiquer avec d'autres périphériques IPv6 sur la même liaison et
uniquement sur cette liaison (sous-réseau). Les paquets associés à une adresse source ou de
destination link-local ne peuvent pas être acheminés au-delà de leur liaison d'origine.

Comme illustré dans la figure, les messages OSPFv3 sont envoyés au moyen de :

 Adresse IPv6 source - Il s'agit de l'adresse link-local IPv6 de l'interface de sortie.

 Adresse IPv6 de destination - Les paquets OSPFv3 peuvent être envoyés à une
adresse de monodiffusion en utilisant l'adresse link-local IPv6 du voisin. Ils peuvent
également être envoyés au moyen d'une adresse de multidiffusion. L'adresse FF02::5
est l'adresse pour tous les routeurs OSPF, tandis que FF02::6 est l'adresse de
multidiffusion du DR/BDR.
Configuration du OSPFv3
La Figure 1 illustre la topologie de réseau qui est utilisée pour configurer OSPFv3.

La Figure 2 illustre le routage de monodiffusion IPv6 et la configuration des adresses de

monodiffusion globale de R1, comme indiqué dans la topologie de référence. Supposons que
les interfaces de R2 et R3 ont aussi été configurées avec leur adresse de monodiffusion
globale, comme indiqué dans la topologie de référence.

Dans cette topologie, aucune adresse IPv4 n'est configurée pour les routeurs. Un réseau
dont les interfaces de routeur sont configurées avec des adresses IPv4 et IPv6 est appelé « à
double pile » (dual-stack). Sur un réseau à double pile, les protocoles OSPFv2 et OSPFv3
peuvent être activés simultanément.

La Figure 3 présente les étapes de configuration du protocole OSPFv3 de base dans une zone
unique.
Dans la figure, le résultat de la commande show ipv6 interface brief confirme que les
adresses globales IPv6 correctes ont été configurées et que les interfaces sont activées. En
outre, notez que chaque interface a automatiquement généré une adresse link-local, comme
indiqué dans la figure.

Les adresses link-local sont créées automatiquement lorsqu'une adresse de monodiffusion

globale IPv6 est attribuée à l'interface. Les adresses de monodiffusion globales ne sont pas
obligatoires sur une interface ; en revanche, les adresses link-local IPv6 le sont.

Sauf s'ils ont été configurés manuellement, les routeurs Cisco créent l'adresse link-local au
moyen du préfixe FE80::/10 et du processus EUI-64. EUI-64 consiste à utiliser l'adresse MAC
Ethernet 48-bit, à insérer FFFE au milieu et à manipuler le septième bit. Pour les interfaces
série, Cisco utilise l'adresse MAC d'une interface Ethernet. Notez que dans la figure les trois
interfaces utilisent la même adresse link-local.
Il est difficile d'identifier et de mémoriser les adresses link-local créées au moyen du format
EUI-64 ou, dans certains cas, les ID d'interface aléatoires Étant donné que les protocoles de
routage IPv6 utilisent des adresses link-local IPv6 pour l'adressage de monodiffusion et les
informations d'adresse de tronçon suivant dans la table de routage, il est courant de définir
des adresses facilement reconnaissables.

Configurer manuellement l'adresse link-local permet de créer une adresse qui est
reconnaissable et plus facile à mémoriser. Ainsi, un routeur avec plusieurs interfaces peut
attribuer la même adresse link-local à chaque interface IPv6. La raison en est que l'adresse
link-local est uniquement requise pour les communications locales.

Les adresses link-local peuvent être configurées manuellement au moyen de la même

commande d'interface que celle utilisée pour créer des adresses de monodiffusion globale
IPv6, mais en ajoutant le mot clé link-local à la commande ipv6 address.

Une adresse link-local possède un préfixe dans la plage FE80 à FEBF. Lorsqu'une adresse
commence par cet hextet (segment de 16 bits), le mot clé link-local doit suivre l'adresse.

L'exemple de la Figure 1 configure la même adresse link-local FE80::1 sur les trois interfaces
de R1. FE80::1 a été choisi pour faciliter la mémorisation des adresses link-local de R1.

Un examen rapide des interfaces telles qu'illustrées dans la Figure 2 confirme que les
adresses link-local de l'interface de R1 ont été remplacées par FE80::1.
Utilisez le contrôleur de syntaxe de la Figure 3 pour configurer et vérifier l'adresse link-local
FE80::2 sur R2 ainsi que l'adresse link-local FE80::3 sur R3.

Sar 49

Utilisez la commande de mode de configuration globale ipv6 router ospf process-id pour
passer en mode de configuration du routeur. L'invite du mode de configuration du routeur
IPv6 est différente de l'invite du mode de configuration du routeur IPv4. Utilisez le mode de
confirmation du routeur IPv6 pour configurer les paramètres globaux OSPFv3, tels que
l'attribution d'un ID de routeur OSPF et d'une bande passante de référence de 32 bits.

Les protocoles de routage IPv6 sont activés sur une interface, et non en mode de
configuration du routeur, à l'instar de leurs homologues IPv4. La commande de mode de
configuration du routeur IPv4 network n'existe pas dans IPv6.

À l'instar d'OSPFv2, la valeur process-id est un nombre compris entre 1 et 65 535 choisi par
l'administrateur réseau. La valeur process-id n'a qu'une signification locale, ce qui veut dire
qu'elle n'a pas à correspondre à celle des autres routeurs OSPF pour établir des contiguïtés
avec ces voisins.

OSPFv3 nécessite l'affectation d'un ID de routeur 32 bits pour que le protocole OSPF puisse
être activé sur une interface. Le schéma logique dans la Figure 1 illustre la façon dont un ID
de routeur est choisi. À l'instar d'OSPFv2, OSPFv3 utilise :

 D'abord, un ID de routeur configuré explicitement.

 Si aucun n'est configuré, le routeur utilise l'adresse IPv4 configurée la plus élevée
d'une interface de bouclage.

 Si aucun n'est configuré, le routeur utilise l'adresse IPv4 configurée la plus élevée
d'une interface active.

 S'il n'y a aucune source d'adresses IPv4 sur un routeur, le routeur affiche un message
de console pour configurer l'ID de routeur manuellement.

Remarque : par souci de cohérence, l'ensemble des trois routeurs utilisent l'ID de processus
10.

Comme illustré dans la topologie de la Figure 2, les routeurs R1, R2 et R3 doivent se voir
affecter les ID de routeur indiqués. La commande router-id rid utilisée pour attribuer un ID
de routeur dans OSPFv2 est la même que celle qui est utilisée dans OSPFv3.

L'exemple de la Figure 3 :

 Passe en mode de configuration OSPFv3 du routeur. Remarquez que l'invite du

routeur est différente de celle de l'invite de mode de protocole de routage IPv4 par
défaut. Notez également l'affichage du message de console informatif lors de l'accès
au mode de configuration du routeur OSPFv3.
  Attribue l'ID de routeur 1.1.1.1.

 Modifie la bande passante de référence sur 1 000 000 000 bits/s (1 Gbit/s), parce que
le réseau comporte des liens Gigabit Ethernet. Notez le message de console
informatif qui indique que cette commande doit être configurée sur tous les routeurs
du domaine de routage.

 La commande show ipv6 protocols permet de vérifier que l'ID de processus 10 du

protocole OSPFv3 utilise l'ID de routeur 1.1.1.1.

Utilisez le contrôleur de syntaxe dans la Figure 4 pour configurer les paramètres globaux
OSPFv3 sur R2 et R3.

Les ID de routeur doivent parfois être modifiés, par exemple, si l'administrateur réseau a
défini un nouveau modèle d'identification d'ID de routeur. Cependant, une fois qu'un
routeur OSPFv3 définit un ID de routeur, cet ID ne peut pas être modifié tant que le routeur
n'est pas redémarré ou que le processus OSPF n'est pas supprimé.
Dans la Figure 1, notez que l'ID de routeur actuel correspond à 10.1.1.1. L'ID de routeur
OSPFv3 devrait être 1.1.1.1.

Dans la Figure 2, l'ID de routeur 1.1.1.1 est attribué à R1.

Remarque : pour réinitialiser l'ID de routeur, il est préférable de supprimer le processus

OSPF.

Dans la Figure 3, le processus de routage OSPF est supprimé à l'aide de la commande du

mode d'exécution privilégié clear ipv6 ospf process. Ceci contraint le protocole OSPF sur R1
à renégocier les contiguïtés de voisinage au moyen du nouvel ID de routeur.

La commande show ipv6 protocols vérifie que l'ID de routeur a changé.

Utilisez le contrôleur de syntaxe dans la Figure 4 pour modifier l'ID de routeur de R1.

OSPFv3 utilise une autre méthode pour activer une interface pour OSPF. Au lieu d'utiliser la
commande du mode de configuration de routeur network pour spécifier les adresses
d'interface correspondantes, OSPFv3 est configuré directement sur l'interface.

Pour activer OSPFv3 sur une interface, utilisez la commande du mode de configuration
d'interface ipv6 ospf process-id area area-id.
La valeur process-id identifie le processus de routage spécifique et doit être identique à l'ID
de processus utilisé pour créer le processus de routage dans la commande ipv6 router ospf
process-id.

La valeur area-id est la zone à associer à l'interface OSPFv3. Bien que n'importe quelle valeur
pourrait avoir été configurée pour la zone, 0 a été sélectionné, parce que la zone 0 est la
zone de réseau fédérateur à laquelle toutes les autres zones doivent se connecter, comme
illustré dans la Figure 1. Cela facilite la migration vers le protocole OSPF à zones multiples, le
cas échéant.

Dans la Figure 2, OSPFv3 est activé sur les interfaces de R1 au moyen de la commande ipv6
ospf 10 area 0. La commande affiche show ipv6 ospf interface brief les interfaces OSPFv3
actives.

Utilisez le contrôleur de syntaxe de la Figure 3 pour activer OSPFv3 sur les interfaces de R2 et
R3.
Vérification d'OSPFv3
Utilisez la commande show ipv6 ospf neighbor pour vérifier qu'une contiguïté est bien
établie entre le routeur et ses routeurs voisins. Si l'ID de routeur du routeur voisin ne
s'affiche pas, ou qu'il n'affiche pas l'état FULL, les deux routeurs n'ont pas établi de
contiguïté OSPF.

Lorsque deux routeurs n'établissent pas de contiguïté de voisinage, les informations d'état
de liens ne sont pas échangées. Une LSDB incomplète peut entraîner des erreurs dans les
arborescences SPF et les tables de routage. Les routes vers les réseaux de destination
peuvent ne pas exister, ou peuvent ne pas être les meilleurs chemins.

La Figure 1 illustre la contiguïté de voisinage de R1. Pour chaque voisin, cette commande
affiche les éléments suivants :

 Neighbor ID : ID de routeur voisin.

 Pri : priorité OSPF de l'interface. Cette valeur est utilisée pour le choix du routeur
désigné (DR) et du routeur désigné de secours (BDR).

 State : état OSPF de l'interface. L'état FULL signifie que le routeur et son voisin ont
des LSDB OSPF identiques. Sur les réseaux à accès multiple tels que l'Ethernet, deux
routeurs contigus peuvent avoir pour état affiché 2WAY. Le tiret indique qu'aucun DR
ou BDR n'est requis en raison du type de réseau.

 Dead Time : durée de temps pendant laquelle le routeur attend un paquet Hello
OSPF du voisin avant de déclarer le voisin hors service. Cette valeur est réinitialisée
lorsque l'interface reçoit un paquet Hello.

 Interface ID : ID de l'interface ou du lien.

 Interface : interface sur laquelle ce routeur a établi une contiguïté avec son voisin.

Utilisez le contrôleur de syntaxe dans la Figure 2 pour vérifier les voisins R2 et R3 au moyen
de la commande show ipv6 opsf neighbor.
Comme illustré dans la Figure 1, la commande show ipv6 protocols est un moyen rapide de
vérifier les informations de configuration OSPFv3 essentielles, notamment l'ID de processus
OSPF, l'ID du routeur et les interfaces compatibles OSPFv3.

Utilisez le contrôleur de syntaxe de la Figure 2 pour vérifier les paramètres de

protocole OSPF de R2 et R3 en utilisant la commande show ipv6 protocols.

Utilisez la commande show ipv6 ospf pour examiner également l'ID de processus et l'ID de
routeur du protocole OSPFv3. Cette commande affiche les informations de zone OSPF et la
dernière fois où l'algorithme SPF a été calculé.
Le moyen le plus rapide de vérifier les paramètres d'interface OSPF consiste à utiliser la
commande show ipv6 opsf interface. Cette commande fournit une liste détaillée de chaque
interface utilisant OSPF.

Pour extraire et afficher un résumé des interfaces compatibles OSPFv3 sur R1, utilisez la
commande show ipv6 ospf interface brief, comme illustré dans la Figure 1.

Utilisez le contrôleur de syntaxe de la Figure 2 pour afficher un résumé des interfaces

compatibles OSPF sur R2 en utilisant la commande show ipv6 ospf interface brief.
Remarquez que la spécification du nom d'interface comme dans la commande show ipv6
ospf interface serial 0/0/1 permet d'obtenir des informations OSPF détaillées.

Continuez à utiliser le contrôleur de syntaxe de la Figure 2 pour obtenir un résumé des

interfaces compatibles OSPF sur R3 en utilisant la commande show ipv6 ospf interface brief.
Récupérez et affichez des informations supplémentaires pour l'interface série 0/0/0 au
moyen de la commande show ipv6 ospf interface serial 0/0/0.
Dans la Figure 1, la commande show ipv6 route ospf fournit des informations sur des routes
OSPF dans la table de routage.

Utilisez le contrôleur de syntaxe de la Figure 2 pour vérifier la table de routage OSPFv3 de R2

et R3, utilisez la commande show ipv6 route ospf.
Dans cet exercice, l'adressage IPv6 est déjà configuré. Vous êtes chargé de configurer la
topologie à trois routeurs avec un protocole OSPFv3 de base à zone unique, puis de vérifier
la connectivité entre les périphériques finaux.

Packet Tracer : configuration du protocole OSPFv3 de base dans une zone unique -
Instructions

Packet Tracer : configuration du protocole OSPFv3 de base dans une zone unique - PKA

Exo 83.35 pka et pdf

Au cours de ce TP, vous aborderez les points suivants :

 Partie 1 : création du réseau et configuration des paramètres de périphérique de

base

 Partie 2 : configuration du routage OSPFv3

 Partie 3 : configuration des interfaces OSPFv3 passives

Travaux pratiques : configuration du protocole OSPFv3 de base dans une zone unique
TP 83.36 pdf

Résumé
Résumé
Exercice : découverte pas-à-pas du protocole OSPFv3

Scénario

Cet exercice en classe est conçu pour des groupes de trois étudiants. L'objectif est
d'examiner le processus de routage SPF.

Vous concevrez un réseau et procéderez à son adressage, communiquerez le schéma

d'adresse réseau et le fonctionnement des liens réseau aux membres de votre groupe et
calculerez le chemin le plus court.

Effectuez les étapes comme indiqué sur le PDF pour cet exercice en classe.

Si vous avez le temps, partagez votre conception de réseau et votre protocole OSPF avec un
autre groupe.

Exercice en classe : découverte pas-à-pas du protocole OSPFv3 - Instructions

Exo pka et pdf 84.11

 D
ans ce projet d'intégration des compétences, votre objectif est de configurer OSPFv2 et
OSPFv3. Vous configurerez l'adressage IP pour tous les périphériques. Vous configurerez
ensuite le routage OSPFv2 pour la partie IPv4 du réseau et le routage OSPFv3 pour la partie
IPv6 du réseau. Un routeur disposera de configurations à la fois pour IPv4 et pour IPv6. Enfin,
vous vérifierez vos configurations et testerez la connectivité entre les périphériques finaux.

Packet Tracer : instructions pour l'exercice d'intégration des compétences

Packet Tracer : exercice d'intégration des compétences – PKA

Exo pka et pdf 84.12

La version actuelle du protocole OSPF pour IPv4 est OSPFv2, présenté dans le document RFC
1247 et mis à jour dans le document RFC 2328 par John Moy. En 1999, OSPFv3 pour IPv6 a
été publié dans le document RFC 2740.

OSPF est un protocole de routage à état de liens, sans classe, avec une distance
administrative par défaut de 110, et identifié dans la table de routage par le code source de
route O.
OSPF est activé avec la commande de mode de configuration globale router ospf process-id.
La valeur de process-id n'a qu'une signification locale, ce qui veut dire qu'il n'a pas à
correspondre à celui des autres routeurs OSPF pour établir des contiguïtés avec des voisins.

La commande network utilisée avec le protocole OSPF a la même fonction que lorsqu'elle
est utilisée avec les autres protocoles de routage IGP, mais sa syntaxe diffère légèrement. La
valeur wildcard-mask est l'inverse du masque de sous-réseau et la valeur area-id doit être
définie sur 0.

Par défaut, des paquets Hello OSPF sont envoyés toutes les 10 secondes sur les segments à
accès multiple et point à point, et toutes les 30 secondes sur les segments NBMA (Frame
Relay, X.25, ATM), et sont utilisés par OSPF pour établir des contiguïtés de voisinage. Par
défaut, l'intervalle Dead est quatre fois plus long que l'intervalle Hello.

Pour que les routeurs deviennent contigus, leurs intervalles de paquets Hello et Dead, leurs
types de réseau et leurs masques de sous-réseau doivent correspondre. Utilisez la
commande show ip ospf neighbors pour vérifier les contiguïtés OSPF.

OSPF sélectionne un routeur désigné (DR) pour servir de point de collecte et de distribution
pour les paquets LSA envoyés et reçus dans le réseau à accès multiple. Un routeur désigné
de secours (BDR) est sélectionné pour remplir le rôle de routeur désigné si ce dernier venait
à défaillir. Tous les autres routeurs sont connus sous le nom de DROthers. Tous les routeurs
envoient leur LSA au DR, qui les diffuse ensuite aux autres routeurs du réseau à accès
multiple.

La commande show ip protocols sert à vérifier les données de configuration OSPF

importantes, notamment l'ID de processus OSPF, l'ID du routeur et les réseaux auxquels ce
dernier fait ses annonces.

OSPFv3 est activé sur une interface et n'est pas en mode de configuration du routeur.
OSPFv3 a besoin que les adresses link-local soient configurées. Le routage monodiffusion
IPv6 doit être activé pour OSPFv3. Un ID de routeur de 32 bits est requis avant qu'une
interface puisse être activée pour OSPFv3.