Dépanner les voisins Open Shortest Path First bloqués dans l'état Exstart/Exchange

Introduction

Ce document décrit comment dépanner les situations dans lesquelles les voisins OSPF (Open Shortest Path First) sont bloqués dans les états Exstart et Exchange. 

Conditions préalables

Exigences

Il est recommandé que l'utilisateur soit familiarisé avec le fonctionnement et la configuration OSPF de base, en particulier avec les états de voisinage OSPF.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Routeurs Cisco 2503

• Logiciel Cisco IOS^® version 12.2(24a) à exécuter sur les deux routeurs

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

Les états OSPF pour la formation de contiguïté sont Down, Init, 2-way, Exstart, Exchange, Loading et Full. Il peut y avoir nombre de raisons pour lesquelles les voisins d'Open Shortest Path First (OSPF) sont coincés dans l'état exstart/exchange. Ce document se concentre sur une non-concordance de MTU entre les voisins OSPF qui résulte en l'état Exstart/Exchange. Pour plus de détails sur la façon de dépanner OSPF, consultez Dépanner des problèmes courants avec OSPF .

État Exstart

Une fois que deux routeurs voisins OSPF ont établi une communication bidirectionnelle et terminé la sélection DR/BDR (sur les réseaux à accès multiple), les routeurs passent à l’état Exstart. Dans cet état, les routeurs voisins établissent une relation Primaire/Subordonné et déterminent le numéro de séquence du descripteur de base de données (DBD) initial à utiliser pendant l'échange des paquets DBD.

État Exchange

