Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

Informations générales

État Exstart

État Exchange

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

Solution

Informations connexes

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

Conditions requises

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.

Components Used

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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

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, référez-vous àDépanner 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 à É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, la sortie dushow 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 recréation 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) :

Configuration du Routeur 6

Configuration du Routeur 7

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. Utilisezdebug ip packetet debug ip ospf adjsur chaque routeur pour voir le processus de contiguïté OSPF au fur et à mesure de son exécution. 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 le 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 suivent le numéro de séquence principal. Cette boucle se poursuit indéfiniment, ce qui empêche l'un 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.

Note: 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 la MTU d'interface dans les paquets DBD, qui est conforme à la OSPFRFC 2178, annexe G.9. Quand un routeur reçoit un paquet DBD qui est annoncé une MTU plus grande que le routeur peut recevoir, le routeur ignore le paquet DBD et l'état 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), laip ospf mtu-ignoreLa commande de configuration d'interface 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 Cisco Catalyst 5000 avec un module de commutation de route (RSM) 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 1500, et l'interface FDDI sur le routeur 2 a une MTU de 4500. 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 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, cetteip ospf mtu-ignoreest 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-correspondance 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é. Cela est vrai, sauf si vous avez une liaison point à point, auquel cas il envoie un paquet de multidiffusion. En voici les causes possibles :

- Mappage incorrect de circuits virtuels 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 de la norme OSPFRFC 2328 indique que le processus Exstart/Exchange est lancé pour l'un de ces événements (dont l'un peut être causé 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

- Support technique - Cisco Systems