J’ai décidé d’écrire cet article pour raconter mon histoire avec la commande « ip ospf mtu-ignore », il s’agit d’un ticket que j’avais traité récemment qui concerne le protocole OSPF et plus précisément l’établissement d’une session OSPF entre deux voisins.

Dans le ticket en question, le client me précise que la session OSPF stagne dans l’étape « Loading » et ne passe jamais à la phase « Full », sachant que la session était fonctionnelle avant sa réinitialisation. Ceux qui connaissent le fonctionnement du protocole OSPF, savent que dans la phase « Loading », le routeur en question demande à son voisin des LSA via « LS Request » mais il ne l’est pas reçu via des « LS Update ».

Pourquoi ses LSA n’arrivent pas?, est-ce qu’ils sont bloqués quelque part dans le chemin ?, ou le routeur voisin n’a pas reçu de base le LS Request pour répondre ?, pourquoi ça fonctionnait avant ?.

Je sais que je vous dois une réponse claire sur le sujet, c’est pour cela j’ai monté une petite maquette pour simuler une architecture OSPF simple, puis j’ai utilisé Wireshark pour capturer le trafic OSPF.

Au départ, la maquette est composée de deux routeurs, R1 et R2 connectés entre eux via un lien point à point direct et le protocole OSPF est utilisé pour échanger leurs réseaux LAN (représentés par des interfaces Loopback) respectifs.

La configuration OSPF des deux routeurs est comme suit :

La configuration du routeur R1 :

interface Loopback0

ip address 1.1.1.1 255.255.255.255

ip ospf network point-to-point

!

interface GigabitEthernet0/0

ip address 192.168.12.1 255.255.255.0

ip ospf network point-to-point

!

router ospf 1

router-id 1.1.1.1

network 0.0.0.0 255.255.255.255 area 0

La configuration du routeur R2 :

interface Loopback0

ip address 2.2.2.2 255.255.255.255

ip ospf network point-to-point

!

interface GigabitEthernet0/0

ip address 192.168.12.2 255.255.255.0

ip ospf network point-to-point

!

router ospf 1

router-id 2.2.2.2

network 0.0.0.0 255.255.255.255 area 0

Une fois la configuration est effective dans les deux routeurs, la session OSPF est montée entre eux et un message de log montre bien que la session OSPF est passé de l’étape Loading à Full.

*Nov 19 06:28:09.032: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0 from LOADING to FULL, Loading Done[OK]

Rappel du concept OSPF Flooding

Le principe est simple, chaque routeur demande à son voisin via un LS Request l’ensemble des LSAs qu’il ne connait pas, ou tout simplement qu’il a constaté que son voisin en possède une version plus récente de ses LSA, observés dans les messages Database description (DD) lors de la phase « Exchange », le voisin s’en charge à lui y transmettre via des LS Update.

La capture Wireshark ci-dessous illustre le principe :

Imaginons pour l’instant que l’architecture a évolué dans le temps et vous avez créé 150 Vlans supplémentaires (Représentés par des interfaces Loopaback créés dans le R1) et vous avez aussi augmenté la taille MTU des interfaces du R1 et R2 pour permettre aux baies de stockage connectées derrière ces routeurs d’utiliser les Jumbo Frames pour une meilleure performances IO.

Finalement vous avez rajouté un 3ème routeur (R3) derrière R2 pour se connecter au réseau WAN. L’interface d’interconnexion entre R2 et R3 est positionnée dans l’Area 0

La nouvelle architecture est illustrée ci-dessous :

La session OSPF entre R1 et R2 est toujours opérationnelle et R2 reçoit belle est bien l’ensemble des routes annoncées par R1.

R2#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

1.1.1.1 0 FULL/ - 00:00:39 192.168.12.1 GigabitEthernet0/0

R2#sh ip route ospf

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

a - application route

+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 150 subnets

O 1.1.1.1 [110/2] via 192.168.12.1, 03:34:01, GigabitEthernet0/0

O 1.1.1.2 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.3 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.4 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.5 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.6 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.7 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.8 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.9 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.10 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.11 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.12 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.13 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.14 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.15 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.16 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.17 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.18 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.19 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.20 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.21 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.22 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.23 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

O 1.1.1.24 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

….

O 1.1.1.150 [110/2] via 192.168.12.1, 00:05:19, GigabitEthernet0/0

En revanche la session OSPF avec R3 ne monte pas, en lançant un debug, on reçoit un message d’erreur expliquant que le taille MTU des deux interfaces n’est pas identique.

*Nov 24 19:55:21.695: OSPF-1 ADJ Gi0/1: Nbr 3.3.3.3 has smaller interface MTU

*Nov 24 19:55:21.695: OSPF-1 ADJ Gi0/1: Send DBD to 3.3.3.3 seq 0x1D67 opt 0x52 flag 0x2 len 72

