Contents

Introduction

Monitore o uso da CPU e da memória

Verifique o status do diagnóstico de hardware

Exibir perfil de hardware

Monitoramento de buffer ativo

Monitorar Contadores/Estatísticas de Interface

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

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

Coletar Núcleos de Sistema e Logs de Processo

Informações Relacionadas

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