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 OSPF-Nachbarstatus.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
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 eine Reihe von Gründen 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 OSPF-Problemen.
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 die Primary/Subordinate
Beziehung ausgehandelt wurde (der Router mit der höchsten Router-ID wird zum primären Router), wechseln die benachbarten Router 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 MTU-Einstellungen (Maximum Transmission Unit) für die neighboring
Router-Schnittstellen nicht übereinstimmen. 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, zeigt die Ausgabe desshow ip ospf neighbor
Befehls eine Ausgabe an, die der in dieser Abbildung gezeigten ähnelt.

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):
Router 6-Konfiguration |
Konfiguration von Router 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 |
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 die Befehle debug ip packet
und debug ip ospf adj
auf jedem Router, um den OSPF-Adjacency-Prozess anzuzeigen. Die Ausgabe von Router 6 und 7 aus den Schritten 1 bis 14 lautet:
-
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
-
Router 7-Debug-Ausgabe:
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
-
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
-
Router 7-Debug-Ausgabe:
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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 der Primary/Subordinate
Ermittlung wird Router 7 aufgrund seiner höheren Router-ID als 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.
Schritt 13 zeigt, dass Router 6 als subordinate
die Sequenznummer von Router 7 verwendet und sein zweites DBD-Paket sendet, das die Header seiner 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 angekündigtes DBD-Paket empfängt, dessen MTU größer ist als die, die der Router empfangen kann, ignoriert der Router das DBD-Paket, und der Nachbarstatus bleibt 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:

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):
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