Une fois le Primary/Subordinate a été négociée (le routeur dont l'ID de routeur est le plus élevé devient le routeur principal), les routeurs voisins passent à l'état Exchange. Dans cet état, les routeurs échangent des paquets DBD, qui décrivent l'intégralité de leur base de données d'état des liaisons. Les routeurs envoient également des paquets de requête d’état de liens, qui demandent des LSA (Link-State Advertisements) plus récentes aux voisins.

Bien que les voisins OSPF passent par les états Exstart/Exchange pendant le processus normal de création de contiguïté OSPF, il n'est pas normal que les voisins OSPF soient bloqués dans cet état. La section suivante décrit la raison la plus courante pour laquelle les voisins OSPF sont bloqués dans cet état. Référez-vous à Comprendre les états de voisinage OSPF pour en savoir plus sur les différents états OSPF.

Voisins bloqués dans l'état Exstart/Exchange

Le problème se produit le plus souvent lorsque vous tentez d'exécuter OSPF entre un routeur Cisco et un routeur d'un autre fournisseur. Le problème se produit lorsque les paramètres de l'unité de transmission maximale (MTU) pour neighboring les interfaces du routeur ne correspondent pas. Si le routeur avec la MTU supérieure envoie un paquet plus grand que la MTU définie sur le routeur voisin, le routeur voisin ignore le paquet. Lorsque ce problème se produit, le résultat de la commande show ip ospf neighbor affiche un résultat similaire à celui illustré dans cette figure.

Les routeurs 6 et 7 se connectent via Frame Relay

Cette section décrit une reconstitution réelle de ce problème.

Les routeurs 6 et 7 de cette figure sont connectés via Frame Relay et le routeur 6 a été configuré avec 5 routes statiques redistribuées dans OSPF. L’interface série du routeur 6 a une MTU par défaut de 1 500, tandis que l’interface série du routeur 7 a une MTU de 1 450. Chaque configuration de routeur est indiquée dans le tableau (seules les informations de configuration nécessaires sont indiquées) :

interface Serial2

!--- MTU is set to its default value of 1500.

 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay lmi-type ansi
!
interface Serial2.7 point-to-point
 ip address 10.170.10.6 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 101
!
router ospf 7
 redistribute static subnets
 network 10.170.10.0 0.0.0.255 area 0
!
ip route 192.168.0.10 255.255.255.0 Null0
ip route 192.168.10.10 255.255.255.0 Null0
ip route 192.168.10.0 255.255.255.0 Null0
ip route 192.168.37.10 255.255.255.0 Null0
ip route 192.168.38.10 255.255.255.0 Null0

interface Serial0
 mtu 1450
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 frame-relay lmi-type ANSI
!
interface Serial0.6 point-to-point
 ip address 172.16.7.11 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 110
!
router ospf 7
 network 172.16.11.6 0.0.0.255 area 0

Le résultat de la commande show ip ospf neighbor pour chaque routeur est :

router-6#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.7.11      1   EXCHANGE/  -    00:00:36    172.16.7.11    Serial2.7
router-6#

router-7#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.170.10.6      1   EXSTART/  -     00:00:33    10.170.10.6    Serial0.6
router-7#

Le problème se produit lorsque le routeur 6 envoie un paquet DBD de plus de 1 450 octets (MTU du routeur 7) alors qu'il est en état d'échange. Utilisez debug ip packet et debug ip ospf adj sur chaque routeur pour voir le processus de contiguïté OSPF au fur et à mesure qu’il se déroule. Le résultat des étapes 1 à 14 pour les routeurs 6 et 7 est le suivant :

1. Sortie de débogage du routeur 6 :

   <<<ROUTER 6 IS SENDING HELLOS BUT HEARS NOTHING, STATE OF NEIGHBOR IS DOWN>>>
   
   00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
   Serial2.7 is dead
   00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
   Serial2.7 is dead, state DOWN

2. Sortie de débogage du routeur 7 :

   <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

3. Sortie de débogage du routeur 6 :

   <<<ROUTER 6 SENDING HELLOS>>>
   
   00:03:53: IP: s=10.170.10.6 (local), d=224.0.0.5 
   (Serial2.7), len 64, sending broad/multicast, proto=89
   00:04:03: IP: s=10.170.10.6 (local), d=224.0.0.5 
   (Serial2.7), Len 64, sending broad/multicast, proto=89

4. Sortie de débogage du routeur 7 :

   <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

5. Sortie de débogage du routeur 7 :

   <<<OSPF ENABLED ON ROUTER 7, BEGINS SENDING HELLOS AND BUILDING A ROUTER LSA>>>
   
   00:17:44: IP: s=172.16.7.11 (local), d=224.0.0.5 
   (Serial0.6), Len 64, sending broad/multicast, proto=89
   00:17:44: OSPF: Build router LSA for area 0, 
   router ID 172.16.7.11, seq 0x80000001

6. Sortie de débogage du routeur 6 :

   <<<RECEIVE HELLO FROM ROUTER7>>>
   
   00:04:04: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
   Len 64, rcvd 0, proto=89
   00:04:04: OSPF: Rcv hello from 172.16.7.11 area 0 from 
   Serial2.7 172.16.7.11
   00:04:04: OSPF: End of hello processing

7. Sortie de débogage du routeur 6 :

   <<<ROUTER 6 SEND HELLO WITH ROUTER7 ROUTERID IN THE HELLO PACKET>>>
   
   00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 
   (Serial2.7), Len 68, sending broad/multicast, proto=89

8. Sortie de débogage du routeur 7 :

   <<<ROUTER 7 RECEIVES HELLO FROM ROUTER6 CHANGES STATE TO 2WAY>>>
   
   00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
   Len 68, rcvd 0, proto=89
   00:17:53: OSPF: Rcv hello from 10.170.10.6 area 0 from 
   Serial0.6 10.170.10.6
   00:17:53: OSPF: 2 Way Communication to 10.170.10.6 on 
   Serial0.6, state 2WAY

9. Sortie de débogage du routeur 7 :

   <<<ROUTER 7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD>>>
   
   00:17:53: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
   seq 0x13FD opt 0x2 flag 0x7 Len 32
   00:17:53: IP: s=172.16.7.11 (local), d=224.0.0.5 
   (Serial0.6), Len 52, sending broad/multicast, proto=89
   00:17:53: OSPF: End of hello processing

10. Sortie de débogage du routeur 6 :

    <<<ROUTER 6 RECEIVES ROUTER7'S INITIAL DBD PACKET CHANGES STATE TO 2-WAY>>>
    
    00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:04:13: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
    00:04:13: OSPF: 2 Way Communication to 172.16.7.11 on 
    Serial2.7, state 2WAY

11. Sortie de débogage du routeur 6 :

    <<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE NEGOTIATION - ROUTER 6 IS SUBORDINATE)>>>
    
    00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 
    00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), 
    Len 52, sending broad/multicast, proto=89 
    00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE

