Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Einfügeprozess für Token-Ring

Lose-Test

Physische Einfügung und Überwachung

Adressprüfung duplizieren

Teilnahme an Ringumfrage

Initialisierung anfordern

Fehlerbehebung

Flussdiagramm

LAN-Netzwerk-Manager

Verwendung von Cisco IOS Software-Befehlen

Keepalives

Verwendung von LAN Analyzer

Zugehörige Informationen

Einführung

In diesem Dokument werden einige der häufigsten Probleme beschrieben, die dazu führen, dass eine Token Ring-Schnittstelle des Cisco Routers nicht in einen Token Ring eingefügt wird. Es bietet ein Ablaufdiagramm, in dem Sie schnell einen Überblick über die Schritte zur Fehlerbehebung an der Token Ring-Schnittstelle erhalten. In diesem Dokument werden auch einige der gebräuchlichsten Cisco IOS® Software-Befehle erläutert und beschrieben, wie diese Befehle zum Erfassen von Informationen über die Token Ring-Schnittstelle verwendet werden, um das Problem erfolgreich zu beheben.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

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 in den Cisco Technical Tips Conventions.

Einfügeprozess für Token-Ring

Um eine erfolgreiche Fehlerbehebung für Token Ring-Schnittstellen durchführen zu können, ist es wichtig, die Ereignisabfolge zu verstehen, die vor dem Beitritt einer Station zum Ring stattfindet.

Es gibt fünf Phasen, in denen eine Station einem Ring beitreten kann:

1. Lose-Test

2. Physische Eingliederung und Überwachung

3. Doppelte Adressprüfung

4. Teilnahme an Ringumfrage

5. Initialisierung anfordern

Lose-Test

Der Einfügeprozess beginnt mit einem Schleimtest. In dieser Phase werden der Transmitter und der Receiver des Token Ring-Adapters getestet und das Kabel zwischen dem Adapter und der Multistation Access Unit (MAU) getestet. Wird das Übertragungskabel durch eine MAU physisch in den Empfangsdraht zurückgeschraubt? Der Adapter kann so Medientest-MAC-Frames über das Kabel an die MAU (wo sie eingewickelt ist) und zurück an sich übertragen. Während dieser Phase sendet der Adapter Lobe-Media-Test-MAC-Frames an die Zieladresse 00-00-00-00-00 (mit der Quelladresse des Adapters) und einen Duplication Address Test (DAT) MAC-Frame (der die Adresse des Adapters als Quelle und Ziel enthält), um das Kabel zu erweitern. Wenn der Schleimtest erfolgreich ist, ist Phase 1 abgeschlossen.

Physische Einfügung und Überwachung

In Phase 2 wird ein ph-antom Strom gesendet, um das Hub-Relay zu öffnen, sobald das Hub-Relay die Station öffnet und sich am Ring anhängt. Die Station überprüft dann, ob ein aktiver Monitor (AM) vorhanden ist, indem sie nach einem der folgenden Frames sucht:

- Aktiver Monitor vorhanden (AMP) MAC-Frame

- Standby-Monitor vorhanden (SMP) MAC-Frame

- MAC-Frames für Klingelton-Bereinigung

Wenn innerhalb von 18 Sekunden keiner dieser Frames erkannt wird, geht die Station davon aus, dass kein aktiver Monitor vorhanden ist, und sie initiiert den Überwachungs-Konflikt-Prozess. Durch den Überwachungs-Konflikt wird die Station mit der höchsten MAC-Adresse zum aktiven Monitor. Wenn der Konflikt nicht innerhalb einer Sekunde beendet wird, kann der Adapter nicht geöffnet werden. Wenn der Adapter zum AM wird und eine Säuberung initiiert und der Löschvorgang nicht innerhalb einer Sekunde abgeschlossen wird, kann der Adapter nicht geöffnet werden. Wenn der Adapter einen Beacon-MAC-Frame oder einen Station-MAC-Frame empfängt, kann der Adapter nicht geöffnet werden.

Adressprüfung duplizieren

Im Rahmen der doppelten Adressenprüfungsphase überträgt die Station eine Reihe doppelter MAC-Frames, die an sich selbst adressiert sind. Wenn die Station zwei Frames zurückerhält, wobei der Address Recognized Indicator (ARI) und der Frame Copied Indicator (FCI) auf 1 festgelegt sind, weiß sie, dass diese Adresse in diesem Ring ein Duplikat ist, sich selbst trennt und einen Fehler beim Öffnen meldet. Dies ist erforderlich, da der Token Ring lokale Adressen (LAAs) zulässt. Wenn diese Prüfung nicht durchgeführt wird, können am Ende zwei Adapter mit derselben MAC-Adresse verwendet werden. Wenn diese Phase nicht innerhalb von 18 Sekunden abgeschlossen ist, meldet die Station einen Fehler und trennt sich vom Ring.

Hinweis: Wenn in einem anderen Ring eine doppelte MAC-Adresse vorhanden ist, die in überbrückten Token Ring-Quellrouten zulässig ist, wird dies nicht erkannt. Die doppelte Adressprüfung ist nur lokal von Bedeutung.

Teilnahme an Ringumfrage

