Commutateurs : Commutateurs Cisco Nexus, s�rie�3500

Procédé de Contrôle de l'état du système de plate-forme de commutateur de gamme 3500 de Nexus

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit le processus général qui est utilisé afin d'exécuter un contrôle d'états du système sur les Plateformes de commutateur de gamme 3500 de Cisco Nexus qui exécutent la version du système d'exploitation de Nexus (NX-OS) 6.0(2). 

Contribué par Yogesh Ramdoss et Matt Blanshard, ingénieurs TAC Cisco.

Surveillez l'utilisation de CPU et mémoire

Afin de recevoir un aperçu de l'utilisation de CPU et mémoire du système, sélectionnez la commande de ressources en show system :

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 au sujet des processus qui consomment des cycles CPU ou la mémoire, sélectionnez les commandes internes d'utilisation de mémoire de noyau de tri et de show system CPU de processus d'exposition :

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#

La sortie prouve que la zone mémoire élevée est utilisée par le NX-OS, et la région de mémoire basse est utilisée par le noyau. Les valeurs de MemTotal et de MemFree fournissent toute la mémoire qui est disponible pour le commutateur.

Afin de générer des alertes d'utilisation de mémoire, configurez le commutateur semblable à ceci :

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

Remarque: Pour ce document, les valeurs 50, 70, et 90 sont utilisées seulement comme exemples ; choisissez les limites de seuil basées sur vos besoins.

État de diagnostics de matériel de contrôle

Afin de vérifier l'état de diagnostics de matériel, écrivez le show diagnostic result toute la commande. Assurez-vous que tous les tests passent, et que le résultat diagnostique global est PASSAGE.

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>

Profil de matériel de vue

Sélectionnez la commande d'état de profil de matériel d'exposition afin de vérifier le profil de matériel en cours qui est configuré sur le commutateur, et l'utilisation de table de matériel :

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 de hôte et de l'Unicast/les entrées correspondance de préfixe la plus longue de Multidiffusion (LPM) sont dans la limite spécifiée.

Remarque: Pour des performances optimales du commutateur, il est important de choisir le modèle approprié de profil de matériel.

Si vous voulez que le commutateur génère un Syslog à un seuil d'avertissement spécifique, configurez le commutateur semblable à ceci :

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

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

Remarque: La valeur seuil par défaut est de 90 pour cent pour l'unicast et la Multidiffusion.

Pour plus de détails, référez-vous à l'article configurant PIM Cisco, qui prévoit des détails de configuration basés sur le permis installé et des caractéristiques activées. Également, si vous voulez optimaliser la table d'expédition, référez-vous aux commutateur de la gamme Cisco Nexus 3000 : Comprenez, configurez et accordez l'article de Cisco de Tableau d'expédition.

Surveillance active de mémoire tampon

La surveillance active de mémoire tampon (ABM) fournit les données granulaires d'occupation de mémoire tampon, qui permettent une meilleure vue dans des points névralgiques d'encombrement. Ce prises en charge de fonctionnalité deux modes de fonctionnement : Mode d'Unicast et de Multidiffusion.

En mode d'Unicast, l'ABM surveille et met à jour les données d'utilisation de mémoire tampon par mémoire-bloc, et l'utilisation de la mémoire tampon d'unicast pour chacun des 48 ports. En mode de Multidiffusion, il surveille et met à jour les données d'utilisation de mémoire tampon par mémoire-bloc, et l'utilisation de la mémoire tampon de Multidiffusion par mémoire-bloc.

Remarque: Le pour en savoir plus, mettent en référence la mémoire tampon d'Active de Cisco Nexus 3548 surveillant l'article de Cisco. La figure 4 de l'article prouve que l'utilisation de mémoire tampon a fait une pointe à 22:15:32 et a duré jusqu'à 22:15:37. En outre, l'histogramme fournit des preuves des pics soudains dans l'utilisation et affiche la vitesse à laquelle la mémoire tampon s'écoule. S'il y a un récepteur lent (tel qu'un récepteur 1-Gbps parmi des récepteurs de 10 Gbits/s), alors afin d'éviter des pertes de paquets, vous devez inclure une configuration semblable à ceci : <x> de port de lent-récepteur de Multidiffusion de profil de matériel.

Compteurs d'interface de surveillance/statistiques

Afin de surveiller la perte du trafic, sélectionnez la commande des Ethernets x/y d'interface d'exposition. La sortie de cette commande fournit les informations de débit de trafic de base, et également des baisses/erreurs 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 écarts d'entrée ou de sortie affichent des valeurs différentes de zéro, déterminez si les paquets lâchés sont monodiffusé et/ou 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#

La sortie indique que le trafic abandonné n'est pas dû au Qualité de service (QoS). Maintenant vous devez vérifier les statistiques d'adresse MAC de matériel :

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

