Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Das Problem

Die Lösung

Zugehörige Informationen

Einführung

Dieser technische Hinweis erklärt ein Problem mit der Bildung von OSPF-Adjacency, wenn die Dialer-Schnittstellen als Punkt-zu-Punkt-Verbindungen konfiguriert sind.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Das Problem

Der OSPF-Netzwerktyp an der Primärrate-Schnittstelle (PRI), der Basisrate-Schnittstelle (BRI) und der Dialer-Schnittstelle ist Point-to-Point, d. h., eine Schnittstelle kann keine Adjacency mit mehr als einem Nachbarn bilden. Ein häufiges Problem, wenn eine PRI-, BRI- oder Dialer-Schnittstelle versucht, eine OSPF-Adjacency zu bilden, ist, dass der Nachbar im Exstart-/Austauschprozess feststeckt. Schauen wir uns ein Beispiel an.

Mithilfe des Befehls show ip ospf neighbor können wir sehen, dass der Nachbarstatus in "EXSTART" feststeckt.

RTR-A# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

3.3.3.3           1   EXSTART/  -     00:00:37    3.3.3.3         Serial6/0:23

3.3.3.4           1   EXSTART/  -     00:00:39    3.3.3.4         Serial6/0:23

RTR-B# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

3.3.3.2           1   EXSTART/  -     00:00:36    3.3.3.2         BRI0

RTR-C# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

3.3.3.2           1   EXSTART/  -     00:00:35    3.3.3.2         BRI0

Die RTR-Bs-Konfiguration zeigt, dass der Netzwerktyp Point-to-Point ist:

RTR-B# show ip ospf interface bri0

BRI0 is up, line protocol is up (spoofing)

Internet Address 3.3.3.3/24, Area 2

Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1562

Transmit Delay is 1 sec, State POINT_TO_POINT,

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Hello due in 00:00:06

Index 1/1, flood queue length 0

Next 0x0(0)/0x0(0)

Last flood scan length is 1, maximum is 1

Last flood scan time is 0 msec, maximum is 0 msec

Neighbor Count is 1, Adjacent neighbor count is 0

Suppress hello for 0 neighbor(s)

Wir können diese Situation mit dem Befehl debug ip ospf adj debuggen. Sehen wir uns einige Beispielausgaben an, die bei der Ausführung dieses Befehls auf RTR-B in der Abbildung oben ermittelt wurden:

1: Send DBD to 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32

2: Rcv DBD from 3.3.3.2 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32

mtu 1500 state EXSTART

3: First DBD and we are not SLAVE

4: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92 mtu

1500 state EXSTART

5: NBR Negotiation Done. We are the MASTER

6: Send DBD to 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92

7: Database request to 3.3.3.2

8: sent LS REQ packet to 3.3.3.2, length 12

9: Rcv DBD from 3.3.3.2 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32

mtu 1500 state EXCHANGE

10: EXCHANGE - inconsistent in MASTER/SLAVE

11: Bad seq received from 3.3.3.2 on BRI0

12: Send DBD to 3.3.3.2 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32

13: Rcv DBD from 3.3.3.2 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92

mtu 1500 state EXSTART

14: Unrecognized dbd for EXSTART

15: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32

mtu 1500 state EXSTART

16: Unrecognized dbd for EXSTART

Zeilen 1-3: RTR-B sendet das erste DBD an 3.3.3.2 (RTR-A) mit seq 0xB41 und empfängt das erste DBD von 3.3.3.2 (RTR-A) mit seq# 0x1D06. Die Verhandlungen über Nachbarländer sind noch nicht abgeschlossen.

Zeilen 4 bis 6: RTR-B erhält eine Antwort von 3.3.3.2 (RTR-A), die darauf hinweist, dass RTR-A die erste DBD von RTR-B erhalten hat. Da RTR-B die höhere Router-ID hat, wählt RTR-A sich selbst Slave. Nach Erhalt der Bestätigung von RTR-A erklärt sich RTR-B selbst als Master und sendet das erste DBD mit darin enthaltenen Daten. Beachten Sie die Folgenummer, d. h. 0xB42. Da RTR-B der Master ist, kann nur die Sequenznummer erhöht werden.

Zeile 7: RTR-B fordert Daten von RTR-A an, da RTR-A angegeben hat, dass mehr Daten gesendet werden müssen (Flag-Einstellung auf 0x2 im letzten DBD, das von RTR-A empfangen wurde).

