Fehlerbehebung: DLSw-Konfiguration
Inhalt
Einführung
In diesem Dokument wird erläutert, wie Sie eine DLSw-Konfiguration (Data-Link Switching) zur Fehlerbehebung verwenden können.
Voraussetzungen
Anforderungen
Für dieses Dokument bestehen keine speziellen Anforderungen.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).
Hintergrundinformationen
Wenn die Peers keine Verbindung herstellen, überprüfen Sie, ob eine IP-Verbindung zwischen den beiden Routern besteht. Wenn ja, prüfen Sie, ob die entsprechenden DLSw-Peer-Anweisungen auf den lokalen Routern und den Remote-Routern vorhanden sind. Weitere Informationen finden Sie unter Grundlegende DLSw+-Konfigurationen und Fehlerbehebung bei Problemen mit der DLSw-IP-Verbindung. Wenn keine Remote-Anweisungen vorhanden sind, verwenden Sie das Schlüsselwort Promiscuous in der lokalen Peer-Anweisung an einem Ende. Weitere Informationen finden Sie unter DLSw+-Konfigurationsbefehle.
Netzwerktopologie
Dieser Abschnitt behandelt einige häufige Probleme und enthält Tipps zur Fehlerbehebung.
Schleifen
Beachten Sie, dass die RIF-Terminierung (Routing Information Field) ein wichtiger Aspekt von DLSw ist. RIF verursacht große Probleme durch die einfache Erstellung von Schleifen im Netzwerk.
Netzwerktopologie
Hier ist eine Beispieltopologie, die die Erstellung einer Schleife verfolgt.
DLSw beendet die RIF, und das Paket läuft endlos herum. Jedes Mal, wenn ein CANUREACH (CUR)-Frame vom Peer an den Peer gesendet wird, erstellt der Peer des Empfängers einen neuen Explorer (NO RIF) und sendet diesen.
Schleifenerstellung: Szenario 1
Dies ist die Route eines Explorers:
-
Der 3174 in Ring 11 sendet einen Explorer, um den Host zu erreichen.
-
Sowohl San Francisco 1 (SF1) als auch die Bridge kopieren den Frame.
-
SF1 erstellt einen CUR-Frame nach Los Angeles 1 (LA1), dem Peer, der LA1 sagt, dass der 3174 den Host erreichen möchte.
-
San Francisco 2 (SF2) empfängt das Paket und wiederholt die Aktion.
-
LA1 und Los Angeles 2 (LA2) erstellen den Entdecker und schicken ihn zum Ring.
-
LA1 und LA2 erhalten jeweils einen Explorer (den, den der andere erstellt hat).
Jetzt entsteht ein Problem. Jede Seite stellt fest, dass der 3174 lokal angeschlossen ist, und jeder Router zeigt den 3174 sowohl lokal als auch remote an.
-
Jede Seite sendet einen CUR-Frame an SF1 und SF2, und erstellt vom 3174 einen Explorer für den Host.
-
Beide Router (SF1 und SF2) kopieren den Frame erneut und stellen fest, dass der Host sowohl lokal als auch remote ist. DLSw bricht und geht in eine Schleife.
In diesem Fall sollten Sie am besten sicherstellen, dass die virtuellen Ringe für die Router auf beiden Seiten der Cloud identisch sind:
Schleifenerstellung: Szenario 2
Die Router auf beiden Seiten der Cloud werden mit derselben virtuellen Ringnummer konfiguriert. Diese Konfiguration stellt sicher, dass ein Router, der einen Explorer sendet, den Ring bereits passiert hat und daher der Router den Explorer verwirft. Wenn LA1 einen Explorer für einen CUR-Frame generiert, den SF1 empfängt, verwirft LA2 den Explorer, da der Explorer bereits Ring 1 durchlaufen hat. Für die Router müssen unterschiedliche Bridge-Nummern konfiguriert sein, wenn sie zum selben Ring übergehen. Dies ist auf der LA-Seite dieses Netzwerks der Fall. Bei Ethernet müssen Sie einen Peer deaktivieren:
Ein Paket auf dem Ethernet hat keine RIF an sich. Wenn der andere Router im LAN eine Broadcast-Nachricht erstellt, kann der Router daher nicht feststellen, ob der Broadcast vom anderen Router oder von einer ursprünglichen Station stammt. Bei der Systems Network Architecture (SNA) kann der Router nicht feststellen, ob das Paket lokal oder remote generiert wird. Explorer vom Token-Ring haben sowohl Quell- als auch Ziel-MAC-Adressen. Daher sind solche Entdecker nicht wirklich eine Broadcast auf dem Ethernet. Sie werden vielmehr als direkter Rahmen von einer Station an eine andere gesendet.
Betrachten Sie die folgende Sequenz:
-
Der 3174 sendet einen Explorer an den Host.
-
Sowohl SF1 als auch SF2 akzeptieren den Explorer.
-
SF1 und SF2 generieren jeweils eine CUR auf der anderen Seite, LA1 und LA2.
-
Diese CURs generieren beide einen Explorer, auf den der Host reagiert. Da es sich um einen einzigen Routen-Explorer handelt, reagiert der gesamte Routen-Explorer.
-
Sowohl LA1 als auch LA2 erstellen einen CUR-Frame zu SF1 und SF2, wodurch dieses Paket für den 3174 erstellt wird.
Das Problem besteht darin, dass SF1 die MAC-Adresse des Hosts vom Ethernet abhört und feststellt, dass sich der Host im eigenen lokalen LAN befindet. Im SF1-Cache scheint der Host jedoch von einem Remote-Peer zu reagieren. Daher ist der Host auf dem Router sowohl lokal als auch remote definiert.
DLSw bricht und geht in eine Schleife.
Um DLSw zu beheben, müssen Sie einen Peer deaktivieren oder die Ethernet-Redundanzfunktion verwenden. Weitere Informationen finden Sie im Konfigurationsbeispiel für die DLSw-Ethernet-Redundanz.
Feedback