12. Sortie de débogage du routeur 7 :

    <<<RECEIVE ROUTER 6'S INITIAL DBD PACKET (MTU MISMATCH IS RECOGNIZED)>>>
    
    00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:17:53: OSPF: Rcv DBD from 10.170.10.6 on Serial0.6 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
    00:17:53: OSPF: Nbr 10.170.10.6 has larger interface MTU 

13. Sortie de débogage du routeur 6 :

    <<<SINCE ROUTER 6 IS SUBORDINATE SEND DBD PACKET WITH LSA HEADERS, SAME SEQ# (0x13FD) TO ACK ROUTER 7'S DBD. (NOTE SIZE OF PKT)>>>
    
    00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x2 Len 1472 
    00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), 
    Len 1492, sending broad/multicast, proto=89

14. Sortie de débogage du routeur 7 :

    <<<NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, RETRANSMIT>>>
    
    00:17:54: IP: s=172.16.7.11 (local), d=224.0.0.5 
    (Serial0.6), Len 68, sending broad/multicast, proto=89
    00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
    Retransmitting DBD to 10.170.10.6 on Serial0.6 [1]

À ce stade, le routeur 6 continue d’essayer d’envoyer un accusé de réception au paquet DBD initial du routeur 7.

00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:04:13: OSPF: Rcv hello from 172.16.7.11 area 0 from
Serial2.7 172.16.7.11
00:04:13: OSPF: End of hello processing

00:04:18: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:18: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

00:04:18: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:18: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 1492, sending broad/multicast, proto=89

00:04:23: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

00:04:23: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:23: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

Le routeur 7 n’obtient jamais de réponse de la part du routeur 6, car le paquet DBD du routeur 7 est trop volumineux pour la MTU du routeur 7. Le routeur 7 retransmet le paquet DBD à plusieurs reprises.

0:17:58: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [2]

00:18:03: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:18:03: OSPF: Rcv hello from 10.170.10.6 area 0 from
Serial0.6 10.170.10.6
00:18:03: OSPF: End of hello processing

00:18:04: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89

00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [3]

00:18:08: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
router-7#

Comme le routeur 6 a un MTU plus élevé, il continue d’accepter le paquet DBD du routeur 7, tente de les accuser réception et reste dans l’état EXCHANGE.

Comme le routeur 7 a une MTU inférieure, il ignore les paquets DBD avec ACK du routeur 6, continue à retransmettre le paquet DBD initial et reste dans l'état EXSTART.

Aux étapes 9 et 11, les routeurs 7 et 6 envoient leurs premiers paquets DBD avec l'indicateur 0x7 défini dans le cadre de la négociation primaire/subordonnée. Après Primary/Subordinate , le routeur 7 est choisi comme routeur principal en raison de son ID de routeur plus élevé. Les indicateurs des étapes 13 et 14 indiquent clairement que le routeur 7 est principal (indicateur 0x7) et le routeur 6 est subordonné (indicateur 0x2).

À l'étape 10, le routeur 6 reçoit le paquet DBD initial du routeur 7 et passe de son état à l'état bidirectionnel.

À l'étape 12, le routeur 7 reçoit le paquet DBD initial du routeur 6 et reconnaît une non-concordance de MTU. (Le routeur 7 est capable de reconnaître une discordance de MTU, car le routeur 6 inclut sa MTU d'interface dans le champ MTU d'interface du paquet DBD). Le DBD initial du routeur 6 est rejeté par le routeur 7. Le routeur 7 retransmet le paquet DBD initial.

L'étape 13 montre que le routeur 6, comme subordinate, adopte le numéro de séquence du routeur 7 et envoie son deuxième paquet DBD qui contient les en-têtes de ses LSA, ce qui augmente la taille du paquet. Cependant, le routeur 7 ne reçoit jamais ce paquet DBD car il est plus grand que la MTU du routeur 7.

Après l'étape 13, le routeur 7 continue de retransmettre le paquet DBD initial au routeur 6, tandis que le routeur 6 continue d'envoyer des paquets DBD qui adhèrent au numéro de séquence principal. Cette boucle se poursuit indéfiniment, ce qui empêche l'un ou l'autre des routeurs de passer de l'état exstart/exchange.

Solution

