Fehlerbehebung: Nexus Kurzreferenz für Anfänger

Einleitung

In diesem Dokument werden verschiedene Tools zur Fehlerbehebung bei Nexus-Produkten beschrieben, mit denen Sie Probleme diagnostizieren und beheben können.

Überblick

Es ist wichtig zu wissen, welche Tools verfügbar sind und in welchem Szenario Sie sie für einen maximalen Gewinn verwenden würden. In der Tat ist manchmal ein bestimmtes Werkzeug nicht machbar, einfach weil es entworfen ist, um an etwas anderem zu arbeiten.

In dieser Tabelle sind die verschiedenen Tools für die Fehlerbehebung auf der Nexus-Plattform und ihre Funktionen zusammengefasst. Details und CLI-Beispiele finden Sie im Abschnitt "Nexus-Tools".

TOOLS	FUNKTION	ANWENDUNGSBEISPIELE	PRO	KONTRA	PERSISTENZ	EFFEKTIONSEBENE	VERWENDETE CLI-BEFEHLE
Ethanalyzer	Erfassung von Datenverkehr, der an die oder von der CPU gerichtet ist	Probleme mit Verkehrsflaute, Latenz und Staus	Hervorragend bei Problemen mit Langsamkeit, Überlastung und Latenz geeignet.	Erkennt in der Regel nur Kontrollebenen-Datenverkehr, Übertragungsrate begrenzt.	–	Steuern Sie Fläche. Kann in einigen Szenarien für die Datenebene verwendet werden (SPAN zu CPU).	Integrierte lokale #ethanalyzer Schnittstelle #ethanalyzer lokale Schnittstelle [Schnittstellen-ID] Anzeigefilter [WORD]  beispiel: #ethanalyzer lokale Schnittstelle Ethernet 6/4-Anzeigefilter ICMP
SPAN	Erfassen und spiegeln Sie eine Reihe von Paketen.	Fehlgeschlagene Ping-Signale, fehlerhafte Pakete usw.	Hervorragend für zeitweiligen Datenverlust geeignet.	Externes Gerät mit Sniffer-Software erforderlich Erfordert TCAM-Ressourcen.	Die SPAN-Sitzung muss konfiguriert und aktiviert/deaktiviert werden.	Steuerung + Daten	#monitor session [#] #description [NAME] #source interface [Port-ID] #destination interface [Port-ID] #no shut
DMirror	Erfassen Sie Datenverkehr, der an die oder von der CPU gerichtet ist, nur für Broadcom Nexus-Geräte.	Probleme mit der Datenverkehrsverlangsamung, Latenz und Staus.	Hervorragend bei Problemen mit Langsamkeit, Überlastung und Latenz geeignet.	Nur für Broadcom Nexus-Geräte. Durchsatzbegrenzung (CloudScale Nexus 9000 verfügt über SPAN-zu-CPU)	–	Steuern Sie Fläche. Kann in einigen Szenarien für die Datenebene verwendet werden.	Variiert je nach Plattform, siehe ELAM im Überblick - Cisco
ELAM	Erfasst ein einzelnes Paket, das den Nexus-Switch erreicht (oder verlässt, wenn Nexus 7000)	Überprüfen Sie, ob das Paket den Nexus erreicht, die Weiterleitungsentscheidungen, die Paketprüfung auf Änderungen, die Schnittstelle/das VLAN des Pakets usw.	Hervorragend für Paketfluss- und Weiterleitungsprobleme geeignet. Non-intrusive	Erfordert umfassende Kenntnisse der Hardware. Verwendet spezielle Trigger-Mechanismen, die architekturspezifisch sind. Nur nützlich, wenn Sie wissen, welchen Verkehr Sie überprüfen möchten.	–	Steuerung + Daten	# Attach-Modul [MODULE NUMBER] # debug platform internal <>
Nexus 9000 Packet Tracer	Pfad des Pakets erkennen.	Verbindungsprobleme und Paketverluste	Stellt einen Zähler für Flussstatistiken bereit, der für einen vorübergehenden/vollständigen Verlust nützlich ist. Ideal für Line Cards ohne TCAM Schnitzereien.	ARP-Datenverkehr kann nicht erfasst werden. Funktioniert nur für Nexus 9000.	–	Daten + Steuerung	# test packet-tracer src_IP [SOURCE IP] dst_IP [DESTINATION IP] # test packet-tracer start # test packet-tracer stop # test packet-tracer show
Routenverfolgung	Pfad des Pakets in Bezug auf L3-Hops ermitteln.	Fehlgeschlagene Pings, keine Verbindung zu Host/Ziel/Internet usw.	Erkennt die verschiedenen Hops im Pfad, um L3-Fehler zu isolieren.	Identifiziert nur Bereiche, in denen die L3-Grenze überschritten wird (identifiziert nicht das Problem selbst).	–	Daten + Steuerung	# traceroute [ZIEL-IP]  Die Argumente umfassen: Port, Portnummer, Quelle, Schnittstelle, VRF, Quellschnittstelle
Ping	Testen der Verbindung zwischen zwei Punkten in einem Netzwerk	Testen der Erreichbarkeit zwischen Geräten	Ein schnelles und einfaches Tool zum Testen der Verbindung.	Gibt nur an, ob der Host erreichbar ist.	–	Daten + Steuerung	# ping [ZIEL-IP]  Die Argumente umfassen: Anzahl, Paketgröße, Quellschnittstelle, Intervall, Multicast, Loopback, Timeout
PACL/RACL/VACL	Erfassung des ein- und ausgehenden Datenverkehrs eines bestimmten Ports oder VLANs	Intermittierender Paketverlust zwischen Hosts, Überprüfung, ob Pakete beim Nexus eintreffen/abgehen usw.	Hervorragend für zeitweiligen Datenverlust geeignet.	Erfordert TCAM-Ressourcen. Bei einigen Modulen ist eine manuelle TCAM-Partitionierung erforderlich.	Persistent (angewendet auf aktuelle Konfiguration)	Daten + Steuerung	# ip access-list [ACL NAME] # ip port access-group [ACL NAME] # ip access-group [ACL NAME]  Die Argumente umfassen: Verweigern, Fragmente, Nein, Zulassen, Bemerkung, Anzeigen, Statistik, Beenden, Beenden, Pop, Push, Wo
LogFlash	Speichert Verlaufsdaten für den Switch global, z. B. Protokollkonten, Absturzdateien und Ereignisse, unabhängig vom erneuten Laden des Geräts.	Plötzliches Neuladen/Herunterfahren von Geräten. Bei jedem Neuladen eines Geräts liefern Log-Flash-Daten Informationen, die für die Analyse hilfreich sein können.	Die Informationen werden beim Neuladen des Geräts (persistenter Speicher) beibehalten.	Extern auf Nexus 7000 = muss auf der Supervisor-Plattform installiert/integriert sein, damit diese Protokolle erfasst werden können (con gilt nicht für 3K/9K, da logflash eine Partition des internen Speichergeräts ist).	Durchgängiges Neuladen	Daten + Steuerung	# dir logflash:
OBFL	Speichert Verlaufsdaten für ein bestimmtes Modul, z. B. Fehler- und Umgebungsdaten.	Plötzliches Neuladen/Herunterfahren von Geräten. Bei jedem Neuladen eines Geräts werden Flash-Daten protokolliert. Diese Informationen können hilfreich sein.	Die Informationen werden beim Neuladen des Geräts (persistenter Speicher) beibehalten.	Unterstützt eine begrenzte Anzahl von Lese- und Schreibvorgängen.	Durchgängiges Neuladen	Daten + Steuerung	# show logging onboard module [#]  Die Argumente umfassen: Boot-Uptime, Card-Boot-History, Card-first-power-on, Counterstats, Geräteversion, Endzeit, Umgebungs-History, Error-Stats, Exception-Log, intern, Interrupt-Stats, obfl-history, stat-trace, Startzeit, Status
Ereignisverlauf	Wenn Sie Informationen für einen bestimmten Prozess benötigen, der gerade ausgeführt wird.	Jeder Prozess im Nexus verfügt über einen eigenen Ereignisverlauf, beispielsweise CDP, STP, OSPF, EIGRP, BGP, vPC, LACP usw.	Fehlerbehebung bei einem bestimmten Prozess auf Nexus	Informationen gehen verloren, wenn das Gerät neu geladen wird (nicht permanent).	Nicht permanent	Daten + Steuerung	# show [PROCESS] internal event-history [ARGUMENT]  Die Argumente umfassen: Adjacency, CLI, Event, Flooding, ha, hello, ldp, lsa, msgs, objstore, Redistribution, rib, segrt, spf, spf-trigger, statistics, te
Fehlerbehebung	Wenn Sie detaillierte Echtzeit-/Live-Informationen für einen bestimmten Prozess benötigen.	Das Debugging kann für jeden Prozess im Nexus durchgeführt werden, z. B. CDP, STP, OSPF, IGRP, BGP, vPC, LACP usw.	Fehlerbehebung für einen bestimmten Prozess, der auf Nexus ausgeführt wird, in Echtzeit für mehr Genauigkeit	Kann die Netzwerkleistung beeinträchtigen.	Nicht permanent	Daten + Steuerung	# Debug-Prozess [PROCESS]  beispiel: # debug ip ospf [?]
GOLD	Bietet Systemstart-, Laufzeit- und On-Demand-Diagnosen für Hardwarekomponenten (z. B. E/A- und Supervisor-Module).	Testen Sie Hardware wie USB, Bootflash, OBFL, ASIC-Speicher, PCIE, Port-Loopback, NVRAM usw.	Erkennen von Fehlern in der Hardware und Durchführen erforderlicher Korrekturmaßnahmen erst ab Release 6(2)8.	Erkennt nur Hardwareprobleme.	Nicht permanent	–	# show diagnostic content module all # show diagnostic description module [#] all testen
EEM	Überwachen Sie Ereignisse auf dem Gerät, und ergreifen Sie die erforderlichen Maßnahmen.	Alle Geräteaktivitäten, die eine Aktion/Problemumgehung/Benachrichtigung erfordern, z. B. das Herunterfahren der Schnittstelle, eine Lüfterstörung, die CPU-Nutzung usw.	Unterstützt Python-Skripte.	Zur Konfiguration von EEM sind Netzwerkadministratorberechtigungen erforderlich.	EEM-Skript und -Trigger befinden sich in der Konfiguration.	–	Variiert, siehe Konfigurieren des Embedded Event Manager