In der Ringabfrage erhält die Station die Adresse ihres NAUN (Nearest Active Upstream Neighbor) und teilt ihre Adresse dem nächsten Downstream-Nachbarn mit. Bei diesem Vorgang wird die Ringzuordnung erstellt. Die Station muss warten, bis sie einen AMP- oder SMP-Frame empfängt, wobei die ARI- und FCI-Bits auf 0 gesetzt sind. Ist dies der Fall, wechselt die Station beide Bit (ARI und FCI) in 1, wenn genügend Ressourcen verfügbar sind, und stellt einen SMP-Frame für die Übertragung in die Warteschlange. Wenn innerhalb von 18 Sekunden keine solchen Frames empfangen werden, meldet die Station, dass sie den Ring nicht öffnet und nicht wieder entfernt. Wenn die Station erfolgreich an einer Ringabfrage teilnimmt, geht sie in die letzte Phase des Einfügens, der Anforderungsinitialisierung.

Initialisierung anfordern

In der Anfrageinitialisierungsphase sendet die Station vier MAC-Frames zur Anfrageinitialisierung an die funktionale Adresse des Ring Parameter Servers (RPS). Wenn im Ring kein RPS vorhanden ist, verwendet der Adapter seine eigenen Standardwerte und meldet den erfolgreichen Abschluss des Einfügeprozesses. Wenn der Adapter einen seiner vier Request Initialization MAC Frames zurückerhält, wobei die ARI- und FCI-Bits auf 1 gesetzt sind, wartet er zwei Sekunden auf eine Antwort. Wenn keine Antwort erfolgt, wird sie bis zu vier Mal erneut gesendet. Wenn zu diesem Zeitpunkt keine Antwort erfolgt, wird ein Fehler bei der Anfrageinitialisierung gemeldet und das Einsetzen aus dem Ring wird entfernt.

Dies ist eine Liste der funktionellen Adressen:

C000.0000.0001 - Active monitor

C000.0000.0002 - Ring Parameter Server

C000.0000.0004 - Network Server Heartbeat

C000.0000.0008 - Ring Error Monitor

C000.0000.0010 - Configuration Report Server

C000.0000.0020 - Synchronous Bandwidth Manager

C000.0000.0040 - Locate Directory Server

C000.0000.0080 - NetBIOS

C000.0000.0100 - Bridge

C000.0000.0200 - IMPL Server

C000.0000.0400 - Ring Authorization Server

C000.0000.0800 - LAN Gateway

C000.0000.1000 - Ring Wiring Concentrator

C000.0000.2000 - LAN Manager

Weitere Informationen zu Funktionsadressen finden Sie in den Spezifikationen zu IEEE802.5.

Fehlerbehebung

Flussdiagramm

In diesem Flussdiagramm finden Sie eine schnelle Übersicht zur Fehlerbehebung:

Wenn eine Token Ring-Schnittstelle Probleme beim Einstecken in den Ring hat, muss zunächst geprüft werden, ob Sie in einen bereits vorhandenen Ring einstecken. Wenn ja, müssen Sie die Ringnummer, die auf der Token Ring-Schnittstelle konfiguriert wurde, mit der bestehenden Ringnummer abgleichen, die von anderen Source-Route Bridges (SRBs) verwaltet wird.

Hinweis: Cisco Router akzeptieren Ringnummern standardmäßig im Dezimalformat, während die meisten IBM-Bridges in der Hexadezimalschreibweise arbeiten. Stellen Sie daher sicher, dass Sie die Umwandlung von hexadezimal in decimal durchführen, bevor Sie dies auf dem Cisco Router konfigurieren. Wenn Sie beispielsweise eine SRB mit der Rufnummer 0x10 haben, müssen Sie auf dem Cisco Router 16 eingeben. Alternativ können Sie die Klingelnummer in der Token Ring-Schnittstelle des Cisco Routers im Hexadezimalformat eingeben, wenn Sie der Klingelnummer den Wert 0x voranstellen:

turtle(config)# interface token

turtle(config)# interface tokenring 0

turtle(config-if)# source

turtle(config-if)# source-bridge 0x10 1 0x100

Hinweis: Wenn Sie die Konfiguration anzeigen, zeigt der Router die Klingelnummern automatisch in Dezimalschreibweise an. Aus diesem Grund sind Dezimalklingelnummern das am häufigsten verwendete Format auf Cisco Routern. Dies ist der relevante Teil eines show run-Befehls:

source-bridge ring-group 256

interface TokenRing0

no ip address

ring-speed 16

source-bridge 16 1 256

!--- 16 is the physical ring number, 1 is the bridge number or ID, !--- and 256 is the Virtual Ring number.

source-bridge spanning

Wenn Sie die Klingelnummern nicht finden, gibt die Cisco Token Ring-Schnittstelle eine ähnliche Meldung aus und fährt sich selbst herunter:

02:50:25: %TR-3-BADRNGNUM: Unit 0, ring number (6) doesn't match

established number (5).

02:50:25: %LANMGR-4-BADRNGNUM: Ring number mismatch on TokenRing0,

shutting down the interface

02:50:27: %LINK-5-CHANGED: Interface TokenRing0, changed state

to administratively down

Sie müssen dann die richtige Ringnummer auf der Token Ring-Schnittstelle konfigurieren???In diesem Fall 5????und den Befehl no shutdown manuell ausführen.

