Token Ring Bridging und RIF-Decodierung

Einführung

In diesem Dokument wird die Dekodierung des Token Ring Bridging and Routing Information Field (RIF) erläutert.

Token-Ring-Frames haben eine ähnliche Struktur wie 802.3-Ethernet- und FDDI-Frames (Fiber Distributed Data Interface). Diese Frames enthalten Ziel- und Quelladressen sowie eine Frame Check Sequence (FCS) und einen Abschnitt zum Übertragen von Daten. Begrenzungszeichen zum Starten und Beenden sind ebenfalls üblich.

Token Ring-Frames, aber auch zusätzliche Funktionen integriert. Dazu gehören:

• Routing Information Field (RIF) (optional)

• Zugriffskontrolle

• Frame Control (FC)- und Frame Status (FS)-Felder

Sie können auch das erste Bit der Quelladresse verwenden, um das Vorhandensein eines RIF anzugeben. Allerdings ist nur ein Feld relativ, wenn Sie Source-Route Bridging (SRB) studieren.

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 unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Routinginformationsfelder

Das erste Bit der Quelladresse muss auf 1 gesetzt werden, um ein RIF zu unterstützen.

Das RIF ist ein ziemlich kompliziertes Feld. Es speichert die Kombination aus Klingelnummern und Brückennummern, die ein Frame zwischen Endstationen durchquert. Die RIF verfügt außerdem über ein Zwei-Oktett-Kontrollfeld, das verschiedene Eigenschaften der RIF selbst bereitstellt. Zwei Stationen, die über ein SRB- oder ein RSRB-Netzwerk (Remote Source-Route Bridging) kommunizieren, verwenden für die Dauer der Sitzung immer dieselbe RIF.

Der Ring-to-Bridge-Teil der RIF zwischen PC A und PC B im vorherigen Diagramm lautet 00AF.00B0.

Überprüfung der MAC-Adressstruktur

Lokal verwaltete Adressen (LAAs) sind am häufigsten auf Token Ring-Stationen zu finden, obwohl es möglich ist, Ethernet- und FDDI-Stationen LAAs zuzuweisen. In den LAAs ist das zweite Bit der ersten Tabelle auf 1 festgelegt.

Eine der Fähigkeiten, die Sie zur Unterstützung von Token Ring-Netzwerken benötigen, ist die Möglichkeit, Hexadezimalnummerierungsschemata bei Bedarf in Binärschemata zu konvertieren. Der Token Ring liefert fast alle Informationen in Hexadezimalziffern, aber die zugrunde liegende Struktur basiert auf Binärziffern. Die Hexadezimaldarstellung maskiert normalerweise einige der zugrunde liegenden Strukturen. Sie müssen in der Lage sein, die Hexadezimaldarstellung in binäre Darstellung zu konvertieren, um die Felder, mit denen Sie arbeiten, korrekt interpretieren zu können.

In diesem Beispiel wird diese Konvertierung veranschaulicht.

1. Teilen Sie die Hexadezimalzahl in einzelne Ziffern:

   

2. Konvertieren Sie die Hexadezimalziffern in die vier Binärziffern (Einkerben), die jede Hexadezimalziffer repräsentiert:

   

3. Ändern Sie die Binärdateien in binäre Oktette:

   

Hexadezimale Nummerierung

Wenn die vorherige Adresse eine Zieladresse ist, kann das erste Bit auf 1 festgelegt werden, was bedeutet, dass es für eine Gruppe oder funktionale Adresse an den Empfangsstationen bestimmt ist. Seltsamerweise ist das lokale/universelle Bit auf 1 gesetzt, ebenso wie das funktionale/Gruppen-Adressbit. Da es möglich ist, eine lokal verwaltete Funktionsadresse für Token Ring sowie eine universell zugewiesene Adresse zu haben, scheint dies eine Aufsicht des IEEE 802.5-Ausschusses zu sein. Funktions- und Gruppenadressen fallen nicht in den Anwendungsbereich dieses Dokuments, da sie nicht direkt auf Token Ring Bridging anwendbar sind. Weitere Informationen finden Sie im Dokument Token Ring/IEEE 802.5 Kapitelziele.

Wenn die vorherige Adresse eine Quelladresse ist und der Token Ring-Frame ein RIF enthält, wird das erste Bit auf 1 festgelegt. Wenn es sich ebenfalls um eine LAA handelt, beginnt die Adresse mit 0xC. Ermitteln Sie dies anhand der Hexadezimaldump des Frames.