Nexus-Tools

Weitere Informationen zu verschiedenen Befehlen und deren Syntax bzw. Optionen finden Sie unter Cisco Nexus Switches der Serie 9000 - Befehlsreferenzen - Cisco.

Ethanalyzer

Ethanalyzer ist ein NX-OS-Tool zur Erfassung von CPU-Datenverkehr in Paketen. Alles, was die CPU trifft, egal ob Eingang oder Ausgang, kann mit diesem Tool erfasst werden. Es basiert auf dem weit verbreiteten Open-Source-Netzwerkprotokoll-Analyzer Wireshark. Weitere Informationen zu diesem Tool finden Sie im Ethanalyzer auf Nexus 7000 Troubleshooting Guide - Cisco

Dabei ist zu beachten, dass Ethanalyzer im Allgemeinen den gesamten Datenverkehr vom und zum Supervisor erfasst. Dies bedeutet, dass schnittstellenspezifische Erfassungen nicht unterstützt werden. Spezifische Schnittstellenerweiterungen sind für ausgewählte Plattformen in neueren Codepunkten verfügbar. Außerdem erfasst Ethanalyzer nur Datenverkehr, der über eine CPU geleitet wird, und nicht Datenverkehr, der über eine Hardware geleitet wird. Sie können beispielsweise den Datenverkehr entweder über die In-Band-Schnittstelle, die Verwaltungsschnittstelle oder einen Port an der Vorderseite (sofern unterstützt) erfassen:

Nexus9000_A(config-if-range)# ethanalyzer local interface inband
Capturing on inband
2020-02-18 01:40:55.183177 cc:98:91:fc:55:8b -> 01:80:c2:00:00:00 STP RST. Root = 32768/1/cc:98:91:fc:55:80  Cost = 0  Port = 0x800b
2020-02-18 01:40:55.184031 f8:b7:e2:49:2d:f2 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:40:55.184096 f8:b7:e2:49:2d:f5 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:40:55.184147 f8:b7:e2:49:2d:f4 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:40:55.184190 f8:b7:e2:49:2d:f3 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:40:55.493543 dc:f7:19:1b:f9:85 -> 01:80:c2:00:00:00 STP RST. Root = 32768/1/dc:f7:19:1b:f9:80  Cost = 0  Port = 0x8005
2020-02-18 01:40:56.365722      0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xc82a6d3
2020-02-18 01:40:56.469094 f8:b7:e2:49:2d:b4 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:40:57.202658 cc:98:91:fc:55:8b -> 01:80:c2:00:00:00 STP RST. Root = 32768/1/cc:98:91:fc:55:80  Cost = 0  Port = 0x800b
2020-02-18 01:40:57.367890      0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xc82a6d3
10 packets captured

Nexus9000_A(config-if-range)# ethanalyzer local interface mgmt
Capturing on mgmt0
2020-02-18 01:53:07.055100 cc:98:91:fc:55:94 -> 01:80:c2:00:00:00 STP RST. Root = 32768/46/84:8a:8d:7d:a2:80  Cost = 4  Port = 0x8014
2020-02-18 01:53:09.061398 cc:98:91:fc:55:94 -> 01:80:c2:00:00:00 STP RST. Root = 32768/46/84:8a:8d:7d:a2:80  Cost = 4  Port = 0x8014
2020-02-18 01:53:11.081596 cc:98:91:fc:55:94 -> 01:80:c2:00:00:00 STP RST. Root = 32768/46/84:8a:8d:7d:a2:80  Cost = 4  Port = 0x8014
2020-02-18 01:53:13.080874 cc:98:91:fc:55:94 -> 01:80:c2:00:00:00 STP RST. Root = 32768/46/84:8a:8d:7d:a2:80  Cost = 4  Port = 0x8014
2020-02-18 01:53:15.087361 cc:98:91:fc:55:94 -> 01:80:c2:00:00:00 STP RST. Root = 32768/46/84:8a:8d:7d:a2:80  Cost = 4  Port = 0x8014
2020-02-18 01:53:17.090164 cc:98:91:fc:55:94 -> 01:80:c2:00:00:00 STP RST. Root = 32768/46/84:8a:8d:7d:a2:80  Cost = 4  Port = 0x8014
2020-02-18 01:53:19.096518 cc:98:91:fc:55:94 -> 01:80:c2:00:00:00 STP RST. Root = 32768/46/84:8a:8d:7d:a2:80  Cost = 4  Port = 0x8014
2020-02-18 01:53:20.391215 00:be:75:5b:d9:00 -> 01:00:0c:cc:cc:cc CDP Device ID: Nexus9000_A(FDO21512ZES)  Port ID: mgmt0
2020-02-18 01:53:21.119464 cc:98:91:fc:55:94 -> 01:80:c2:00:00:00 STP RST. Root = 32768/46/84:8a:8d:7d:a2:80  Cost = 4  Port = 0x8014
2020-02-18 01:53:23.126011 cc:98:91:fc:55:94 -> 01:80:c2:00:00:00 STP RST. Root = 32768/46/84:8a:8d:7d:a2:80  Cost = 4  Port = 0x8014
10 packets captured

Nexus9000-A# ethanalyzer local interface front-panel eth1/1 
Capturing on 'Eth1-1'
1 2022-07-15 19:46:04.698201919 28:ac:9e:ad:5c:b8 → 01:80:c2:00:00:00 STP 53 RST. Root = 32768/1/28:ac:9e:ad:5c:b7 Cost = 0 Port = 0x8001
2 2022-07-15 19:46:04.698242879 28:ac:9e:ad:5c:b8 → 01:00:0c:cc:cc:cd STP 64 RST. Root = 32768/1/28:ac:9e:ad:5c:b7 Cost = 0 Port = 0x8001
3 2022-07-15 19:46:04.698314467 28:ac:9e:ad:5c:b8 → 01:00:0c:cc:cc:cd STP 64 RST. Root = 32768/10/28:ac:9e:ad:5c:b7 Cost = 0 Port = 0x8001
4 2022-07-15 19:46:04.698386112 28:ac:9e:ad:5c:b8 → 01:00:0c:cc:cc:cd STP 64 RST. Root = 32768/20/28:ac:9e:ad:5c:b7 Cost = 0 Port = 0x8001
5 2022-07-15 19:46:04.698481274 28:ac:9e:ad:5c:b8 → 01:00:0c:cc:cc:cd STP 64 RST. Root = 32768/30/28:ac:9e:ad:5c:b7 Cost = 0 Port = 0x8001
6 2022-07-15 19:46:04.698555784 28:ac:9e:ad:5c:b8 → 01:00:0c:cc:cc:cd STP 64 RST. Root = 32768/40/28:ac:9e:ad:5c:b7 Cost = 0 Port = 0x8001
7 2022-07-15 19:46:04.698627624 28:ac:9e:ad:5c:b8 → 01:00:0c:cc:cc:cd STP 64 RST. Root = 32768/50/28:ac:9e:ad:5c:b7 Cost = 0 Port = 0x8001

Diese Ausgabe zeigt einige der Nachrichten, die mit Ethanalyzer erfasst werden können.

Nexus9000_A(config-if-range)# ethanalyzer local interface inband limit-captured-frames 0
Capturing on inband
2020-02-18 01:43:30.542588 f8:b7:e2:49:2d:f2 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:30.542626 f8:b7:e2:49:2d:f5 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:30.542873 f8:b7:e2:49:2d:f4 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:30.542892 f8:b7:e2:49:2d:f3 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:31.596841 dc:f7:19:1b:f9:85 -> 01:80:c2:00:00:00 STP RST. Root = 32768/1/dc:f7:19:1b:f9:80  Cost = 0  Port = 0x8005
2020-02-18 01:43:31.661089 f8:b7:e2:49:2d:b2 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:31.661114 f8:b7:e2:49:2d:b3 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:31.661324 f8:b7:e2:49:2d:b5 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:31.776638 cc:98:91:fc:55:8b -> 01:80:c2:00:00:00 STP RST. Root = 32768/1/cc:98:91:fc:55:80  Cost = 0  Port = 0x800b
2020-02-18 01:43:33.143814 f8:b7:e2:49:2d:b4 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:33.596810 dc:f7:19:1b:f9:85 -> 01:80:c2:00:00:00 STP RST. Root = 32768/1/dc:f7:19:1b:f9:80  Cost = 0  Port = 0x8005
2020-02-18 01:43:33.784099 cc:98:91:fc:55:8b -> 01:80:c2:00:00:00 STP RST. Root = 32768/1/cc:98:91:fc:55:80  Cost = 0  Port = 0x800b
2020-02-18 01:43:33.872280 f8:b7:e2:49:2d:f2 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:33.872504 f8:b7:e2:49:2d:f5 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
2020-02-18 01:43:33.872521 f8:b7:e2:49:2d:f4 -> 01:80:c2:00:00:0e LLC U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0134
15 packets captured