Quand vous exécutez un dépannage pour des baisses du trafic, les options principales de vérifier sont encombrement, erreurs, et qos. L'option de pktflow fournit à des statistiques de trafic dans les directions RX et TX, les plages spécifiques de packet-size.

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 -

Remarque: La valeur hexadécimale 0x3f997 égale 260503 dans le format décimal.

switch# show interface eth1/10
Ethernet1/10 is up
<snip>  0 input with dribble  
260503 input discard
<snip>

Dans la sortie, 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 baisse du trafic est due vu à 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

Remarque: La sortie indique que 6153699 paquets ont été lâchés dans la Recevoir-direction, qui est fallacieuse. Référez-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 qui sont utilisées afin de capturer des pertes de paquets :

  • affichez les Ethernets x/y d'interface
  • Ethernets x/y de show queueing interface
  • affichez à matériel le #> interne de <port de port d'erreurs de MAC de périphérique de statistiques

Surveillez les statistiques de Réglementation du plan de commande

La Réglementation du plan de commande (CoPP) protège l'avion de contrôle afin d'assurer la stabilité du réseau. Pour des détails supplémentaires, mettez en référence l'article configurant de Cisco de Réglementation du plan de commande.

Afin de surveiller les statistiques de CoPP, sélectionnez la commande de contrôle-avion de show policy-map interface :

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 la sortie, les paquets appariés du matériel (HW) et du logiciel (SW) pour le copp-s-ping sont identiques. Ceci signifie que la quantité de paquets qui est comptée par le HW est 30 (tout envoyé vers le gestionnaire intrabande CPU), et le SW compte le même nombre de paquets avant qu'il les envoie à la CPU. Ceci indique qu'aucun paquet n'est lâché par CoPP, parce qu'il est dans la limite configurée de 100 p/s.

Quand vous regardez la classe de copp-s-glaner, qui apparie les paquets qui sont destinés à l'adresse IP pour laquelle l'entrée de cache de Protocole ARP (Address Resolution Protocol) n'est pas présente, le nombre de paquets qui est vu par le HW est 103,088, tandis que les correspondances seulement 51544 de SW. Ceci indique que le CoPP a relâché 51544 paquets (de 103088-51544), parce que le débit de ces paquets dépasse 500 p/s.

Les compteurs de SW sont obtenus du gestionnaire intrabande CPU, et les compteurs HW proviennent la liste de contrôle d'accès (ACL) qui est programmée dans le HW. Si vous rencontrez une situation où les paquets appariés par HW égalent zéro, et une valeur différente de zéro est présent pour les paquets appariés par SW, alors aucun ACL n'est présent dans le HW pour ce class-map spécifique, qui peut être normal. Il est également important de noter que ces deux compteurs ne pourraient pas être votés en même temps, et vous devriez seulement utiliser le troubelshoot de valeurs du compteur si la différence est significative.

Les statistiques de CoPP ne pourraient pas être directement liées aux paquets HW-commutés, mais il est encore approprié si les paquets qui devraient être envoyés par le commutateur sont donnés un coup de volée à la CPU. Un paquet-coup de volée est provoqué par par de diverses raisons, comme quand vous exécutez une contiguïté de glaner.

Rendez-vous compte qu'il y a trois types de stratégies de CoPP : Par défaut, couche 2 (L2), et couche 3 (L3). Choisissez la stratégie appropriée basée sur le scénario de déploiement, et modifiez la stratégie de CoPP basée sur les observations. Afin de régler avec précision le CoPP, vérifiez régulièrement, et contrôle après que vous obteniez de nouveaux services/applications ou après qu'une reconception de réseau.

Remarque: Afin d'effacer les compteurs, sélectionnez la commande de clear copp statistics.

Exécutez la vérification de l'intégrité de système de fichiers de Bootflash

Afin d'exécuter une vérification de l'intégrité sur le système de fichiers de bootflash, sélectionnez la commande de bootflash de contrôle d'états du système :

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 non monté quand vous exécutez le test, et il est remonté sur une fois que le test est complet. Assurez-vous que le système de fichiers n'est pas accédé à tandis que vous exécutez le test.

Collectez le system cores et les logs de processus

Attention : Assurez-vous que le système n'éprouve aucunes remises ou crash de processus, et ne générez aucuns fichiers image mémoire ou log de processus quand vous tentez d'utiliser les commandes qui sont mentionnées dans cette section.

Sélectionnez ces commandes afin de collecter le system cores et les logs 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

Remarque: Mettez en référence les fichiers image mémoire récupérants de Cisco Nexus commutant l'article de Cisco de Plateformes pour plus de détails au sujet de ce processus.

Informations connexes


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 116699