Hinweis: Die Bridge-Nummer (oder Bridge-ID) muss nicht mit anderen Bridge-Nummern im Netzwerk übereinstimmen. Sie können im gesamten Netzwerk einen eindeutigen Wert oder dieselbe Bridge-Nummer verwenden, solange Sie über einen eindeutigen RIF-Pfad (Routing Information Field) für jedes Gerät im SRB-Netzwerk verfügen. Ein Beispiel, wenn Sie unterschiedliche Bridge-Nummern benötigen, ist, dass zwei Ringe über zwei parallele Bridges verbunden sind. In diesem Fall führt die Nichtverwendung unterschiedlicher Bridge-Nummern zu zwei physisch unterschiedlichen Pfaden, jedoch zu denselben RIF-Informationen.

Hinweis: Wenn Sie den Source-Bridge-Befehl hinzufügen oder entfernen, wird die Token Ring-Schnittstelle deaktiviert, was zu Unterbrechungen für und von diesem Router über die Token Ring-Schnittstelle führt. Weitere Informationen zum Konfigurieren von SRB finden Sie unter Understanding and Troubleshooting Local Source-Route Bridging.

Sie müssen nicht nur Ringnummern zuordnen, sondern auch sicherstellen, dass die Ringgeschwindigkeit korrekt eingestellt ist. d. h. 4 oder 16 Mbit/s. Andernfalls wird ein Ring-Beacon erzeugt, und es kommt zu einem Netzwerkausfall in diesem Ring. Wenn die Ringnummern und die Ringgeschwindigkeit korrekt eingerichtet sind, die Token Ring-Schnittstelle aber immer noch nicht in den Ring eingesetzt werden kann, können Sie mithilfe des Eliminationsprozesses Probleme mit Kabeln oder der MAU ausschließen. Verwenden Sie einen Wrap-Stecker, oder stellen Sie sicher, dass der Adapter an eine funktionierende MAU angeschlossen ist. Schlechte Verkabelung verursacht viele Adapterprobleme während des Einfügevorgangs. Folgende Punkte sollten Sie beachten:

- Ist der Adapter so konfiguriert, dass er den korrekten Medienport, das ungeschirmte Twisted-Pair-Kabel (UTP) oder das abgeschirmte Twisted-Pair-Kabel (STP) verwendet?

- Ist das Kabel, das vom Adapter zum Hub führt, vollständig und korrekt?

- Welche Art von Medienfilter wird verwendet? Beachten Sie, dass 4 Mbit/s bei 16 Mbit/s nicht immer funktionieren.

Es kann sein, dass beim Ring ein Problem mit der physischen Schicht (z. B. Verkabelung, Leitungsgeräusche oder Jitter) auftritt, das auftritt, wenn mehr Stationen einsetzen. Dies führt zu Löschungen und Beacons, die einen neu eingelegten Adapter starten. Dies kann vermieden werden, wenn die Token Ring-Schnittstelle aktiviert wird, wenn sie mit einer anderen MAU ohne andere Stationen verbunden ist. Anschließend können Sie nach und nach weitere Stationen hinzufügen, um zu sehen, wann ein Fehler auftritt. Dieser Test beseitigt auch mögliche Konfliktprobleme wie Active Monitor, RPS, Configuration Report Server (CRS) und andere. Weitere Informationen finden Sie im Abschnitt LAN Network Manager.

LAN-Netzwerk-Manager

LAN Network Manager (LNM, vormals LAN Manager) ist ein IBM-Produkt, das eine Reihe von Source-Route-Bridges verwaltet. LNM verwendet eine Version des Common Management Information Protocol (CMIP), um mit dem LNM-Station-Manager zu sprechen. Mit LNM können Sie die gesamte Sammlung von Token-Rings überwachen, aus denen Ihr Bridge-Netzwerk für die Quellroute besteht. Sie können LNM verwenden, um die Konfiguration von Quell-Route-Bridges zu verwalten, Token-Ring-Fehler zu überwachen und Informationen von Token Ring-Parameterservern zu sammeln.

Ab der Cisco IOS Software Version 9.0 unterstützen Cisco Router, die Token Ring-Schnittstellen mit 4 und 16 Mbit/s verwenden, die für SRB konfiguriert sind, das von LNM verwendete proprietäre Protokoll. Diese Router bieten alle Funktionen, die das IBM Bridge-Programm derzeit bietet. So kann LNM mit einem Router kommunizieren, als handele es sich um eine Quell-Route-Bridge von IBM (z. B. IBM 8209), und alle mit dem Router verbundenen Token-Ring-Verbindungen verwalten oder überwachen, unabhängig davon, ob es sich um einen virtuellen Ring oder einen physischen Ring handelt. LNM ist auf Cisco Routern standardmäßig aktiviert. Außerdem sind diese Befehle für die Konfiguration der versteckten Schnittstellen standardmäßig aktiviert:

- [no] lnm crs - Das CRS überwacht die aktuelle logische Konfiguration eines Token Ring und meldet alle Änderungen an LNM. CRS meldet außerdem verschiedene andere Ereignisse, z. B. den Wechsel eines aktiven Monitors auf einem Token Ring.

- [no] lnm rps - Das RPS meldet dem LNM, wenn eine neue Station einem Token Ring beitritt, und stellt sicher, dass alle Stationen in einem Ring eine einheitliche Reihe von Berichtsparametern verwenden.