Sie können mit Ethanalyzer auch Filter verwenden, um sich auf bestimmten Datenverkehr zu konzentrieren. Es gibt zwei Arten von Filtern, die Sie mit Ethanalzyer verwenden können. Sie werden als Capture-Filter und Display-Filter bezeichnet. Ein Erfassungsfilter erfasst nur den Datenverkehr, der den im Erfassungsfilter definierten Kriterien entspricht. Ein Anzeigefilter erfasst weiterhin den gesamten Datenverkehr, es wird jedoch nur der Datenverkehr angezeigt, der den im Anzeigefilter definierten Kriterien entspricht.

Nexus9000_B# ping 10.82.140.106 source 10.82.140.107 vrf management count 2
PING 10.82.140.106 (10.82.140.106) from 10.82.140.107: 56 data bytes
64 bytes from 10.82.140.106: icmp_seq=0 ttl=254 time=0.924 ms
64 bytes from 10.82.140.106: icmp_seq=1 ttl=254 time=0.558 ms

Nexus9000_A(config-if-range)# ethanalyzer local interface mgmt display-filter icmp
Capturing on mgmt0
2020-02-18 01:58:04.403295 10.82.140.107 -> 10.82.140.106 ICMP Echo (ping) request
2020-02-18 01:58:04.403688 10.82.140.106 -> 10.82.140.107 ICMP Echo (ping) reply
2020-02-18 01:58:04.404122 10.82.140.107 -> 10.82.140.106 ICMP Echo (ping) request
2020-02-18 01:58:04.404328 10.82.140.106 -> 10.82.140.107 ICMP Echo (ping) reply

4 packets captured

Sie können Pakete auch mit der Detailoption erfassen und in Ihrem Terminal anzeigen, ähnlich wie in Wireshark. Auf diese Weise können Sie die vollständigen Header-Informationen basierend auf dem Paketdisektor-Ergebnis anzeigen. Wenn beispielsweise ein Frame verschlüsselt ist, können Sie die verschlüsselte Nutzlast nicht sehen. Siehe folgendes Beispiel:

Nexus9000_A(config-if-range)# ethanalyzer local interface mgmt display-filter icmp detail
Capturing on mgmt0
Frame 2 (98 bytes on wire, 98 bytes captured)
    Arrival Time: Feb 18, 2020 02:02:17.569801000
    [Time delta from previous captured frame: 0.075295000 seconds]
    [Time delta from previous displayed frame: 0.075295000 seconds]
    [Time since reference or first frame: 0.075295000 seconds]
    Frame Number: 2
    Frame Length: 98 bytes
    Capture Length: 98 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:icmp:data]
Ethernet II, Src: 00:be:75:5b:de:00 (00:be:75:5b:de:00), Dst: 00:be:75:5b:d9:00 (00:be:75:5b:d9:00)
    Destination: 00:be:75:5b:d9:00 (00:be:75:5b:d9:00)
        Address: 00:be:75:5b:d9:00 (00:be:75:5b:d9:00)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
>>>>>>>Output Clipped

Mit Ethanalyzer können Sie:

• Schreiben Sie die Ausgabe (eine PCAP-Datei) in den angegebenen Dateinamen auf verschiedenen Zieldateisystemen: bootflash, logflash, USB usw.
• Anschließend können Sie die gespeicherte Datei an eine Stelle außerhalb des Geräts übertragen und sie bei Bedarf in Wireshark anzeigen.
• Lesen Sie eine Datei vom Bootflash und zeigen Sie sie auf Ihrem Terminal an. Genau wie beim direkten Lesen von der CPU-Schnittstelle können Sie auch die vollständigen Paketinformationen anzeigen, wenn Sie das Stichwort detail verwenden.

Beispiele für verschiedene Schnittstellenquellen und Ausgabeoptionen:

Nexus9000_A# ethanalyzer local interface mgmt capture-filter "host 10.82.140.107" write bootflash:TEST.PCAP
Capturing on mgmt0
10
Nexus9000_A# dir bootflash:
       4096    Feb 11 02:59:04 2020  .rpmstore/
       4096    Feb 12 02:57:36 2020  .swtam/
       2783    Feb 17 21:59:49 2020  09b0b204-a292-4f77-b479-1ca1c4359d6f.config
       1738    Feb 17 21:53:50 2020  20200217_215345_poap_4168_init.log
       7169    Mar 01 04:41:55 2019  686114680.bin
       4411    Nov 15 15:07:17 2018  EBC-SC02-M2_303_running_config.txt
   13562165    Oct 26 06:15:35 2019  GBGBLD4SL01DRE0001-CZ07-
        590    Jan 10 14:21:08 2019  MDS20190110082155835.lic
       1164    Feb 18 02:18:15 2020  TEST.PCAP
>>>>>>>Output Clipped

Nexus9000_A# copy bootflash: ftp:
Enter source filename: TEST.PCAP
Enter vrf (If no input, current vrf 'default' is considered): management
Enter hostname for the ftp server: 10.122.153.158
Enter username: calo
Password:
***** Transfer of file Completed Successfully *****
Copy complete, now saving to disk (please wait)...
Copy complete.

Nexus9000_A# ethanalyzer local read bootflash:TEST.PCAP
2020-02-18 02:18:03.140167 10.82.140.107 -> 10.82.140.106 ICMP Echo (ping) request
2020-02-18 02:18:03.140563 10.82.140.106 -> 10.82.140.107 ICMP Echo (ping) reply
2020-02-18 02:18:15.663901 10.82.140.107 -> 10.82.140.106 ICMP Echo (ping) request
2020-02-18 02:18:15.664303 10.82.140.106 -> 10.82.140.107 ICMP Echo (ping) reply
2020-02-18 02:18:15.664763 10.82.140.107 -> 10.82.140.106 ICMP Echo (ping) request
2020-02-18 02:18:15.664975 10.82.140.106 -> 10.82.140.107 ICMP Echo (ping) reply
2020-02-18 02:18:15.665338 10.82.140.107 -> 10.82.140.106 ICMP Echo (ping) request
2020-02-18 02:18:15.665536 10.82.140.106 -> 10.82.140.107 ICMP Echo (ping) reply
2020-02-18 02:18:15.665864 10.82.140.107 -> 10.82.140.106 ICMP Echo (ping) request
2020-02-18 02:18:15.666066 10.82.140.106 -> 10.82.140.107 ICMP Echo (ping) reply

RTP-SUG-BGW-1# ethanalyzer local interface front-panel eth1-1 write bootflash:e1-1.pcap
Capturing on 'Eth1-1'
10

RTP-SUG-BGW-1# ethanalyzer local read bootflash:e1-1.pcap detail
Frame 1: 53 bytes on wire (424 bits), 53 bytes captured (424 bits) on interface Eth1-1, id 0
    Interface id: 0 (Eth1-1)
        Interface name: Eth1-1
    Encapsulation type: Ethernet (1)
    Arrival Time: Jul 15, 2022 19:59:50.696219656 UTC
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1657915190.696219656 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 53 bytes (424 bits)
    Capture Length: 53 bytes (424 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:llc:stp]

SPAN

SwitchPort Analyzer (SPAN) wird verwendet, um den gesamten Datenverkehr von einer Schnittstelle zu erfassen und diesen Datenverkehr an einen Zielport zu spiegeln. Der Ziel-Port stellt in der Regel eine Verbindung zu einem Netzwerk-Analysetool her (z. B. einem PC mit Wireshark), mit dem Sie den Datenverkehr analysieren können, der diese Ports durchquert. Sie können SPAN für den Datenverkehr von einem einzelnen Port oder von mehreren Ports und VLANs verwenden.

SPAN-Sitzungen umfassen einen Quell- und einen Ziel-Port. Ein Quell-Port kann ein Ethernet-Port (ohne Subschnittstellen), Port-Channels oder Supervisor Inband-Schnittstellen sein und nicht gleichzeitig ein Ziel-Port sein. Darüber hinaus werden für einige Geräte wie die 9300- und 9500-Plattform auch Fabric Extender (FEX)-Ports unterstützt. Ein Ziel-Port kann ein Ethernet-Port (Access oder Trunk), Port-Channel (Access oder Trunk) sein. Bei einigen Geräten wie dem 9300 werden Uplink-Ports ebenfalls unterstützt, FEX-Ports werden jedoch nicht unterstützt. ziel.

Sie können mehrere SPAN-Sitzungen als Eingangs-/Ausgangs-/beides konfigurieren. Die Gesamtzahl der SPAN-Sitzungen, die ein einzelnes Gerät unterstützen kann, ist begrenzt. Ein Nexus 9000 kann beispielsweise bis zu 32 Sitzungen unterstützen, während ein Nexus 7000 nur 16 Sitzungen unterstützt. Sie können dies in der CLI überprüfen oder die SPAN-Konfigurationsanleitungen für das von Ihnen verwendete Produkt lesen.

Hier sind die Links für Nexus 9000 bzw. Nexus 7000:

Cisco Nexus Serie 9000 NX-OS - Systemmanagement-Konfigurationsleitfaden, Version 9.3(x) - Konfigurieren von SPAN [Cisco Nexus Switches der Serie 9000] - Cisco

Cisco Nexus Serie 7000 NX-OS - Systemmanagement - Konfigurationsanleitung - Konfigurieren von SPAN [Cisco Nexus Switches der Serie 7000] - Cisco

Es gibt verschiedene Arten von SPAN-Sitzungen. Einige der gebräuchlichsten Typen sind hier aufgelistet:

