Fehlerbehebung: Open Shortest Path First Neighbors mit festem Exstart-/Exchange-Status

Einleitung

In diesem Dokument wird die Fehlerbehebung in Situationen beschrieben, in denen OSPF-Nachbarn (Open Shortest Path First) in den Status Exstart und Exchange feststecken. 

Voraussetzungen

Anforderungen

Es wird empfohlen, dass der Benutzer mit den grundlegenden OSPF-Betriebs- und Konfigurationsfunktionen vertraut ist, insbesondere mit den OSPF-Nachbarstatus.

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Cisco 2503 Router

• Cisco IOS^® Softwareversion 12.2(24a) für beide Router

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hintergrundinformationen

Die OSPF-Zustände für die Adjacency-Bildung sind Down, Init, 2-Wege, Exstart, Exchange, Loading und Full. Es kann mehrere Gründe geben, warum die Nachbarn von Open Shortest Path First (OSPF) im Status Exstart/Exchange feststecken. Dieses Dokument konzentriert sich auf eine MTU-Diskrepanz zwischen OSPF-Nachbarn, die zu einem Exstart-/Exchange-Status führt. Weitere Informationen zur Problembehandlung bei OSPF finden Sie unter Problembehandlung bei häufigen Problemen mit OSPF .

Exstart-Status

Nachdem zwei benachbarte OSPF-Router eine bidirektionale Kommunikation hergestellt und die DR/BDR-Auswahl (in Netzwerken mit mehreren Zugriffen) abgeschlossen haben, wechseln die Router in den Exstart-Status. In diesem Zustand stellen die benachbarten Router eine primäre/untergeordnete Beziehung her und bestimmen die Sequenznummer des DBD (Initial Database Descriptor), die beim Austausch der DBD-Pakete verwendet werden soll.

Wechselkursstatus

Sobald Primary/Subordinate -Beziehung ausgehandelt wurde (der Router mit der höchsten Router-ID wird zum primären Router), und die benachbarten Router wechseln in den Exchange-Status. In diesem Zustand tauschen die Router DBD-Pakete aus, die ihre gesamte Link-State-Datenbank beschreiben. Die Router senden außerdem Link-State-Anforderungspakete, die aktuellere Link-State-Advertisements (LSAs) von Nachbarn anfordern.

Obwohl OSPF-Nachbarn während des normalen OSPF-Adjacency-Building-Prozesses durch den Exstart/Exchange-Status wechseln, ist es nicht normal, dass OSPF-Nachbarn in diesem Status feststecken. Im nächsten Abschnitt wird der häufigste Grund dafür beschrieben, dass OSPF-Nachbarn in diesem Zustand feststecken. Weitere Informationen zu den verschiedenen OSPF-Zuständen finden Sie unter OSPF-Nachbarstaaten verstehen.

Nachbarn im Exstart-/Exchange-Status feststecken

Das Problem tritt am häufigsten auf, wenn Sie versuchen, OSPF zwischen einem Cisco Router und einem Router eines anderen Anbieters auszuführen. Das Problem tritt auf, wenn die Maximum Transmission Unit (MTU)-Einstellungen für neighboring Router-Schnittstellen stimmen nicht überein. Wenn der Router mit der höheren MTU ein Paket sendet, das größer ist als die auf dem benachbarten Router festgelegte MTU, ignoriert der Nachbar-Router das Paket. Wenn dieses Problem auftritt, wird die Ausgabe des show ip ospf neighbor zeigt eine Ausgabe an, die der Darstellung in dieser Abbildung ähnelt.

Router 6 und Router7 Verbindung über Frame-Relay

In diesem Abschnitt wird eine tatsächliche Wiederherstellung dieses Problems beschrieben.

Router 6 und Router 7 in dieser Abbildung sind über Frame-Relay verbunden, und Router 6 wurde mit fünf statischen Routen konfiguriert, die in OSPF umverteilt wurden. Die serielle Schnittstelle auf Router 6 hat die standardmäßige MTU von 1500, während die serielle Schnittstelle auf Router 7 eine MTU von 1450 hat. Jede Router-Konfiguration wird in der Tabelle angezeigt (nur die erforderlichen Konfigurationsinformationen werden angezeigt):

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

Der Befehl show ip ospf neighbor gibt für jeden Router Folgendes aus:

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#