- [no] lnm rem - Ring Error Monitor (REM) überwacht Fehler, die von einer beliebigen Station im Ring gemeldet werden. Darüber hinaus überwacht REM, ob der Ring funktionsfähig oder fehlerhaft ist.

Diese Befehle sind in der Konfiguration nur sichtbar, wenn sie deaktiviert wurden:

para# config terminal

Enter configuration commands, one per line.  End with CNTL/Z.

para(config)# interface tokenRing 0

para(config-if)# no lnm crs

para(config-if)# ^Z

Dies ist Teil der Token Ring-Schnittstellenkonfiguration, in der die Konfiguration angezeigt wird:

interface TokenRing0

ip address 192.168.25.18 255.255.255.240

no ip directed-broadcast

ring-speed 16

source-bridge 200 1 300

source-bridge spanning

no lnm CRS

Bei der Fehlerbehebung für Token Ring-Schnittstellen kann es erforderlich sein, CRS, RPS, REM oder alle drei auf dem Cisco Router zu deaktivieren, um Konflikte mit anderen Token Ring-Geräten auszuschließen. Ein typisches Szenario hierfür ist, dass eine Token-Ring-Station nicht in den Ring eingesetzt werden kann, obwohl dieselbe Station in einen isolierten Ring ohne andere Stationen eingesetzt werden kann. Sie können einzelne Server wie RPS, CRS und REM deaktivieren oder die LNM-Funktion auf dem Router komplett in dieser globalen Konfiguration deaktivieren:

- lnm disabled (Deaktiviert): Dieser Befehl beendet alle LNM-Server-Eingabe- und Reporting-Links. Es handelt sich um eine Übermenge der Funktionen, die normalerweise an einzelnen Schnittstellen durch die no lnm rem, no lnm rps und no lnm rps ausgeführt werden.

Wenn Sie LNM deaktivieren und dies das Problem löst, stellen Sie sicher, dass Sie keinen bekannten Fehler finden. Wenn LNM in Ihrem Netzwerk nicht erforderlich ist, können Sie es deaktivieren.

Sie können auch die LNM-Funktion des Cisco Routers nutzen, um Stationen aufzulisten, die sich in den lokalen Ringen befinden, die mit dem Router verbunden sind, um festzustellen, ob isolierende Fehlerzahlen vorliegen, und um zu sehen, von welcher Station diese gesendet werden:

para# show lnm station

isolating error counts

station      int    ring  loc.   weight   line  inter burst  ac   abort

0005.770e.0a8c   To0    00C8  0000   00 - N   00000 00000 00000 00000 00000

0006.f425.ce89   To0    00C8  0000   00 - N   00000 00000 00000 00000 00000

Hinweis: Wenn Sie LNM deaktivieren, können Sie keine der show lnm-Befehle verwenden.

Im Befehl show lnm station sind die Stationsadresse, die Ringnummer und alle gemeldeten Fehler von besonderem Interesse. Eine vollständige Erklärung der Felder finden Sie im Befehl show lnm station im Befehlsreferenz-Handbuch.

Ein weiterer nützlicher LNM-Befehl ist der Befehl show lnm interface:

para# show lnm interface tokenring 0

nonisolating error counts

interface   ring   Active Monitor   SET    dec  lost  cong.  fc   freq. token

To0         0200   0005.770e.0a8c  00200  00001 00000 00000 00000 00000 00000

Notification flags: FE00, Ring Intensive: FFFF, Auto Intensive: FFFF

Active Servers: LRM LBS REM RPS CRS

Last NNIN:   never, from 0000.0000.0000.

Last Claim:  never, from 0000.0000.0000.

Last Purge:  never, from 0000.0000.0000.

Last Beacon: never, 'none' from 0000.0000.0000.

Last MonErr: never, 'none' from 0000.0000.0000.

isolating error counts

station      int    ring  loc.   weight   line  inter burst  ac   abort

0005.770e.0a8c   To0    00C8  0000   00 - N   00000 00000 00000 00000 00000

0006.f425.ce89   To0    00C8  0000   00 - N   00000 00000 00000 00000 00000

Über diesen Befehl können Sie schnell sehen, wer der aktive Monitor ist, welche Stationen sich im direkt verbundenen Ring befinden und welche aktiven Server im Ring (z. B. REM, RPS usw.) aktiv sind.

Dies sind die anderen Befehlsoptionen für show lnm:

show lnm bridge

show lnm config

show lnm ring

Verwendung von Cisco IOS Software-Befehlen

Dies sind die gebräuchlichsten Cisco IOS Software-Fehlerbehebungsbefehle für Token Ring-Schnittstellen:

- Show-Schnittstellen Token

- Controller-Token anzeigen

- Tokenereignisse debuggen

Show-Schnittstellen Token

Dies sind die Highlights des Befehls show interfaces tokenring:

ankylo# show interfaces tokenring1/0

TokenRing1/0 is up, line protocol is up

Hardware is IBM2692, address is 0007.78a6.a948 (bia 0007.78a6.a948)

Internet address is 1.1.1.1/24

MTU 4464 bytes, BW 16000 Kbit, DLY 630 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation SNAP, loopback not set

Keepalive set (10 sec)