• Local SPAN (Lokales SPAN): Ein SPAN-Sitzungstyp, bei dem sich der Quell- und der Ziel-Host lokal im Switch befinden. Mit anderen Worten: Die gesamte für die Einrichtung der SPAN-Sitzung erforderliche Konfiguration wird auf einen einzigen Switch angewendet, d. h. auf denselben Switch, auf dem sich die Quell- und Ziel-Host-Ports befinden.
• Remote SPAN (RSPAN): Ein SPAN-Sitzungstyp, bei dem sich der Quell- und der Ziel-Host nicht lokal auf dem Switch befinden. Mit anderen Worten: Sie konfigurieren Quell-RSPAN-Sitzungen auf einem Switch und Ziel-RSPAN auf dem Ziel-Switch und erweitern die Verbindung mit dem RSPAN-VLAN.

• Erweitertes Remote-SPAN (ERSPAN): Der Switch kapselt den kopierten Frame mit einem Generic Routing Encapsulation (GRE) Tunnel-Header und leitet das Paket an das konfigurierte Ziel weiter. Sie konfigurieren Quell- und Zielsitzungen auf den Kapselungs- und Entkapselungsschaltern (zwei verschiedene Geräte). Dadurch können Sie den SPAN-Verkehr über ein Layer-3-Netzwerk leiten.
• SPAN-zu-CPU: Ein Name, der einem speziellen Typ einer SPAN-Sitzung zugewiesen wird, bei der Ihr Ziel-Port der Supervisor oder die CPU ist. Dies ist eine Form der lokalen SPAN-Sitzung und kann in Fällen verwendet werden, in denen eine Standard-SPAN-Sitzung nicht genutzt werden kann. Einige der häufigsten Gründe sind: keine verfügbaren oder geeigneten SPAN-Zielports, kein Zugriff auf den Standort oder ein nicht verwalteter Standort, kein Gerät verfügbar, das eine Verbindung mit dem SPAN-Zielport herstellen kann usw. Weitere Informationen finden Sie unter diesem Link Nexus 9000 Cloud Scale ASIC NX-OS SPAN-to-CPU Procedure - Cisco. Beachten Sie, dass die Übertragungsrate der SPAN-zu-CPU durch Control Plane Policing (CoPP) begrenzt ist, sodass sniffing  eine oder mehrere Quellschnittstellen, die die Richtlinie überschreiten, zu Verlusten für die SPAN-zu-CPU-Sitzung führen können. Wenn dies geschieht, spiegeln die Daten nicht 100 % des Inhalts des Kabels wider, sodass SPAN zu CPU nicht immer für Fehlerbehebungsszenarien mit hoher Datenrate und/oder vorübergehendem Verlust geeignet ist. Sobald Sie eine SPAN-zu-CPU-Sitzung konfigurieren und administrativ aktivieren, müssen Sie Ethanalyzer ausführen, um den Datenverkehr anzuzeigen, der an die CPU gesendet wird, um die Analyse entsprechend durchzuführen.

Dies ist ein Beispiel dafür, wie Sie eine einfache lokale SPAN-Sitzung auf einem Nexus 9000 konfigurieren können:

Nexus9000_A(config-monitor)# monitor session ?

*** No matching command found in current mode, matching in (config) mode ***
  <1-32>
  all     All sessions

Nexus9000_A(config)# monitor session 10
Nexus9000_A(config-monitor)# ?
  description  Session description (max 32 characters)
  destination  Destination configuration
  filter       Filter configuration
  mtu          Set the MTU size for SPAN packets
  no           Negate a command or set its defaults
  show         Show running system information
  shut         Shut a monitor session
  source       Source configuration
  end          Go to exec mode
  exit         Exit from command interpreter
  pop          Pop mode from stack or restore from name
  push         Push current mode to stack or save it under name
  where        Shows the cli context you are in

Nexus9000_A(config-monitor)# description Monitor_Port_e1/1
Nexus9000_A(config-monitor)# source interface ethernet 1/1
Nexus9000_A(config-monitor)# destination interface ethernet 1/10
Nexus9000_A(config-monitor)# no shut

Dieses Beispiel zeigt die Konfiguration einer SPAN-zu-CPU-Sitzung, die gestartet wurde, und dann die Verwendung von Ethanalyzer zur Erfassung des Datenverkehrs:

N9000-A# show run monitor

monitor session 1
source interface Ethernet1/7 rx
destination interface sup-eth0                  << this is what sends the traffic to CPU
no shut

RTP-SUG-BGW-1# ethanalyzer local interface inband mirror limit-c 0
Capturing on 'ps-inb'
2020-02-18 02:18:03.140167 10.82.140.107 -> 10.82.140.106 ICMP Echo (ping) request 
2020-02-18 02:18:15.663901 10.82.140.107 -> 10.82.140.106 ICMP Echo (ping) request

Entspiegeln

Dmirror ist eine SPAN-TO-CPU-Sitzung für Broadcom-basierte Nexus-Plattformen. Das Konzept ist dasselbe wie für SPAN-to-CPU und die Rate auf 50 pps (Pakete pro Sekunde) begrenzt. Die Funktion wurde implementiert, um den internen Datenpfad mit der bcm-shell-CLI zu debuggen. Aufgrund der damit verbundenen Einschränkungen gibt es keine NX-OS-CLI, mit der Benutzer SPAN-Sitzungen für den Sup konfigurieren können, da dies den Steuerungsdatenverkehr beeinflussen und CoPP-Klassen verwenden kann.

ELAM

Das Embedded Logic Analyzer Module (ELAM) bietet die Möglichkeit, die ASIC zu untersuchen und zu bestimmen, welche Weiterleitungsentscheidungen für ein EINZELNES Paket getroffen werden. Mithilfe von ELAM können Sie ermitteln, ob das Paket die Weiterleitungs-Engine erreicht, und welche Ports/VLAN-Informationen zur Verfügung stehen. Sie können auch überprüfen, ob die Paketstruktur von L2 nach L4 geändert wurde und ob Änderungen am Paket vorgenommen wurden.

Es ist wichtig zu verstehen, dass ELAM architekturabhängig ist und das Verfahren zur Paketerfassung je nach interner Architektur von Plattform zu Plattform variiert. Sie müssen die ASIC-Zuordnungen der Hardware kennen, um das Tool korrekt anwenden zu können. Für den Nexus 7000 werden zwei Erfassungen für ein einzelnes Paket durchgeführt, eine vor der Entscheidungsfindung, der Daten-BUS (DBUS), und die andere nach der Entscheidungsfindung, der Ergebnis-BUS (RBUS). Wenn Sie die DBUS-Informationen anzeigen, können Sie sehen, was/wo das Paket empfangen wurde, sowie die Layer-2- bis Layer-4-Informationen. Die Ergebnisse im RBUS können Ihnen zeigen, wohin das Paket weitergeleitet wird und ob der Frame geändert wurde. Sie müssen Trigger für DBUS und RBUS einrichten, sicherstellen, dass sie bereit sind, und dann versuchen, das Paket in Echtzeit zu erfassen. Die Vorgehensweise für verschiedene Linecards ist wie folgt:

Einzelheiten zu den verschiedenen ELAM-Verfahren finden Sie unter den Links in dieser Tabelle:

ELAM - ÜBERBLICK	ELAM im Überblick - Cisco
Nexus 7K F1-Modul	ELAM-Verfahren für Nexus 7000 F1-Module - Cisco
Nexus 7K F2-Modul	ELAM-Verfahren für Nexus 7000 F2-Module - Cisco
Nexus 7000 F3-Modul	F3 - ELAM-Beispiel
Nexus 7K M-Modul	ELAM-Verfahren für Nexus 7000-Module der M-Serie - Cisco
Nexus 7K M1/M2- und F2-Modul	Nexus 7000 ELAM für M1/M2 und F2 und Ethanalyzer
Nexus 7K M3-Modul	ELAM-Verfahren für Nexus 7000 M3-Module - Cisco

ELAM für Nexus 7000 - M1/M2 (Eureka-Plattform)

• Überprüfen Sie die Modulnummer mit dem Befehl show module.
• Am Modul mit Anschlussmodul x anhängen, wobei x die Modulnummer ist.
• Überprüfen Sie mithilfe des Befehls show hardware internal dev-port-map die interne ASIC-Zuordnung, und überprüfen Sie, ob L2LKP und L3LKP vorhanden sind.

Nexus7000(config)# show module
Mod  Ports  Module-Type                         Model              Status
---  -----  ----------------------------------- ------------------ ----------
1    0      Supervisor Module-2                 N7K-SUP2E          active *
2    0      Supervisor Module-2                 N7K-SUP2E          ha-standby
3    48     1/10 Gbps Ethernet Module           N7K-F248XP-25E     ok
4    24     10 Gbps Ethernet Module             N7K-M224XP-23L     ok

 
Nexus7000(config)# attach module 4
Attaching to module 4 ...
To exit type 'exit', to abort type '$.'
Last login: Fri Feb 14 18:10:21 UTC 2020 from 127.1.1.1 on pts/0
 
module-4# show hardware internal dev-port-map
--------------------------------------------------------------
CARD_TYPE:       24 port 10G
>Front Panel ports:24
--------------------------------------------------------------
 Device name             Dev role              Abbr num_inst:
--------------------------------------------------------------
> Skytrain               DEV_QUEUEING           QUEUE  4
> Valkyrie               DEV_REWRITE            RWR_0  4
> Eureka                 DEV_LAYER_2_LOOKUP     L2LKP  2
> Lamira                 DEV_LAYER_3_LOOKUP     L3LKP  2
> Garuda                 DEV_ETHERNET_MAC       MAC_0  2
> EDC                    DEV_PHY                PHYS   6
> Sacramento Xbar ASIC   DEV_SWITCH_FABRIC      SWICHF 1
+-----------------------------------------------------------------------+
+----------------+++FRONT PANEL PORT TO ASIC INSTANCE MAP+++------------+
+-----------------------------------------------------------------------+
FP port |  PHYS | SECUR | MAC_0 | RWR_0 | L2LKP | L3LKP | QUEUE |SWICHF
   1       0       0       0       0,1     0       0       0,1     0
   2       0       0       0       0,1     0       0       0,1     0
   3       0       0       0       0,1     0       0       0,1     0
   4       0       0       0       0,1     0       0       0,1     0
   5       1       0       0       0,1     0       0       0,1     0
   6       1       0       0       0,1     0       0       0,1     0
   7       1       0       0       0,1     0       0       0,1     0
   8       1       0       0       0,1     0       0       0,1     0
   9       2       0       0       0,1     0       0       0,1     0
   10      2       0       0       0,1     0       0       0,1     0
   11      2       0       0       0,1     0       0       0,1     0
   12      2       0       0       0,1     0       0       0,1     0
   13      3       1       1       2,3     1       1       2,3     0
   14      3       1       1       2,3     1       1       2,3     0
   15      3       1       1       2,3     1       1       2,3     0
   16      3       1       1       2,3     1       1       2,3     0
   17      4       1       1       2,3     1       1       2,3     0
   18      4       1       1       2,3     1       1       2,3     0
   19      4       1       1       2,3     1       1       2,3     0
   20      4       1       1       2,3     1       1       2,3     0
   21      5       1       1       2,3     1       1       2,3     0
   22      5       1       1       2,3     1       1       2,3     0
   23      5       1       1       2,3     1       1       2,3     0
   24      5       1       1       2,3     1       1       2,3     0
+-----------------------------------------------------------------------+
+-----------------------------------------------------------------------+

• Zunächst erfassen Sie das Paket in L2 und prüfen, ob die Weiterleitungsentscheidung richtig ist. Schauen Sie dazu in die Spalte "L2LKP mappings" (L2LKP-Zuordnungen), und geben Sie die ASIC-Instanznummer an, die dem Port entspricht.
• Als Nächstes führen Sie ELAM auf dieser Instanz mit dem Befehl elam asic eureka instance x aus.wobei x die ASIC-Instanznummer ist und die Trigger für DBUS und RBUS konfiguriert werden. Überprüfen Sie den Status der Trigger mit dem Befehlsstatus, und bestätigen Sie, dass die Trigger konfiguriert wurden.

module-4(eureka-elam)# trigger dbus dbi ingress ipv4 if source-ipv4-address 192.0.2.2 destination-ipv4-address 192.0.2.4 rbi-corelatemodule-4(eureka-elam)#trigger rbus rbi pb1 ip if cap2 1
module-4(eureka-elam)# status

Slot: 4, Instance: 1
EU-DBUS: Configured
trigger dbus dbi ingress ipv4 if source-ipv4-address 192.168.10.1
EU-RBUS: Configured
trigger rbus rbi pb1 ip if cap2 1

• Aktivieren Sie die Trigger mit dem Befehl start, und überprüfen Sie den Status der Trigger mit dem Befehlsstatus, um zu bestätigen, dass die Trigger aktiviert sind.

module-4(eureka-elam)# start
module-4(eureka-elam)# status

Slot: 4, Instance: 1
EU-DBUS: Armed     <<<<<<<<<<
trigger dbus dbi ingress ipv4 if source-ipv4-address 192.168.10.1
EU-RBUS: Armed     <<<<<<<<<<
trigger rbus rbi pb1 ip if cap2 1

• Sobald der Status zeigt, dass die Auslöser bewaffnet sind, sind sie bereit, zu erfassen. Zu diesem Zeitpunkt müssen Sie den Datenverkehr weiterleiten und den Status erneut überprüfen, um festzustellen, ob die Trigger tatsächlich ausgelöst wurden.

module-4(eureka-elam)# status

Slot: 4, Instance: 1
EU-DBUS: Triggered     <<<<<<<<<<
trigger dbus dbi ingress ipv4 if source-ipv4-address 192.168.10.1
EU-RBUS: Triggered     <<<<<<<<<<
trigger rbus rbi pb1 ip if cap2 1

• Überprüfen Sie nach der Auslösung die Paketsequenznummer für rbus und dbus, um sicherzustellen, dass beide dasselbe Paket erfasst haben. Dies kann mit dem Befehl show dbus geschehen. | i sek. ; Show-Rbus | i seq. Wenn die Sequenznummer übereinstimmt, können Sie den Inhalt von dbus und rbus sehen. Wenn nicht, führen Sie die Erfassung erneut aus, bis Sie dasselbe Paket erfassen können.

Anmerkung: Um die Genauigkeit zu erhöhen, sollten Sie ELAM immer mehrmals ausführen, um Weiterleitungsprobleme zu bestätigen.

• Sie können den Inhalt von rbus und dbus mit den Befehlen show dbus und show rbus anzeigen. Wichtig bei der Erfassung sind die Sequenznummer und der Quell-/Zielindex. Dbus zeigt Ihnen den Quellindex, der Ihnen den Port mitteilt, auf dem das Paket empfangen wurde. Rbus zeigt den Zielindex des Ports an, an den das Paket weitergeleitet wird. Zusätzlich können Sie auch Quell- und Ziel-IP/MAC-Adressen sowie VLAN-Informationen anzeigen.
• Mit dem Quell- und Zielindex (auch LTL-Index genannt) können Sie den zugehörigen Port an der Vorderseite mit dem Befehl show system internal pixm info ltl #überprüfen

ELAM für Nexus 7000 - M1/M2 (Lamira-Plattform)

Die Vorgehensweise ist auch für die Lamira-Plattform identisch, es gibt jedoch einige Unterschiede:

• Sie führen ELAM mit dem Schlüsselwort Lamiraelam asic lamira instance x aus.
• Die Befehle zum Auslösen des ELAM lauten wie folgt:

module-4(lamira-elam)# trigger dbus ipv4 if source-ipv4-address 192.0.2.2 destination-ipv4-address 192.0.2.4
module-4(lamira-elam)# trigger rbus 
    
    
      ip if elam-match 1 
    

• Sie überprüfen den Status mit dem Status-Befehl und stellen sicher, dass sie bewaffnet sind, bevor Sie Datenverkehr senden, und ausgelöst, nachdem Sie ihn erfasst haben.
• Sie können dann die Ausgänge von dbus und show bus in ähnlicher Weise interpretieren, wie für Eureka gezeigt.

ELAM für Nexus 7000 - F2/F2E (Clipper-Plattform)

Auch hier ist das Verfahren ähnlich, nur die Auslöser sind unterschiedlich. Es gibt folgende Unterschiede:

• Sie führen ELAM mit dem Schlüsselwort Clipperelam asic clipper instance x aus und geben den Layer 2- oder Layer 3-Modus an.

module-4# elam asic  clipper instance 1
module-4(clipper-elam)# 
    
    

• Die Befehle zum Auslösen des ELAM sind wie folgt:

module-4(clipper-l2-elam)# trigger dbus ipv4 ingress if source-ipv4-address 192.0.2.3 destination-ipv4-address 192.0.2.2
module-4(clipper-l2-elam)# trigger rbus ingress if trig

• Mit dem Status-Befehl überprüfen Sie den Status und stellen sicher, dass sie bewaffnet sind, bevor Sie Datenverkehr senden, und ausgelöst, nachdem Sie ihn erfasst haben.
• Sie können dann die Ausgänge von dbus und show bus in ähnlicher Weise interpretieren, wie für Eureka gezeigt.

ELAM für Nexus 7000 - F3 (Flanker-Plattform)

Auch hier ist das Verfahren ähnlich, nur Trigger sind unterschiedlich. Es gibt folgende Unterschiede:

• Sie führen ELAM mit dem Schlüsselwort Flanker elam asic flanker instance x aus und geben den Layer 2- oder Layer 3-Modus an.

module-4# elam asic flanker instance 1
module-4(flanker-elam)# 
    
    

• Die Befehle zum Auslösen des ELAM sind wie folgt:

module-9(fln-l2-elam)# trigger dbus ipv4 if destination-ipv4-address 10.1.1.2
module-9(fln-l2-elam)# trigger rbus ingress if trig

• Mit dem Befehl status überprüfen Sie den Status und stellen sicher, dass sie bewaffnet sind, bevor Sie Datenverkehr senden und ausgelöst werden, nachdem Sie ihn erfasst haben.
• Sie können dann die Ausgänge von dbus und rbus in ähnlicher Weise interpretieren, wie für Eureka gezeigt.

ELAM für Nexus 9000 (Tahoe-Plattform)

Beim Nexus 9000 unterscheidet sich das Verfahren geringfügig vom Nexus 7000. Informationen zu Nexus 9000 finden Sie unter dem Link Nexus 9000 Cloud Scale ASIC (Tahoe) NX-OS ELAM - Cisco

• Überprüfen Sie zunächst mithilfe des Befehls show hardware internal tah interface # die Schnittstellenzuordnung. Die wichtigsten Informationen in dieser Ausgabe sind ASIC#, Slice # und die Quell-ID (srcid) #.

• Zusätzlich können Sie diese Informationen mit dem Befehl show system internal ethpm info interface # | i i src. Wichtig sind hier neben den zuvor aufgeführten Werten die Werte dpid und dmod.
• Überprüfen Sie die Modulnummer mit dem Befehl show module.
• Am Modul mit Anschlussmodul x anschließen, wobei x die Modulnummer ist.
• Führen Sie ELAM auf dem Modul mit dem Befehl module-1# debug platform internal tah elam asic #.
• Konfigurieren Sie den inneren oder äußeren Trigger auf Basis der Art des Datenverkehrs, den Sie erfassen möchten (L2, L3, gekapselten Datenverkehr wie GRE oder VXLAN usw.):