Mit Ausnahme einiger spezialisierter Implementierungen hat das fragliche WAN keine Auswirkungen auf das Konzept des RSRB. Der Datenverkehr wird in den meisten Fällen IP-basiert übertragen. Solange IP-Verbindungen zwischen den Routern möglich sind, funktioniert RSRB erfolgreich.

Das WAN kann Frame Relay sein, wie in diesem Beispiel gezeigt.

Das WAN kann wie in diesem Beispiel X.25 sein.

Das WAN kann wie in diesem Beispiel ein virtueller Ring sein.

Der WAN-Typ ist nicht relevant, da der Token-Ring-Frame sicher in TCP/IP oder einfach IP verpackt ist, bevor er die WAN-Schnittstelle erreicht. Fast jeder LAN- oder WAN-Typ unterstützt Fast-Sequected Transport (FST)-Kapselung.

Bei der direkten Kapselung müssen Sie sicherstellen, dass die Maximum Transmission Units (MTUs) aller Schnittstellen im Pfad den gesamten 802.5-Frame verarbeiten können, da die direkte Kapselung keine Fragmentierung zulässt. Sie müssen der maximalen Token-Ring-MTU im Pfad zusätzliche 73 Byte hinzufügen, d. h. für den Cisco RSRB-Header und anderen Token-Ring-Overhead, um die richtige MTU für alle Nicht-Token-Ring-Schnittstellen im Pfad zu erhalten. Bei seriellen Verbindungen muss die MTU 1573 betragen, wenn die Token Ring-MTU 1500 ist. Für die direkte Kapselung ist nur ein Hop zulässig.

Im vorherigen Diagramm kann PC A PC B nicht erreichen, und PC B kann PC A nur erreichen, wenn Router B über (nicht direkte) RSRB-Peers mit Router A verfügt. Router A verfügt über RSRB-Peers mit Router B. Router A und B können auch über eine direkte Kapselung zwischen ihnen verfügen. Router B kann direkt zu Router A, aber nicht Router C angeschlossen werden. Router C kann direkt zu Router A weitergeleitet werden, Router B und C benötigen jedoch echte Peers, um miteinander zu kommunizieren.

Eine andere Möglichkeit, dies anzuzeigen, wird in diesem Diagramm veranschaulicht:

Transparentes Bridging der Quellroute

Source-Route Transparent Bridging (SRT) wurde der 802.5-Spezifikation hinzugefügt. Sie ermöglicht 802.5-Frames ohne RIF das Durchlaufen von Token Ring-Schnittstellen, die für transparente Bridging konfiguriert sind. SRT übersetzt auch 802.3 bis 802.5 für Ethernet Token Ring Bridging. Die Probleme beim Bridging routingfähiger Protokolle über unterschiedliche Medien werden damit nicht gelöst.

Stationen, die SRT verwenden, können nicht mit Stationen kommunizieren, auf denen SRB ausgeführt wird, wenn sie sich in separaten Ringen befinden. Die beiden Szenarien sind grundsätzlich unvereinbar. Ein SRT-PC benötigt die proprietäre Lösung von Cisco, um mit einem SRB-PC zu kommunizieren.

Für die Kommunikation mit einem Ethernet-PC ist bei einem SRB-PC auch die Lösung von Cisco erforderlich.

Hinweis: Im vorherigen Diagramm:

• 6 ist die falsche Ringnummer, die für das Ethernet-Segment verwendet wird.

• 7 ist die gefälschte Bridge-Nummer, die auf das Ethernet-Segment zeigt.

• Die Token Ring-PCs setzen voraus, dass sich die Ethernet-PCs auf einem Token Ring befinden, da sie ein gültiges RIF benötigen.

• Der Router stellt den gefälschten Teil der RIF dar und fügt die RIF zu den Frames hinzu, die für PCs A und B bestimmt sind.

• Die Ethernet-PCs werden nicht darüber informiert, dass die PCs A und B nicht über Ethernet verbunden sind. Der Router entfernt die RIFs aus PC-A- und PC-B-Frames.

Die IEEE hat beschlossen, ein Übertragungsschema für die Bitreihenfolge für Ethernet zu verwenden, das sich von dem des Token Ring unterscheidet. Das Schema für FDDI-Ethernet ist zuerst die "Least Significant Bit" (LSB), während die von FDDI und Token Ring zuerst die "Most Significant Bit" (MSB) sind.

Source-Route Bridging

Dies ist ein einfaches Szenario, in dem SRB veranschaulicht wird:

Die PCs verwenden Source-Routing und müssen irgendwie miteinander kommunizieren. Das Wort Source in Source Routing weist darauf hin. Aber bei transparenter Überbrückung ist dies kein Thema, da transparente Überbrückung für die Endstationen transparent ist. Die Endstationen übertragen einfach Frames, als ob sie überhaupt mit einer Station kommunizieren könnten. PCs senden Entdecker, um ihnen zu helfen, einander zu erreichen.

Explorer

Betrachten Sie die RIF im Token Ring-Rahmen, um das Konzept der Entdecker zu verstehen. Die RIF besteht aus zwei Hauptabschnitten:

• die Steuerbytezeichen (2)

• Ring-and-Bridge-Bytes (weniger als 30)

Dies ist die Aufschlüsselung der Steuerbyteure:

• drei Bit für Broadcast-Typ (dargestellt durch BBB in diesem Diagramm)

• fünf Bit für die Länge des gesamten RIF (LLL) (2*2*2*2=32 Byte verfügbar)

• ein Bit für die Richtung (D)

• drei Bit für die MTU des angeschlossenen Token Ring-Netzwerks (FFF)

• die letzten vier Bit für IBM (reserviert [RRR])

Dies wird häufig als BBLLL.DFFFRRR dargestellt. Darüber hinaus ist BBBLNGTH.DMTURESV eine weitere hilfreiche Darstellung der Steuerungbyte.

Beachten Sie, dass IBM im Hexadezimalformat arbeitet und der Quellroute-Pfad von PC A zu PC B 00AF.00B0 ist. Denken Sie daran, dass Sie den Binärausdruck der Ring-and-Bridge-Bits in den Hexadezimalausdruck konvertieren müssen, der bei der Arbeit mit SRB verwendet wird. Dieser Pfad im Binärformat lautet 0000000.1010111.00000000.10110000. Gebunden in Binärdateien, ist es 0000.000.1010.1111.0000.0000.1011.0000. Die letzte Brückennummer ist immer 0000, da Pfade auf Ringen enden, nicht auf Brücken. Die Regel ist, dass drei Klingeltöne einen Ring bilden, und eine Klammer eine Brücke. Der Bereich liegt zwischen 1 und 4095 für Ringe und zwischen 1 und 15 für Bridges.

Der Ring-and-Bridge-Bereich der RIF wurde bereits besprochen. Weitere Informationen finden Sie im Abschnitt Routinginformationsfelder. Wenn Sie dem ursprünglichen RIF die beiden Kontrollbytezeichen hinzufügen, endet die Einstellung mit 00AF.00B0. Die RIF muss mindestens zwei Byte lang sein, da sie die Steuerungs-Bytes erfordert. Sie haben zwei Ringe, daher müssen Sie zwei Ring-and-Bridge-Kombinationen von jeweils zwei Byte hinzufügen. Dadurch ist die RIF sechs Byte lang. Beachten Sie, dass die Binärstruktur der Bytes BBXLLL.DFFFXXXX.RRRRRRRRRBBB.RRRRRRRRBBB.RRRBBB lautet.

Nehmen wir als Beispiel einen Single-Route-Explorer von PC A zu PC B.

Die RIF lautet C670.00AF.00B0. Das Nble C670 ist immer 0.

Das Single-Route-Explorer-RIF wird im Ring B als C610.00AF.00B0 angezeigt. Dabei wird von einer MTU von 1500 ausgegangen und davon ausgegangen, dass es von links nach rechts gelesen wird. Das direkte RIF ist 0610.00AF.00B0, das eine MTU von 1500 annimmt und davon ausgeht, dass es von links nach rechts gelesen wird. Die MTU-Bits werden von 11 (0x7) auf die maximale MTU reduziert, die jede Bridge verarbeiten kann, während der Explorer die Bridge durchquert. Die Bridge untersucht den aktuellen Wert der MTU-Bits. Wenn der Wert größer ist, als die Bridge unterstützt, muss die Bridge den Wert auf die größte MTU reduzieren, die sie unterstützen kann. Für das Übersetzungsbrücken zu Ethernet beträgt die maximale MTU 1.500.

Wenn eine Multi-Port-Bridge die Zwei-Port-Bridge ersetzt, sind weitere RIFs möglich:

• PC A an PC C: 0610,00AF.00C0

• PC A an PC B: 0610,00AF.00B0