Zeile 8: RTR-B sendet ein Link-State-Anforderungspaket an 3.3.3.2 (RTR-A). Dies ist ein OSPF-Pakettyp 3. Dieses Paket wird normalerweise an die IP-Adresse des Nachbarn gesendet. In diesem Fall ist die IP-Adresse des Nachbarn seine Router-ID.

Posten 9 - 11: RTR-B erhält eine Antwort vom Slave (RTR-A) mit einer komplett anderen Sequenznummer und einer Fahne von 0x7, der Init Flag. Dieses DBD war für einen anderen Router vorgesehen (höchstwahrscheinlich RTR-C), wurde aber von RTR-B falsch empfangen. RTR-B gibt an, dass eine Diskrepanz vorliegt, da eine Markierung von 0x7 bedeutet, dass der Slave seinen Status zu master geändert hat, indem er das MS (Master/Slave)-Bit während des Adjacency-Austauschs festlegt. RTR-B beschwert sich auch über die Sequenznummer, da sie nicht in der richtigen Reihenfolge ist. Der Slave sollte immer der Sequenznummer des Meisters folgen.

Zeile 12: RTR-B initialisiert die Adjacency neu, indem das erste DBD an 3.3.3.2 gesendet wird, um Master und Slave erneut auszuwählen.

Zeilen 13-14: RTR-B empfängt ein DBD von 3.3.3.2 (RTR-A), das anzeigt, dass es sich um einen Slave handelt, ohne die laufende Nummer von RTR-B zu erkennen. RTR-B erklärt, dass es dieses DBD nicht erkennt, da die Master- und Slave-Aushandlung noch nicht abgeschlossen ist. Dieses DBD-Paket war für einen anderen Router vorgesehen.

Zeile 15: RTR-B erhält eine Antwort von 3.3.3.2 (RTR-A) für das alte DBD, aber es ist zu spät, weil RTR-B den Adjacency-Prozess bereits neu initialisiert hat.

Zeile 16: RTR-B erkennt dieses DBD nicht, da es sich um eine "alte" Adjacency handelt, die bereits durch RTR-B abgerissen wurde.

Dieser Prozess wird sich endlos wiederholen.

Die Lösung

Gemäß Abschnitt 8.1 von RFC 2328 sendet OSPF ein Multicast-Paket für einen Point-to-Point-Netzwerktyp, selbst nachdem die Schnittstelle den 2-Wege-Status erreicht hat. Da RTR-A versucht, Adjacencies mit RTR-B und RTR-C zu bilden, empfängt RTR-B DBD-Pakete, die für RTR-C bestimmt sind, und RTR-C DBD-Pakete, die für RTR-B bestimmt sind.

Um dieses Problem zu beheben, ändern Sie den Netzwerktyp aller Router in Point-to-Multipoint. Dadurch wird das Verhalten von OSPF zum Senden von Unicast-Paketen nach dem 2-Wege-Zustand geändert. Nun empfängt RTR-B nur noch Pakete, die für sich selbst bestimmt sind, und RTR-C empfängt Pakete, die für sich selbst bestimmt sind. Durch diese Änderung des Netzwerktyps wird sichergestellt, dass der OSPF-Router eine Adjacency auf einer PRI-, BRI- oder Dialer-Schnittstelle bildet.

Um den Netzwerktyp zu ändern, geben Sie die folgenden Konfigurationsbefehle ein, und beenden Sie jede Zeile durch Drücken der EINGABETASTE. Als Beispiel wird RTR-B geändert.

RTR-B# configure terminal

RTR-B(config)# int bri 0

RTR-B(config-if)# ip ospf network point-to-multipoint

RTR-B(config-if)# end

Wenn wir uns nun die show-Befehle für RTR-B anschauen, können wir überprüfen, ob der Netzwerktyp Point-to-Multipoint ist und der Status voll ist.

RTR-B# show ip ospf interface bri0

BRI0 is up, line protocol is up (spoofing)

Internet Address 3.3.3.3/24, Area 2

Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 1562

Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,

Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

Hello due in 00:00:16

Index 1/1, flood queue length 0

Next 0x0(0)/0x0(0)

Last flood scan length is 1, maximum is 1

Last flood scan time is 0 msec, maximum is 0 msec

Neighbor Count is 1, Adjacent neighbor count is 1

Adjacent with neighbor 172.16.141.10

Suppress hello for 0 neighbor(s)

RTR-B# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

172.16.141.10     1   FULL/  -        00:01:36    3.3.3.2         BRI0

Zugehörige Informationen

- Konfigurieren von BRI-to-BRI-Dialup mit DDR-Dialer-Karten

- OSPF-Support-Seite

- Technischer Support - Cisco Systems