Nexus9000(config)# attach module 1
module-1# debug platform internal tah elam asic 0
module-1(TAH-elam)# trigger init asic # slice # lu-a2d 1 in-select 6 out-select 0 use-src-id #
module-1(TAH-elam-insel6)# reset
module-1(TAH-elam-insel6)# set outer ipv4 dst_ip 192.0.2.1 src_ip 192.0.2.2

• Sobald die Trigger festgelegt sind, starten Sie ELAM mit dem Befehl start, senden Datenverkehr und zeigen die Ausgabe mit dem Befehl report an. In der Berichtausgabe werden die ausgehenden und eingehenden Schnittstellen sowie die VLAN-ID, die Quell- und Ziel-IP/MAC-Adresse angezeigt.
  
  

SUGARBOWL ELAM REPORT SUMMARY
slot - 1, asic - 1, slice - 1
============================
 

Incoming Interface: Eth1/49
Src Idx : 0xd, Src BD : 10
Outgoing Interface Info: dmod 1, dpid 14
Dst Idx : 0x602, Dst BD : 10

Packet Type: IPv4
Dst MAC address: CC:46:D6:6E:28:DB
Src MAC address: 00:FE:C8:0E:27:15
.1q Tag0 VLAN: 10, cos = 0x0
Dst IPv4 address: 192.0.2.1
Src IPv4 address: 192.0.2.2

Ver     =  4, DSCP    =    0, Don't Fragment = 0
Proto   =  1, TTL     =   64, More Fragments = 0
Hdr len = 20, Pkt len =   84, Checksum       = 0x667f

ELAM für Nexus 9000 (NorthStar-Plattform)

Das Verfahren für die NorthStar-Plattform ist das gleiche wie die Tahoe-Plattform, der einzige Unterschied besteht darin, dass das Schlüsselwort ns anstelle von tah verwendet wird, wenn der ELAM-Modus eingegeben wird:

module-1# debug platform internal ns elam asic 0

N9K Packet Tracer

Mit dem Nexus 9000 Packet Tracer-Tool kann der Pfad des Pakets nachverfolgt werden. Dank der integrierten Zähler für Flussstatistiken ist das Tool ein nützliches Tool für Szenarien mit vorübergehenden/vollständigen Datenverlusten. In Fällen, in denen die TCAM-Ressourcen begrenzt oder nicht verfügbar sind, wäre es sehr nützlich, andere Tools auszuführen. Darüber hinaus kann dieses Tool ARP-Datenverkehr nicht erfassen und zeigt keine Details zum Paketinhalt wie Wireshark an.

Verwenden Sie folgende Befehle, um die Paketverfolgung zu konfigurieren:

N9K-9508# test packet-tracer src_ip 
     
       dst_ip 
      
          
       
            <==== provide your src and dst ip 
N9K-9508# test packet-tracer start                                  <==== Start packet tracer
N9K-9508# test packet-tracer stop                                   <==== Stop packet tracer
N9K-9508# test packet-tracer show                                   <==== Check for packet matches

Weitere Informationen finden Sie unter dem Link Nexus 9000: Erläuterung des Packet Tracer-Tools - Cisco

Traceroute und Pings

Diese Befehle sind die zwei nützlichsten Befehle, mit denen Sie Verbindungsprobleme schnell identifizieren können.

Ping verwendet Internet Control Message Protocol (ICMP), um ICMP-Echo-Nachrichten an das jeweilige Ziel zu senden, und wartet auf ICMP-Echo-Antworten von diesem Ziel. Wenn der Pfad zwischen den Hosts problemlos funktioniert, ohne dass Probleme auftreten, können Sie sehen, dass die Antworten zurückkommen und die Pings erfolgreich sind. Der Befehl ping sendet standardmäßig 5x ICMP-Echo-Nachrichten (gleiche Größe in beide Richtungen), und wenn alles gut funktioniert, können Sie 5x ICMP-Echo-Antworten sehen. Manchmal schlägt die erste Echoanfrage fehl, wenn Switches die MAC-Adresse während der ARP-Anfrage (Address Resolution Protocol) ermitteln. Wenn Sie den Ping direkt danach wiederholen, gibt es keinen anfänglichen Pingverlust. Darüber hinaus können Sie die Anzahl der Pings, die Paketgröße, die Quelle, die Quellschnittstelle und die Zeitüberschreitungsintervalle mit den folgenden Schlüsselwörtern festlegen:

F241.04.25-N9K-C93180-1# ping 10.82.139.39 vrf management
PING 10.82.139.39 (10.82.139.39): 56 data bytes
36 bytes from 10.82.139.38: Destination Host Unreachable
Request 0 timed out
64 bytes from 10.82.139.39: icmp_seq=1 ttl=254 time=23.714 ms
64 bytes from 10.82.139.39: icmp_seq=2 ttl=254 time=0.622 ms
64 bytes from 10.82.139.39: icmp_seq=3 ttl=254 time=0.55 ms
64 bytes from 10.82.139.39: icmp_seq=4 ttl=254 time=0.598 ms
 

F241.04.25-N9K-C93180-1# ping 10.82.139.39 ?
  <CR>
  count             Number of pings to send
  df-bit            Enable do not fragment bit in IP header
  interval          Wait interval seconds between sending each packet
  packet-size       Packet size to send
  source            Source IP address to use
  source-interface  Select source interface
  timeout           Specify timeout interval
  vrf               Display per-VRF information

Mit der Traceroute werden die verschiedenen Hops identifiziert, die ein Paket benötigt, bevor es sein Ziel erreicht. Es ist ein sehr wichtiges Tool, da es dabei hilft, die L3-Grenze zu identifizieren, an der ein Fehler auftritt. Sie können den Port, die Quell- und die Quell-Schnittstelle auch mit den folgenden Schlüsselwörtern verwenden:

F241.04.25-N9K-C93180-1# traceroute 10.82.139.39 ?
  <CR>
  port              Set destination port
  source            Set source address in IP header
  source-interface  Select source interface
  vrf               Display per-VRF information


Nexus_1(config)# traceroute 192.0.2.1
traceroute to 192.0.2.1 (192.0.2.1), 30 hops max, 40 byte packets
 1 198.51.100.3 (198.51.100.3)  1.017 ms  0.655 ms  0.648 ms
 2 203.0.113.2 (203.0.113.2)  0.826 ms  0.898 ms  0.82 ms
 3 192.0.2.1 (192.0.2.1)  0.962 ms  0.765 ms  0.776 ms

PACL/RACL/VACL

Zugriffskontrolllisten (ACLs) sind wichtige Tools, mit denen Sie den Datenverkehr nach einem bestimmten Kriterium filtern können. Sobald die ACL mit Einträgen für Abgleichkriterien gefüllt ist, kann sie angewendet werden, um eingehenden oder ausgehenden Datenverkehr zu erfassen. Ein wichtiger Aspekt von ACL ist die Möglichkeit, Zähler für Flow-Statistiken bereitzustellen. Die Begriffe PACL/RACL/VACL beziehen sich auf verschiedene Implementierungen dieser ACLs, die Ihnen die Verwendung von ACL als leistungsstarkes Fehlerbehebungstool speziell für den zeitweiligen Verlust von Datenverkehr ermöglichen. Diese Begriffe werden hier kurz beschrieben:

• Port-Zugriffskontrollliste (PACL): Wenn Sie eine Zugriffsliste auf einen L2-Switch-Port bzw. eine L2-Switch-Schnittstelle anwenden, wird diese Zugriffsliste als PACL bezeichnet.
• Router Access Control List (RACL): Wenn Sie eine Zugriffsliste auf einen gerouteten L3-Port/eine geroutete Schnittstelle anwenden, wird diese Zugriffsliste als RACL (RACL) bezeichnet.
• VLAN-Zugriffskontrollliste (VACL): Sie können VACLs so konfigurieren, dass sie auf alle Pakete angewendet werden, die in ein VLAN oder aus einem VLAN heraus geroutet oder innerhalb eines VLAN überbrückt werden. VACLs dienen ausschließlich der Paketfilterung und der Umleitung des Datenverkehrs an bestimmte physische Schnittstellen. VACLs werden nicht nach Richtung definiert (Eingang oder Ausgang).

In dieser Tabelle werden die Versionen der Zugriffskontrolllisten verglichen.

ACL-TYP	PACL	RACL	VACL
FUNKTION	An einer L2-Schnittstelle empfangenen Datenverkehr filtern.	An einer L3-Schnittstelle empfangenen Datenverkehr filtern.	Filtern des vLAN-Datenverkehrs.
ANGEWENDET AUF	- L2-Schnittstellen/-Ports - L2-Port-Channel-Schnittstellen - Wenn sie auf einen Trunk-Port angewendet wird, filtert die ACL den Datenverkehr in allen VLANs, die auf diesem Trunk-Port zulässig sind.	- VLAN-Schnittstellen - Physische L3-Schnittstellen - L3-Subschnittstellen - L3-Port-Channel-Schnittstellen - Management-Schnittstellen	Nach der Aktivierung wird die ACL auf alle Ports in diesem VLAN angewendet (einschließlich Trunk-Ports).
ANGEWANDTE RICHTUNG	Nur eingehend.	Eingehend oder ausgehend	-

Hier ist ein Beispiel, wie Sie eine Zugriffsliste konfigurieren können. Weitere Informationen finden Sie unter dem Link Cisco Nexus 9000 Serie NX-OS Security Configuration Guide, Release 9.3(x) - Configuring IP ACLs [Cisco Nexus Switches der Serie 9000] - Cisco