• PC B an PC C: 0610,00BF,00C0

  Hinweis: Diese drei sind keine Explorer-RIFs. Sie werden an RIFs mit einer MTU von 1.500 gerichtet und von links nach rechts gelesen.

• PC A an PC B: 0690,00AF.00B0

  Hinweis: Dies ist die gleiche RIF wie im vorherigen Diagramm beschrieben, wobei das D-Bit jedoch auf 1 festgelegt ist, wenn es von rechts nach links gelesen wird.

Wenn ein Cisco Router mit mehreren Ports die Zwei-Port-Bridge ersetzt, fungiert der Router als virtueller Ring zur Verbindung der echten Ringe. Es fügt den Token Ring-Schnittstellen Bridges hinzu. In den meisten Fällen können alle Bridge-Nummern 1 sein. Die Ausnahme sind parallele Bridges, die zwei Ringe verbinden. PC A an PC C ist jetzt 0810.00A1.00F1.00C0.

Cisco Router mit drei Token-Ring-Schnittstellen

Es ist möglich, einen Router mit nur zwei Token Ring-Schnittstellen zu haben. In diesem Fall ist ein virtueller Ring nicht erforderlich. Sie wird ähnlich wie eine Zwei-Schnittstellen-Bridge konfiguriert, kann jedoch kein RSRB ausführen.

Dieses Diagramm zeigt einen Cisco Router mit zwei Token Ring-Schnittstellen. Dieser Router kann kein RSRB ausführen.

Die RIF ist der schwierigste und grundlegendste Aspekt der Token Ring SRB. Im verbleibenden Teil dieses Dokuments werden weitere Möglichkeiten zum Erzielen von Token-Ring-Frames über verschiedene Netzwerktopologien erläutert, da diese als Token-Rings für die RIF erscheinen. Wenn die RIF nicht beendet wird, muss die Technologie zum Verschieben der Frames von Station zu Station irgendwie eine genaue RIF-Adresse aufweisen. Data-Link Switching (DLSw) ist die wichtigste Implementierung, die das RIF terminiert. Dieses Dokument behandelt nur Implementierungen, bei denen die RIF durchgängig im gesamten Netzwerk übertragen wird.

Dabei sind einige allgemeine Regeln zu beachten:

• SNA-Geräte (Systems Network Architecture) senden meist Routen-Explorer, um das gewünschte Zielgerät zu suchen. Dabei handelt es sich um Unicast zu den MAC-Zieladressen. Die Zielgeräte kehren in der Regel das Richtungsbit (D) um und senden den Frame als vermittelten Rahmen zurück, nicht als Explorer. SNA hat keinen Broadcast-Hintergrundverkehr. Beispielsweise senden FEPs (Front End Processors) keine Frames, die ihren Standort übertragen, um gefunden zu werden.

• Network Basic Input/Output Systems (NetBIOS) senden Single-Route-Explorer und erwarten, dass die Zielstation mit einer Antwort antwortet, die auf alle Routen des Explorers antwortet. NetBIOS führt auch eine große Anzahl von Hintergrundübertragungen durch. Geräte senden ständig Frames, die ihren Standort und andere wichtige Nachrichten kommunizieren. NetBIOS sendet seine Explorer in der Regel an die funktionale NetBIOS-Adresse, für die alle NetBIOS-Stationen Folgendes überwachen: C000 000 0080.

• Die meisten anderen Protokolle senden ihre Explorer als MAC-Broadcasts, z. B. FFFF.FFFF.FFFF oder C000.FFFF.FFFF.

• Novell kann für das Senden von Broadcasts über eine Route oder alle Routen konfiguriert werden. Stationen benötigen möglicherweise route.com. Server benötigen route.nlm.

Wenn Sie zwei Ringe mit parallelen Brücken verbinden, müssen die Bridge-Nummern eindeutig sein.

Lokale Bestätigung

Bei der lokalen Bestätigung (Local-Bestätigt, Local-ack) ist der Router an einer 802.2 Logical Link Control (LLC2-Sitzung) vom Typ 2 (Logical Link Control) beteiligt, die auf der Steuerungsebene der Datenverbindung zwischen zwei Endstationen stattfindet. Sie müssen einige der Grundlagen der 802.2 Data-Link Control Layer kennen, um Local-ack zu verstehen. 802.2 ist ein internationaler IEEE- und OSI-Standard (Open System Interconnection) für die Kommunikation auf der Sicherungsschicht. Die Spezifikationsnummer der Internationalen Organisation für Normung (ISO) lautet 8802.2. Obwohl sich viele bei Diskussionen über LANs auf das siebenschichtige OSI-Modell beziehen, eignet sich das IEEE LAN-Referenzmodell besser.

