Processo de verificação de integridade do sistema da plataforma do switch Nexus 3500 Series

Introduction

Este documento descreve o processo geral usado para executar uma verificação de integridade do sistema nas plataformas de switch Cisco Nexus 3500 Series que executam o Nexus Operating System (NX-OS) Release 6.0(2).

Monitore o uso da CPU e da memória

Para receber uma visão geral da CPU e do uso da memória do sistema, insira o comando 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#

Se você precisar de mais detalhes sobre os processos que consomem ciclos de CPU ou memória, insira os comandos show process cpu sort e show system internal kernel memory 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#

A saída mostra que a região de alta memória é usada pelo NX-OS, e a região de memória baixa é usada pelo kernel. Os valores MemTotal e MemFree fornecem a memória total disponível para o switch.

Para gerar alertas de uso de memória, configure o switch da seguinte forma:

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

Note: Para este documento, os valores 50, 70 e 90 são usados apenas como exemplos; escolha limites com base nas suas necessidades.

Verifique o status do diagnóstico de hardware

Para verificar o status do diagnóstico de hardware, insira o comando show diagnostic result all. Verifique se todos os testes foram bem-sucedidos e se o Resultado de diagnóstico geral é 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>

Exibir perfil de hardware

Insira o comando show hardware profile status para verificar o perfil de hardware atual configurado no switch e o uso da tabela de 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#

Certifique-se de que o uso das Entradas de Host e Entradas Unicast/Multicast Longest Prefix Match (LPM) estejam dentro do limite especificado.

Note: Para um desempenho ótimo do switch, é importante escolher o modelo de perfil de hardware apropriado.

Se você deseja que o switch gere um syslog em um nível de limite específico, configure o switch da seguinte forma:

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

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

Note: O valor de limite padrão é 90% para unicast e multicast.

Para obter mais detalhes, consulte o artigo Configuring PIM Cisco , que fornece detalhes de configuração com base na licença instalada e nos recursos habilitados. Além disso, se desejar otimizar a tabela de encaminhamento, consulte os Switches Cisco Nexus 3000 Series: Entender, Configurar e Ajustar o artigo da Cisco da Tabela de Encaminhamento.

Monitoramento de buffer ativo

O Ative Buffer Monitoring (ABM) fornece os dados de ocupação de buffer granular, que permitem uma melhor compreensão dos pontos de conexão do congestionamento. Este recurso suporta dois modos de operação: Modo unicast e multicast.

No modo Unicast, o ABM monitora e mantém os dados de uso do buffer por bloco de buffer e a utilização do buffer unicast para todas as 48 portas. No modo Multicast, ele monitora e mantém os dados de uso do buffer por bloco de buffer e a utilização do buffer multicast por bloco de buffer.

Note: Para obter mais informações, consulte o artigo da Cisco Cisco Nexus 3548 Ative Buffer Monitoring. A Figura 4 do artigo mostra que o uso do buffer atingiu o pico em 22:15:32 e durou até 22:15:37. Além disso, o histograma fornece evidência de picos repentinos no uso e mostra a velocidade na qual o buffer drena. Se houver um receptor lento (como um receptor de 1 Gbps entre os receptores de 10 Gbps), para evitar quedas de pacotes, você deve incluir uma configuração semelhante a esta: porta de receptor lento multicast de perfil de hardware <x>.

Monitorar Contadores/Estatísticas de Interface

Para monitorar a perda de tráfego, insira o comando show interface ethernet x/y. A saída desse comando fornece informações básicas sobre a taxa de tráfego e também quedas/erros no nível da porta.

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#

Se a entrada ou saída descartar mostrar valores diferentes de zero, determine se os pacotes descartados são unicast e/ou 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#

A saída indica que o tráfego descartado não é devido à Qualidade de Serviço (QoS). Agora você deve verificar as estatísticas de endereço MAC do 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

Quando você executa uma solução de problemas para quedas de tráfego, as principais opções a serem verificadas são congestionamento, erros e qos. A opção pktflow fornece estatísticas de tráfego nas direções RX e TX, com intervalos de tamanho de pacote específicos.

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: O valor hexadecimal 0x3f997 é igual a 260503 em formato decimal.

