Processus de contrôle d'intégrité du système de la plate-forme de commutation Nexus 3500

Introduction

Ce document décrit le processus général utilisé pour effectuer une vérification de l'état du système sur les plates-formes de commutation Cisco Nexus 3500 qui exécutent Nexus Operating System (NX-OS) version 6.0(2).

Surveiller l'utilisation du processeur et de la mémoire

Afin de recevoir une vue d'ensemble de l'utilisation du processeur et de la mémoire du système, entrez la commande show system resources :

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#

Si vous avez besoin de plus de détails sur les processus qui consomment des cycles CPU ou de la mémoire, entrez les commandes show process cpu sort et show system internal kernel usage :

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#

Le résultat montre que la région Haute mémoire est utilisée par le NX-OS, et la région Faible mémoire est utilisée par le noyau. Les valeurs MemTotal et MemFree fournissent la mémoire totale disponible pour le commutateur.

Afin de générer des alertes d'utilisation de la mémoire, configurez le commutateur comme suit :

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

Note: Pour le présent document, les valeurs 50, 70 et 90 ne sont utilisées que comme exemples ; choisissez des seuils en fonction de vos besoins.

Vérifier l'état des diagnostics matériels

Afin de vérifier l'état des diagnostics matériels, entrez la commande show diagnostic result all. Assurez-vous que tous les tests réussissent et que le résultat de diagnostic global est PASS.

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>

Afficher le profil matériel

Entrez la commande show hardware profile status afin de vérifier le profil matériel actuel configuré sur le commutateur et l'utilisation de la table matérielle :

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#

Assurez-vous que l'utilisation des entrées d'hôte et des entrées LPM (Plus Long Prefix Match) Unicast/Multicast se situe dans la limite spécifiée.

Note: Pour optimiser les performances du commutateur, il est important de choisir le modèle de profil matériel approprié.

Si vous voulez que le commutateur génère un syslog à un niveau de seuil spécifique, configurez le commutateur de la même manière que ceci :

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

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

Note: La valeur de seuil par défaut est de 90 % pour la monodiffusion et la multidiffusion.

Pour plus de détails, reportez-vous à l'article Configuration de PIM Cisco, qui fournit des détails de configuration basés sur la licence installée et les fonctionnalités activées. En outre, si vous souhaitez optimiser la table de transfert, reportez-vous aux commutateurs Cisco Nexus 3000 : Comprendre, configurer et ajuster l'article Cisco de la table de transfert.

Surveillance de tampon active

La surveillance active de la mémoire tampon (ABM) fournit des données granulaires sur l'occupation de la mémoire tampon, ce qui permet de mieux comprendre les points chauds de congestion. Cette fonctionnalité prend en charge deux modes de fonctionnement : Mode monodiffusion et multidiffusion.

En mode monodiffusion, ABM surveille et gère les données d'utilisation de la mémoire tampon par bloc de mémoire tampon, ainsi que l'utilisation de la mémoire tampon de monodiffusion pour les 48 ports. En mode multidiffusion, il surveille et gère les données d'utilisation de la mémoire tampon par bloc de mémoire tampon et l'utilisation de la mémoire tampon multidiffusion par bloc de mémoire tampon.

