Warum bildet OSPF keine Adjazenz auf einer PRI-, BRI- oder Dialer-Schnittstelle?
Inhalt
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
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
10-Aug-2005 |
Erstveröffentlichung |
Feedback