Das Problem tritt auf, wenn Router 6 ein DBD-Paket sendet, das größer als 1450 Byte (MTU von Router 7) ist, während er sich im Austauschzustand befindet. Verwenden Sie debug ip packet und debug ip ospf adj -Befehlen auf jedem Router, um den OSPF-Adjacency-Prozess genau zu verfolgen. Die Ausgabe von Router 6 und 7 aus den Schritten 1 bis 14 lautet:

1. Router 6-Debug-Ausgabe:

   <<<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. Router 7-Debug-Ausgabe:

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

3. Router 6-Debug-Ausgabe:

   <<<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. Router 7-Debug-Ausgabe:

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

5. Router 7-Debug-Ausgabe:

   <<<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. Router 6-Debug-Ausgabe:

   <<<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. Router 6-Debug-Ausgabe:

   <<<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. Router 7-Debug-Ausgabe:

   <<<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. Router 7-Debug-Ausgabe:

   <<<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. Router 6-Debug-Ausgabe:

    <<<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. Router 6-Debug-Ausgabe:

    <<<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. Router 7-Debug-Ausgabe:

    <<<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. Router 6-Debug-Ausgabe:

    <<<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. Router 7-Debug-Ausgabe:

    <<<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]

An diesem Punkt versucht Router 6 weiterhin, das anfängliche DBD-Paket von Router 7 zu übernehmen.

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

Router 7 erhält nie eine Bestätigung von Router 6, da das DBD-Paket von Router 7 zu groß für die MTU von Router 7 ist. Router 7 sendet das DBD-Paket wiederholt weiter.

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#

Da Router 6 eine höhere MTU hat, akzeptiert er weiterhin das DBD-Paket von Router 7, versucht, sie zu bestätigen, und bleibt im EXCHANGE-Status.

Da Router 7 eine niedrigere MTU hat, ignoriert er die DBD-Pakete zusammen mit ACK von Router 6, sendet das anfängliche DBD-Paket weiter und bleibt im EXSTART-Status.

In den Schritten 9 und 11 senden Router 7 und Router 6 ihre ersten DBD-Pakete, bei denen das Flag 0x7 als Teil der primären/untergeordneten Aushandlung festgelegt wurde. Nach Primary/Subordinate Router 7 wird aufgrund seiner höheren Router-ID als Primary (Primär) ausgewählt. Die Markierungen in den Schritten 13 und 14 zeigen deutlich an, dass Router 7 primär (Markierung 0x7) und Router 6 untergeordnet (Markierung 0x2) ist.

In Schritt 10 empfängt Router 6 das erste DBD-Paket für Router 7 und wechselt seinen Status in den 2-Wege-Modus.

In Schritt 12 empfängt Router 7 das erste DBD-Paket von Router 6 und erkennt eine MTU-Diskrepanz. (Router 7 kann eine MTU-Diskrepanz erkennen, da Router 6 seine Schnittstellen-MTU in das Schnittstellen-MTU-Feld des DBD-Pakets aufnimmt). Das anfängliche DBD von Router 6 wird von Router 7 abgelehnt. Router 7 sendet das erste DBD-Paket erneut.

In Schritt 13 wird gezeigt, dass Router 6 subordinateverwendet die Sequenznummer für Router 7 und sendet das zweite DBD-Paket, das die Header der LSAs enthält, wodurch die Größe des Pakets erhöht wird. Router 7 empfängt dieses DBD-Paket jedoch nie, da es größer als die MTU von Router 7 ist.

Nach Schritt 13 sendet Router 7 weiterhin das erste DBD-Paket an Router 6, während Router 6 weiterhin DBD-Pakete sendet, die der primären Sequenznummer entsprechen. Diese Schleife wird unbegrenzt fortgesetzt, sodass keiner der Router den Übergang aus dem exstart/exchange-Status heraus vollziehen kann.

Lösung

Da das Problem durch nicht übereinstimmende MTUs verursacht wird, besteht die Lösung darin, eine der beiden Router-MTUs an die benachbarte MTU anzupassen.

Hinweis: In Version 12.0(3) der Cisco IOS Software wurde eine Erkennung von MTU-Diskrepanzen zwischen den Schnittstellen eingeführt. Diese Erkennung umfasst den OSPF, der die Schnittstellen-MTU in den DBD-Paketen ankündigt, entsprechend OSPF RFC 2178, Anhang G.9. Wenn ein Router ein DBD-Paket empfängt, für das eine MTU angekündigt wird, die größer ist als die, die der Router empfangen kann, ignoriert der Router das DBD-Paket, und der Nachbar-Status verbleibt in Exstart. Dadurch wird die Bildung einer Adjacency verhindert. Um dieses Problem zu beheben, stellen Sie sicher, dass die MTU an beiden Enden einer Verbindung gleich ist.

