Systemstatusprüfung für Nexus Switches der Serie 3500

Einführung

Dieses Dokument beschreibt den allgemeinen Prozess für die Durchführung einer Systemstatusprüfung auf Cisco Nexus Switches der Serie 3500, auf denen Nexus Operating System (NX-OS), Version 6.0(2), ausgeführt wird.

Überwachung der CPU- und Arbeitsspeichernutzung

Geben Sie den Befehl show system resources ein, um eine Übersicht über die CPU- und Speichernutzung des Systems zu erhalten:

switch# show system resources 

Load average:   1 minute: 0.32   5 minutes: 0.13   15 minutes: 0.10
Processes   :   366 total, 2 running
CPU states  :   5.5% user,   12.0% kernel,   82.5% idle
        CPU0 states  :   10.0% user,   18.0% kernel,   72.0% idle
        CPU1 states  :   1.0% user,   6.0% kernel,   93.0% idle
Memory usage:   4117064K total,   2614356K used,   1502708K free
Switch#

Wenn Sie weitere Details über die Prozesse benötigen, die CPU-Zyklen oder Arbeitsspeicher benötigen, geben Sie den show process cpu sort ein und zeigen Sie die Befehle für die interne Kernel-Speichernutzung an:

switch# show process cpu sort
PID    Runtime(ms)  Invoked   uSecs  1Sec    Process
-----  -----------  --------  -----  ------  -----------
 3239     55236684  24663045   2239    6.3%  mtc_usd
 3376          776      7007    110    2.7%  netstack
   15     26592500 178719270    148    0.9%  kacpid
 3441      4173060  29561656    141    0.9%  cfs
 3445      7646439   6391217   1196    0.9%  lacp
 3507     13646757  34821232    391    0.9%  hsrp_engine
    1        80564    596043    135    0.0%  init
    2            6       302     20    0.0%  kthreadd
    3         1064    110904      9    0.0%  migration/0
<snip>

switch# show system internal kernel memory usage 
MemTotal:      4117064 kB
MemFree:       1490120 kB
Buffers:           332 kB
Cached:        1437168 kB
ShmFS:         1432684 kB
Allowed:       1029266 Pages
Free:           372530 Pages
Available:      375551 Pages
SwapCached:          0 kB
Active:        1355724 kB
Inactive:       925400 kB
HighTotal:     2394400 kB
HighFree:       135804 kB
LowTotal:      1722664 kB
LowFree:       1354316 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:              12 kB
Writeback:           0 kB
AnonPages:      843624 kB
Mapped:         211144 kB
Slab:            98524 kB
SReclaimable:     7268 kB
SUnreclaim:      91256 kB
PageTables:      19604 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:   2058532 kB
Committed_AS: 10544480 kB
VmallocTotal:   284664 kB
VmallocUsed:    174444 kB
VmallocChunk:   108732 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     2048 kB
DirectMap4k:      2048 kB
DirectMap2M:   1787904 kB
switch#

Die Ausgabe zeigt, dass der High-Memory-Bereich von NX-OS verwendet wird und der Low Memory-Bereich vom Kernel verwendet wird. Die Werte MemTotal und MemFree stellen den gesamten für den Switch verfügbaren Speicher bereit.

Um Warnungen zur Speichernutzung zu generieren, konfigurieren Sie den Switch wie folgt:

switch(config)# system memory-thresholds minor 50 severe 70 critical 90

Hinweis: Für dieses Dokument werden die Werte 50, 70 und 90 nur als Beispiele verwendet. Wählen Sie Grenzwertgrenzen entsprechend Ihren Anforderungen aus.

Überprüfen Sie den Hardwarediagnosestatus.

Um den Hardwarediagnosestatus zu überprüfen, geben Sie den Befehl show diagnose result all ein. Stellen Sie sicher, dass alle Tests erfolgreich sind und das Gesamtdiagnoseergebnis PASS ist.

switch# show diagnostic result all 

