Fehlerbehebung bei Cisco Router Token Ring-Schnittstellen
Inhalt
Einleitung
In diesem Dokument werden einige der häufigsten Probleme beschrieben, die dazu führen, dass eine Cisco Router-Token-Ring-Schnittstelle kein Token-Ring einfügt. Es enthält ein Flussdiagramm mit einer schnellen Übersicht über die zur Fehlerbehebung an der Token Ring-Schnittstelle erforderlichen Schritte. In diesem Dokument werden auch einige der am häufigsten verwendeten Cisco IOS®-Softwarebefehle erläutert und wie diese zur Erfassung von Informationen über die Token Ring-Schnittstelle verwendet werden, um das Problem erfolgreich zu beheben.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Token-Ring einfügen
Um Token-Ring-Schnittstellen erfolgreich zu beheben, ist es wichtig, die Abfolge von Ereignissen zu kennen, die vor dem Beitritt einer Station zum Ring auftreten.
Es gibt fünf Phasen, in denen eine Station einem Ring beitritt:
Lappentest
Der Einfügevorgang beginnt mit einem Lappentest. Diese Phase testet den Sender und Empfänger des Token Ring-Adapters und testet das Kabel zwischen dem Adapter und der Multistation Access Unit (MAU). Ein MAU wickelt die Übertragungsleitung des Verbindungskabels??? physisch auf die Empfangsleitung zurück. Dadurch kann der Adapter Medientest-MAC-Frames über das Kabel an die MAU übertragen (wo diese eingewickelt ist) und zurück an sich selbst. 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) über das Kabel. Besteht der Lappentest, ist Phase eins abgeschlossen.
Prüfung auf physische Einfügung und Überwachung
In der zweiten Phase wird ein pH-Antom-Strom zum Öffnen des Nabenrelais gesendet, sobald das Nabenrelais die Station öffnet und sich selbst am Ring befestigt. Die Station prüft dann, ob ein aktiver Monitor (AM) vorhanden ist, indem sie einen der folgenden Frames überprüft:
-
Aktiver Monitor vorhanden (AMP) MAC-Frame
-
Standby Monitor vorhanden (SMP) MAC-Frame
-
Klingeltonbereinigung von MAC-Frames
Wenn innerhalb von 18 Sekunden kein Frame erkannt wird, geht die Station davon aus, dass kein aktiver Monitor vorhanden ist, und initiiert den Monitor-Contention-Prozess. Durch den Monitor-Konfliktprozess 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 als AM fungiert und eine Bereinigung initiiert und der Bereinigungsvorgang nicht innerhalb einer Sekunde abgeschlossen wird, kann der Adapter nicht geöffnet werden. Wenn der Adapter einen Beacon-MAC-Frame oder einen Remove-Station-MAC-Frame empfängt, kann sich der Adapter nicht öffnen.
Doppelte Adressprüfung
Im Rahmen der Duplikat-Adressprüfung sendet die Station eine Reihe von Duplikat-Adress-MAC-Frames an sich selbst. Wenn die Station zwei Frames mit dem Address Recognized Indicator (ARI) und dem Frame Copied Indicator (FCI) mit dem Wert 1 zurückempfängt, weiß sie, dass es sich bei dieser Adresse um ein Duplikat in diesem Ring handelt, löst sich ab und meldet einen Fehler beim Öffnen. Dies ist erforderlich, da der Token-Ring lokal verwaltete Adressen (Local Administered Addresses, LAAs) zulässt. Andernfalls könnten zwei Adapter mit derselben MAC-Adresse anfallen. Wenn diese Phase nicht innerhalb von 18 Sekunden abgeschlossen ist, meldet die Station einen Ausfall und löst sich vom Ring.
Hinweis: Wenn in einem anderen Ring eine doppelte MAC-Adresse vorhanden ist, was in Bridge-Token-Ring-Netzwerken mit Quellroute zulässig ist, wird diese nicht erkannt. Die doppelte Adressprüfung ist nur lokal von Bedeutung.
Teilnahme an der Umfrage
In der Ringabfragephase ermittelt die Station die Adresse ihres NAUN (Nearest Active Upstream Neighbor) und gibt diese Adresse ihrem nächsten nachgeschalteten Nachbarn bekannt. Bei diesem Prozess 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. Wenn dies der Fall ist, kippt die Station beide Bits (ARI und FCI) auf 1, wenn genügend Ressourcen verfügbar sind, und reiht einen SMP-Frame für die Übertragung in die Warteschlange ein. Wenn innerhalb von 18 Sekunden keine solchen Frames empfangen werden, meldet die Station ein fehlgeschlagenes Öffnen und Entfernen der Frames aus dem Ring. Wenn die Station erfolgreich an einer Ringabfrage teilnimmt, beginnt die letzte Phase der Einfügung und Anforderungsinitialisierung.
Initialisierung anfordern
In der Anforderungsinitialisierungsphase sendet die Station vier Anforderungsinitialisierungs-MAC-Frames an die Funktionsadresse des Ringparameter-Servers (RPS). Wenn kein RPS im Ring vorhanden ist, verwendet der Adapter seine eigenen Standardwerte und meldet den erfolgreichen Abschluss des Einfügevorgangs. Wenn der Adapter eines seiner vier MAC-Frames für die Anforderungsinitialisierung empfängt, wobei das ARI- und das FCI-Bit auf 1 gesetzt sind, wartet er zwei Sekunden auf eine Antwort. Wenn keine Antwort erfolgt, wird die Nachricht bis zu viermal neu übertragen. Wenn keine Antwort erfolgt, wird ein Fehler bei der Anforderungsinitialisierung gemeldet, und der Ring wird entfernt.
Dies ist eine Liste der Funktionsadressen:
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 kurze Übersicht zur Fehlerbehebung:
Wenn eine Token Ring-Schnittstelle Probleme beim Einfügen in den Ring hat, muss zuerst überprüft werden, ob der Ring bereits vorhanden ist. Wenn ja, müssen Sie die auf der Token Ring-Schnittstelle konfigurierte Ringnummer mit der vorhandenen Ringnummer abgleichen, die von anderen Source-Route Bridges (SRBs) gesteuert wird.
Hinweis: Cisco Router akzeptieren Klingeltöne standardmäßig im Dezimalformat, während die meisten IBM-Bridges die Hexadezimalnotation verwenden. Stellen Sie deshalb sicher, dass Sie die Konvertierung von hexadezimal in dezimal 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 auf der Token Ring-Schnittstelle des Cisco Routers im Hexadezimalformat eingeben, wenn Sie der Klingelnummer 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 Rufnummern automatisch in Dezimalschreibweise an. Daher sind dezimale Klingeltöne das am häufigsten verwendete Format auf Cisco Routern. Dies ist der relevante Teil eines Befehls show run:
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 nicht mit den Klingelnummern übereinstimmen, gibt die Cisco Token Ring-Schnittstelle eine ähnliche Meldung aus und schaltet sich selbst ab:
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 Klingelnummer auf der Token Ring-Schnittstelle konfigurieren???in diesem Fall 5???und dann manuell den Befehl no shutdown eingeben.
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 einen eindeutigen RIF-Pfad (Routing Information Field) zu jedem Gerät im SRB-Netzwerk haben. Ein Beispiel für den Fall, dass Sie unterschiedliche Brückennummern benötigen, ist, dass Sie zwei Ringe haben, die über zwei parallele Brücken verbunden sind. In diesem Fall führt die Nichtverwendung unterschiedlicher Bridge-Nummern zu zwei physisch unterschiedlichen Pfaden, aber den gleichen RIF-Informationen.
Hinweis: Wenn Sie den Quell-Bridge-Befehl hinzufügen oder entfernen, springt die Token-Ring-Schnittstelle zurück, was zu Unterbrechungen an und von diesem Router über die Token-Ring-Schnittstelle führt. Weitere Informationen zur SRB-Konfiguration finden Sie unter Grundlagen und Fehlerbehebung beim lokalen Source-Route-Bridging.
Zusätzlich zu den entsprechenden Klingeltönen müssen Sie auch sicherstellen, dass die Klingeltongeschwindigkeit korrekt eingestellt ist, d. h. 4 oder 16 Mbit/s. Andernfalls wird ein Ring-Beacon generiert, und es kommt zu einem Netzwerkausfall in diesem Ring. Wenn die Rufnummern und die Ringgeschwindigkeit korrekt eingerichtet sind, die Token Ring-Schnittstelle jedoch immer noch nicht in den Ring eingefügt werden kann, eliminieren Sie Probleme mit Kabeln oder mit der MAU. Verwenden Sie einen Wrap-Plug, oder stellen Sie sicher, dass der Adapter an eine funktionierende MAU angeschlossen ist. Eine fehlerhafte Verkabelung verursacht viele Adapterprobleme während des Einfügevorgangs. Hier finden Sie einige wichtige Informationen:
-
Ist der Adapter für die Verwendung des richtigen Medien-Ports, UTP-Kabels (Unshielded Twisted-Pair) oder STP-Kabels (Shielded Twisted-Pair) konfiguriert?
-
Ist das Kabel, das vom Adapter zum Hub verläuft, vollständig und korrekt?
-
Welche Art von Medienfilter wird verwendet? Beachten Sie, dass bei 4 Mbit/s nicht immer alles mit 16 Mbit/s funktioniert.
Möglicherweise liegt ein Problem mit der physischen Schicht des Rings vor (z. B. Verkabelung, Leitungsrauschen oder Jitter), das sich zeigt, wenn weitere Stationen hinzugefügt werden. Dies führt zu Bereinigungen und Beacons, die einen neu eingesteckten Adapter auslösen. Dies kann vermieden werden, wenn die Token Ring-Schnittstelle aktiviert wird, wenn sie mit einer anderen MAU ohne andere Stationen verbunden ist. Sie können dann nach und nach weitere Stationen hinzufügen, um zu sehen, an welchem Punkt Sie einen Fehler bekommen. Mit diesem Test werden auch mögliche Konflikte wie Active Monitor, RPS, Configuration Report Server (CRS) und andere vermieden. Weitere Informationen finden Sie im Abschnitt LAN Network Manager.
LAN-Netzwerkmanager
LAN Network Manager (LNM, ehemals LAN Manager) ist ein IBM-Produkt, das eine Reihe von Quell-Routing-Bridges verwaltet. LNM verwendet eine Version des Common Management Information Protocol (CMIP) für die Kommunikation mit dem LNM-Stationsmanager. Mit LNM können Sie die gesamte Sammlung von Token-Ringen überwachen, aus denen Ihr überbrücktes Quellrouten-Netzwerk besteht. Sie können LNM verwenden, um die Konfiguration von Quell-Routing-Bridges zu verwalten, Token-Ring-Fehler zu überwachen und Informationen von Token-Ring-Parameterservern zu erfassen.
Seit Version 9.0 der Cisco IOS Software unterstützen Cisco Router, die Token Ring-Schnittstellen mit 4 und 16 Mbit/s verwenden, die für SRB konfiguriert wurden, das von LNM verwendete Protokoll. Diese Router bieten alle Funktionen, die das IBM Bridge-Programm derzeit bereitstellt. So kann LNM mit einem Router wie mit einer IBM-Quell-Routen-Bridge (z. B. dem IBM 8209) kommunizieren und jeden Token Ring verwalten oder überwachen, der mit dem Router verbunden ist, egal ob es sich um einen virtuellen Ring oder einen physischen Ring handelt. LNM ist auf Cisco Routern standardmäßig aktiviert. Außerdem sind die folgenden ausgeblendeten Schnittstellenkonfigurationsbefehle standardmäßig aktiviert:
-
[no] lnm crs - Das CRS überwacht die aktuelle logische Konfiguration eines Token-Rings und meldet alle Änderungen an LNM. CRS meldet außerdem verschiedene andere Ereignisse, z. B. den Wechsel eines aktiven Monitors in 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 konsistente Berichtsparameter verwenden.
-
[no] lnm rem - Ring Error Monitor (REM) überwacht Fehler, die von einer Station im Ring gemeldet werden. Darüber hinaus überwacht REM, ob sich der Ring in einem Funktions- oder Fehlerzustand befindet.
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 an Token Ring-Schnittstellen kann es erforderlich sein, CRS, RPS, REM oder alle drei Komponenten des Cisco Routers zu deaktivieren, um Konflikte mit anderen Token Ring-Geräten auszuschließen. Ein typisches Szenario ist, wenn eine Token-Ring-Station nicht in den Ring eingefügt werden kann, obwohl dieselbe Station in einen isolierten Ring ohne andere Stationen eingefügt werden kann. Mit dieser globalen Konfiguration können Sie einzelne Server wie RPS, CRS und REM deaktivieren oder die LNM-Funktion auf dem Router deaktivieren:
-
lnm disabled (lnm deaktiviert): Dieser Befehl beendet alle LNM-Servereingabe- und -Reporting-Links. Es handelt sich dabei um eine übergeordnete Gruppe von Funktionen, die normalerweise an einzelnen Schnittstellen mit den Befehlen no lnm rem, no lnm rps und no lnm rps ausgeführt werden.
Wenn Sie LNM deaktivieren und damit das Problem lösen, stellen Sie sicher, dass Sie nicht auf einen bekannten Fehler stoßen. Wenn LNM in Ihrem Netzwerk nicht erforderlich ist, können Sie es deaktiviert lassen.
Sie können die LNM-Funktion des Cisco Routers auch nutzen, um Stationen aufzulisten, die sich in den mit dem Router verbundenen lokalen Ringen befinden, um festzustellen, ob isolierende Fehlerzähler vorhanden sind, und um festzustellen, welche Station sie sendet:
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 keinen der Befehle show lnm verwenden.
Von besonderem Interesse ist der Befehl show lnm station: Adresse der Station, Klingeltonnummer und etwaige gemeldete Fehler. Eine vollständige Erläuterung 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
Mit diesem Befehl können Sie sofort sehen, wer der aktive Monitor ist, welche Stationen im direkt verbundenen Ring vorhanden sind und welche Server im Ring aktiv sind (z. B. REM, RPS usw.).
Dies sind die anderen Befehlsoptionen show lnm:
show lnm bridge show lnm config show lnm ring
Verwendung von Cisco IOS Software-Befehlen
Nachstehend finden Sie die gebräuchlichsten Befehle zur Fehlerbehebung für Token Ring-Schnittstellen in der Cisco IOS Software:
Schnittstellen-Token anzeigen
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
Wenn die Ausgabemedien Frames nicht akzeptieren können und die Ausgabewarteschlange den Maximalwert erreicht, bevor sie beginnt, Pakete zu verwerfen, kann es zu Ausgabeverlusten kommen. Ausgabeverwerfungen weisen nicht unbedingt auf ein Problem hin, da ein verworfener Explorer-Frame (da er bereits in einem bestimmten Ring gelaufen ist) den Zähler für Ausgabeverwerfungen erhöhen kann.
Ein zunehmender Rückgang der Eingangsleistung kann jedoch schwerwiegend sein und sollte sorgfältig analysiert werden. Eingabeverwerfungen können durch unzureichende Systempuffer verursacht werden; siehe 0 no buffer in der vorherigen Ausgabe von show interfaces tokenring1/0. Der Inkrementierungszähler no buffer der Ausgabe von show interfaces könnte mit dem Inkrementierungszähler misses der Ausgabe von show buffers korrelieren und der entsprechende Pufferpool müsste angepasst werden. Weitere Informationen finden Sie unter Buffer Tuning for all Cisco Routers.
Hinweis: Die Ein- und Ausgabewarteschlangen können mit der Länge der Haltewarteschlange {in} erhöht werden. | out}-Befehl; es ist jedoch wichtig, den Grund zu verstehen, warum diese Warteschlangen ihren maximalen Haltewert erreichen, bevor Sie sie erhöhen. Wenn Sie den Maximalwert für die Warteschlange erhöhen, vergrößern Sie möglicherweise nur den Zeitraum, bevor sie wieder überlaufen.
Sie sollten auch den Drosseln Zähler überprüfen. Dieser Leistungsindikator gibt an, wie oft die Eingangspuffer einer Schnittstelle bereinigt wurden, weil sie nicht schnell genug bedient wurden oder überlastet sind. Normalerweise kann ein Sturm des Explorers dazu führen, dass sich der Throttle-Zähler erhöht. Weitere Informationen finden Sie im Befehl source-bridge explorer-maxrate und im Abschnitt Optimized Explorer Processing unter Configuring Source-Route Bridging.
Hinweis: Bei jeder Drosselung werden alle Pakete in der Eingabewarteschlange verworfen. Dies führt zu einer sehr langsamen Leistung und kann auch bestehende Sitzungen stören.
Ein Übergang tritt auf, wenn die Schnittstelle ihren Zustand ändert, z. B. wenn sie von "down" zu "initializing" oder von "initializing" zu "up" wechselt. Ein Reset erfolgt, wenn die Schnittstelle gestartet wird. Das Einsetzen anderer Geräte in den Ring sollte nicht dazu führen, dass einer dieser Zähler ansteigt, es kann jedoch zu einer höheren Anzahl von weichen Fehlern kommen. Wenn der Befehl show interface tokenring keine Verwerfungen, Eingabefehler oder Ausgabefehler anzeigt, Sie jedoch eine erhebliche Anzahl von Resets und Übergängen sehen, dann setzen die Keepalives möglicherweise die Schnittstelle zurück.
Hinweis: Wenn Sie eine Token-Ring-Schnittstelle löschen, werden ein Reset und zwei Übergänge ausgeführt: ein Übergang von "bis" zur Initialisierung und einer von "initialisieren" zu "up".
Im Feld Letzter Klingelstatus wird der letzte Klingelstatus für den Klingelton angezeigt. Beispielsweise gibt 0x2000 einen Softwarefehler an. 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: Softwarefehler 0x2000 ist ein sehr häufig auftretender, normaler Ringstatus. 0x20 gibt die Ringinitialisierung an und 00 ist die Länge des Untervektors; dies bedeutet, dass eine Ringstation in den Ring eingetreten ist.
Controller-Token anzeigen
Der nächste Cisco IOS Software-Befehl, der zur Fehlerbehebung verwendet werden kann, ist der Befehl show controllers 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
Weiche Fehler - Dies ist eine Kombination aller weichen Fehler, die von dieser Schnittstelle erkannt werden. Zu den weichen Fehlern gehören Leitungsfehler, mehrere Monitore, Fehler beim Festlegen von ARI- und FCI-Werten, Burst-Fehler, verlorene Frames, beschädigte Token, verlorene Token, zirkulierende Frames oder Prioritätstoken, verlorene Monitore und Frequenzfehler. Weitere Informationen finden Sie unter Informationen zu weichen Fehlern.
Harte Fehler - Dies sind Fehler, die von Software-Routinen nicht behoben werden können. Der Ring wurde physisch zurückgesetzt. Weitere Informationen finden Sie unter Token Ring Abnormal State List (Liste abnormaler Tokenring-Status).
Überwachungszustand: (aktiv) - Zeigt den Zustand des Controllers an. Mögliche Werte sind aktiv, fehlgeschlagen, inaktiv und zurückgesetzt.
SRB REM RPS CRS/NetMgr - gibt an, dass SRB, REM, RPS und CRS auf der Schnittstelle aktiviert sind. Weitere Informationen finden Sie im Abschnitt LAN Network Manager.
Wichtige Informationen in der Ausgabe sind die Adapter-MAC- und NAUN-Adresse, mit deren Hilfe die Ringtopologie bestimmt werden kann. Sie können auch herausfinden, wer der Ring Beacon NAUN ist; das heißt, der nächste aktive Upstream-Nachbar zur Beaconing-Station. Dadurch erhalten Sie einen Ausgangspunkt, um festzustellen, wo das Problem liegen könnte: die Beaconing-Station, die Beacon-NAUN oder das Kabel, das zwischen ihnen liegt. Eine Erläuterung der übrigen Felder finden Sie unter show controllers token im Befehlsreferenz-Handbuch.
Debug-Tokenereignisse
Der letzte Cisco IOS Software-Befehl, der zur Fehlerbehebung verwendet wird, 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
Achtung: Debug-Tokenereignisse sollten sich nur minimal auf den Router auswirken, da nur Token-Ring-Ereignisse und keine Pakete angezeigt werden. Wenn Sie jedoch einen sehr vollen Klingelton mit vielen Übergängen haben, sollten Sie den Protokollierungspuffer und die Befehle no logging console (Keine Protokollierungskonsole) eingeben und physischen Zugriff auf den Router haben.
Die vorherige Ausgabe des Debug-Tokens stammt von einem Cisco 2500-Router. Die Ausgabe kann eine Vielzahl von Botschaften enthalten, sollte jedoch Hinweise darauf geben, wo das Problem liegen könnte. Im vorherigen Beispiel wurde die Token Ring-Schnittstelle erfolgreich initialisiert. Das Debugging enthält auch Informationsmeldungen im Klingelmodus sowie in Gruppenadresse und Funktionsadresse.
Ringmodus-Definitionen
Dies sind Werte, die vom Hauptsystem an die Adapterkarten übergeben werden, um anzugeben, welchen Modus die Schnittstelle verwenden soll. Sie steuern, ob bestimmte Funktionsbits eingeschaltet werden oder nicht, und steuern die Befehlsflags, die beim Einfügen in den Token-Ring verwendet werden. Für den Klingelmodus bedeuten diese Zahlen Folgendes:
Für das vorherige Debugbeispiel lautet der Klingelmodus 0x0F00. Dies ist ein 2-Byte-Wert, der folgende Bedeutung 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 Klingelmodus ist also eine Summe dieser Biteinstellungen. 0xF00 steht für Bridge, Ring Error Monitor, Ring Parameter Server und Configuration Report Server.
modifizierte Open-Version mit Option
Dies ist die neue Einstellung des Chipsatzes von Cisco. Im vorherigen Beispieldebug können Sie die geänderte Open-Option mit der Option 1180 sehen. Dies ist ein 16-Bit-Wert, der von links nach rechts gelesen wird. Der Cisco Router kann Optionen nur ein-, aber nicht ausschalten.
+ 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
Informationen zur Option 0x1180 finden Sie in den vorherigen fett gedruckten Bits.
Festlegen der Funktions- und Gruppenadressen
Im vorherigen Beispieldebug wurde die funktionale Adresse auf w/800011A und die Gruppenadresse auf w/800000 festgelegt.
Dies sind 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 Deinstallation und erneuten Insertion 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, ausfallen. Geben Sie den Schnittstellenbefehl Keepalive {0 - 32767} aus, 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 aufspringen. Dies ersetzt jedoch nicht das gute Netzwerkdesign und die ordnungsgemäße Ringsegmentierung.
Verwendung von LAN Analyzer
Sehr oft treten in Token Ring-Netzwerken intermittierend Probleme auf, die sich in zufälligen Abständen wiederholen. Dadurch gestaltet sich die Fehlerbehebung deutlich schwieriger. Dies ist in Situationen üblich, in denen Sie eine zufällige Anzahl von Stationen haben, die eine langsame Leistung erleben oder dazu neigen, sich vorübergehend vom Ring zu lösen. Auch die Verwendung der oben genannten Techniken zur Fehlerbehebung von Einfügeproblemen kann manchmal nicht ausreichend Informationen liefern.
Zur Eingrenzung des Problems ist möglicherweise ein Token Ring LAN-Analyzer erforderlich, um Frames zu erfassen und zu analysieren. Der Analyzer sollte der direkte Upstream-Nachbar der Station sein, die einzufügen versucht. Es ist daher wichtig zu wissen, wonach Sie in einer Token Ring-Spur suchen sollten und was Sie in einem gesunden Token Ring-Netzwerk erwarten können. Die Token Ring-Frame-Analyse geht über den Umfang dieses Dokuments hinaus. Diese Frames werden jedoch im Token Ring-Trace einer erfolgreichen Token Ring-Stationseinfügung angezeigt:
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 Spur wurde so gefiltert, dass nur die interessanten Frames angezeigt werden (siehe Kommentare). In einem Netzwerkanalysator können diese Frames genauer untersucht werden, um die detaillierten Informationen anzuzeigen, die in diesen Feldern enthalten sind.
Es ist sehr wahrscheinlich, dass Sie auch weiche Fehler sehen - wie Burst-Fehler, Leitungsfehler, Token-Fehler, Klingeltonbereinigungen und verlorene Frame-Fehler - die durch den einfachen Vorgang des Öffnens des Hub-Relais verursacht werden. Gehen Sie nicht davon aus, dass das Vorhandensein dieser Fehler auf einen problematischen Klingelton hinweist, da es sich hierbei um normale Symptome handelt, die während des Einfügevorgangs auftreten.
Andere Frames, nach denen gesucht werden muss, sind vom AM gesendete MAC-Frames, die als Neighbor Notification Incomplete (NNI) oder Ring Poll Failure (Ringabfragefehler) bezeichnet werden. Dieser Frame sollte alle sieben Sekunden in einem fehlerhaften Ring ausgegeben werden, kurz vor einem AMP-MAC-Frame. Der NNI-Frame ist wichtig, da er die Adresse der letzten Station enthält, an der die Ringabfrage erfolgreich abgeschlossen wurde. Der nachgelagerte Nachbar dieser Station ist normalerweise der Schuldige, und Sie können den nachgelagerten Nachbarn entfernen, um das Problem zu lösen.
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
05-Dec-2001 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)