In Cisco IOS Software 12.01(3) wurde der Konfigurationsbefehl ip ospf mtu-ignore interface ebenfalls eingeführt, um die Erkennung von MTU-Diskrepanzen zu deaktivieren. Dies ist jedoch nur in seltenen Fällen erforderlich, wie in diesem Diagramm gezeigt:

Fiber Distributed Data Interface (FDDI)-Port

Das vorherige Diagramm zeigt einen FDDI-Port (Fiber Distributed Data Interface) auf einem Cisco Catalyst 5000 mit einem Route Switch Module (RSM), das mit einer FDDI-Schnittstelle auf Router 2 verbunden ist. Das virtuelle LAN (VLAN) auf dem RSM ist eine virtuelle Ethernet-Schnittstelle mit einer MTU von 1500, und die FDDI-Schnittstelle auf Router 2 hat eine MTU von 4500. Wenn ein Paket am FDDI-Port des Switches empfangen wird, wird es an die Backplane gesendet, und die Umwandlung/Fragmentierung von FDDI in Ethernet findet innerhalb des Switches selbst statt. Dies ist eine gültige Konfiguration, aber mit der Funktion zur Erkennung von MTU-Diskrepanzen wird keine OSPF-Adjacency zwischen dem Router und dem RSM gebildet. Da sich FDDI und Ethernet-MTU unterscheiden, ist dieser Befehl ip ospf mtu-ignore auf der VLAN-Schnittstelle des RSM hilfreich, um die OSPF-Erkennung von MTU-Diskrepanzen zu stoppen und die Adjacency zu bilden.

Beachten Sie, dass MTU-Diskrepanzen zwar am häufigsten auftreten, aber nicht der einzige Grund dafür sind, dass OSPF-Nachbarn im Exstart/Exchange-Status feststecken. Das Problem wird am häufigsten durch die Unfähigkeit verursacht, DBD-Pakete erfolgreich auszutauschen. Die Hauptursache kann jedoch eine der folgenden sein:

• MTU-Nichtübereinstimmung

• Unicast ist defekt. Im Exstart-Status sendet der Router ein Unicast-Paket an den Nachbarn, um Primary (Primär) und Subordinate (Untergeordnet) auszuwählen. Dies gilt, es sei denn, Sie verfügen über eine Point-to-Point-Verbindung, über die ein Multicast-Paket gesendet wird. Mögliche Ursachen:

  • Falsche Virtual Circuit (VC)-Zuordnung in einer ATM- (Asynchronous Transfer Mode) oder Frame Relay-Umgebung in einem hochredundanten Netzwerk

  • MTU-Problem, d. h. die Router können nur ein Paket einer bestimmten Länge pingen.

  • Die Zugriffsliste blockiert das Unicast-Paket.

  • NAT wird auf dem Router ausgeführt und übersetzt das Unicast-Paket.

• Nachbar zwischen PRI und BRI/Dialer.

• Beide Router haben dieselbe Router-ID (falsche Konfiguration).

Darüber hinaus wird in Abschnitt 10.3 des OSPF-RFC 2328 angegeben, dass der Exstart-/Exchange-Prozess für eines dieser Ereignisse initiiert wird (eines davon könnte durch interne Softwareprobleme verursacht werden):

• Sequenznummer stimmt nicht überein.

  • Unerwartete DD-Sequenznummer.

  • Das "I"-Bit wird unerwartet gesetzt.

  • Optionsfeld, das sich vom letzten Optionsfeld im DBD-Paket unterscheidet.

• SchlechterLSReq

  • Der Nachbar sendet während des Austauschprozesses ein nicht erkanntes LSA.

  • Der Nachbar hat während des Austauschprozesses ein LSA angefordert, das nicht gefunden werden konnte.

Wenn OSPF keine Nachbarn bildet, berücksichtigen Sie zur Fehlerbehebung die oben genannten Faktoren, z. B. die physischen Medien und die Netzwerk-Hardware.

Zugehörige Informationen

• OSPF-Nachbarstaaten
• Erläuterung von OSPF-Nachbarproblemen
• Technischer Support und Downloads von Cisco