Current bootup diagnostic level: complete
Module 1: 48x10GE Supervisor  SerialNo : <serial #>
  Overall Diagnostic Result for Module 1 : PASS
  Diagnostic level at card bootup: complete

  Test results: (. = Pass, F = Fail, I = Incomplete, U = Untested, A = Abort)

     1) TestUSBFlash ------------------------> .
     2) TestSPROM ---------------------------> .
     3) TestPCIe ----------------------------> .
     4) TestLED -----------------------------> .
     5) TestOBFL ----------------------------> .
     6) TestNVRAM ---------------------------> .
     7) TestPowerSupply ---------------------> .
     8) TestTemperatureSensor ---------------> .
     9) TestFan -----------------------------> .
    10) TestVoltage -------------------------> .
    11) TestGPIO ----------------------------> .
    12) TestInbandPort ----------------------> .
    13) TestManagementPort ------------------> .
    14) TestMemory --------------------------> .
    15) TestForwardingEngine ----------------> .
<snip>

Hardwareprofil anzeigen

Geben Sie den Befehl show hardware profile status ein, um das aktuelle Hardwareprofil, das auf dem Switch konfiguriert ist, und die Verwendung der Hardwaretabelle zu überprüfen:

switch# show hardware profile status 
 Hardware table usage:
Max Host Entries = 65535, Used = 341
Max Unicast LPM Entries = 24576, Used = 92
Max Multicast LPM Entries = 8192, Used (L2:L3) = 1836 (1:1835)
Switch#

Stellen Sie sicher, dass die Verwendung der Hosteinträge und Unicast/Multicast Longest Prefix Match (LPM)-Einträge innerhalb der angegebenen Grenze liegt.

Hinweis: Für eine optimale Leistung des Switches ist es wichtig, die richtige Hardwareprofilvorlage auszuwählen.

Wenn Sie möchten, dass der Switch ein Syslog auf einer bestimmten Schwellenwertebene generiert, konfigurieren Sie den Switch ähnlich wie folgt:

switch(config)# hardware profile multicast syslog-threshold ?
  <1-100>  Percentage

switch(config)# hardware profile unicast syslog-threshold ?
  <1-100>  Percentage

Hinweis: Der Standardwert für den Grenzwert beträgt 90 Prozent für Unicast und Multicast.

Weitere Informationen finden Sie im Artikel Configuring PIM Cisco (Konfiguration von PIM), der Konfigurationsdetails basierend auf der installierten Lizenz und den aktivierten Funktionen enthält. Wenn Sie die Weiterleitungstabelle optimieren möchten, verwenden Sie die Cisco Nexus Switches der Serie 3000: Cisco Artikel zur Weiterleitungstabelle verstehen, konfigurieren und anpassen.

Aktive Puffer-Überwachung

Active Buffer Monitoring (ABM) stellt präzise Pufferbelegungsdaten bereit, die einen besseren Einblick in überlastete Bereiche ermöglichen. Diese Funktion unterstützt zwei Betriebsmodi: Unicast- und Multicast-Modus.

Im Unicast-Modus überwacht und verwaltet der ABM die Puffer-Nutzungsdaten pro Pufferblock und die Unicast-Puffer-Nutzung für alle 48 Ports. Im Multicast-Modus überwacht und verwaltet es die Puffernutzungsdaten pro Pufferblock und die Multicast-Puffer-Auslastung pro Pufferblock.

Hinweis: Weitere Informationen finden Sie im Artikel Cisco Nexus 3548 Active Buffer Monitoring Cisco. Abbildung 4 des Artikels zeigt, dass die Puffernutzung um 22:15:32 ihren Höhepunkt erreichte und bis 22:15:37 Uhr anhielt. Außerdem zeigt das Histogramm plötzliche Spitzen bei der Nutzung und die Geschwindigkeit, mit der der Puffer abfließt. Wenn ein langsamer Empfänger vorhanden ist (z. B. ein 1-Gbit/s-Empfänger unter 10-Gbit/s-Empfängern), müssen Sie zur Vermeidung von Paketverlusten eine ähnliche Konfiguration verwenden: Hardwareprofil-Multicast-Slow-Receiver-Port <x>.

Überwachen von Schnittstellenzählern/Statistiken

Um Datenverkehrsverluste zu überwachen, geben Sie den Befehl show interface ethernet x/y ein. Die Ausgabe dieses Befehls enthält grundlegende Informationen zur Datenverkehrsrate sowie Verwerfungen/Fehler auf Portebene.

