In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden verschiedene Tools zur Fehlerbehebung bei Nexus-Produkten beschrieben, mit denen Sie Probleme diagnostizieren und beheben können.
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 zur oder von der CPU |
Probleme mit Verkehrsflaute, Latenz und Staus |
Hervorragend bei Problemen mit Langsamkeit, Überlastung und Latenz |
Erkennt in der Regel nur Steuerungsebenen-Datenverkehr, Übertragungsrate begrenzt |
– |
Steuern Sie Fläche. Kann in bestimmten 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 einer Reihe von Paketen |
Fehlgeschlagene |
Hervorragend für zeitweiligen Datenverlust |
Externes Gerät mit Sniffer-Software erforderlich Erfordert TCAM-Ressourcen |
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 |
Erfassung von Datenverkehr zur oder von der CPU nur für Broadcom Nexus-Geräte |
Probleme mit Verkehrsflaute, Latenz und Staus |
Hervorragend bei Problemen mit Langsamkeit, Überlastung und Latenz |
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 |
Erfasst ein einzelnes Paket, das den Nexus-Switch erreicht (oder verlässt, wenn Nexus 7000) |
Überprüfen, ob das Paket den Nexus erreicht, Weiterleitungsentscheidungen, Änderungen am Paket, Schnittstelle/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. Perfekt 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 erkennen |
Fehlgeschlagene Pings, Host/Ziel/Internet nicht erreichbar 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 |
Erreichbarkeit zwischen Geräten testen |
Ein schnelles und einfaches Tool zum Testen der Konnektivität |
Identifiziert nur, ob der Host erreichbar ist oder nicht |
– |
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 |
Erfordert TCAM-Ressourcen. Bei einigen Modulen ist eine manuelle TCAM-Partitionierung erforderlich. |
Persistent (auf |
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 |
Globale Speicherung von Verlaufsdaten für den Switch, 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. |
Informationen bleiben beim Neuladen des Geräts erhalten (persistenter Speicher) |
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 |
Speicherung von Verlaufsdaten für ein bestimmtes Modul, z. B. Ausfall- und Umgebungsdaten |
Plötzliches Neuladen/Herunterfahren von Geräten. Bei jedem Neuladen eines Geräts liefern Log-Flash-Daten hilfreiche Informationen. |
Informationen bleiben beim Neuladen des Geräts erhalten (persistenter Speicher) |
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 derzeit ausgeführt wird |
Jeder Prozess im Nexus verfügt über einen eigenen Ereignisverlauf, z. B. 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 |
Für jeden Prozess im Nexus kann eine Fehlersuche durchgeführt werden, z. B. für CDP, STP, OSPF, IGRP, BGP, vPC, LACP usw. |
Fehlerbehebung bei einem bestimmten Prozess auf Nexus in Echtzeit für eine detailliertere Analyse |
Beeinträchtigung der Netzwerkleistung |
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) |
Hardware wie USB, Bootflash, OBFL, ASIC-Speicher, PCIE, Port-Loopback, NVRAM usw. testen |
Erkennen von Fehlern in der Hardware und Durchführen erforderlicher Korrekturmaßnahmen erst ab Version 6(2)8 |
Erkennt nur Hardwareprobleme |
Nicht permanent |
– |
# show diagnostic content module all # show diagnostic description module [#] all testen |
EEM |
Überwachen von Ereignissen auf dem Gerät und Ergreifen der erforderlichen Maßnahmen |
Alle Geräteaktivitäten, die eine Aktion/Problemumgehung/Benachrichtigung erfordern, z. B. Herunterfahren der Schnittstelle, Fehlfunktion des Lüfters, CPU-Nutzung usw. |
Unterstützt Python-Skripte |
Für die Konfiguration von EEM sind Netzwerkadministratorberechtigungen erforderlich. |
EEM-Skript und -Trigger befinden sich in der Konfiguration | – |
Variiert, siehe |
Weitere Informationen zu verschiedenen Befehlen und deren Syntax bzw. Optionen finden Sie unter Cisco Nexus Switches der Serie 9000 - Befehlsreferenzen - Cisco.
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 nur wenige der Nachrichten, die mit Ethanalyzer erfasst werden können.
Hinweis: Standardmäßig erfasst Ethanalyzer nur bis zu 10 Pakete. Sie können diesen Befehl jedoch verwenden, um die CLI aufzufordern, Pakete unbegrenzt zu erfassen. Drücken Sie STRG+C, um den Erfassungsmodus zu beenden.
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:
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]
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), ein 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.
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 über die CLI überprüfen oder die SPAN-Konfigurationsanleitungen für das von Ihnen verwendete Produkt konsultieren.
Hinweis: Jede NX-OS-Version unterscheidet sich hinsichtlich Produkttyp, unterstützter Schnittstellentypen und Funktionalität. Beachten Sie die aktuellen Konfigurationsrichtlinien und -einschränkungen für das Produkt und die Version, die Sie verwenden.
Hier sind die Links für Nexus 9000 bzw. Nexus 7000:
Es gibt verschiedene Arten von SPAN-Sitzungen. Einige der gebräuchlichsten Typen sind hier aufgelistet:
Hinweis: RSPAN wird auf Nexus nicht unterstützt.
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 entspricht dem für SPAN-to-CPU und ist 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 Entscheidung für den Datenbus (DBUS) und eine andere nach der Entscheidung für den Ergebnisbus (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 |
|
Nexus 7K F1-Modul |
|
Nexus 7K F2-Modul |
|
Nexus 7000 F3-Modul |
|
Nexus 7K M-Modul |
|
Nexus 7K M1/M2- und F2-Modul |
|
Nexus 7K M3-Modul |
ELAM für Nexus 7000 - M1/M2 (Eureka-Plattform)
- Überprüfen Sie die Modulnummer mit dem Befehl show module.
- Am Modul durch Hinzufügen von Modul x anhängen, wobei x die Modulnummer ist.
- Überprüfen Sie mit dem Befehl show hardware internal dev-port-map die interne ASIC-Zuordnung, und prü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 xwhere x ist die ASIC-Instanznummer aus und konfigurieren unsere Trigger für DBUS und RBUS. Ü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 seq ; show rbus | i seq. Wenn die Sequenznummer übereinstimmt, können Sie den Inhalt von dbus und rbus anzeigen. Wenn nicht, führen Sie die Erfassung erneut aus, bis Sie dasselbe Paket erfassen können.
Hinweis: Führen Sie ELAM immer mehrmals aus, 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 <ife|ofe> 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 werden, 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)# <layer2/Layer3>
- 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 werden, 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)# <layer2/Layer3>
- 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 diese bewaffnet sind, bevor Sie Datenverkehr senden, und ausgelöst, nachdem Sie sie 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 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 anhängen, 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
Das Nexus 9000 Packet Tracer-Tool kann verwendet werden, um den Pfad des Pakets zu verfolgen, und mit seinen integrierten Zählern für Flussstatistiken ist es ein wertvolles Tool für Szenarien mit vorübergehenden/vollständigen Datenverlusten. Diese Vorgehensweise ist sehr nützlich, wenn die TCAM-Ressourcen für die Ausführung anderer Tools eingeschränkt oder nicht verfügbar sind. 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 <src_ip> dst_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: Packet Tracer Tool - 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
Traceroute wird verwendet, um die verschiedenen Hops zu identifizieren, die ein Paket nimmt, 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 Access Control List (PACL) (Portzugriffskontrollliste): 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 bezeichnet.
- VLAN Access Control List (VACL): Sie können VACLs so konfigurieren, dass sie für alle Pakete gelten, die in oder aus einem VLAN 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 im 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 <Name_of_ACL> 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
Falls ein Benutzer das Gerät neu lädt oder es aufgrund eines Ereignisses plötzlich 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 onboard module x oder hang mod x verwenden; show logging onboard.
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. Verwenden Sie ?, um zu überprüfen, ob verschiedene Optionen unter einem Prozess verfügbar sind.
Nexus93180(config)# show <Process> 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. Verwenden Sie ?, um zu überprüfen, ob unter einem Prozess verschiedene Optionen verfügbar sind.
Nexus93180# debug <Process> ?
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:
- Boot-Up Diagnostics (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 dagegen nicht.
- Laufzeit- oder Integritätsüberwachungsdiagnose: 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 oder eine einfache Benachrichtigung eines SNMP-Servers oder die Anzeige eines CLI-Protokolls usw.
- Action Statements (Aktionshinweise): 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: Hierbei handelt es sich im Grunde um ein Ereignis in Kombination mit einer oder mehreren Action-Anweisungen, die Sie über die CLI oder ein Bash-Skript auf dem Supervisor 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.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
2.0 |
22-Sep-2023 |
Aktualisierte Stilanforderungen und Formatierung. |
1.0 |
29-Aug-2022 |
Erstveröffentlichung |