Nexus93180(config)# ip access-list 
     
Nexus93180(config-acl)# ?
  <1-4294967295>  Sequence number
  deny            Specify packets to reject
  fragments       Optimize fragments rule installation
  no              Negate a command or set its defaults
  permit          Specify packets to forward
  remark          Access list entry comment
  show            Show running system information
  statistics      Enable per-entry statistics for the ACL
  end             Go to exec mode
  exit            Exit from command interpreter
  pop             Pop mode from stack or restore from name
  push            Push current mode to stack or save it under name
  where           Shows the cli context you are in

Nexus93180(config)# int e1/1

Nexus93180(config-if)# ip port access-group <NAME_of_ACL> ? >>>>>> When you configure ACL like this, it is PACL.   
  in  Inbound packets

Nexus93180(config-if)# ip access-group <NAME_of_ACL> ?      >>>>>> When you configure ACL like this, it is RACL.
  in   Inbound packets
  out  Outbound packets

LOGFLASH

LogFlash ist eine Art von persistentem Speicher, der auf Nexus-Plattformen entweder als externer Compact Flash-Speicher, als USB-Gerät oder als integrierter Datenträger im Supervisor verfügbar ist. Wenn der Switch entfernt wird, benachrichtigt das System den Benutzer regelmäßig, dass LogFlash fehlt. Logflash wird auf dem Supervisor installiert und enthält Verlaufsdaten wie Accounting-Protokolle, Syslog-Meldungen, Debugging-Meldungen und Embedded Event Manager (EEM)-Ausgaben. EEM wird später in diesem Artikel besprochen. Sie können den Inhalt von LogFlash mit dem folgenden Befehl überprüfen:

Nexus93180(config)# dir logflash:
          0    Nov 14 04:13:21 2019  .gmr6_plus
      20480    Feb 18 13:35:07 2020  ISSU_debug_logs/
         24    Feb 20 20:43:24 2019  arp.pcap
         24    Feb 20 20:36:52 2019  capture_SYB010L2289.pcap
       4096    Feb 18 17:24:53 2020  command/
       4096    Sep 11 01:39:04 2018  controller/
       4096    Aug 15 03:28:05 2019  core/
       4096    Feb 02 05:21:47 2018  debug/
    1323008    Feb 18 19:20:46 2020  debug_logs/
       4096    Feb 17 06:35:36 2020  evt_log_snapshot/
       4096    Feb 02 05:21:47 2018  generic/
       1024    Oct 30 17:27:49 2019  icamsql_1_1.db
      32768    Jan 17 11:53:23 2020  icamsql_1_1.db-shm
     129984    Jan 17 11:53:23 2020  icamsql_1_1.db-wal
       4096    Feb 14 13:44:00 2020  log/
      16384    Feb 02 05:21:44 2018  lost+found/
       4096    Aug 09 20:38:22 2019  old_upgrade/
       4096    Feb 18 13:40:36 2020  vdc_1/

Usage for logflash://sup-local
 1103396864 bytes used
 7217504256 bytes free
 8320901120 bytes total

Wenn ein Benutzer das Gerät neu lädt oder es aufgrund eines Ereignisses plötzlich von alleine neu lädt, gehen alle Protokollinformationen verloren. In solchen Szenarien kann LogFlash historische Daten liefern, die überprüft werden können, um eine wahrscheinliche Ursache des Problems zu identifizieren. Natürlich ist weitere Sorgfalt erforderlich, um die Ursache zu identifizieren, die Ihnen Hinweise darauf gibt, wonach Sie suchen sollten, falls dieses Ereignis erneut auftritt.

Informationen zur Installation von Logflash auf dem Gerät finden Sie unter dem Link Nexus 7000-Protokollierungsfunktionen - Cisco.

OBFL

On Board Failure Logging (OBFL) ist eine Art von persistentem Speicher, der sowohl für Nexus Top-of-Rack- als auch für modulare Switches verfügbar ist. Wie der LogFlash werden die Informationen nach dem erneuten Laden des Geräts beibehalten. OBFL speichert Informationen wie Ausfälle und Umgebungsdaten. Die Informationen variieren je nach Plattform und Modul. Hier sehen Sie jedoch eine Beispielausgabe für Modul 1 der Nexus 93108-Plattform (d. h. ein festes Chassis mit nur einem Modul):

Nexus93180(config)# show logging onboard module 1 ?
*** No matching command found in current mode, matching in (exec) mode ***
  <CR>
  >                      Redirect it to a file
  >>                     Redirect it to a file in append mode
  boot-uptime            Boot-uptime
  card-boot-history      Show card boot history
  card-first-power-on    Show card first power on information
  counter-stats          Show OBFL counter statistics
  device-version         Device-version
  endtime                Show OBFL logs till end time mm/dd/yy-HH:MM:SS
  environmental-history  Environmental-history
  error-stats            Show OBFL error statistics
  exception-log          Exception-log
  internal               Show Logging Onboard Internal
  interrupt-stats        Interrupt-stats
  obfl-history           Obfl-history
  stack-trace            Stack-trace
  starttime              Show OBFL logs from start time mm/dd/yy-HH:MM:SS
  status                 Status
  |                      Pipe command output to filter


Nexus93180(config)# show logging onboard module 1 status
----------------------------
OBFL Status
----------------------------
    Switch OBFL Log:                                    Enabled
    Module:  1 OBFL Log:                                Enabled
    card-boot-history                                   Enabled
    card-first-power-on                                 Enabled
    cpu-hog                                             Enabled
    environmental-history                               Enabled
    error-stats                                         Enabled
    exception-log                                       Enabled
    interrupt-stats                                     Enabled
    mem-leak                                            Enabled
    miscellaneous-error                                 Enabled
    obfl-log (boot-uptime/device-version/obfl-history)  Enabled
    register-log                                        Enabled
    system-health                                       Enabled
    temp Error                                          Enabled
    stack-trace                                         Enabled

Auch diese Informationen sind nützlich, wenn ein Gerät entweder vom Benutzer absichtlich oder aufgrund eines Ereignisses, das ein erneutes Laden ausgelöst hat, neu geladen wird. In diesem Fall können OBFL-Informationen helfen, aus Sicht einer Line Card zu identifizieren, was schief gelaufen ist. Der Befehl show logging onboard ist ein guter Ausgangspunkt. Denken Sie daran, dass Sie alles, was Sie brauchen, aus dem Modulkontext heraus erfassen müssen. Stellen Sie sicher, dass Sie show logging on board module x verwenden oder mod x anhängen. Logging an Bord anzeigen.

Ereignisverlauf

Der Ereignisverlauf ist eines der leistungsstarken Tools, mit dem Sie Informationen zu verschiedenen Ereignissen erhalten, die bei einem auf Nexus ausgeführten Prozess auftreten. Mit anderen Worten: Jeder Prozess, der auf einer Nexus-Plattform ausgeführt wird, verfügt über Ereignisverlaufslisten, die im Hintergrund ausgeführt werden und Informationen zu verschiedenen Ereignissen dieses Prozesses speichern (diese stellen sich als ständig ausgeführte Debugs vor). Diese Ereignisverlaufslisten sind nicht persistent, und alle gespeicherten Informationen gehen beim Neuladen des Geräts verloren. Diese sind sehr nützlich, wenn Sie ein Problem mit einem bestimmten Prozess identifiziert haben und diesen Prozess beheben möchten. Wenn beispielsweise das OSPF-Routing-Protokoll nicht ordnungsgemäß funktioniert, können Sie mit OSPF verknüpfte Ereignisverlaufshistorien verwenden, um den Fehler beim OSPF-Prozess zu identifizieren. Auf der Nexus-Plattform finden Sie Ereignisprotokolle zu nahezu allen Prozessen, z. B. CDP/STP, UDLD, LACP/OSPF, EIGRP/BGP usw.

So überprüfen Sie normalerweise anhand von Referenzbeispielen, ob Ereignisverläufe für einen Prozess vorhanden sind. Jeder Prozess hat mehrere Optionen, also verwenden ? , um zu prüfen, ob verschiedene Optionen unter einem Prozess verfügbar sind.

Nexus93180(config)# show 
     
       internal event-history ? 
     

Nexus93180# show ip ospf event-history ?
  adjacency       Adjacency formation logs
  cli             Cli logs
  event           Internal event logs
  flooding        LSA flooding logs
  ha              HA and GR logs
  hello           Hello related logs
  ldp             LDP related logs
  lsa             LSA generation and databse logs
  msgs            IPC logs
  objstore        DME OBJSTORE related logs
  redistribution  Redistribution logs
  rib             RIB related logs
  segrt           Segment Routing logs
  spf             SPF calculation logs
  spf-trigger     SPF TRIGGER related logs
  statistics      Show the state and size of the buffers
  te              MPLS TE related logs

Nexus93180# show spanning-tree internal event-history ?
  all      Show all event historys
  deleted  Show event history of deleted trees and ports
  errors   Show error logs of STP
  msgs     Show various message logs of STP
  tree     Show spanning tree instance info
  vpc      Show virtual Port-channel event logs

Fehlerbehebung

Debugging-Programme sind leistungsstarke Tools in NX-OS, mit denen Sie Fehlerbehebungsereignisse in Echtzeit ausführen und in einer Datei oder einer Anzeige in der CLI protokollieren können. Es wird dringend empfohlen, die Debug-Ausgaben in einer Datei zu protokollieren, da sie sich auf die CPU-Leistung auswirken. Seien Sie vorsichtig, bevor Sie ein Debugging direkt über die CLI ausführen.

