Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Hintergrundinformationen

Exstart-Status

Wechselkursstatus

Nachbarn im Exstart-/Austauschstatus feststecken

Lösung

Zugehörige Informationen

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 verstehen.

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 Fehlerbehebung bei OSPF finden Sie unter Fehlerbehebung bei 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 auch Link-State-Anforderungspakete, die aktuellere Link-State-Advertisements (LSA) 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-Status finden Sie unter OSPF Neighbor Statesto.

Nachbarn im Exstart-/Austauschstatus 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 desshow 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 erforderliche 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 Siedebug ip packetund 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 ursprü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 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). Der erste DBD auf 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 folgen. 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.

Anmerkung: In Version 12.0(3) der Cisco IOS Software wurde die Erkennung von MTU-Diskrepanzen zwischen den Schnittstellen eingeführt. Diese Erkennung betrifft den OSPF, der die Schnittstellen-MTU in den DBD-Paketen ankündigt, entsprechend OSPFRFC 2178, Anhang G.9. Wenn ein Router ein DBD-Paket empfängt, das eine MTU ankündigt, die größer ist als die vom Router empfangene MTU, ignoriert der Router das DBD-Paket und der Nachbar-Status 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)ip ospf mtu-ignoreEin Schnittstellenkonfigurationsbefehl wurde 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:

Fibre 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,ip ospf mtu-ignoreist auf der VLAN-Schnittstelle des RSM nützlich, um die OSPF-Erkennung von MTU-Diskrepanzen zu beenden 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-Abweichung

- 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 OSPFRFC 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 – Cisco Systems