Objectifs de certification
CCNA 200-301
3.4 Configurer et vérifier single area OSPFv2
- 3.4.a Neighbor adjacencies
- 3.4.b Point-to-point
- 3.4.c Broadcast (DR/BDR selection)
- 3.4.d Router ID
Messages OSPF
Ce chapitre est la suite de celui sur la configuration d’OSPF en Cisco IOS. Pour construire ses routes, les routeurs OSPF entretiennent des relations de voisinage et s’échangent toute une série de messages qui sont décrits dans ce chapitre : Hello, “Database Description packet” (DBD), “Link-state request” (LSR), “Link-state update” (LSU) et “Link-state acknowledgmen”t (LSAck).
1. Messages OSPF
1. Relations de voisinage
Avant de s’échanger des informations de routage, les routeurs OSPF établissent des relations ou des états avec leurs voisins afin de partager efficacement les informations d’états de lien.
2. Messages OSPF
Un protocole à vecteur de distance comme RIP (ou IGRP) utilise aveuglément le Broadcast ou le Multicast en envoyant par chaque interface la table de routage complète toutes les 30 secondes (par défaut).
A contrario, les routeurs OSPF comptent 5 différents types de paquets pour identifier leurs voisins et mettre à jour les informations de routage à état de lien.
OSPF utilise l’Unicast et deux adresses Multicast pour livrer ces messages :
-
224.0.0.5
,FF02::5
(Tous les routeurs OSPF) -
224.0.0.6
,FF02::6
(Les routeurs DR/BDR OSPF)
3. Cinq types de messages OSPF
Type de paquet OSPF | Description |
---|---|
Type 1 Hello | Établit et maintient les informations de contiguïté (adjacency information) avec les voisins. |
Type 2 Database Description packet (DBD) | Décrit le contenu des bases de données d’état de liens (link-state database) des routeurs OSPF. |
Type 3 Link-state request (LSR) | Demande des éléments spécifiques des bases de données d’état de liens (link-state database) des routeurs OSPF. |
Type 4 Link-state update (LSU) | Transporte les link-sate advertisements, les LSA, aux routeurs voisins. |
Type 5 Link-state acknowledgment (LSAck) | Accusés de réception des LSA des voisins. |
2. Messages Hello
2.1. Hello OSPF
Quand un routeur commence un processus de routage OSPF sur une interface, il envoie un paquet Hello et continue à envoyer ces paquets à intervalles réguliers.
Ces paquets Hello seront utilisés dans les états de voisinage Init et Two-way.
2.2. Paquets Hello (type 1)
À la couche 3 du modèle OSI, les paquets Hello sont adressés en multicast 224.0.0.5
ou FF02::5
. Ces adresses correspondent à “tous les routeurs OSPF”. Les routeurs OSPF utilisent ces paquets Hello pour initier de nouvelles adjacences et pour s’assurer que les routeurs voisins sont fonctionnels.
Les paquets Hello sont envoyés toutes les 10 secondes par défaut sur un réseau multi-accès et point à point, et toutes les 30 secondes sur un NBMA (Non Broadcast Multi Access, comme Frame-Relay).
Dans un réseau multi-accès, le protocole Hello élit un DR et un BDR.
2.3. En-tête OSPFv2
Remarquons ici particulièrement le champ Router ID dont nous avons parlé plus haut. On notera aussi le champ Area ID d’une taille de 32 bits.
2.4. Router ID OSPF
Le champ Router ID est utilisé pour identifier de manière unique un routeur OSPF. Il est important que ce Router ID soit unique dans le processus de routage !
Il prendra la valeur de la plus haute adresse IP du routeur (32 bits). Puisqu’une adresse IP est censée être unique dans un réseau, elle convient bien pour remplir ce champ.
Aussi, parce qu’un routeur supporte de multiples adresses IP assignées pour l’interconnexion des réseaux, on utilisera volontiers l’adresse IP d’interfaces de loopback (virtuelles) qui ne participeront pas nécessairement au routage.
Leur avantage est aussi dans le fait que ces interfaces ne tombent jamais (en fonction d’une dépendance à un lien physique).
2.5. Interface de loopback
Notons enfin que pour remplir par défaut ce champ Router ID, les IOS Cisco prendront toujours en compte l’IP de l’interface de loopback, la plus élevée, quand bien même des interfaces physiques auraient une IP plus élevée.
Par contre, en absence d’interface de loopback, sur du matériel Cisco, l’adresse IPv4 la plus élevée d’une des interfaces physiques sera prise.
En OSPFv3, selon les versions IOS, on sera obligé de fixer ce Router ID. Selon les points de vue, il serait préférable de maîtriser cet identifiant.
2.6. Charge du paquet Hello
Un paquet Hello transporte des informations que tous les voisins doivent agréer avant qu’une adjacence ne soit formée et avant que les informations d’état de lien ne soient échangées. Notons le champ Rtr Prio qui intervient dans la désignation des rôles entre routeurs OSPF.
Aussi les délais configurés sur les interfaces doivent correspondre ; autrement le processus d’adjacence ne peut pas continuer.
2.7. Message type 1 Hello OSPFv2
2.8. Vérification des délais OSPFv2
R1#show ip ospf interface g0/2
GigabitEthernet0/2 is up, line protocol is up
Internet Address 192.168.95.1/30, Area 0, Attached via Network Statement
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 2.2.2.2, Interface address 192.168.95.2
Backup Designated router (ID) 1.1.1.1, Interface address 192.168.95.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
...
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 2.2.2.2 (Designated Router)
Suppress hello for 0 neighbor(s)
2.9. Vérifications des délais OSPFv3
R1#show ipv6 ospf interface g0/2
GigabitEthernet0/2 is up, line protocol is up
Link Local Address FE80::1, Interface ID 4
Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 2.2.2.2, local address FE80::2
Backup Designated router (ID) 1.1.1.1, local address FE80::1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
...
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 2.2.2.2 (Designated Router)
Suppress hello for 0 neighbor(s)
2.10. Délais hello-interval et dead-interval
Si les paquets Hello sont envoyés toutes les 10 secondes (hello-interval) sur les réseaux Ethernet et point à point, ils sont envoyés toutes les 30 secondes en NBMA (Frame-Relay).
Le dead-interval est la durée après laquelle un lien est considéré “down” par OSPF. Par défaut, 4 x le délai Hello : respectivement 40 et 120 secondes.
2.11. Configuration du délai hello
Les délais doivent correspondre sur les interfaces. Quand ces délais ne correspondent pas de part et d’autre de la liaison, la relation de voisinage OSPF ne peut pas s’établir.
Pour changer des délais :
(config-if)#ip ospf hello-interval ?
<1-65535> Seconds
2.12. Configuration du dead interval
Par défaut le dead interval est 4 x le hello interval.
Le dead interval se fixe de manière administrative ou en fixant le nombre de hellos à la seconde :
(config-if)#ip ospf dead-interval ?
<1-65535> Seconds
minimal Set to 1 second
(config-if)#ip ospf dead-interval minimal ?
hello-multiplier Set multiplier for Hellos
(config-if)#ip ospf dead-interval minimal hello-multiplier ?
<3-20> Number of Hellos sent within 1 second
3. Autres paquets
3.1. Type 2 DBD
Ces paquets sont utilisés au moment de l’état ExStart, les routeurs vont déterminer qui commence à envoyer les informations. Ici, le principe est d’établir une relation Maître/Esclave entre deux routeurs. Le routeur qui déclare la plus haute ID (la priorité n’intervient pas) commencera et orchestrera l’échange en tant que maître.
Les routeurs sont maintenant prêts à s’engager dans le processus Exchange.
Le maître mène l’esclave à un échange de paquets Database Description (DBDs) qui décrivent la base de données de liens de chaque routeur dans les détails.
Ces descriptions comportent le type d’état de lien, l’adresse du routeur qui fait l’annonce, le coût du lien et un numéro de séquence.
3.2. Etat Loading
Chacun des routeurs compare les informations qu’il reçoit avec ce qu’il sait déjà.
Si des DBDs annoncent des nouveaux états de lien ou des mises à jour d’état de lien, le routeur qui les reçoit entre alors en état Loading et envoie des paquets LSR (Type 3) à propos des nouvelles informations. En réponse aux paquets LSR, l’autre enverra des informations complètes d’état de lien des paquets LSUs (Type 4). Les LSUs transportent des états de lien, des LSAs.
Les routeurs confirment la réception des LSAs en envoyant des paquets LSAck (Type 5), qui contiennent une correspondance aux numéros de séquences envoyés dans les LSAs.
Quand l’état Loading est terminé, les routeurs entrent en Full Adjacency. Il faudra qu’ils entrent dans cet état avant de créer leur table de routage et de router le trafic. À ce moment, les routeurs d’une même zone ont une base de données d’état de lien identique.
3.3. Messages Type 3 LSR
3.4. Message Type 4 LSU
3.5. Message Type 5 LSAck
3.6. Types de LSAs
- Type 1 - Router LSA - Le routeur annonce sa présence et liste les liens vers les autres routeurs ou réseaux dans la même zone, avec leur métrique. Les LSAs Type 1 sont envoyés par inondation seulement au sein de la zone.
- Type 2 - Network LSA - Le DR (designated router) envoie sur un segment multi-accès (comme Ethernet) la liste des routeurs qui sont sur le même segment. Ils ne sont propagés uniquement au sein de la zone. On y trouve l’adresse du DR.
- Type 3 - Summary LSA - Un ABR envoie des informations résumées d’une autre zone.
- Type 4 - ASBR-Summary LSA - Ils ajoutent une information de l’ABR concernant une route externe propagée par inondation dans toutes les zones de type 5 External LSA.
- Type 5 - External LSA - Ce type de LSA contient des informations injectées dans OSPF via un autre processus. Ils sont envoyés par inondation dans toutes les zones (sauf les zones stub et NSSA)
- Les LSAs de type 6 à 11 sont en dehors des sujets du CCNA.
3.7. Base de données d’états de lien
R2#sh ip ospf database database-summary | begin Process 1
Process 1 database summary
LSA Type Count Delete Maxage
Router 2 0 0
Network 1 0 0
Summary Net 2 0 0
Summary ASBR 1 0 0
Type-7 Ext 0 0 0
Opaque Link 0 0 0
Opaque Area 0 0 0
Type-5 Ext 1 0 0
Prefixes redistributed in Type-5 0
Opaque AS 0 0 0
Non-self 6
Total 7 0 0
3.8. Captures
- R2 redémarre en OSPFv2 : https://www.cloudshark.org/captures/7c22ce5a7b90
- R2 redémarre en OSPFv3 : https://www.cloudshark.org/captures/7c22ce5a7b90