Mit Ausnahme der OSI-Protokolle (Connection Mode Network Service [CMNS] und Connectionless Network Service [CLNS]) und der ITU-Protokolle (International Telecommunication Unit) wie X.25 sind die meisten Protokolle oberhalb der Sicherungsschicht entweder proprietär, wie Internetwork Packet Exchange (IPX), AppleTalk und Digital Equipment Corporation Network (DECnet), oder sie werden von einem anderen TCP standardisiert/IP und der Internet Engineering Task Force [IETF]). Weder die IEEE noch die ITU kontrollieren die Spezifikation der meisten Protokolle, die heute über LANs laufen.

IEEE LAN-Referenzmodell

Die IEEE entschied sich, die OSI-Datenverbindungsschicht in zwei Schichten zu unterteilen. Der Layer 802.2 bietet drei Diensttypen:

1. verbindungslos

2. verbindungsorientiert

3. anerkannte verbindungslos

Typ 3 wird kaum je verwendet. Typ 2 wird von SNA und NetBIOS verwendet. Routbare Protokolle wie IP, IPX und AppleTalk, die für 802.2 konfiguriert sind, verwenden Typ 1.

802.2-Format

In diesem Abschnitt werden einige der wichtigsten Bereiche der 802.2-Schicht behandelt.

Service Access Points (SAPs) werden zur Multiplikation und Demultiplex von übergeordneten Protokollen über die 802.2-Ebene verwendet. Typische SAPs sind 04 (SNA), F0 (NetBIOS) und E0 (IPX). Das Kontrollfeld ist in 802.2 zwei Oktette. Sie wird für die Initialisierung und Beendigung von Sitzungen, die Flusskontrolle und die Sitzungsüberwachung verwendet. Local-ack übernimmt hauptsächlich die Flusssteuerung und Sitzungsüberwachung. Sie gilt nur für verbindungsorientierte Sitzungen vom Typ 2.

Eine verbindungsorientierte Sitzung bestätigt die empfangenen Frames und gibt die gesendete Frame-Nummer an. Der dritte Informationsrahmen für einen Sitzungspartner, der noch keinen I-Frame gesendet hat, wird beispielsweise als I NR0 NS3 gesendet. Damit wird mitgeteilt, dass Informationsrahmen 3 gesendet werden soll und dass der nächste I-Frame als Sequenznummer 0 erwartet wird. Wenn der Sitzungspartner bereits Frames 0-4 gesendet hat, wird der I-Frame als I NR5 NS3 gesendet. Damit wird bestätigt, dass Frames 0-4 empfangen wurden, und dem Partner mitgeteilt, dass es in Ordnung ist, weitere Frames zu senden. Wenn ein Sitzungspartner aus irgendeinem Grund für einen befristeten Zeitraum keine weiteren Frames empfangen kann, kann der Partner einen Aufsichtsrahmen senden, um die Sitzung zu beenden (z. B. S RNR5). Die NR5 teilt dem anderen Partner mit, was eingegangen ist, und der RNR teilt mit, dass der Empfänger nicht bereit ist.

Überwachungs-Frames werden auch verwendet, wenn die Timer, die in den Endstationen eingestellt werden, ablaufen, bevor sie eine Bestätigung ausstehender I-Frames erhalten. Die Stationen können einen aufsichtlichen, empfängerbereiten Frame senden, der den Partner auffordert, sofort zu reagieren. Die Stationen können beispielsweise S RR NR4 POLL senden, wobei davon ausgegangen wird, dass der nächste Frame 4 beträgt. In dieser Situation ist Local-ack nützlich.

Manchmal kann die Übertragungsverzögerung über das WAN die Timer-Einstellungen in den Endsystemen überschreiten. Dies veranlasst die Endstationen, die I-Frames erneut zu übertragen, obwohl die ursprünglichen Frames zugestellt und die Bestätigungen zurückgegeben werden. Local-ack sendet S-RR-Frames an die Endstation, von der sie stammen, während der RSRB-Code den Frame an das andere Endsystem überträgt.

Die automatische Decodierung der RIF kann mit dem RIF Decoder Tool durchgeführt werden.

Zugehörige Informationen

• Verständnis und Fehlerbehebung für lokales Source-Route Bridging
• RIF-Passthru in der DLSw+-Schulungsergänzung
• Technischer Support und Dokumentation - Cisco Systems