Debugs werden in der Regel nur dann ausgeführt, wenn Sie ein Problem als einen einzigen Prozess identifiziert haben und in Echtzeit überprüfen möchten, wie sich dieser Prozess mit echtem Datenverkehr im Netzwerk verhält. Sie müssen eine Debugfunktion aktivieren, die auf den definierten Benutzerkontoberechtigungen basiert.

Ebenso wie der Ereignisverlauf können Sie auf einem Nexus-Gerät Debug-Vorgänge für jeden Prozess ausführen, z. B. für CDP/STP, UDLD, LACP/OSPF, EIGRP/BGP usw.

So führen Sie normalerweise ein Debuggen für einen Prozess aus. Jeder Prozess hat mehrere Optionen, also nutzen ? , um zu prüfen, ob verschiedene Optionen unter einem Prozess verfügbar sind.

Nexus93180# debug 
    
    
      ? 
    

Nexus93180# debug spanning-tree ?
  all      Configure all debug flags of stp
  bpdu_rx  Configure debugging of stp bpdu rx
  bpdu_tx  Configure debugging of stp bpdu tx
  error    Configure debugging of stp error
  event    Configure debugging of Events
  ha       Configure debugging of stp HA
  mcs      Configure debugging of stp MCS
  mstp     Configure debugging of MSTP
  pss      Configure debugging of PSS
  rstp     Configure debugging of RSTP
  sps      Configure debugging of Set Port state batching
  timer    Configure debugging of stp Timer events
  trace    Configure debugging of stp trace
  warning  Configure debugging of stp warning

Nexus93180# debug ip ospf ?
  adjacency                Adjacency events
  all                      All OSPF debugging
  database                 OSPF LSDB changes
  database-timers          OSPF LSDB timers
  events                   OSPF related events
  flooding                 LSA flooding
  graceful-restart         OSPF graceful restart related debugs
  ha                       OSPF HA related events
  hello                    Hello packets and DR elections
  lsa-generation           Local OSPF LSA generation
  lsa-throttling           Local OSPF LSA throttling
  mpls                     OSPF MPLS
  objectstore              Objectstore Events
  packets                  OSPF packets
  policy                   OSPF RPM policy debug information
  redist                   OSPF redistribution
  retransmission           OSPF retransmission events
  rib                      Sending routes to the URIB
  segrt                    Segment Routing Events
  snmp                     SNMP traps and request-response related events
  spf                      SPF calculations
  spf-trigger              Show SPF triggers

GOLD

Generic OnLine Diagnostics (GOLD), wie der Name schon sagt, werden diese Tests in der Regel als Systemstatusprüfung verwendet und dienen der Überprüfung oder Verifizierung der betreffenden Hardware. Es gibt verschiedene Online-Tests, die auf der verwendeten Plattform basieren. Einige dieser Tests sind unterbrechungsfrei, andere dagegen nicht. Diese Online-Tests lassen sich wie folgt kategorisieren:

• Systemstart-Diagnose: Diese Tests werden beim Hochfahren des Geräts ausgeführt. Darüber hinaus wird die Verbindung zwischen dem Supervisor und den Modulen geprüft. Dies schließt die Verbindung zwischen Daten- und Kontrollebene für alle ASICs ein. Tests wie ManagementPortLoopback und EOBCLoopback führen zu Unterbrechungen, OBFL- und USB-Tests zu Unterbrechungen.
• Laufzeitdiagnose oder Diagnose der Systemüberwachung: Diese Tests liefern Informationen über den Zustand des Geräts. Diese Tests sind unterbrechungsfrei und werden im Hintergrund ausgeführt, um die Stabilität der Hardware zu gewährleisten. Sie können diese Tests nach Bedarf oder zur Fehlerbehebung aktivieren/deaktivieren.
• On-Demand-Diagnose: Alle genannten Tests können bei Bedarf wiederholt werden, um ein Problem zu lokalisieren.

Mit dem folgenden Befehl können Sie überprüfen, ob verschiedene Online-Tests für Ihren Switch verfügbar sind:

Nexus93180(config)# show diagnostic content module all
Diagnostics test suite attributes:
B/C/* - Bypass bootup level test / Complete bootup level test / NA
P/*   - Per port test / NA
M/S/* - Only applicable to active / standby unit / NA
D/N/* - Disruptive test / Non-disruptive test / NA
H/O/* - Always enabled monitoring test / Conditionally enabled test / NA
F/*   - Fixed monitoring interval test / NA
X/*   - Not a health monitoring test / NA
E/*   - Sup to line card test / NA
L/*   - Exclusively run this test / NA
T/*   - Not an ondemand test / NA
A/I/* - Monitoring is active / Monitoring is inactive / NA

Module 1: 48x10/25G + 6x40/100G Ethernet Module (Active)

                                                       Testing Interval
ID     Name                               Attributes      (hh:mm:ss)
____   __________________________________ ____________   _________________
 1)    USB--------------------------->     C**N**X**T*     -NA-
 2)    NVRAM------------------------->     ***N******A     00:05:00
 3)    RealTimeClock----------------->     ***N******A     00:05:00
 4)    PrimaryBootROM---------------->     ***N******A     00:30:00
 5)    SecondaryBootROM-------------->     ***N******A     00:30:00
 6)    BootFlash--------------------->     ***N******A     00:30:00
 7)    SystemMgmtBus----------------->     **MN******A     00:00:30
 8)    OBFL-------------------------->     C**N**X**T*     -NA-
 9)    ACT2-------------------------->     ***N******A     00:30:00
10)    Console----------------------->     ***N******A     00:00:30
11)    FpgaRegTest------------------->     ***N******A     00:00:30
12)    Mce--------------------------->     ***N******A     01:00:00
13)    AsicMemory-------------------->     C**D**X**T*     -NA-
14)    Pcie-------------------------->     C**N**X**T*     -NA-
15)    PortLoopback------------------>     *P*N**XE***     -NA-
16)    L2ACLRedirect----------------->     *P*N***E**A     00:01:00
17)    BootupPortLoopback------------>     CP*N**XE*T*     -NA-

Verwenden Sie den folgenden Befehl, um anzuzeigen, was jeder der 17 genannten Tests bewirkt:

Nexus93180(config)# show diagnostic description module 1 test all
USB :
        A bootup test that checks the USB controller initialization
        on the module.

NVRAM :
        A health monitoring test, enabled by default that checks the
        sanity of the NVRAM device on the module.

RealTimeClock :
        A health monitoring test, enabled by default that verifies
        the real time clock on the module.

PrimaryBootROM :
        A health monitoring  test that verifies the primary BootROM
        on the module.

SecondaryBootROM :
        A health monitoring  test that verifies the secondary BootROM
        on the module.

BootFlash :
        A Health monitoring test, enabled by default, that verifies
        access to the internal compactflash devices.

SystemMgmtBus :
        A Health monitoring test, enabled by default, that verifies
        the standby System Bus.

OBFL :
        A bootup test that checks the onboard flash used for failure
        logging (OBFL) device initialization on the module.

ACT2 :
        A Health monitoring test, enabled by default, that verifies
        access to the ACT2 device.

Console :
        A health monitoring test,enabled by default that checks health
        of console device.

FpgaRegTest :
        A health monitoring test,enabled by default that checks read/write
        access to FPGA scratch registers on the module.

Mce :
        A Health monitoring test, enabled by default, that check for
        machine errors on sup.

AsicMemory :
        A bootup test that checks the asic memory.

Pcie :
        A bootup test that tests pcie bus of the module

PortLoopback :
        A health monitoring test that tests the packet path from
        the Supervisor card to the physical port in ADMIN DOWN state
        on Linecards.

L2ACLRedirect :
        A health monitoring test, enabled by default, that does a
        non disruptive loopback for TAHOE asics to check the ACL Sup
        redirect with the CPU port.

BootupPortLoopback :
        A Bootup test that tests the packet path from the Supervisor
        card to all of the physical ports at boot time.

EEM

Embedded Event Manager (EEM) ist ein leistungsstarkes Tool, mit dem Sie Ihr Gerät so programmieren können, dass es bestimmte Aufgaben für den Fall eines bestimmten Ereignisses ausführt. Es überwacht verschiedene Ereignisse auf dem Gerät und ergreift dann die erforderlichen Maßnahmen, um das Problem zu beheben und möglicherweise wiederherzustellen. EEM besteht aus drei Hauptkomponenten, die hier jeweils kurz beschrieben werden:

• Event-Anweisung: Dies sind die Ereignisse, die überwacht werden sollen, damit Nexus eine bestimmte Aktion ausführt, z. B. eine Problemumgehung durchführen, einen SNMP-Server benachrichtigen oder ein CLI-Protokoll anzeigen usw.
• Aktionspläne: Dies sind die Schritte, die EEM nach der Auslösung eines Ereignisses durchführt. Diese Aktionen können einfach sein, eine Schnittstelle zu deaktivieren oder einige show-Befehle auszuführen und Ausgaben in eine Datei auf dem FTP-Server zu kopieren, eine E-Mail zu senden usw.
• Richtlinien: Es handelt sich im Grunde um ein Ereignis in Kombination mit einer oder mehreren action-Anweisungen, die Sie auf dem Supervisor über CLI oder ein Bash-Skript konfigurieren können. Sie können EEM auch mit einem Python-Skript aufrufen. Sobald die Richtlinie auf dem Supervisor definiert wurde, wird sie an das entsprechende Modul weitergeleitet.

Weitere Informationen zu EEM finden Sie unter dem Link Cisco Nexus 9000 Series NX-OS System Management Configuration Guide, Release 9.2(x) - Configuring the Embedded Event Manager [Cisco Nexus Switches der Serie 9000] - Cisco.