Note: Pour plus d'informations, reportez-vous à l'article Cisco Surveillance active de la mémoire tampon du Cisco Nexus 3548. La figure 4 de l'article montre que l'utilisation de la mémoire tampon a atteint son maximum à 22:15:32 et a duré jusqu'à 22:15:37. De plus, l'histogramme fournit une preuve de pointes soudaines dans l'utilisation et montre la vitesse à laquelle la mémoire tampon draine. S'il existe un récepteur lent (tel qu'un récepteur 1 Gbit/s parmi les récepteurs 10 Gbit/s), afin d'éviter les pertes de paquets, vous devez inclure une configuration similaire à celle-ci : port récepteur lent multidiffusion de profil matériel <x>.

Statistiques/compteurs d'interface de surveillance

Afin de surveiller la perte de trafic, entrez la commande show interface ethernet x/y. Le résultat de cette commande fournit des informations de base sur le débit de trafic, ainsi que des pertes/erreurs au niveau du port.

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#

Si les valeurs d'entrée ou de sortie rejetées ne sont pas nulles, déterminez si les paquets abandonnés sont de monodiffusion et/ou de multidiffusion :

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#

Le résultat indique que le trafic abandonné n'est pas dû à la qualité de service (QoS). Vous devez maintenant vérifier les statistiques d'adresse MAC matérielle :

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

Lorsque vous effectuez un dépannage pour les pertes de trafic, les options clés à vérifier sont la congestion, les erreurs et la qos. L'option pktflow fournit des statistiques de trafic dans les directions RX et TX, avec des plages de taille de paquet spécifiques.

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 -

Note: La valeur hexadécimale 0x3f997 est 260503 au format décimal.

switch# show interface eth1/10

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

   

Dans le résultat, le message d'erreur PORT_EXCEPTION_ICBL_PKT_DROP indique que le trafic reçu sur le port a une balise Dot1Q pour un VLAN qui n'est pas activé sur le commutateur.

Voici un autre exemple, où la perte de trafic est vue en raison de la QoS :

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

Note: Le résultat indique que 6153699 paquets ont été abandonnés dans la direction de réception, ce qui est trompeur. Reportez-vous à l'ID de bogue Cisco 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>

En résumé, voici les commandes utilisées pour capturer les pertes de paquets :

• show interface ethernet x/y
• show queuing interface ethernet x/y
• show hardware internal statistics périphérique mac errors port <port #>
  

Statistiques de contrôle du plan de contrôle de surveillance

La fonction CoPP (Control Plane Policing) protège le plan de contrôle afin d'assurer la stabilité du réseau. Pour plus de détails, reportez-vous à l'article Cisco Configuration de la réglementation du plan de contrôle.

Afin de surveiller les statistiques CoPP, entrez la commande show policy-map interface control-plane :

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>

Dans le résultat, les paquets correspondants Matériel (matériel) et Logiciel (logiciel) pour copp-s-ping sont identiques. Cela signifie que la quantité de paquets qui est comptée par le matériel est de 30 (tous envoyés vers le pilote de CPU intrabande), et le logiciel compte le même nombre de paquets avant de les envoyer au processeur. Cela indique qu'aucun paquet n'est abandonné par CoPP, car il se trouve dans la limite configurée de 100 p/s.

Lorsque vous regardez la classe copp-s-glean, qui correspond aux paquets destinés à l'adresse IP pour laquelle l'entrée de cache ARP (Address Resolution Protocol) n'est pas présente, le nombre de paquets qui est vu par le matériel est 103 088, alors que le logiciel ne correspond qu'à 5144 . Cela indique que la CoPP a abandonné 51544 (103088-51544) paquets, car le débit de ces paquets dépasse 500 p/s.

Les compteurs logiciels sont obtenus à partir du pilote d'entrée de bande du processeur et les compteurs matériels proviennent de la liste de contrôle d'accès (ACL) qui est programmée dans le matériel. Si vous rencontrez une situation où les paquets correspondants matériels sont égaux à zéro et qu'une valeur non nulle est présente pour les paquets correspondants logiciels, alors aucune liste de contrôle d'accès n'est présente dans le matériel pour cette carte de classe spécifique, ce qui peut être normal. Il est également important de noter que ces deux compteurs peuvent ne pas être interrogés en même temps, et vous ne devriez utiliser les valeurs de compteur que pour déchiffrer si la différence est significative.

Les statistiques CoPP ne sont peut-être pas directement liées aux paquets commutés sur matériel, mais elles restent pertinentes si les paquets qui doivent être envoyés par le biais du commutateur sont punis sur le processeur. Un paquet-punt est causé par diverses raisons, par exemple lorsque vous exécutez une contiguïté en étoile.

Sachez qu'il existe trois types de politiques CoPP : Par défaut, couche 2 (L2) et couche 3 (L3). Choisissez la stratégie appropriée en fonction du scénario de déploiement et modifiez la stratégie CoPP en fonction des observations. Pour affiner le CoPP, vérifiez régulièrement et vérifiez après avoir obtenu de nouveaux services/applications ou après une reconception du réseau.

Note: Afin d'effacer les compteurs, entrez la commande clear copp statistics.

Vérification de l'intégrité du système de fichiers Bootflash

Afin d'effectuer une vérification d'intégrité sur le système de fichiers bootflash, entrez la commande system health check bootflash :

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#

Attention : Le système de fichiers est démonté lorsque vous exécutez le test et il est remonté une fois le test terminé. Assurez-vous que le système de fichiers n'est pas accessible pendant l'exécution du test.

Collecter les coeurs système et les journaux de processus

Attention : Assurez-vous que le système ne connaît aucune réinitialisation ou panne de processus et ne génère aucun fichier principal ou journal de processus lorsque vous essayez d'utiliser les commandes mentionnées dans cette section.

Entrez ces commandes afin de collecter les coeurs système et les journaux de processus :

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

Note: Reportez-vous à l'article Récupération des fichiers principaux des plates-formes de commutation Cisco Nexus pour plus d'informations sur ce processus.

Informations connexes

• Fiches techniques et documentation - Commutateurs Cisco Nexus 3000
• Comparer les modèles - Commutateurs Cisco Nexus 3000
• Introduction - Commutateurs Cisco Nexus 3000
• Présentation “ compteur d'interface de ” d'abandon d'entrée dans Nexus3000 - Communautés d'assistance Cisco
• Support et documentation techniques - Cisco Systems