switch# show interface eth1/10
Ethernet1/10 is up
 Dedicated Interface 
  Belongs to Po1
  Hardware: 100/1000/10000 Ethernet, address: 30f7.0d9c.3b51
  (bia 30f7.0d9c.3b51)
  MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA
  Port mode is trunk
  full-duplex, 10 Gb/s, media type is 10G
  Beacon is turned off
  Input flow-control is off, output flow-control is off
  Rate mode is dedicated
  Switchport monitor is off 
  EtherType is 0x8100 
  Last link flapped 3d21h
  Last clearing of "show interface" counters never
  14766 interface resets
  30 seconds input rate 47240 bits/sec, 68 packets/sec
  30 seconds output rate 3120720 bits/sec, 3069 packets/sec
  Load-Interval #2: 5 minute (300 seconds)
    input rate 50.18 Kbps, 52 pps; output rate 3.12 Mbps, 3.05 Kpps
  RX
    4485822 unicast packets  175312538 multicast packets  388443 broadcast
    packets
    180186040 input packets  9575683853 bytes
    0 jumbo packets  0 storm suppression bytes
    1 runts  0 giants  1 CRC  0 no buffer
    2 input error  0 short frame  0 overrun   0 underrun  0 ignored
    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
    0 input with dribble  260503 input discard
    0 Rx pause
  TX
    159370439 unicast packets  6366799906 multicast packets  1111 broadcast
    packets
    6526171456 output packets  828646014117 bytes
    0 jumbo packets
    0 output errors  0 collision  0 deferred  0 late collision
    0 lost carrier  0 no carrier  0 babble 0 output discard
    0 Tx pause

switch#

Wenn die Ein- oder Ausgabedateien Nicht-Nullwerte anzeigen, stellen Sie fest, ob es sich bei den verworfenen Paketen um Unicast- und/oder Multicast-Werte handelt:

switch# show queuing interface ethernet 1/10
Ethernet1/10 queuing information:
  TX Queuing
    qos-group  sched-type  oper-bandwidth
        0       WRR            100

  RX Queuing
    Multicast statistics:
        Mcast pkts dropped                      : 0
    Unicast statistics:
    qos-group 0
    HW MTU: 1500 (1500 configured)
    drop-type: drop, xon: 0, xoff: 0
    Statistics:
        Ucast pkts dropped                      : 0
switch#

Die Ausgabe zeigt an, dass der blockierte Datenverkehr nicht auf Quality of Service (QoS) zurückzuführen ist. Jetzt müssen Sie die Hardware-MAC-Adressstatistiken überprüfen:

switch# show hardware internal statistics device mac ?
  all         Show all stats
  congestion  Show congestion stats
  control     Show control stats
  errors      Show error stats
  lookup      Show lookup stats
  pktflow     Show packetflow stats
 qos         Show qos stats
  rates       Show packetflow stats
  snmp        Show snmp stats

Wenn Sie eine Fehlerbehebung bei Verwerfen von Datenverkehr durchführen, sind die wichtigsten Überprüfungsoptionen Überlastung, Fehler und QoS. Die pktflow-Option stellt Datenverkehrsstatistiken in der RX- und TX-Richtung mit spezifischen Paketgrößenbereichen bereit.

switch# show hardware internal statistics device mac errors port 10
|------------------------------------------------------------------------|
| Device: L2/L3 forwarding ASIC   Role:MAC                               |
|------------------------------------------------------------------------|
Instance:0
ID   Name                                          Value              Ports
--   ----                                          -----              -----
198  MTC_MB_CRC_ERR_CNT_PORT9                      0000000000000002   10 -
508  MTC_PP_CNT_PORT1_RCODE_CHAIN3                 0000000000000002   10 -
526  MTC_RW_EG_PORT1_EG_CLB_DROP_FCNT_CHAIN3       000000000054da5a   10 -
3616 MTC_NI515_P1_CNT_TX                           0000000000000bed   10 -
6495 TTOT_OCT                                      000000000005f341   10 -
7365 RTOT                                          0000000000000034   10 -
7366 RCRC                                          0000000000000001   10 -
7374 RUNT                                          0000000000000001   10 -
9511 ROCT                                          00000000000018b9   10 -
10678 PORT_EXCEPTION_ICBL_PKT_DROP                 000000000003f997   10 -

