Switches : Cisco Nexus 3500 Series Switches

Proceso del control de Estados generales del sistema de la plataforma del 3500 Series Switch del nexo

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe el proceso general que se utiliza para realizar un control de Estados generales del sistema en las Plataformas del 3500 Series Switch del nexo de Cisco que funcionan con la versión del sistema operativo del nexo (NX-OS) 6.0(2). 

Contribuido por Yogesh Ramdoss y Matt Blanshard, ingenieros de Cisco TAC.

Monitor CPU y uso de la memoria

Para recibir una descripción del CPU y el uso de la memoria del sistema, ingrese el comando de los recursos del sistema de la demostración:

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 usted requiere más detalles sobre los procesos que consumen los ciclos de la CPU o la memoria, ingrese la clase CPU del proceso de la demostración y muestre a sistema los comandos usage de la memoria núcleo interna:

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 salida muestra que la región de memoria alta es utilizada por el NX-OS, y la región de memoria baja es utilizada por el corazón. Los valores de MemTotal y de MemFree proporcionan la memoria total que está disponible para el Switch.

Para generar las alertas del uso de la memoria, configure el Switch similar a esto:

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

Nota: Para este documento, los valores 50, 70, y 90 se utilizan solamente como ejemplos; elija los límites de umbral basados en sus necesidades.

Marque el estatus de los diagnósticos del hardware

Para marcar el estatus de los diagnósticos del hardware, ingrese el comando all del resultado del diagnóstico de la demostración. Asegúrese de que todas las pruebas pasen, y de que el resultado del diagnóstico total es PASO.

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>

Vea el perfil del hardware

Ingrese el comando status del perfil del hardware de la demostración para marcar el perfil del hardware actual que se configura en el Switch, y el uso de la tabla del hardware:

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#

Asegúrese de que el uso de las entradas de host y el unicast/las entradas de las coincidencias con el prefijo de máxima longitud del Multicast (LPM) estén dentro del límite especificado.

Nota: Para el rendimiento óptimo del Switch, es importante elegir la plantilla apropiada del perfil del hardware.

Si usted quisiera que el Switch generara un Syslog en un límite de umbral específico, configure el Switch similar a esto:

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

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

Nota: El valor de umbral predeterminado es el 90 por ciento para el unicast y el Multicast.

Para más detalles, refiera al artículo PIM que configura Cisco, que proporciona los detalles de la configuración basados en la licencia instalada y las características habilitadas. También, si usted quiere optimizar la tabla de reenvío, refiera a los 3000 Series Switch del nexo de Cisco: Entienda, configure y ajuste el artículo de Cisco de la tabla de reenvío.

Supervisión activa del buffer

La supervisión activa del buffer (ABM) proporciona los datos granulares de la ocupación del buffer, que permite una mejor penetración en los hotspots de la congestión. Este soportes de característica dos modos de operación: Unicast y modo de multidifusión.

En el modo unidifusión, el ABM monitorea y mantiene los datos del uso de búfer por el buffer-bloque, y la utilización del almacén intermedio del unicast para los 48 puertos. En el modo de multidifusión, monitorea y mantiene los datos del uso de búfer por el buffer-bloque, y la utilización del almacén intermedio del Multicast por el buffer-bloque.

Nota: Para más información, refiérase al buffer activo del nexo 3548 de Cisco que monitorea el artículo de Cisco. El cuadro 4 del artículo muestra que el uso de búfer enarboló en 22:15:32 y duró hasta 22:15:37. También, el histograma proporciona las pruebas de los puntos súbitos en el uso y muestra la velocidad a la cual el buffer drena. Si hay un receptor lento (tal como un receptor 1-Gbps entre los receptores 10-Gbps), después para evitar las caídas de paquetes, usted debe incluir una configuración similar a esto: <x> del puerto del lento-receptor del Multicast del perfil del hardware.

Contadores de la interfaz/estadísticas del monitor

Para monitorear la pérdida de tráfico, ingrese el comando del x/y de las interfaces Ethernet de la demostración. La salida de este comando proporciona la información de relaciones del tráfico básica, y también los descensos del nivel de Puerto/los errores.

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 los descartes de la entrada de información o de la salida muestran los valores sin cero, determine si los paquetes perdidos son unicast y/o Multicast:

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 salida indica que el tráfico interrumpido no es debido al Calidad de Servicio (QoS). Ahora usted debe marcar las estadísticas del MAC Address de hardware:

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