ARP type: SNAP, ARP Timeout 04:00:00

Ring speed: 16 Mbps

Duplex: half

Mode: Classic token ring station

Source bridging enabled, srn 5 bn 1 trn 100 (ring group)

spanning explorer enabled

Group Address: 0x00000000, Functional Address: 0x0800001A

Ethernet Transit OUI: 0x000000

Last Ring Status 18:15:54

(0x2000)

Last input 00:00:01, output 00:00:01, output hang never

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

27537 packets input, 1790878 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

7704 packets output, 859128 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 output buffer failures, 0 output buffers swapped out

1 transitions

Ausgabeverwerfungen können verursacht werden, wenn die Ausgabemedien Frames nicht akzeptieren können und die Ausgabewarteschlange den maximalen Wert erreicht, bevor sie Pakete verwerfen. Ausgabeverwerfungen weisen möglicherweise nicht notwendigerweise auf ein Problem hin, da ein gelöschter Explorer-Frame (da er bereits in einem bestimmten Ring durchlaufen wurde) den Ausgabeverwerfungszähler erhöhen kann.

Steigende Eingangsverluste können jedoch schwerwiegend sein und sollten sorgfältig analysiert werden. Eingabepacks können durch unzureichende Systempuffer verursacht werden. Siehe 0 no buffer in der vorherigen show interfaces tokenring1/0 output. Der inkrementelle no buffer-Zähler der show interface-Ausgabe kann mit dem inkrementierenden Mises-Zähler der show buffers-Ausgabe korrelieren, und der entsprechende Puffer-Pool muss möglicherweise angepasst werden. Weitere Informationen finden Sie unter Buffer Tuning für alle Cisco Router.

Hinweis: Eingabe- und Ausgabewarteschlangen können mit der Länge der Warteschlange {in | out}-Befehl; Es ist jedoch wichtig zu verstehen, warum diese Warteschlangen ihren maximalen Haltewert erreichen, bevor Sie sie erhöhen. Wenn Sie den Maximalwert für Warteschlangen erhöhen, wird der Zeitraum möglicherweise erst verlängert, bevor der Überlauf erneut erfolgt.

Sie sollten auch den Zähler für die Kehle überprüfen. Dieser Zähler gibt an, wie oft die Eingangspuffer einer Schnittstelle gereinigt wurden, weil sie nicht schnell genug gewartet wurden oder überlastet sind. In der Regel kann ein Sturm eines Explorers dazu führen, dass der Throttles-Zähler inkrementiert wird. Weitere Informationen finden Sie im Befehl source-bridge explorer-maxrate und im Abschnitt Optimized Explorer Processing unter Konfigurieren des Source-Route-Bridging.

Hinweis: Bei jeder Drosselung werden alle Pakete in der Eingangswarteschlange verworfen. Dies führt zu einer sehr langsamen Leistung und kann auch vorhandene Sitzungen unterbrechen.

Ein Übergang erfolgt, wenn die Schnittstelle ihren Zustand ändert, z. B. wenn sie von einem Absturz zum Initialisieren oder vom Initialisieren zum Hochfahren geht. Ein Zurücksetzen erfolgt, wenn die Schnittstelle gestartet wird. Die Einfügung anderer Geräte in den Ring sollte nicht dazu führen, dass eine dieser Zähler zunimmt, aber die Anzahl der Soft-Fehler wird erhöht. Wenn der Befehl show interface tokenring keine Verwerfungen, Eingabefehler oder Ausgabefehler anzeigt, Sie aber eine beträchtliche Anzahl von Zurücksetzungen und Übergängen sehen, können die Keepalives die Schnittstelle zurücksetzen.

Hinweis: Wenn Sie eine Tokenklingelschnittstelle löschen, erfolgt eine Zurücksetzung und zwei Übergänge: einen Übergang von der Initialisierung zur Initialisierung und einen von der Initialisierung zur Inbetriebnahme.

Das Feld Letzter Ringstatus zeigt den letzten Klingelstatus für den Klingelton an. 0x2000 beispielsweise weist auf einen Softwarefehler hin. Dies ist eine Liste möglicher Statuswerte:

RNG_SIGNAL_LOSS FIXSWAP(0x8000)

RNG_HARD_ERROR  FIXSWAP(0x4000)

RNG_SOFT_ERROR  FIXSWAP(0x2000)

RNG_BEACON      FIXSWAP(0x1000)

RNG_WIRE_FAULT  FIXSWAP(0x0800)

RNG_HW_REMOVAL  FIXSWAP(0x0400)

RNG_RMT_REMOVAL FIXSWAP(0x0100)

RNG_CNT_OVRFLW  FIXSWAP(0x0080)

RNG_SINGLE      FIXSWAP(0x0040)

RNG_RECOVERY    FIXSWAP(0x0020)

RNG_UNDEFINED   FIXSWAP(0x021F)

RNG_FATAL       FIXSWAP(0x0d00)

RNG_AUTOFIX     FIXSWAP(0x0c00)

RNG_UNUSEABLE   FIXSWAP(0xdd00)

Hinweis: Der Softwarefehler 0x2000 ist ein sehr gebräuchlicher, normaler Ringstatus. 0x20 steht für Ringinitialisierung und 00 für die Länge des Subvektors. Dies weist darauf hin, dass eine Ringstation in den Ring eingedrungen ist.