Hinweis: Der Hexadezimalwert 0x3f997 entspricht 260503 im Dezimalformat.

switch# show interface eth1/10

Ethernet1/10 is up
<snip>  0 input with dribble  
260503 input discard
<snip>

   

In der Ausgabe gibt die Fehlermeldung PORT_EXCEPTION_ICBL_PKT_DROP an, dass der auf dem Port empfangene Datenverkehr ein Dot1Q-Tag für ein VLAN hat, das auf dem Switch nicht aktiviert ist.

Hier ist ein weiteres Beispiel, bei dem der Datenverkehr aufgrund von QoS abnimmt:

switch# show interface ethernet 1/11

Ethernet1/11 is up
<snip>
  TX

<snip>
    0 output errors  0 collision  0 deferred  0 late collision
    0 lost carrier  0 no carrier  0 babble 6153699 output discard
    0 Tx pause
switch#

switch# show queuing interface ethernet 1/11

Ethernet1/11 queuing information:
  TX Queuing
    qos-group  sched-type  oper-bandwidth
        0       WRR            100

  RX Queuing
    Multicast statistics:
        Mcast pkts dropped                      : 0
    Unicast statistics:
    qos-group 0
    HW MTU: 1500 (1500 configured)
    drop-type: drop, xon: 0, xoff: 0
    Statistics:
        Ucast pkts dropped                      : 6153699

Hinweis: Die Ausgabe gibt an, dass 6153699 Pakete in Empfangsrichtung verworfen wurden, was irreführend ist. Weitere Informationen finden Sie unter Cisco Bug ID CSCuj20713.

switch# show hardware internal statistics device mac all | i 11|Port

(result filtered for relevant port)
ID   Name           Value              Ports
<snip>
5596 TX_DROP        00000000005de5e3   11 -  <--- 6153699 Tx Drops in Hex
<snip>
10253 UC_DROP_VL0   00000000005de5e3   11 -  <--- Drops for QoS Group 0 in Hex
<snip>

Zusammenfassend sind hier die Befehle aufgeführt, die zur Erfassung von Paketverlusten verwendet werden:

• show interface ethernet x/y
• show queuing interface ethernet x/y
• show hardware internal statistics device maerrors port <port #>
  

Überwachung von Control Plane Policing-Statistiken

Control Plane Policing (CoPP) schützt die Kontrollebene, um die Netzwerkstabilität zu gewährleisten. Weitere Informationen finden Sie im Artikel Configuring Control Plane Policing Cisco.

Um die CoPP-Statistiken zu überwachen, geben Sie den Befehl show policy-map interface control-plane ein:

switch# show policy-map interface control-plane 

Control Plane
  service-policy  input: copp-system-policy

    class-map copp-s-ping (match-any)
      match access-group name copp-system-acl-ping
      police pps 100 , bc 0 packets
        HW Matched Packets   30
        SW Matched Packets   30
    class-map copp-s-l3destmiss (match-any)
      police pps 100 , bc 0 packets
        HW Matched Packets   76
        SW Matched Packets   74
    class-map copp-s-glean (match-any)
      police pps 500 , bc 0 packets
        HW Matched Packets   103088
        SW Matched Packets   51544
<snip>

In der Ausgabe sind die Hardware (HW) und die Software (SW) Übereinstimmte Pakete für copp-s-ping identisch. Dies bedeutet, dass die Anzahl der Pakete, die von der HW gezählt werden, 30 beträgt (alle an den In-Band-CPU-Treiber gesendet) und dass die SW die gleiche Anzahl von Paketen zählt, bevor sie an die CPU gesendet werden. Dies weist darauf hin, dass keine Pakete von CoPP verworfen werden, da sie innerhalb der konfigurierten Obergrenze von 100 Po/s liegen.