Puisque le problème est causé par des MTU non concordants, la solution est de changer l'un des MTU de routeur pour correspondre au MTU voisin.

Remarque : la version 12.0(3) du logiciel Cisco IOS a introduit la détection de non-concordance MTU d'interface. Cette détection implique l'OSPF qui annonce le MTU d'interface dans les paquets DBD, qui est conforme à la RFC 2178 d'OSPF, annexe G.9. Lorsqu’un routeur reçoit un paquet DBD annoncé comme ayant une MTU supérieure à celle qu’il peut recevoir, il ignore le paquet DBD et l’état du voisin reste dans Exstart. Cela empêche la formation d'une contiguïté. Pour résoudre ce problème, assurez-vous que les MTU sont identiques aux deux extrémités d'une liaison.

Dans le logiciel Cisco IOS 12.01(3), la commande de configuration d'interface ip ospf mtu-ignore a également été introduite pour désactiver la détection de non-concordance MTU ; cependant, ceci n'est nécessaire que dans de rares cas, comme illustré dans ce schéma :

Port FDDI (Fiber Distributed Data Interface)

Le schéma précédent montre un port FDDI (Fiber Distributed Data Interface) sur un commutateur Cisco Catalyst 5000 avec un module RSM (Route Switch Module) connecté à une interface FDDI sur le routeur 2. Le réseau local virtuel (VLAN) sur le RSM est une interface Ethernet virtuelle avec une MTU de 1 500, et l'interface FDDI sur le routeur 2 a une MTU de 4 500. Lorsqu’un paquet est reçu sur le port FDDI du commutateur, il est envoyé au fond de panier et la conversion/fragmentation FDDI vers Ethernet se produit au sein du commutateur lui-même. Il s'agit d'une configuration valide, mais avec la fonctionnalité de détection de non-concordance de MTU, la contiguïté OSPF n'est pas établie entre le routeur et le RSM. Étant donné que FDDI et Ethernet MTU sont différents, cette commande ip ospf mtu-ignore est utile sur l'interface VLAN du RSM pour arrêter la détection OSPF d'une non-correspondance de MTU et former la contiguïté.

Il est important de noter que la non-concordance de MTU, bien que la plus courante, n'est pas la seule raison pour laquelle les voisins OSPF sont bloqués dans l'état Exstart/Exchange. Le problème est le plus souvent dû à l'incapacité d'échanger correctement des paquets DBD. Cependant, la cause première peut être l'une des suivantes :

• Non-concordance MTU

• La monodiffusion est interrompue. Dans l’état Exstart, le routeur envoie un paquet de monodiffusion au voisin pour sélectionner Primary et Subordonné. Ceci est vrai, sauf si vous avez une liaison point à point, auquel cas il envoie un paquet multicast. En voici les causes possibles :

  • Mappage de circuit virtuel incorrect dans un environnement ATM (Asynchronous Transfer Mode) ou Frame Relay dans un réseau hautement redondant.

  • Problème de MTU, ce qui signifie que les routeurs ne peuvent envoyer des requêtes ping qu’à un paquet d’une certaine longueur.

  • La liste d’accès bloque le paquet de monodiffusion.

  • NAT s’exécute sur le routeur et traduit le paquet de monodiffusion.

• Voisin entre PRI et BRI/dialer.

• Les deux routeurs ont le même ID de routeur (configuration incorrecte).

En outre, la section 10.3 du document OSPF RFC 2328 indique que le processus Exstart/Exchange est lancé pour l'un de ces événements (dont l'un peut être provoqué par des problèmes logiciels internes) :

• Non-concordance des numéros de séquence.

  • Numéro de séquence DD inattendu.

  • Le bit « I » est défini de manière inattendue.

  • Champ d'option différent du dernier champ d'option reçu dans le paquet DBD.

• BadLSReq

  • Le voisin envoie une LSA non reconnue pendant le processus d’échange.

  • Le voisin a demandé une LSA introuvable pendant le processus d'échange.

Lorsque le protocole OSPF ne forme pas de voisins, tenez compte des facteurs mentionnés précédemment, tels que le support physique et le matériel réseau, afin de résoudre le problème.

Informations connexes

• États des voisins OSPF
• Explication des problèmes de voisins OSPF
• Assistance technique et téléchargements Cisco