Fehlerbehebung bei Token-Ring-Schnittstellen des Cisco Routers
Inhalt
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:
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
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.
Feedback