IP : Protocole OSPF (Open Shortest Path First)

Pourquoi les voisins OSPF sont-ils bloqués en état Exstart/Exchange ?

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Les états d'OSPF pour la formation de contiguïté sont Down, Init, Attempt, 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 d'OSPF ayant pour résultat l'état exstart/exchange. Pour plus de détails sur la résolution de problèmes d'OSPF, référez-vous à la résolution de problèmes d'OSPF.

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient être au courant de l'exécution de base et de la configuration OSPF, particulièrement au sujet des états des voisins OSPF.

Composants utilisés

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

  • Routeur Cisco 2503

  • Exécution de version de logiciel 12.2(24a) de½ du¿Â du Cisco IOSï sur les deux Routeurs

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

État d'Exstart

Après que deux routeurs voisins OSPF établissent la communication bidirectionnelle et se terminent l'élection DR/BDR (sur des réseaux multi-accès), la transition de Routeurs à l'état d'exstart. Dans cet état, les routeurs voisins établissent des relations master/slave et déterminent le numéro de séquence initial du descripteur de base de données (DBD) pour les utiliser tout en permutant des paquets DBD.

État d'échange

Une fois que les relations master/slave ont été négociées (le routeur avec l'ID du routeur le plus élevé devient le maître), la transition de routeurs voisins dans l'état d'échange. Dans cet état, les Routeurs permutent les paquets DBD, qui décrivent leur ensemble de la base de données d'états de liens. Les Routeurs envoient également les paquets de requête d'état de liaison, qui demandent des annonces plus récentes d'état de lien (LSA) des voisins.

Bien que la transition de voisins OSPF par les états d'exstart/échange pendant le processus de création de contiguïté normal OSPF, il ne soit pas normale pour que les voisins OSPF soient coincés dans cet état. Est ci-dessous la raison la plus commune que les voisins OSPF sont bloqué dans cet état. Référez-vous aux états des voisins OSPF pour se renseigner plus sur les différents états OSPF.

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

Le problème se pose le plus souvent en tentant d'exécuter l'OSPF le routeur entre un routeur de Cisco et d'un constructeur différent. Le problème se pose quand les configurations de Maximum Transmission Unit (MTU) pour des interfaces de routeur voisin ne s'assortissent pas. Si le routeur avec le MTU plus élevé envoie un paquet plus grand que le MTU réglé sur le routeur voisin, le routeur voisin ignore le packet.0 quand ce problème se pose, la sortie de la commande de show ip ospf neighbor affiche la sortie semblable qui affiché ci-dessous.

Une récréation réelle de ce problème est décrite dans cette section.

/image/gif/paws/13684/12a_01.gif

Le routeur 6 et le routeur 7 dans la topologie ci-dessus sont connectés par l'intermédiaire du Relais de trames et le routeur 6 a été configuré avec 5 artères statiques redistribuées dans l'OSPF. L'interface série sur le routeur 6 a le MTU par défaut de 1500, alors que l'interface série sur le routeur 7 a un MTU de 1450. Chaque configuration de routeur est affichée dans la table ci-dessous (seulement les informations de configuration nécessaires sont affichées) :

Configuration du routeur 6 Configuration du routeur 7
interface Serial2

!--- MTU sets to it's 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 170.170.11.6 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 101
!
router ospf 7
redistribute static subnets
network 170.170.11.0 0.0.0.255 area 0

ip route 192.79.34.0 255.255.255.0 Null0
ip route 192.79.35.0 255.255.255.0 Null0
ip route 192.79.36.0 255.255.255.0 Null0
ip route 192.79.37.0 255.255.255.0 Null0
ip route 192.79.38.0 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 170.170.11.7 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 110!
!

router ospf 7
network 170.170.11.0 0.0.0.255 area 0

La sortie de commande de show ip ospf neighbor pour chaque routeur est :

router-6# show ip ospf neighbor

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

router-7# show ip ospf neighbor

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

Le problème se pose quand le routeur 6 envoie à un paquet DBD de plus grands que 1450 octets (MTU de routeur 7's) tandis que dans l'état d'échange. Utilisez le debug ip packet et les commandes de debug ip ospf adj sur chaque routeur de voir le processus de contiguïté OSPF comme il a lieu. La sortie du routeur 6 et 7 des étapes 1 14 est :

  1. Sortie de débogage du routeur 6 :

    ***ROUTER6 IS SENDING HELLOS BUT HEARS NOTHING, 
    STATE OF NEIGHBOR IS DOWN
    00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on 
    Serial2.7 is dead
    00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 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 :

    ***ROUTER6 SENDING HELLOS
    00:03:53: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), len 64, sending broad/multicast, proto=89
    00:04:03: IP: s=170.170.11.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 ROUTER7, BEGINS SENDING 
    HELLOS AND BUILDING A ROUTER LSA
    00:17:44: IP: s=170.170.11.7 (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 170.170.11.7, seq 0x80000001
  6. Sortie de débogage du routeur 6 :

    ***RECEIVE HELLO FROM ROUTER7
    00:04:04: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
    Len 64, rcvd 0, proto=89
    00:04:04: OSPF: Rcv hello from 170.170.11.7 area 0 from 
    Serial2.7 170.170.11.7
    00:04:04: OSPF: End of hello processing
  7. Sortie de débogage du routeur 6 :

    ***ROUTER6 SEND HELLO WITH ROUTER7 ROUTERID 
    IN THE HELLO PACKET
    00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 68, sending broad/multicast, proto=89
  8. Sortie de débogage du routeur 7 :

    ***ROUTER7 RECEIVES HELLO FROM ROUTER6 CHANGES 
    STATE TO 2WAY
    00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
    Len 68, rcvd 0, proto=89
    00:17:53: OSPF: Rcv hello from 170.170.11.6 area 0 from 
    Serial0.6 170.170.11.6
    00:17:53: OSPF: 2 Way Communication to 170.170.11.6 on 
    Serial0.6, state 2WAY
  9. Sortie de débogage du routeur 7 :

    ***ROUTER7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD
    00:17:53: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32
    00:17:53: IP: s=170.170.11.7 (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 :

    ***ROUTER6 RECEIVES ROUTER7'S INITIAL DBD PACKET 
    CHANGES STATE TO 2-WAY
    00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:04:13: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
    00:04:13: OSPF: 2 Way Communication to 170.170.11.7 on 
    Serial2.7, state 2WAY
  11. Sortie de débogage du routeur 6 :

    ***ROUTER6 SENDS DBD PACKET TO ROUTER7 
    (MASTER/SLAVE NEGOTIATION - ROUTER6 IS SLAVE)
    00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
    seq 0xE44 opt 0x2 flag 0x7 Len 32
    00:04:13: IP: s=170.170.11.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 ROUTER6'S INITIAL DBD PACKET 
    (MTU MISMATCH IS RECOGNIZED)
    00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:17:53: OSPF: Rcv DBD from 170.170.11.6 on Serial0.6 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
    00:17:53: OSPF: Nbr 170.170.11.6 has larger interface MTU 
  13. Sortie de débogage du routeur 6 :

    ***SINCE ROUTER6 IS SLAVE SEND DBD PACKET WITH 
    LSA HEADERS, 
    SAME SEQ# (0x13FD) TO ACK ROUTER7'S DBD. (NOTE SIZE OF PKT)
    00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x2 Len 1472
    00:04:13: IP: s=170.170.11.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=170.170.11.7 (local), d=224.0.0.5 
    (Serial0.6), Len 68, sending broad/multicast, proto=89
    00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
    Retransmitting DBD to 170.170.11.6 on Serial0.6 [1]

En ce moment, le routeur 6 continue à essayer à l'ACK le paquet de l'initiale DBD du routeur 7.

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

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

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

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

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

Le routeur 7 n'obtient jamais un ACK du routeur 6 parce que le paquet DBD du routeur 7 est trop grand pour le MTU du routeur 7. Le routeur 7 retransmet à plusieurs reprises le paquet DBD.

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

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

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

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

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

Puisque le routeur 6 a un MTU plus élevé, il continue à recevoir le paquet DBD du routeur 7, des tentatives de les reconnaître, et des restes dans l'état d'ÉCHANGE.

Puisque le routeur 7 a un MTU inférieur, il ignore les paquets DBD avec l'ACK du routeur 6, continue à retransmettre le paquet de l'initiale DBD, et reste dans l'état EXSTART.

Regardons certaines des étapes ci-dessus. Dans l'étape 9 et 11, le routeur 7 et le routeur 6 envoient leurs premiers paquets DBD avec l'indicateur 0x7 réglé en tant qu'élément de la négociation master/slave. Après détermination master/slave, le routeur 7 est élu car le maître en raison de lui est un router-id plus élevé. Les indicateurs dans les étapes 13 et 14 prouve clairement que le routeur 7 est maître (l'indicateur 0x7) et le routeur 6 est esclave (indicateur 0x2).

Dans l'étape 10, le routeur 6 reçoit le paquet et les transitions initiaux du routeur 7 DBD son état à bidirectionnel.

Dans l'étape 12, le routeur 7 reçoit le paquet initial du routeur 6 DBD et identifie une non-concordance de MTU. (Le routeur 7 peut identifier une non-concordance de MTU parce que le routeur 6 inclut son interface MTU dans le domaine d'interface MTU du paquet DBD). Le routeur 6 DBD initial est rejeté par le routeur 7. que le routeur 7 retransmet le paquet de l'initiale DBD.

Étape 13 prouve que le routeur 6, comme esclave, adopte le routeur 7 numéros de séquence et envoie son deuxième paquet DBD contenant les en-têtes de son LSAs, qui augmente la taille du paquet. Cependant, le routeur 7 ne reçoit jamais ce paquet DBD parce qu'il est plus grand que le MTU du routeur 7.

Après l'étape 13, le routeur 7 continue à retransmettre le paquet de l'initiale DBD au routeur 6, alors que le routeur 6 continue à envoyer les paquets DBD qui suivent le numéro de séquence principal. Cette boucle continue indéfiniment, qui empêche l'un ou l'autre de routeur de la transition hors de l'état d'exstart/échange.

La solution

Puisque le problème est provoqué par par des mtu mal adaptés, la solution est de changer l'un ou l'autre de MTU de routeur pour apparier le MTU voisin. Notez que le Cisco IOS ne prend en charge pas un Chang du MTU physique sur une interface de RÉSEAU LOCAL (telle que les Ethernets ou l'Anneau à jeton). Quand le problème se pose entre un routeur de Cisco et un routeur différent de constructeur au-dessus des medias de RÉSEAU LOCAL, ajustez le MTU sur l'autre routeur de constructeur.

Remarque: Détection de non-concordance d'interface MTU introduite par Logiciel Cisco IOS version 12.0(3). Cette détection implique l'OSPF annonçant l'interface MTU dans les paquets DBD, qui est conforme au RFC 2178 OSPFleavingcisco.com , l'annexe G.9. Quand un routeur reçoit un paquet DBD annonçant un MTU plus grand que le routeur peut recevoir, le routeur ignore le paquet DBD et l'état de voisinage demeure dans l'exstart. Ceci empêche la formation d'une contiguïté. Pour réparer ce problème, assurez-vous que le MTU sont identique sur les deux fins d'un lien.

En logiciel de Cisco IOS 12.01(3), la commande de configuration d'interface d'ip ospf mtu-ignore a été également introduite d'arrêter la détection de non-concordance de MTU ; cependant, ceci est nécessaire seulement dans des exemples rares, suivant les indications de ce diagramme :

12b.gif

Le diagramme ci-dessus affiche un port du Fiber Distributed Data Interface (FDDI) sur Cisco Catalyst 5000 avec un module de route switch (RSM) connecté à une interface FDDI sur le Router2. Le RÉSEAU LOCAL virtuel (VLAN) sur le RSM est une interface Ethernet virtuelle avec un MTU de 1500, et l'interface FDDI sur le Router2 a un MTU de 4500. Quand un paquet est reçu sur le port FDDI du commutateur, il va au fond de panier et le FDDI à la conversion/à fragmentation d'Ethernets se produit dans le commutateur lui-même. C'est une installation valide, mais avec la configuration de détection de non-concordance de MTU, la contiguïté OSPF n'est pas formée entre le routeur et le RSM. Puisque le FDDI et le MTU d'Ethernets sont différents, cette commande d'ip ospf mtu-ignore est utile sur l'interface VLAN du RSM de sorte que l'OSPF cesse de détecter la non-concordance de MTU et forme la contiguïté.

Il est important de noter que la non-concordance de MTU, bien que le plus commun, n'est pas la seule raison que les voisins OSPF sont bloqué dans l'état d'exstart/échange. Le problème le plus souvent est provoqué par l'incapacité de permuter avec succès des paquets DBD. Cependant, la cause principale a pu être l'une des ceux-ci :

  • Non-concordance de MTU

  • Unicast est cassé. Dans l'état d'exstart, le routeur envoie un paquet monodiffusion au voisin pour élire le maître et l'esclave. C'est vrai à moins que vous ayez un lien point par point, dans ce cas il envoie un paquet de multidiffusion. En voici les causes possibles :

    • Mappage faux de circuit virtuel (circuit virtuel) dans un Mode de transfert asynchrone (ATM) ou environnement de relais de trame dans fortement le réseau redondant.

    • Le problème de MTU, signifiant les Routeurs peut seulement cingler un paquet d'une certaine longueur.

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

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

  • Voisin entre le PRI et le BRI/dialer.

  • Les deux Routeurs ont le même ID de routeur (SIG-configuration).

En outre, le RFC 2328 OSPFleavingcisco.com , la section 10.3, déclare que l'exstart/processus d'échange est initié pour l'un de ces événements (dont pourrait en sont provoqué par par des problèmes logiciels de logiciel interne) :

  • SequenceNumberMismatch

    • Numéro de séquence inattendu densité double

    • « Je » bit est placé inopinément

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

  • BadLSReq

    • Le voisin envoie le LSA non reconnu pendant le processus d'échange.

    • Le voisin a demandé un LSA pendant le processus d'échange qui ne peut pas être trouvé

Quand l'OSPF ne forme pas des voisins, considérez les facteurs mentionnés ci-dessus, comme les medias et le matériel réseau physiques, afin de dépanner le problème.


Informations connexes


Document ID: 13684