Cuando usted realiza un Troubleshooting para los descensos del tráfico, las opciones dominantes a marcar son congestión, errores, y qos. La opción del pktflow proporciona las estadísticas de tráfico en las direcciones RX y TX, con los rangos específicos del tamaño de paquetes.

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 -

Nota: El valor hexadecimal 0x3f997 iguala 260503 en el formato decimal.

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

En la salida, el mensaje de error PORT_EXCEPTION_ICBL_PKT_DROP indica que el tráfico recibido en el puerto tiene una etiqueta del dot1q para un VLA N que no se habilite en el Switch.

Aquí está otro ejemplo, donde está el descenso del tráfico considerado debido a 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

Nota: La salida indica que 6153699 paquetes fueron caídos en la dirección receptora, que es engañosa. Refiera al Id. de bug 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 resumen, aquí están los comandos que se utilizan para capturar las caídas de paquetes:

  • muestre el x/y de las interfaces Ethernet
  • muestre el x/y de los Ethernetes de la interfaz para colocación en cola
  • muestre que los errores MAC del dispositivo de las estadísticas internas del hardware vira hacia el lado de babor <port->

Monitoree las estadísticas de las Políticas del plano de control

Las Políticas del plano de control (CoPP) protegen el avión del control para asegurar la estabilidad de la red. Para los detalles adicionales, refiérase al artículo de Cisco de las Políticas del plano de control que configura.

Para monitorear las estadísticas de CoPP, ingrese el comando de la controle de plano del 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>

En la salida, los paquetes coincidentes del soporte físico (HW) y del software (SW) para el copp-s-ping son lo mismo. Esto significa que la cantidad de paquetes que es contada por el HW es 30 (enviado todo hacia el driver Inband CPU), y el SW cuenta el mismo número de paquetes antes de que los envíe al CPU. Esto indica que no se cae ningunos paquetes por CoPP, porque está dentro del límite configurado de 100 p/s.

Cuando usted mira la clase del copp-s-espigueo, que hace juego los paquetes que se destinan a la dirección IP para la cual la entrada de caché del Address Resolution Protocol (ARP) no está presente, el número de paquetes que es considerado por el HW es 103,088, mientras que las coincidencias solamente 51544 SW. Esto indica que el CoPP cayó 51544 paquetes (de 103088-51544), porque el índice de estos paquetes excede 500 p/s.

Los contadores SW se obtienen del driver Inband CPU, y los contadores HW vienen de la lista de control de acceso (ACL) que se programa en el HW. Si usted encuentra una situación donde los paquetes coincidentes HW igualan cero, y un valor sin cero está presente para los paquetes coincidentes SW, después no hay ACL presente en el HW para ese clase-mapa específico, que puede ser normal. Es también importante observar que estos dos contadores no se pudieron sondear al mismo tiempo, y usted debe utilizar solamente el troubelshoot de los valores de contador para si la diferencia es significativa.

Las estadísticas de CoPP no se pudieron relacionar directamente con los paquetes HW-conmutados, sino que es todavía relevante si los paquetes que se deben enviar a través del Switch se llevan en batea al CPU. Una paquete-batea es causada por las diversas razones, por ejemplo cuando usted ejecuta una adyacencia de recolección.

Sea consciente que hay tres tipos de directivas de CoPP: Omita, la capa 2 (L2), y la capa 3 (L3). Elija la directiva apropiada basada en el escenario de instrumentación, y modifique la directiva de CoPP basada en las observaciones. Para ajustar el CoPP, marque regularmente, y control después de que usted obtenga los nuevos servicios/aplicaciones o después de que un reajuste de la red.

Nota: Para borrar los contadores, ingrese el comando statistics claro del copp.

Realice la revisión médica del sistema de archivos del bootflash

Para realizar un control de salud en el sistema de archivos del bootflash, ingrese el comando del bootflash del control de Estados generales del sistema:

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#

Precaución: El sistema de archivos es desmontado cuando usted funciona con la prueba, y se remonta una vez que la prueba es completa. Asegúrese de que el sistema de archivos no esté accedido mientras que usted funciona con la prueba.

Recoja las memorias del sistema y los registros de proceso

Precaución: Asegúrese de que el sistema no experimente ningunas restauraciones o caídas de proceso, y no genera ningunos archivos núcleo o registros de proceso cuando usted intenta utilizar los comandos que se mencionan en esta sección.

Ingrese estos comandos para recoger las memorias del sistema y los registros de proceso:

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

Nota: Refiérase a los archivos núcleo que extraen del artículo de Cisco de las Plataformas de la transferencia del nexo de Cisco para más detalles sobre este proceso.

Información Relacionada


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 116699