*Nov 24 19:55:26.527: OSPF-1 ADJ Gi0/1: Rcv DBD from 3.3.3.3 seq 0x1D67 opt 0x52 flag 0x7 len 32 mtu 1500 state EXCHANGE

COMMENT OSPF détecte la valeur de la taille MTU de son voisin ?

Cette information se trouve dans les paquets Database Description (DD) échangés entre les voisins OSPF dans la phase Exstart/exchange. La taille MTU permet à chaque routeur OSPF de connaitre la taille maximale du paquet IP qu’il pourrait envoyer à son voisin sans fragmentation.

Pour corriger ce problème, vous avez décidé d’utiliser la commande « IP ospf mtu-ignore » au niveau de l’interface d’interconnexion GigabitEthernet0/1.

interface GigabitEthernet0/1

mtu 9600

ip address 192.168.23.2 255.255.255.0

ip ospf network point-to-point

ip ospf mtu-ignore

Et là vous constatez que la session OSPF côté R3 stagne dans la phase « Loading » pendant un certain temps puis bascule vers Down.

R3#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

2.2.2.2 0 LOADING/ - 00:00:33 192.168.23.2 GigabitEthernet0/0

R3#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

2.2.2.2 0 LOADING/ - 00:00:32 192.168.23.2 GigabitEthernet0/0

R3#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

2.2.2.2 0 LOADING/ - 00:00:31 192.168.23.2 GigabitEthernet0/0

R3#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

2.2.2.2 0 LOADING/ - 00:00:39 192.168.23.2 GigabitEthernet0/0

R3#

*Nov 25 08:25:51.868: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from LOADING to DOWN, Neighbor Down: Too many retransmissions

Pourtant, côté R2 la session est en phase « Full »

R2#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

3.3.3.3 0 FULL/ - 00:00:38 192.168.23.3 GigabitEthernet0/1

1.1.1.1 0 FULL/ - 00:00:36 192.168.12.1 GigabitEthernet0/0

Selon le RFC 2328:

Loading

“In this state, Link State Request packets are sent to the

neighbor asking for the more recent LSAs that have been

discovered (but not yet received) in the Exchange state.”

Cela signifie que R3 a envoyé un LSA Request à R2 mais il n’a pas eu un LS Update, Allons vérifier ce qui se passe en capturant le trafic à destination du R3 à l’aide de Wireshark.

Contre toute attente, R3 reçoit bien le LS Update

Pourquoi R3 ne traite pas le LS Update en provenance du R2 ?

Tout simplement parce que la taille du paquet contenant le LS UPDATE (1896 octets ) envoyé par R2 est supérieure à la taille MTU de l’interface d’interconnexion du R3, par conséquent R3 drop le LS Update envoyés par R2.

Résultat : 

La base de données OSPF du R3 n’est jamais synchronisée avec les autres routeurs de la même Area ce qui introduit de l’instabilité au sein de l’Area OSPF.

Solution :

S’assurer que la taille MTU est identique dans l’ensemble des interfaces d’interconnexion OSPF, et n’utiliser la commande « ip ospf mtu-ignore » que pour débloquer temporairement la situation après vérification que la taille des LS Update ne dépasse pas la taille MTU inférieure dans le chemin.

IL existe une autre solution pour corriger le problème sans toucher à la configuration du R3. Connaissez-vous cette solution ?  n’hésitez pas à la décrire en commentaire!!!

Si vous avez des questions, un autre avis sur le sujet ou vous avez besoin d’un complément d’informations, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.

Author

Driss JABBAR Un Architect réseaux avec plus de 10 ans d'expérience dans la conception et l'implémentation des architectures complexes LAN/WAN/DC. Pendant son parcours professionnelle, Driss a travaillé chez des intégrateurs et aussi des opérateurs. Driss possède actuellement trois certifications d'expertise Cisco CCIE RS & SP et CCDE. En dehors du travail, Driss consacre plus de temps pour sa famille mais il réserve toujours un petit créneau pour apprendre des nouvelles technologies ou pour regarder un match de foot de son club préféré. Driss est contributeur du blog MHD et joignable à l’adresse : driss.jabbar@mhd-experts.com

3 Comments

  1. Sylvain SAMBOURG Reply

    Utiliser une autre aire pour le voisinage entre R2 et R3 ?

  2. islame tirichine Reply

    c’est quoi la différance entre le problème de mtu mismatch qui >>> stagne dans la phase « Loading » et a la phase Exstart
    , et svp la autre solution que ip ospf mtuignore ??
    merci pour l’explication.

    • Si la valeur MTU est différentes entre deux voisins OSPF, Celui avec la valeur MTU supérieur pourrait envoyer des paquets LSU large ≥ plus large que la taille MTU de l’interface de son voisin. le voisin ignorera ses paquets. Dans cette étape le statut de la session OSPF côté premier routeur est Loading et celui du deuxième est Exstart.

      Concernant l’autre solution, c’est bien annoncer les LSA en Type 5.

Write A Comment