Controller-Token anzeigen

Der nächste Cisco IOS Software-Befehl zur Fehlerbehebung ist der Befehl show controller tokenring:

FEP# show controllers tokenring 0/0

TokenRing0/0: state up

current address: 0000.30ae.8200, burned in address: 0000.30ae.8200

Last Ring Status: none

Stats: soft: 0/0, hard: 0/0, sig loss: 0/0

tx beacon: 0/0, wire fault 0/0, recovery: 0/0

only station: 0/0, remote removal: 0/0

Bridge: local 100, bnum 1, target 60

max_hops 7, target idb: null

Interface failures: 0

Monitor state: (active), chip f/w: '000500.CS1AA5 ', [bridge capable]

ring mode: F00, internal enables:  SRB REM RPS CRS/NetMgr

internal functional: 0800011A (0800011A), group: 00000000 (00000000)

internal addrs: SRB: 0288, ARB: 02F6, EXB 0880, MFB: 07F4

Rev: 0170, Adapter: 02C4, Parms 01F6

Microcode counters:

MAC giants 0/0, MAC ignored 0/0

Input runts 0/0, giants 0/0, overrun 0/0

Input ignored 0/0, parity 0/0, RFED 0/0

Input REDI 0/0, null rcp 0/0, recovered rcp 0/0

Input implicit abort 0/0, explicit abort 0/0

Output underrun 0/0, TX parity 0/0, null tcp 0/0

Output SFED 0/0, SEDI 0/0, abort 0/0

Output False Token 0/0, PTT Expired 0/0

Internal controller counts:

line errors: 0/0,  internal errors: 0/0

burst errors: 0/0,  ari/fci errors: 0/0

abort errors: 0/0, lost frame: 0/0

copy errors: 0/0, rcvr congestion: 0/0

token errors: 0/0, frequency errors: 0/0

Internal controller smt state:

Adapter MAC:     0000.30ae.8200, Physical drop:     00000000

NAUN Address:    0005.770e.0a87, NAUN drop:         00000000

Last source:     0000.30ae.8200, Last poll:         0000.30ae.8200

Last MVID:       0006,           Last attn code:    0006

Txmit priority:  0003,           Auth Class:        7BFF

Monitor Error:   0000,           Interface Errors:  0004

Correlator:      0000,           Soft Error Timer:  00DC

Local Ring:      0000,           Ring Status:       0000

Beacon rcv type: 0000,           Beacon txmit type: 0004

Beacon type:     0000,           Beacon NAUN:       0005.770e.0a87

Beacon drop:     00000000,       Reserved:          0000

Reserved2:       0000

Soft-Fehler - Dies ist eine Kombination aller Soft-Fehler, die von dieser Schnittstelle angezeigt werden. Weiche Fehler umfassen Leitungsfehler, mehrere Monitore, ARI- und FCI-Set-Fehler, Burst-Fehler, verlorene Frames, beschädigtes Token, verlorenes Token, zirkulierendes Frame- oder Prioritätstoken, verlorenen Monitor und Frequenzfehler. Einzelheiten finden Sie unter Informationen zu weichen Fehlern.

Hard errors (Festplattenfehler): Diese Fehler können durch Software-Routinen nicht behoben werden. Der Ring wurde physisch zurückgesetzt. Weitere Informationen finden Sie unter Token Ring Abnormer State List (Token-Ring-Statusliste).

Überwachungsstatus: (active) - Zeigt den Status des Controllers an. Mögliche Werte sind Active, Failure, Inaktiv und Reset.

SRB REM RPS CRS/NetMgr - Zeigt an, dass SRB, REM, RPS und CRS auf der Schnittstelle aktiviert sind. Weitere Informationen finden Sie im Abschnitt LAN Network Manager.

Wichtige Informationen, die auch in der Ausgabe enthalten sind, sind die Adapter-MAC- und NAUN-Adresse, die bei der Bestimmung der Ringtopologie helfen. Sie können auch herausfinden, wer der Ring Beacon NAUN ist. das heißt, der nächstaktive Upstream-Nachbarn zur Beaconing-Station. So können Sie ermitteln, wo das Problem liegt: die Beacon-Station, die Beacon NAUN oder das dazwischen liegende Kabel. Eine Erläuterung der übrigen Felder finden Sie im Token für Controller im Befehlsreferenz-Handbuch.

Tokenereignisse debuggen

Der letzte Befehl der Cisco IOS Software zur Fehlerbehebung ist der Befehl debug token events:

1w6d: TR0 starting.

1w6d: %LINK-5-CHANGED: Interface TokenRing0, changed state to initializing

1w6d: TR0 receive SRB_FREE, state=2, if_state=6

1w6d: TR0 receive SRB_FREE, state=2, if_state=7 ring mode = F00

1w6d: TR0: modified open w/ option 1180

1w6d: TR0: Interface is alive, phys. addr 0000.3090.79a0

setting functional address w/ 800011A

setting group address w/ 80000000

ring mode = F00

1w6d: TR0: modified open w/ option 1180

1w6d: %LINK-3-UPDOWN: Interface TokenRing0, changed state to up

1w6d: %LINEPROTO-5-UPDOWN: Line protocol on Interface TokenRing0,

changed state to up

