In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird die Fehlerbehebung in Situationen beschrieben, in denen OSPF-Nachbarn (Open Shortest Path First) in den Status Exstart und Exchange feststecken.
Es wird empfohlen, dass der Benutzer mit den grundlegenden OSPF-Betriebs- und Konfigurationsfunktionen vertraut ist, insbesondere mit OSPF-Nachbarstatus.
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.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
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.
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.
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.
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 ISSUBORDINATE
)>>>
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 theSLAVE
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 ISSUBORDINATE
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.
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):
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.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
3.0 |
03-Oct-2024 |
PII entfernt.
Aktualisierter Titel, Alternativer Text und Formatierung. |
2.0 |
18-Sep-2023 |
Rezertifizierung |
1.0 |
10-Dec-2001 |
Erstveröffentlichung |