switch# show interface eth1/10

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

   

Na saída, a mensagem de erro PORT_EXCEPTION_ICBL_PKT_DROP indica que o tráfego recebido na porta tem uma marca Dot1Q para uma VLAN que não está habilitada no switch.

Aqui está outro exemplo, em que a queda de tráfego é vista devido à 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: A saída indica que 6153699 pacotes foram descartados na direção Receive, o que é enganoso. Consulte o bug da Cisco 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>

Em resumo, aqui estão os comandos usados para capturar descartes de pacotes:

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

Monitorar Estatísticas de Política de Plano de Controle

O Control Plane Policing (CoPP) protege o plano de controle para garantir a estabilidade da rede. Para obter detalhes adicionais, consulte o artigo Configuring Control Plane Policing da Cisco.

Para monitorar as estatísticas do CoPP, insira o comando 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>

Na saída, o Hardware (HW) e o Software (SW) Pacotes Correspondentes para copp-s-ping são os mesmos. Isso significa que a quantidade de pacotes que é contada pelo HW é 30 (todos enviados para o driver da CPU de banda interna), e o SW conta o mesmo número de pacotes antes de enviá-los para a CPU. Isso indica que nenhum pacote é descartado pelo CoPP, porque está dentro do limite configurado de 100 p/s.

Quando você observa a classe copp-s-glean, que corresponde aos pacotes destinados ao endereço IP para o qual a entrada da cache do Address Resolution Protocol (ARP) não está presente, o número de pacotes vistos pelo HW é 103.088, enquanto o SW corresponde somente 5154 . Isso indica que o CoPP descartou 51544 pacotes (103088-51544), porque a taxa desses pacotes excede 500 p/s.

Os contadores de SW são obtidos do driver de Inband da CPU e os contadores de HW vêm da ACL (Access Control List, lista de controle de acesso) programada no HW. Se você encontrar uma situação em que HW Matched Packets é igual a zero e um valor diferente de zero está presente para os SW Matched Packets, então não há ACL no HW para esse mapa de classe específico, que pode ser normal. Também é importante observar que esses dois contadores podem não ser pesquisados ao mesmo tempo, e você só deve usar os valores de contador para solucionar problemas se a diferença for significativa.

As estatísticas de CoPP podem não estar diretamente relacionadas aos pacotes comutados por HW, mas ainda é relevante se os pacotes que devem ser enviados através do switch forem direcionados para a CPU. Um pacote punt é causado por vários motivos, como quando você executa uma adjacência glean.

Esteja ciente de que há três tipos de políticas de CoPP: Padrão, Camada 2 (L2) e Camada 3 (L3). Escolha a política apropriada com base no cenário de implantação e modifique a política de CoPP com base nas observações. Para ajustar o CoPP, verifique regularmente e depois de obter novos serviços/aplicativos ou após um novo projeto de rede.

Note: Para limpar os contadores, insira o comando clear copp statistics.

Executar verificação de integridade do sistema de arquivos do Bootflash

Para executar uma verificação de integridade no sistema de arquivos bootflash, insira o comando 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#

Caution: O sistema de arquivos é desmontado quando você executa o teste e é remontado assim que o teste é concluído. Certifique-se de que o sistema de arquivos não seja acessado durante a execução do teste.

Coletar Núcleos de Sistema e Logs de Processo

Caution: Certifique-se de que o sistema não experimente reinicializações ou travamentos de processos e não gere nenhum arquivo central ou registro de processos quando você tentar usar os comandos mencionados nesta seção.

Insira estes comandos para coletar os núcleos do sistema e os logs de processo:

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: Consulte o artigo Recuperando arquivos principais das plataformas de switching Cisco Nexus da Cisco para obter mais detalhes sobre esse processo.

Informações Relacionadas

• Dados técnicos e documentação - Switches Cisco Nexus 3000 Series
• Comparar modelos - Switches Cisco Nexus 3000 Series
• Introdução - Switches Cisco Nexus 3000 Series
• Compreendendo o contador de interface "Input Discard" no Nexus3000 - Comunidades de suporte da Cisco
• Suporte Técnico e Documentação - Cisco Systems