In diesem Dokument werden die Schritte zur Fehlerbehebung auf dem GSR12000-Gerät (mit IOS oder IOS-XR) beschrieben, wenn das Gerät nicht erreichbar ist.
Cisco empfiehlt, über grundlegende Kenntnisse der GSR1200 Plattform zu verfügen.
Dieses Dokument ist auf Cisco Router der Serie 12000 beschränkt.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Notieren Sie die LED-Informationen, wie in dieser Tabelle gezeigt, bevor Sie den Knoten weiter wiederherstellen/debuggen.
SSL Nein |
Modul |
Info |
LED-Status |
1 |
Stromregal/PEMs |
PWR OK "GRÜN" => PEM ist gut Andernfalls leuchtet eine der folgenden LED-Anzeigen gelb "AMBER". FEHLER, OC(over current), TEMP(over temperature Hinweis: Informationen müssen für alle im Chassis installierten PEMs gesammelt werden. |
PEM1: PEM2: PEM3: PEM4: |
2 |
Alarmkarte |
Es gibt zwei Konfigurationen von LED ENABLED und FAIL einer für jede Fabric Card (2 CSC + 3 SFC) und einer für Alarm Card selbst GRÜN ist aktiviert AMBER zeigt einen fehlerhaft/leeren Steckplatz an |
Warnkarte: CSC0: SFC0: SFC1: SFC2: |
1 |
Gebläse |
Es gibt zwei Status-LEDs OK und FAIL. OK-LED zeigt an, dass die Blende gut ist. FAIL-LEDs zeigen Blumenfehler an |
TOP: BOT: |
1 |
LC |
Eng3 hat das LED-Segment "IOX RUN" im stabilen Zustand. Eng5 hat LED auf der Frontplatte GRÜN im stabilen Zustand oder AMBER beim Booten oder IN RESET |
Steckplatz 0 bis Steckplatz 15 |
4 |
RP |
Aktives ACTV RP im stabilen Zustand Standby STBY RP im stabilen Zustand Aufzeichnen von Konsolen-Ethernet-LEDs |
ACTV: STBY: |
Alarmkartenvorderseite mit den verschiedenen LEDs
PEM-Frontblende (Privacy Enhanced Mail) mit PEM-Status-LEDs
Überprüfen Sie, ob die Konsolenverbindungsdetails und der Zugriff auf den Terminalserver eingerichtet sind.
Wenn der Konsolenzugriff nicht verfügbar ist, verwenden Sie dieses Ablaufdiagramm.
Wenn der Konsolenzugriff nicht verfügbar ist und LEDs leuchten, aber einen falschen Status anzeigen, verwenden Sie dieses Flussdiagramm.
*Anzeige-LEDs
Befehlsliste 1: Erfassung wird erfasst, wenn auf die Konsole des aktiven RP zugegriffen werden kann.
admin show platform admin show redundancy admin show environment power-supply show power-mgr detail show logging
Führen Sie diese Befehle aus, um Prozessstatus, CPU-Auslastung, Paketmanager-Status zu überprüfen und ggf. Schuldige Prozesse zu identifizieren.
und den in der Sitzung angegebenen Befehl erfassen.
show processes blocked show processes cpu | ex 0% show packet-memory summary
Sammeln Sie diese Protokolle für den oben genannten Prozess.
show processes <jid> show processes threadname <jid> follow jid <> iter <3>
Fabric-Protokolle
admin show controllers fabricq drop admin show controllers fabricq errors admin show controllers fabricq output admin show controllers fabricq queue admin show controllers fabricq tofab admin show controllers fabricq frfab admin show controllers fabric (3 times) show controller fia location <all slots> (3 times)
Mbus-Zähler (2- bis 3-fache Erfassung)
admin show mbus can-error location all admin show mbus counters location all run mtool discover
PD-Spuren
admin show controllers fabric trace admin show sysldr trace all show fiad trace show_psarb_trace (from shell)
Wenn es Zeit, dann können Sie die Showtech (riesige Protokolle) sammeln.
admin show tech-support shelf-management file <qualified disk path>
Befehlsliste 2: Protokolle, die gesammelt werden müssen, wenn nur auf die Konsole des Standby-Systems zugegriffen werden kann
Hinweis: Protokolle werden nur erfasst, wenn der aktive Konsolenzugriff nicht verfügbar ist, der Standby-Zugriff jedoch möglich ist.
Verfahren: Greifen Sie mit diesem Verfahren auf ksh(shell) von standby zu, und schließen Sie mit diesem Verfahren an aktives ksh over mbus an, und sammeln Sie Protokolle von der Shell des aktiven Geräts.
<esc>ksh von der Standby-Konsole aus und schließen dann <Aktiver Knoten> an
Grundlegende Protokolle zur Erfassung von Kartenstatus, Stromversorgungsstatus und Konsolenprotokollen
show_platform –a envmon_show -m –p show_logging -A admin show logging
Protokolle zur Überprüfung, ob der Fabric-Treiber und die QADs fehlerfrei sind
fabricq_lwm_show_command -v -a fabricq_lwm_show_command -v -t fabricq_lwm_show_command -v -f fabricq_lwm_show_command -v -q fabricq_lwm_show_command -v -d fabricq_lwm_show_command -v -r fabricq_lwm_show_command -v -o fabricq_lwm_show_command -v -p fabricq_lwm_show_command -v -c fabricq_lwm_show_command -v -p fabricq_lwm_show_command -v -s qad_show -b -i
So prüfen Sie das Problem mit dem Bus (2-3 Mal sammeln)
mtool discover show_mbus can-stats show_mbus can-error
Führen Sie diese Befehle aus, um den Prozessstatus, die CPU-Auslastung und den Paketmanager-Status zu überprüfen, ggf. den Schulterprozess zu identifizieren und den in dieser Sitzung angegebenen Befehl zu erfassen.
show_processes -b show_proc_cpu -c | grep -v -E 0% packet_show summary packet_show corrupt Collect below set of logs for the above identified process sysmgr_show -o -p <jid in hex> show_processes -T -p <jid in hex> attach_process -j <jid> -i 3
PD-Spuren sammeln
fiad_show_ltrace show_psarb_trace sysldr_show_ltrace
IOS-Befehlsliste: Erfassung, die erfasst werden soll, wenn auf die Konsole zugegriffen werden kann.
Show logging Show tech Show gsr Show monitor event-trace lci Show monitor event-trace agent-ctrl Show monitor event-trace board Show monitor event-trace fab Show gsr agent-ctrl show gsr power-mgr details show env power show env internal
Wiederholen Sie diese Protokolle mit der Zeitlücke.
Execute-on all show controller fia Show controller fia Show controller errors fabric counters Show controller errors Show controller xbar Show controllers sca Show controllers clock Show controllers csc-fpga Show controllers fab-clk Show mbus counters Show mbus can