1w6d: %SYS-5-CONFIG_I: Configured from console by console

Vorsicht: Debugtokenereignisse sollten nur minimale Auswirkungen auf den Router haben, da nur Token-Ringereignisse und keine Pakete angezeigt werden. Wenn Sie jedoch bei vielen Übergängen einen sehr ausgelasteten Klingelton haben, sollten Sie den Protokollierungspuffer und die Befehle für die Protokollierungskonsole ausgeben und physischen Zugriff auf den Router haben.

Die vorherige Ausgabe von Debugtoken-Ereignissen stammt von einem Cisco Router der Serie 2500. Die Ausgabe kann eine Vielzahl von Meldungen enthalten, sollte aber einige Hinweise geben, wo das Problem liegen könnte. Im vorherigen Beispiel wird eine erfolgreiche Initialisierung der Token Ring-Schnittstelle veranschaulicht. Das Debuggen enthält auch Informationsmeldungen, die im Ringmodus sowie in der Gruppenadresse und Funktionsadresse enthalten sind.

Ringmodusdefinitionen

Diese Werte werden vom Hauptsystem an die Adapterplatinen übergeben, um anzugeben, welcher Modus die Schnittstelle verwenden soll. Sie steuern, ob bestimmte Funktionsbits aktiviert sind oder nicht, und steuern die Befehlsflags, die beim Einsetzen in den Token Ring verwendet werden. Für den Ringmodus bedeutet dies Folgendes:

Für das vorherige Beispieldebug ist der Ringmodus 0x0F00, ein 2-Byte-Wert, der folgende Bedeutungen hat:

RINGMODE_LOOPBACK       0x8000

RINGMODE_NO_RINGSTAT    0x4000

RINGMODE_ALL_FRAMES     0x2000

RINGMODE_ALL_LLC        0x1000

RINGMODE_BRIDGE         0x0800  /* status only */

RINGMODE_REM            0x0400  /* be Ring Error Monitor */

RINGMODE_RPS            0x0200  /* be Ring Parameter Server */

RINGMODE_NETMGR         0x0100  /* be Configuration Report Server */

RINGMODE_TBRIDGE        0x0080  /* be a transparent bridge */

RINGMODE_CONTENDER      0x0040  /* be a contender for AMP */

RINGMODE_RS             0x0020  /* listen to ring maintenance MAC frames */

RINGMODE_ALL_MAC        0x0010  /* listen to all MAC frames */

RINGMODE_ETR            0x0008  /* Early Token Release */

RINGMODE_NEED_MAC       0x0730  /* Needs MAC frames */

Der Ringmodus ist daher eine Summe dieser Biteinstellungen. 0xF00 steht für Bridge, Ring Error Monitor, Ring Parameter Server und Configuration Report Server.

Geändertes Öffnen mit Option

Dies ist die neue Chipsatzeinstellung von Cisco. Im vorherigen Beispieldebug wird die Option 1180 zum Öffnen geändert. Dies ist ein 16-Bit-Wert, der von links nach rechts gelesen wird. Der Cisco Router kann Optionen nur ein-, jedoch nicht ausrichten.

+  Bit 0 - Open in Wrap: the open adapter is executed without inserting

phantom drive to allow testing of the lobe.

+  Bit 1 - Disable Hard Error: prevents a change in the Hard Error and

Transmit Beacon bits causing a Ring Status Change ARB.

+  Bit 2 - Disable Soft Error: prevents a change in the Soft Error bit

from causing a Ring Status Change ARB.

+  Bit 3 - Pass Adapter MAC frames: Causes adapter class MAC frames

not supported by the adapter to be passed back as received Frames.

If this bit is off, these frames are discarded.

+  Bit 4 - Pass Attention MAC frames: Causes attention MAC frames that

are not the same as the last received attention MAC frame.

+  Bit 5 - reserved: should be 0

+  Bit 6 - reserved: should be 0

+  Bit 7 - Contender: When the contender bit is on, the adapter will

participate in claim token upon receiving a claim token frame from

another adapter with a lower source address. If this bit is off the

adapter will not enter into claim token process if it receives a

Claim Token MAC frame. The adapter will enter claim token if a need

is detected regardless of the setting of this bit.

+  Bit 8 - Pass Beacon MAC frames: The adapter will pass the first

Beacon MAC frame and all subsequent Beacon MAC frames that have a

change in the source address of the Beacon type.

+  Bit 9 - reserved: should be 0

+  Bit 10 - reserved: should be 0

+  Bit 11 - Token Release: If this bit is set the adapter will not

operate with early token release. If this bit is 0 the adapter will

operate with early token release when the selected ring speed is 16

megabits per second.

+  Bit 12 - reserved: should be 0

+  Bit 13 - reserved: should be 0

+  Bit 14 - reserved: should be 0

+  Bit 15 - reserved: should be 0

Option 0x180 finden Sie in den vorherigen fett formatierten Bits.

Festlegen der Funktions- und Gruppenadressen

Im vorherigen Beispieldebug ist die funktionale Adresse auf w/ 800011A festgelegt und die Gruppenadresse auf w/ 8000000.

Dies sind die Berichtsattribute für LNM:

REPORT_LRM   0x80000000

REPORT_LBS   0x00000100

REPORT_CRS   0x00000010

REPORT_REM   0x00000008

