Fehlerbehebung beim Nexus 7000 mit Message Transaction Services
Einleitung
In diesem Dokument werden die Message and Transition Services (MTS)-Funktionen zur Fehlerbehebung bei Nexus 7000-Plattformen beschrieben.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
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.
Hintergrundinformationen
Services (auch als Prozesse bezeichnet) im NeXus-Betriebssystem (NX-OS) kommunizieren über MTS miteinander.
Wenn sich der Zieldienst physisch auf einem anderen Modul befindet, muss die Kommunikation zwischen Knoten verwendet werden. Die Kommunikation mit dem anderen Modul wird von Advanced Inter Process Communication (AIPC) über die Ethernet Out-of-Band Channel (EOBC)-Verbindungen bereitgestellt. Die EOBC-Verbindungen befinden sich auf der MidPlane des Nexus 7000-Chassis.
MTS bietet:
- Hochverfügbarkeits-Infrastruktur und Anwendungsprogrammschnittstellen (APIs)
- Puffer-Management
- Nachrichtenzustellung
AIPC bietet:
- Zuverlässiger Transport über EOBC
- Bereitstellung einer ACK-basierten Weiterübertragung
- Fragmentierung und Reassemblierung
MTS besteht hauptsächlich aus Ziel-/Quellknoten/SAP und Opcode.
- Knoten - Eine Kennung des physischen Moduls und des VDC.
- SAP - Eine Kennung für jeden Service. (Jeder Service kann mehrere Service Access Points (SAPs) für mehrere Funktionen umfassen.)
- Opcode - Ein Datentyp, den Dienste verwenden, um mit anderen Diensten zu kommunizieren.
Terminologie
MTS: Message and Transaction Services
SAP: Service Access Point
AIPC: Fortschrittliche Kommunikation zwischen Prozessen/Andiamo IPC
EOBC: Ethernet Out-of-Band Channel
NX-OS: NeXus-Betriebssystem
MTS-Formate
Das MTS-Ziel wird durch SAP (einen Service) und Node (das Modul, auf dem der SAP ausgeführt wird) dargestellt.
-
SAP
In den meisten Fällen wird das MTS-Ereignis mithilfe des statischen SAP verfolgt.
SAP kann generell oder pro Modul (Supervisor oder Linecard) geprüft werden.
Hinweis: sup steht für Supervisor und lc für Linecard.
SAP auf jedem Modul ausführen.
`show system internal sysmgr service ~~~~`
n7ka# sh system internal sysmgr service all
Name UUID PID SAP state Start count Tag Plugin ID
---------------- ---------- ------ ----- --------- ----------- ---------------- -----------
aaa 0x000000B5 6942 111 s0009 1 N/A 0
cert_enroll 0x0000012B 6941 169 s0009 1 N/A 0
ExceptionLog 0x00000050 7267 92 s0009 1 N/A 0
`show system internal mts ~~~~~`
n7ka# sh system internal mts sup sap 111 description
Below shows sap on default-VDC, to show saps on non-default VDC, run
show system internal mts node sup-<vnode-id> sap ...
AAA Daemon
Starten von SAP nur auf bestimmten Modulen
`Attach to the module`
n7ka# attach module 4
Attaching to module 4 ...
To exit type 'exit', to abort type '$.'
Last login: Tue Nov 7 15:42:35 PST 2023 from 127.1.1.2 on pts/0
`show system internal sysmgr service ~~~~`
n7ka# show system internal sysmgr service all
Name UUID PID SAP state Start count Tag Plugin ID
---------------- ---------- ------ ----- --------- ----------- ---------------- -----------
aclqo 0x0000016E 1301 190 s0009 1 N/A 0
amm 0x00000260 1130 895 s0009 1 N/A 0
bfdc 0x000002C7 1110 1008 s0009 1 N/A 0
`show system internal mts ~~~~~`
module-4# show system internal mts lc sap 190 description
Aclqos SAP
- Opcode-Registrierung
Manchmal wird MTS an das Ziel SAP 0 gesendet. Dadurch wird der MTS an mehrere SAPs gesendet, die in der SAP-Registry (opcode registry) registriert sind.
Als Beispiel wird Opc 8182 von SAP 175 und 378 registriert und durch den Befehl show system internal mts sup registry persistent bestätigt. Dieses MTS wird also sowohl für SAP 175 als auch für SAP 378 bereitgestellt.
n7ka# show system internal ethpm event-history msgs
51) Event:E_MTS_RX, length:60, at 36968 usecs after Thu Sep 18 14:42:15 2014
[NOT] Opc:MTS_OPC_LINK_EVENT_DOWN(8182), Id:0X034960A1, Ret:SUCCESS
Src:0x00000102/181, Dst:0x00000609/0, Flags:None
HA_SEQNO:0X00000000, RRtoken:0x00000000, Sync:UNKNOWN, Payloadsize:82
Payload:
0x0000: 00 00 00 07 00 11 00 21 00 00 00 04 00 12 00 04
n7ka# show system internal mts sup registry persistent | i 8182
MTS_OPC_LINK_EVENT_DOWN(8182): 175, 378
- Knoten-ID
Die Knoten-ID ist eine 16-Bit-ID.
+ Steckplatz-ID - Modul-Steckplatz-ID. Beginnt mit 1
+ Vnode-ID - ID des virtuellen Knotens. VDC-ID beginnt mit 0
+ Knoten-ID - ID des logischen Knotens. SUP:1, LC:2
Beispiel: 0x805 = 0x08 + 0b0000_0101 = 0x08 + 0x1 + 0x1 (Steckplatz + Vnode + Lnode).
=> SUP-Modul VDC 2 In Steckplatz 8
- MTS-Adresse
Die Knoten-ID ist eine Komponente der MTS-Adresse. Diese MTS-Adresse gibt das Modul an, an das dieses MTS geliefert werden soll.
Die MTS-Adresse (Node ID) ist der linke Teil der Ausgabe, die als Nächstes angezeigt wird.
Src:0x00000102/181, Dst:0x00000609/0, Flags:None
Wenn MTS Unicast ist, entspricht die MTS-Adresse der Knoten-ID.
Prozesskommunikation mit MTS verfolgen
Alter
Sie können den MTS-Kommunikationsverlauf mithilfe von Ereignisverlaufsmeldungen anzeigen. Fast alle Services verfügen über die Funktion für Ereignisverlaufsmeldungen.
Diese CLI ist der MTS-Ereignisverlauf für eth_port_channel (ethpc).
n7ka# show port-channel internal event-history msgs
12) Event:E_MTS_RX, length:60, at 15586 usecs after Thu Sep 18 13:13:57 2014
[REQ] Opc:MTS_OPC_ETHPM_PORT_CLEANUP(61444), Id:0X00323B1E, Ret:SUCCESS
Src:0x00000601/175, Dst:0x00000601/378, Flags:None
HA_SEQNO:0X00000000, RRtoken:0x00323B1E, Sync:UNKNOWN, Payloadsize:26
Payload:
0x0000: 00 00 00 02 00 04 00 02 00 01 00 05 00 0c 00 00
Die Felder, die als Nächstes aufgelistet werden, enthalten weitere Details zu ihrem Verwendungszweck im folgenden Befehl:
Ereignis:E_MTS_RX - gibt an, dass dieses MTS von diesem Dienst, in diesem Fall ethpc, empfangen wurde. Wenn es sich um E_MTS_TX handelt, ist ethpc der Absender dieses MTS.
Src:0x00000601/175 - MTS_addr/SAP, steht für den Absender dieses MTS.
Dst:0x00000601/378 - MTS_addr/SAP, stellt den Empfänger dieses MTS dar.
Id:0X00323B1E - MTS-ID, wobei Sender und Empfänger dieselbe ID für dasselbe MTS haben.
Opc:MTS_OPC_ETHPM_PORT_CLEANUP(61444) - Gibt den Ereignistyp an. Mit anderen Worten, welchen Opcode dieser MTS liefert, wobei 61444 die Opcode-Nummer ist.
Beispiel eines MTS-Ereignisses
Dieses MTS-Ereignisbeispiel bezieht sich auf ein Ereignis bei Verbindungsabbruch.
n7ka# 2014 Sep 18 14:42:15 n7ka %ETHPORT-5-IF_DOWN_LINK_FAILURE: Interface Ethernet1/3 is down (Link failure)
Überprüfen Sie zunächst den ethpm-Verlauf, da es sich um den umfassenden Prozess für alle I/F-bezogenen Dinge handelt.
n7ka# sh system internal ethpm event-history msgs
51) Event:E_MTS_RX, length:60, at 36968 usecs after Thu Sep 18 14:42:15 2014
[NOT] Opc:MTS_OPC_LINK_EVENT_DOWN(8182), Id:0X034960A1, Ret:SUCCESS
Src:0x00000102/181, Dst:0x00000609/0, Flags:None
HA_SEQNO:0X00000000, RRtoken:0x00000000, Sync:UNKNOWN, Payloadsize:82
Payload:
0x0000: 00 00 00 07 00 11 00 21 00 00 00 04 00 12 00 04
Das Ergebnis zeigt, dass das ETHPM das Verbindungsabbruch-Ereignis von Src:0x00000102/181 empfangen hat. Diese MTS-Adresse gibt an, dass sich SAP 181 im VDC 1 LC an Steckplatz 1 befindet.
Bestimmen Sie über die CLI neben SAP 181 Steckplatz 1.
module-1# attach module 1
module-1# show system internal mts lc sap 181 description
Port_client SAP
Verwenden Sie die CLI, die neben angezeigt wird, um den MTS-Verlauf von port_client in Steckplatz 1 zu überprüfen.
module-1# show system internal port-client event-history msgs
49) Event:E_MTS_TX, length:60, at 298743 usecs after Thu Sep 18 14:42:14 2014
[NOT] Opc:MTS_OPC_LINK_EVENT_DOWN(8182), Id:0X034960A1, Ret:SUCCESS
Src:0x00000102/181, Dst:0x00000609/0, Flags:None
HA_SEQNO:0X00000000, RRtoken:0x00000000, Sync:UNKNOWN, Payloadsize:82
Payload:
0x0000: 00 00 00 07 00 11 00 21 00 00 00 04 00 12 00 04
50) Event:E_MTS_RX, length:60, at 298329 usecs after Thu Sep 18 14:42:14 2014
[NOT] Opc:MTS_OPC_LC_LINK_DOWN(8185), Id:0X0349609F, Ret:SUCCESS
Src:0x00000102/536, Dst:0x00000102/0, Flags:None
HA_SEQNO:0X00000000, RRtoken:0x00000000, Sync:UNKNOWN, Payloadsize:17
Payload:
0x0000: 00 00 00 02 40 e5 00 07 02 54 1a 70 b6 00 04 84
Aus Id:0X034960A1 können wir erkennen, dass das 49)-Ereignis das interessante Ereignis ist. Port_Client hat den MTS wie erwartet gesendet. Dies muss durch das vorherige MTS-Ereignis auf Port_Client (d. h. 50) aufgerufen werden. Dieses MTS wurde von Src:0x00000102/536 gesendet.
Überprüfen Sie SAP 536.
module-1# sh system internal mts lc sap 536 de
Naxos FPGA
Nun wissen wir, dass NAXOS FPGA die Quelle dieses ganzen Ereignisses ist. Verwenden Sie die CLI, die neben angezeigt wird, um festzustellen, dass local_fault die Ursache für den Verbindungsausfall ist.
module-1# sh hardware internal naxos event-history port 3
15) Event E_NAXOS_ISR_DATA length:69, at 170763 usecs after Thu Sep 18 14:42:14 2014
TO NAXOS_PORT_STATUS_LINK_DOWN: reg_val 0x14
Status:SUCCESS (0x0)
16) Event E_NAXOS_ISR_DATA length:50, at 170619 usecs after Thu Sep 18 14:42:14 2014
LOCAL_FAULT: reg_val 0x14
Status:SUCCESS (0x0)
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
09-Nov-2023 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)