Wenn Sie sich die copp-s-glean-Klasse anschauen, die den Paketen entspricht, die für die IP-Adresse bestimmt sind, für die der Eintrag im Address Resolution Protocol (ARP)-Cache nicht vorhanden ist, dann beträgt die Anzahl der Pakete, die von der HW angezeigt werden, 103.0888, während die SW nur entspricht 4. Dies weist darauf hin, dass die CoPP-Pakete 51544 (103088-51544) verworfen haben, da die Rate dieser Pakete 500 Ps/s überschreitet.

Die SW-Zähler werden vom CPU-In-Band-Treiber abgerufen, und die HW-Zähler stammen von der Zugriffskontrollliste (ACL), die in der HW programmiert ist. Wenn die HW-Matched Packets 0 (null) sind und für die SW Matched Packets ein Wert von 0 (null) vorhanden ist, ist in der HW für diese spezielle Klassenzuordnung keine ACL vorhanden, was normal sein kann. Beachten Sie auch, dass diese beiden Zähler möglicherweise nicht gleichzeitig abgefragt werden, und Sie sollten nur die Zählerwerte verwenden, um Fehler zu beheben, wenn der Unterschied signifikant ist.

Die CoPP-Statistiken stehen möglicherweise nicht direkt in Zusammenhang mit HW-Switched-Paketen, sind aber dennoch relevant, wenn die Pakete, die über den Switch gesendet werden sollen, an die CPU übertragen werden. Ein Paketpunt wird aus verschiedenen Gründen verursacht, z. B. beim Ausführen einer glean Adjacency.

Beachten Sie, dass es drei Arten von CoPP-Richtlinien gibt: Standard, Layer 2 (L2) und Layer 3 (L3). Wählen Sie die entsprechende Richtlinie basierend auf dem Bereitstellungsszenario aus, und ändern Sie die CoPP-Richtlinie auf der Grundlage der Beobachtungen. Um die CoPP-Funktion zu optimieren, sollten Sie regelmäßig nachfragen und überprüfen, ob Sie neue Services/Anwendungen oder eine Netzwerkumgestaltung erhalten haben.

Hinweis: Um die Zähler zu löschen, geben Sie den Befehl clear copp statistics ein.

Durchführen einer Systemstatusüberprüfung für Bootflash-Dateien

Um eine Statusprüfung auf dem Bootflash-Dateisystem durchzuführen, geben Sie den Bootflash-Befehl Systemstatusprüfung ein:

switch# system health check bootflash 
Unmount successful...
Checking any file system errors...Please be patient...
Result: bootflash filesystem has no errors
done.
Remounting bootflash ...done.
switch#

Vorsicht: Das Dateisystem wird beim Ausführen des Tests entfernt und nach Abschluss des Tests entfernt. Stellen Sie sicher, dass während der Ausführung des Tests nicht auf das Dateisystem zugegriffen wird.

Sammeln von Systemkernen und Verarbeitungsprotokollen

Vorsicht: Stellen Sie sicher, dass das System keine Prozess-Resets oder -Abstürze erlebt und keine Kerndateien oder Prozessprotokolle generiert, wenn Sie versuchen, die in diesem Abschnitt erwähnten Befehle zu verwenden.

Geben Sie die folgenden Befehle ein, um die Systemkerne zu erfassen und Protokolle zu verarbeiten:

switch# show cores

Module  Instance  Process-name     PID       Date(Year-Month-Day Time)
------  --------  ---------------  --------  -------------------------
switch# 

switch# show process log
Process          PID     Normal-exit  Stack  Core   Log-create-time
---------------  ------  -----------  -----  -----  ---------------
ethpc            4217              N      N      N  Tue Jun  4 01:57:54 2013

Hinweis: Weitere Informationen zu diesem Prozess finden Sie im Cisco Artikel Retrieving Core Files from Cisco Nexus Switching-Plattformen.

Zugehörige Informationen

• Datenblätter und Literatur - Cisco Nexus Switches der Serie 3000
• Modelle vergleichen - Cisco Nexus Switches der Serie 3000
• Einführung - Cisco Nexus Switches der Serie 3000
• Funktionsweise der Schnittstellenanzeige "Input Discard" in Nexus 3000 - Cisco Support Communities
• Technischer Support und Dokumentation - Cisco Systems