REPORT_RPS   0x00000002

REPORT_AVAIL 0x8000011a

REPORT_ALL   0x8000011a

Keepalives

Wenn das Problem in der zeitweiligen Aufhebung und erneuten Einfügung einer zufälligen Anzahl von Token Ring-Schnittstellen zu bestehen scheint, kann der Ring extrem überlastet sein, was dazu führt, dass die Keepalives, die von der Token Ring-Schnittstelle gesendet werden, das Zeitlimit überschreiten. Geben Sie den Schnittstellenbefehl keepalive {0 - 32767} ein, um den Keepalive-Wert zu erhöhen. (Der Standardwert ist 10 Sekunden.)

tricera(config)# interface tokenring 4/0/0

tricera(config-if)# keepalive 30

Hinweis: Wenn Sie die Keepalives erhöhen, können Sie verhindern, dass Token Ring-Schnittstellen bounce-Nachrichten senden. Dies ersetzt jedoch kein gutes Netzwerkdesign und keine ordnungsgemäße Ringsegmentierung.

Verwendung von LAN Analyzer

Oft sind die Probleme, mit denen Token Ring-Netzwerke konfrontiert sind, von zeitweiliger Bedeutung, wobei Wiederholungen in willkürlichen Abständen auftreten. Die Fehlerbehebung wird dadurch deutlich schwieriger. Dies ist häufig bei einer zufälligen Anzahl von Stationen der Fall, die eine langsame Leistung erleben oder sich kurzzeitig vom Ring lösen. Auch die Verwendung der oben genannten Techniken zur Fehlerbehebung bei Einfügemöglichkeiten liefert manchmal nicht genügend Informationen.

Um das Problem einzugrenzen, ist möglicherweise ein Token Ring LAN Analyzer erforderlich, um Frames zu erfassen und zu analysieren. Der Analysator sollte der direkte Upstream-Nachbar der Station sein, die versucht, das Gerät einzufügen. Daher ist es wichtig zu wissen, was Sie in einer Token Ring-Spur suchen sollten und was Sie in einem gesunden Token Ring-Netzwerk erwarten. Die Token Ring-Frame-Analyse geht über den Rahmen dieses Dokuments hinaus, aber diese Frames sind das, was Sie im Token Ring-Trace einer erfolgreichen Token Ring-Station-Einfügung erwarten würden:

MAC: Active Monitor Present

!--- Normal ring poll.

MAC: Standby Monitor Present

!--- Normal ring poll.

MAC: Duplicate Address Test

!--- Inserting station sends duplicate address MAC#1 frames.

MAC: Duplicate Address Test

!--- Inserting station sends duplicate address MAC#2 frames.

MAC: Standby Monitor Present

MAC: Report SUA Change

!--- Stored Upstream Address reported to Configuration Report Server !--- by inserting station.

MAC: Standby Monitor Present

!--- Participate in ring poll by inserting station.

MAC: Report SUA Change

!--- SUA reported by station downstream from inserting station.

MAC: Standby Monitor Present

!--- Normal ring poll.

MAC: Request Initialization

!--- Request ring initialization MAC#1 from Ring Parameter Server.

MAC: Request Initialization

!--- Request ring initialization MAC#2 from Ring Parameter Server.

MAC: Request Initialization

!--- Request ring initialization MAC#3 from Ring Parameter Server.

MAC: Request Initialization

!--- Request ring initialization MAC#4 from Ring Parameter Server.

MAC: Report Soft Error

MAC: Active Monitor Present

MAC: Standby Monitor Present

!--- Station inserted and participating in ring poll.

MAC: Standby Monitor Present

Hinweis: Diese Ablaufverfolgung wurde gefiltert, um nur Frames von Interesse anzuzeigen (siehe die Kommentare). In einem Netzwerkanalyst können diese Frames genauer untersucht werden, um die in diesen Feldern enthaltenen detaillierten Informationen anzuzeigen.

Es ist sehr wahrscheinlich, dass Sie auch durch das einfache Öffnen des Hub-Relays ungewöhnliche Fehler wie Burst-Fehler, Leitungsfehler, Tokenfehler, Ringbereinigungen und verlorene Frame-Fehler sehen werden. Gehen Sie nicht davon aus, dass das Vorhandensein dieser Fehler auf einen problematischen Ring hinweist, da dies normale Symptome sind, die während des Einfügevorgangs auftreten.

Andere Frames, die aussehen sollen, sind z. B. vom AM ausgegebene MAC-Frames, die als Neighbor Notification Incomplete (NNI) oder Ring-Polling Failure (Ringfehler) bezeichnet werden. Dieser Frame sollte in einem defekten Ring alle sieben Sekunden vor einem AMP MAC-Frame ausgegeben werden. Der NNI-Frame ist wichtig, da er die Adresse der letzten Station enthält, um den Ringabfrage-Prozess erfolgreich abzuschließen. Der Downstream-Nachbar von dieser Station ist normalerweise der Schuldige, und Sie können den Downstream-Nachbarn entfernen, um das Problem zu lösen.

Zugehörige Informationen

- Fehlerbehebung DLSw

- Support-Seite für DLSw (Data-Link Switching) und DLSw+ (Data-Link Switching Plus)

- Technischer Support und Dokumentation - Cisco Systems