Alta utilização da CPU em Switches Catalyst 4500 baseados no software Cisco IOS
Contents
Introduction
Os switches da série Catalyst 4500, que incluem os switches Catalyst 4948, têm uma metodologia sofisticada do processamento de pacotes para o tráfego limitado por CPU. Um problema normalmente percebido é a utilização elevada da CPU nestes switches. Este documento fornece detalhes sobre a arquitetura de processamento de pacotes pela CPU e mostra como identificar as causas da utilização elevada da CPU nestes switches. O documento também lista alguns cenários comuns de rede ou configuração que causam a utilização elevada da CPU na série Catalyst 4500.
Observação: se você executar Catalyst OS (CatOS)-based Catalyst 4500/4000 Series Switches, consulte o documento Utilização de CPU em Catalyst 4500/4000, 2948G, 2980G e 4912G Switches que executam CatOS Software .
Prerequisites
Requirements
Não existem requisitos específicos para este documento.
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
-
Catalyst 4500 Series Switches
-
Catalyst 4948 Series Switches
Observação: este documento se aplica somente aos switches baseados em software Cisco IOS® e não aos switches baseados em CatOS.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Informações de Apoio
Antes de analisar a arquitetura de manipulação de pacotes da CPU e solucionar problemas de alta utilização da CPU, você deve entender as diferentes maneiras pelas quais os switches de encaminhamento baseado em hardware e os roteadores baseados em software Cisco IOS utilizam a CPU. É comum pensar equivocadamente que alta utilização da CPU indica o esgotamento dos recursos em um dispositivo e a ameaça de uma falha. O problema de capacidade é um dos sintomas de alta utilização da CPU nos roteadores Cisco IOS. No entanto, um problema de capacidade quase nunca é um sintoma de alta utilização da CPU com switches de encaminhamento baseados em hardware como o Catalyst 4500. O Catalyst 4500 foi projetado para encaminhar pacotes no circuito integrado específico da aplicação de hardware (ASIC) e alcançar velocidades de encaminhamento de tráfego de até 102 milhões de pacotes por segundo (Mpps).
A CPU do Catalyst 4500 executa estas funções:
-
Gerencia protocolos de software configurados, por exemplo:
-
STP (Spanning Tree Protocol)
-
Routing Protocol
-
Cisco Discovery Protocol (CDP)
-
Port Aggregation Protocol (PAgP)
-
VLAN Trunk Protocol (VTP)
-
Dynamic Trunking Protocol (DTP)
-
-
Programas de configuração/entradas dinâmicas para ASICs de hardware, por exemplo:
-
Listas de controle de acesso (ACLs)
-
entradas CEF
-
-
Gerencia internamente vários componentes, por exemplo:
-
Placas de linha Power over Ethernet (PoE)
-
Fontes de alimentação
-
Bandeja do ventilador
-
-
Gerencia o acesso ao switch, por exemplo:
-
Telnet
-
Console
-
Simple Network Management Protocol
-
-
Encaminha pacotes através do caminho do software, por exemplo:
-
Pacotes roteados pelo Internetwork Packet Exchange (IPX), que são suportados apenas no caminho do software
-
Fragmentação máxima de unidade de transmissão (MTU)
-
De acordo com essa lista, a alta utilização da CPU pode resultar do recebimento ou do processo de pacotes pela CPU. Alguns dos pacotes enviados para o processo podem ser essenciais para a operação da rede. Um exemplo desses pacotes essenciais são BPDUs (unidade de dados de protocolo de bridge) para configurações de topologia de spanning tree. No entanto, outros pacotes podem ser tráfego de dados encaminhado por software. Esses cenários exigem que os ASICs de comutação enviem pacotes para a CPU para processamento:
-
Pacotes que são copiados para a CPU, mas os pacotes originais são comutados no hardware
Um exemplo é o aprendizado do endereço MAC do host.
-
Pacotes enviados à CPU para processamento
Os exemplos incluem:
-
Atualizações do protocolo de roteamento
-
BPDUs
-
Uma inundação intencional ou não intencional de tráfego
-
-
Pacotes enviados à CPU para encaminhamento
Um exemplo são os pacotes que precisam de roteamento IPX ou AppleTalk.
Entender a arquitetura de manipulação de pacotes da CPU do Catalyst 4500
O Catalyst 4500 tem um mecanismo de Qualidade de Serviço (QoS - Quality of Service) incorporado para diferenciar os tipos de tráfego destinados à CPU. O mecanismo faz a diferenciação com base nas informações do pacote de Camada 2 (L2)/Camada 3 (L3)/Camada 4 (L4). O Supervisor Packet Engine tem 16 filas para lidar com vários tipos de pacotes ou eventos. A Figura 1 mostra essas filas. A Tabela 1 lista as filas e os tipos de pacotes que as filas contêm. As 16 filas permitem que o Catalyst 4500 enfileire os pacotes com base no tipo ou na prioridade do pacote.
Figura 1: O Catalyst 4500 usa várias filas de CPU 
| Número da fila | Nome da fila | Pacotes na Fila |
|---|---|---|
| 0 | Esmp | Pacotes ESMP 1 (pacotes de gerenciamento interno) para ASICs de placa de linha ou outro gerenciamento de componente |
| 1 | Controle | Pacotes de plano de controle L2, como STP, CDP, PAgP, LACP2 ou UDLD3 |
| 2 | Aprendizado de host | Quadros com endereços MAC de origem desconhecida que são copiados para a CPU para criar a tabela de encaminhamento L2 |
| 3, 4, 5 | Fwd L3 Mais Alta, Fwd L3 Alta/Média, Fwd L3 Baixo | Pacotes que devem ser encaminhados em software, como os túneis GRE 4 Se o ARP 5 não for resolvido para o endereço IP de destino, os pacotes serão enviados para essa fila. |
| 6, 7, 8 | L2 Fwd Mais Alta, L2 Fwd Alta/Média, L2 Fwd Baixa | Pacotes que são encaminhados como resultado de bridging
|
| 9, 10 | L3 Rx Alta, L3 Rx Baixa | O tráfego do plano de controle L3, por exemplo, os protocolos de roteamento, destinados aos endereços IP da CPU Exemplos incluem Telnet, SNMP e SSH8. |
| 11 | Falha de RPF | Pacotes multicast que falharam na verificação RPF 9 |
| 12 | ACL fwd(snooping) | Pacotes processados pelos recursos de rastreamento DHCP 10, inspeção ARP dinâmica ou IGMP11 |
| 13 | log de ACL, inacessível | Pacotes que atingem uma ACE 12 com a palavra-chave log ou pacotes que foram descartados devido a uma negação em uma ACL de saída ou à falta de uma rota para o destino Esses pacotes exigem a geração de mensagens ICMP inalcançáveis. |
| 14 | processamento de sw de ACL | Pacotes que são direcionados à CPU devido à falta de recursos adicionais de hardware de ACL, como TCAM 13, para ACL de segurança |
| 15 | Falha/inválido de MTU | Pacotes que precisam ser fragmentados porque o tamanho da MTU da interface de saída é menor que o tamanho do pacote |
1 ESMP = Até mesmo Simple Management Protocol.
2 LACP = Link Aggregation Control Protocol .
3 UDLD = UniDirectional Link Detection (Detecção de link unidirecional).
4 GRE = encapsulamento de roteamento genérico.
5 ARP = Address Resolution Protocol.
6 SVI = interface virtual comutada.
7 TTL = Tempo de Vida.
8 SSH = Secure Shell Protocol.
9 RPF = Reverse Path Forwarding
10 DHCP = Dynamic Host Configuration Protocol.
11 IGMP = Internet Group Management Protocol.
12 ACE = entrada de controle de acesso.
13 TCAM = memória endereçável de conteúdo ternário.
Essas filas são filas separadas:
-
L2 Fwd Highest ou L3 Fwd Highest
-
Altos/Médios ou Altos/Médios de Altos/Médios de Altos/Altos/Médios de Altos/Médios Altos de Altos ou Altos/Médios de Altos/Altos
-
L2 Fwd Low ou L3 Fwd Low
-
L3 Rx Alta ou L3 Rx Baixa
Os pacotes são enfileirados nessas filas com base na etiqueta de QoS, que é o valor de ponto de código de serviços diferenciados (DSCP) do tipo de serviço IP (ToS). Por exemplo, os pacotes com um DSCP de 63 são enfileirados para a fila L3 Fwd Highest. Você pode ver os pacotes recebidos e descartados para essas 16 filas na saída do comando show platform cpu packet statistics all. A saída desse comando é muito longa. Emita o comando show platform cpu packet statistics para mostrar somente os eventos diferentes de zero. Um comando alternativo é o comando show platform cpuport. Use o comando show platform cpuport somente se você executar o Cisco IOS Software Release 12.1(11)EW ou anterior. Este comando foi substituído desde então. No entanto, esse comando mais antigo fazia parte do comando show tech-support nas versões do Cisco IOS Software anteriores ao Cisco IOS Software Release 12.2(20)EWA.
Use o comando show platform cpu packet statistics para toda solução de problemas.
Switch#show platform cpu packet statistics all !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 0 0 0 0 0 Control 48 0 0 0 0 Host Learning 0 0 0 0 0 L3 Fwd High 0 0 0 0 0 L3 Fwd Medium 0 0 0 0 0 L3 Fwd Low 0 0 0 0 0 L2 Fwd High 0 0 0 0 0 L2 Fwd Medium 0 0 0 0 0 L2 Fwd Low 0 0 0 0 0 L3 Rx High 0 0 0 0 0 L3 Rx Low 0 0 0 0 0 RPF Failure 0 0 0 0 0 ACL fwd(snooping) 0 0 0 0 0 ACL log, unreach 0 0 0 0 0 ACL sw processing 0 0 0 0 0 MTU Fail/Invalid 0 0 0 0 0 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 0 0 0 0 0 Control 0 0 0 0 0 Host Learning 0 0 0 0 0 L3 Fwd High 0 0 0 0 0 L3 Fwd Medium 0 0 0 0 0 L3 Fwd Low 0 0 0 0 0 L2 Fwd High 0 0 0 0 0 L2 Fwd Medium 0 0 0 0 0 L2 Fwd Low 0 0 0 0 0 L3 Rx High 0 0 0 0 0 L3 Rx Low 0 0 0 0 0 RPF Failure 0 0 0 0 0 ACL fwd(snooping) 0 0 0 0 0 ACL log, unreach 0 0 0 0 0 ACL sw processing 0 0 0 0 0 MTU Fail/Invalid 0 0 0 0 0
A CPU do Catalyst 4500 atribui pesos às várias filas que a Tabela 1 lista. A CPU atribui os pesos com base na importância, ou tipo, e com base na prioridade de tráfego, ou DSCP. A CPU atende a fila com base nos pesos relativos da fila. Por exemplo, se um pacote de controle, como uma BPDU, e uma solicitação de eco ICMP estiverem pendentes, a CPU servirá primeiro o pacote de controle. Uma quantidade excessiva de tráfego de baixa prioridade ou menos importante não sobrecarrega a CPU da capacidade de processar ou gerenciar o sistema. Esse mecanismo garante que a rede esteja estável mesmo sob alta utilização da CPU. Essa capacidade da rede de permanecer estável é uma informação essencial que você deve entender.
Há outro detalhe de implementação muito importante do tratamento de pacotes de CPU do Catalyst 4500. Se a CPU já tiver atendido pacotes ou processos de alta prioridade, mas tiver mais ciclos de CPU sobressalentes por um período de tempo específico, ela atenderá aos pacotes de fila de baixa prioridade ou executará processos em segundo plano de menor prioridade. A alta utilização da CPU como resultado do processamento de pacotes de baixa prioridade ou dos processos em segundo plano é considerada normal porque a CPU tenta constantemente usar todo o tempo disponível. Dessa forma, a CPU procura o desempenho máximo do switch e da rede sem comprometer a estabilidade do switch. O Catalyst 4500 considera a CPU subutilizada, a menos que a CPU seja usada a 100% para um único slot de tempo.
O Cisco IOS Software Release 12.2(25)EWA2 e posteriores aprimoraram o mecanismo e a contabilização de tratamento de pacotes e processos da CPU. Portanto, use essas versões nas implantações do Catalyst 4500.
Identifique o motivo para a alta utilização da CPU no Catalyst 4500
Agora que você entende a arquitetura e o projeto de tratamento de pacotes da CPU do Catalyst 4500, ainda é possível identificar por que a utilização da CPU do Catalyst 4500 é alta. O Catalyst 4500 tem os comandos e as ferramentas necessários para identificar a causa raiz da alta utilização da CPU. Depois de identificar o motivo, os administradores podem executar uma destas ações:
-
Ação corretiva—Isso pode incluir alterações na configuração ou na rede ou a criação de uma solicitação de serviço do Suporte Técnico da Cisco para análise posterior.
-
Nenhuma ação—O Catalyst 4500 executa de acordo com a expectativa. A CPU exibe alta utilização da CPU porque o Supervisor Engine maximiza os ciclos da CPU para executar todos os trabalhos necessários de encaminhamento de pacotes de software e de segundo plano.
Identifique o motivo para a alta utilização da CPU, mesmo que a ação corretiva não seja necessária em todos os casos. A alta utilização da CPU pode ser apenas um sintoma de um problema na rede. Uma resolução da causa básica desse problema pode ser necessária para reduzir a utilização da CPU.
A Figura 2 mostra a metodologia de identificação e solução de problemas a ser usada para identificar a causa raiz da alta utilização da CPU do Catalyst 4500.
Figura 2: Metodologia de solução de problemas de alta utilização da CPU em switches Catalyst 4500 
As etapas gerais de solução de problemas são:
-
Emita o comando show processes cpu para identificar os processos do Cisco IOS que consomem ciclos de CPU.
-
Execute o comando show platform health para identificar ainda mais os processos específicos da plataforma.
-
Se o processo altamente ativo for K2CpuMan Review , emita o comando show platform cpu packet statistics para identificar o tipo de tráfego que atinge a CPU.
Se a atividade não for devida ao processo K2CpuMan Review, pule a Etapa 4 e vá para a Etapa 5.
-
Identifique os pacotes que atingem a CPU com o uso das Ferramentas de Troubleshooting para Analisar o Tráfego Destinado à CPU, se necessário.
Um exemplo das ferramentas de solução de problemas a serem usadas é o CPU Switched Port Analyzer (SPAN).
-
Revise este documento e a seção Troubleshoot Common High Usation Problems (Solução de problemas comuns de alta utilização da CPU) para causas comuns.
Se ainda não conseguir identificar a causa raiz, entre em contato com o Suporte Técnico da Cisco.
Linha de base do uso da CPU
A primeira etapa importante é saber a utilização da CPU do switch para a configuração e a configuração da rede. Use o comando show processes cpu para identificar a utilização da CPU no switch Catalyst 4500. A atualização contínua da utilização da CPU da linha de base pode ser necessária à medida que você adiciona mais configuração à configuração da rede ou à medida que seu padrão de tráfego de rede é alterado. A Figura 2 indica esse requisito.
Esta saída é de um Catalyst 4507R totalmente carregado. A CPU em estado estacionário é de aproximadamente 32 a 38 por cento, o que é necessário para executar as funções de gerenciamento para este switch:
Switch#show processes cpu CPU utilization for five seconds: 38%/1%; one minute: 32%; five minutes: 32% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 63 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 60 50074 1 0.00% 0.00% 0.00% 0 Load Meter 3 0 1 0 0.00% 0.00% 0.00% 0 Deferred Events !--- Output suppressed. 27 524 250268 2 0.00% 0.00% 0.00% 0 TTY Background 28 816 254843 3 0.00% 0.00% 0.00% 0 Per-Second Jobs 29 101100 5053 20007 0.00% 0.01% 0.00% 0 Per-minute Jobs 30 26057260 26720902 975 12.07% 11.41% 11.36% 0 Cat4k Mgmt HiPri 31 19482908 29413060 662 24.07% 19.32% 19.20% 0 Cat4k Mgmt LoPri 32 4468 162748 27 0.00% 0.00% 0.00% 0 Galios Reschedul 33 0 1 0 0.00% 0.00% 0.00% 0 IOS ACL Helper 34 0 2 0 0.00% 0.00% 0.00% 0 NAM Manager
A utilização da CPU em cinco segundos é expressa como:
x%/y%
O x% representa a utilização total da CPU e y% representa a CPU que é gasta no nível de interrupção. Ao solucionar problemas dos switches Catalyst 4500, concentre-se apenas na utilização total da CPU.
Entender o comando show processes cpu nos switches Catalyst 4500
Esta saída de show processes cpu mostra que há dois processos que usam a CPU— Cat4k Mgmt HiPri e Cat4k Mgmt LoPri . Esses dois processos agregam vários processos específicos da plataforma que executam as funções essenciais de gerenciamento no Catalyst 4500. Esses processos processam o plano de controle de processos, bem como pacotes de dados que precisam ser comutados por software ou processados.
Para ver qual dos processos específicos da plataforma usa a CPU no contexto do Cat4k Mgmt HiPri e do Cat4k Mgmt LoPri , emita o comando show platform health.
Cada um dos processos específicos da plataforma tem um destino/utilização esperada da CPU. Quando esse processo está dentro do destino, a CPU executa o processo no contexto de alta prioridade. A saída do comando show processes cpu conta essa utilização em Cat4k Mgmt HiPri . Se um processo exceder o destino/utilização esperada, esse processo será executado sob o contexto de baixa prioridade. A saída do comando show processes cpu conta essa utilização adicional em Cat4k Mgmt LoPri . Este Cat4k Mgmt LoPri também é usado para executar o segundo plano e outros processos de baixa prioridade, como verificação de consistência e leitura de contadores de interface. Esse mecanismo permite que a CPU execute processos de alta prioridade quando necessário, e os ciclos ociosos da CPU que permanecem são usados para os processos de baixa prioridade. Exceder a utilização da CPU de destino em uma pequena quantidade ou um pico momentâneo na utilização não é uma indicação de um problema que precisa ser investigado.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
S2w-JobEventSchedule 10.00 0.32 10 7 100 500 0 0 0 10:14
Stub-JobEventSchedul 10.00 12.09 10 6 100 500 14 13 9 396:35
StatValueMan Update 1.00 0.22 1 0 100 500 0 0 0 6:28
Pim-review 0.10 0.00 1 0 100 500 0 0 0 0:22
Ebm-host-review 1.00 0.00 8 0 100 500 0 0 0 0:05
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:01
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:00
Acl-Flattener e 1.00 0.00 10 0 100 500 0 0 0 0:00
KxAclPathMan create/ 1.00 0.00 10 5 100 500 0 0 0 0:39
KxAclPathMan update 2.00 0.00 10 0 100 500 0 0 0 0:00
KxAclPathMan reprogr 1.00 0.00 2 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 30.00 10.19 30 28 100 500 14 13 9 397:11
K2AccelPacketMan: Tx 10.00 2.20 20 0 100 500 2 2 1 82:06
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
K2AclCamMan stale en 1.00 0.00 10 0 100 500 0 0 0 0:00
K2AclCamMan hw stats 3.00 1.04 10 5 100 500 1 1 0 39:36
K2AclCamMan kx stats 1.00 0.00 10 5 100 500 0 0 0 13:40
K2AclCamMan Audit re 1.00 0.00 10 5 100 500 0 0 0 13:10
K2AclPolicerTableMan 1.00 0.00 10 1 100 500 0 0 0 0:38
K2L2 Address Table R 2.00 0.00 12 5 100 500 0 0 0 0:00
K2L2 New Static Addr 2.00 0.00 10 1 100 500 0 0 0 0:00
K2L2 New Multicast A 2.00 0.00 10 5 100 500 0 0 0 0:01
K2L2 Dynamic Address 2.00 0.00 10 0 100 500 0 0 0 0:00
K2L2 Vlan Table Revi 2.00 0.00 12 9 100 500 0 0 0 0:01
K2 L2 Destination Ca 2.00 0.00 10 0 100 500 0 0 0 0:00
K2PortMan Review 2.00 0.72 15 11 100 500 1 1 0 37:22
Gigaport65535 Review 0.40 0.07 4 2 100 500 0 0 0 3:38
Gigaport65535 Review 0.40 0.08 4 2 100 500 0 0 0 3:39
K2Fib cam usage revi 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib IrmFib Review 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Default Ro 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib AdjRepop Revie 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Unpunt Rev 2.00 0.01 15 0 100 500 0 0 0 0:23
K2Fib Consistency Ch 1.00 0.00 5 2 100 500 0 0 0 29:25
K2FibAdjMan Stats Re 2.00 0.30 10 4 100 500 0 0 0 6:21
K2FibAdjMan Host Mov 2.00 0.00 10 4 100 500 0 0 0 0:00
K2FibAdjMan Adj Chan 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibMulticast Signa 2.00 0.01 10 2 100 500 0 0 0 2:04
K2FibMulticast Entry 2.00 0.00 10 7 100 500 0 0 0 0:00
K2FibMulticast Irm M 2.00 0.00 10 7 100 500 0 0 0 0:00
K2FibFastDropMan Rev 2.00 0.00 7 0 100 500 0 0 0 0:00
K2FibPbr route map r 2.00 0.06 20 5 100 500 0 0 0 16:42
K2FibPbr flat acl pr 2.00 0.07 20 2 100 500 0 0 0 3:24
K2FibPbr consolidati 2.00 0.01 10 0 100 500 0 0 0 0:24
K2FibPerVlanPuntMan 2.00 0.00 15 4 100 500 0 0 0 0:00
K2FibFlowCache flow 2.00 0.01 10 0 100 500 0 0 0 0:23
K2FibFlowCache flow 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibFlowCache adj r 2.00 0.01 10 0 100 500 0 0 0 0:20
K2FibFlowCache flow 2.00 0.00 10 0 100 500 0 0 0 0:06
K2MetStatsMan Review 2.00 0.14 5 2 100 500 0 0 0 23:40
K2FibMulticast MET S 2.00 0.00 10 0 100 500 0 0 0 0:00
K2QosDblMan Rate DBL 2.00 0.12 7 0 100 500 0 0 0 4:52
IrmFibThrottler Thro 2.00 0.01 7 0 100 500 0 0 0 0:21
K2 VlanStatsMan Revi 2.00 1.46 15 7 100 500 2 2 1 64:44
K2 Packet Memory Dia 2.00 0.00 15 8 100 500 0 1 1 45:46
K2 L2 Aging Table Re 2.00 0.12 20 3 100 500 0 0 0 7:22
RkiosPortMan Port Re 2.00 0.73 12 7 100 500 1 1 1 52:36
Rkios Module State R 4.00 0.02 40 1 100 500 0 0 0 1:28
Rkios Online Diag Re 4.00 0.02 40 0 100 500 0 0 0 1:15
RkiosIpPbr IrmPort R 2.00 0.02 10 3 100 500 0 0 0 2:44
RkiosAclMan Review 3.00 0.06 30 0 100 500 0 0 0 2:35
MatMan Review 0.50 0.00 4 0 100 500 0 0 0 0:00
Slot 3 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 3 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 4 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 4 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 5 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 5 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 6 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 6 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 7 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 7 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
EthHoleLinecardMan(1 1.66 0.04 10 0 100 500 0 0 0 1:18
EthHoleLinecardMan(2 1.66 0.02 10 0 100 500 0 0 0 1:18
EthHoleLinecardMan(6 1.66 0.17 10 6 100 500 0 0 0 6:38
-------------
%CPU Totals 212.80 35.63
Entender o comando show platform health nos Catalyst 4500 Switches
O comando show platform health fornece muitas informações relevantes apenas para um engenheiro de desenvolvimento. Para solucionar problemas de alta utilização da CPU, procure um número maior na coluna %CPU real na saída. Além disso, certifique-se de olhar para o lado direito dessa linha para verificar o uso da CPU desse processo nas colunas média de %CPU de 1 minuto e 1 hora. Às vezes, o processa momentaneamente o pico, mas não segura a CPU por muito tempo. Algumas das altas utilizações momentâneas da CPU acontecem durante a programação ou otimização do hardware da programação. Por exemplo, um pico de utilização da CPU é normal durante a programação de hardware de uma ACL grande na TCAM.
Na saída do comando show platform health na seção Entender o Comando show processes cpu nos Catalyst 4500 Switches, os processos Stub-JobEventSchedule e K2CpuMan Review usam um número maior de ciclos de CPU. A Tabela 2 fornece algumas informações básicas sobre os processos comuns específicos da plataforma que aparecem na saída do comando show platform health.
Tabela 2 - Descrição dos processos específicos da plataforma do comando show platform health| Nome do processo específico da plataforma | Descrição |
|---|---|
| Pim-review | Gerenciamento do estado do chassi/placa de linha |
| Ebm | Módulo de bridge Ethernet, como envelhecimento e monitoramento |
| Acl-Flattener / K2AclMan | processo de união de ACL |
| KxAclPathMan - Caminho TagMan-Review | Gerenciamento e manutenção do estado da ACL |
| K2CpuMan Review | O processo que executa o encaminhamento de pacotes de software Se você vir uma alta utilização da CPU devido a esse processo, investigue os pacotes que atingem a CPU com o uso do comando show platform cpu packet statistics. |
| K2AccelPacketMan | O driver que interage com o mecanismo de pacote para enviar pacotes destinados à CPU |
| K2AclCamMan | Gerencia o hardware TCAM de entrada e saída para QoS e recursos de segurança |
| K2AclPolicerTableMan | Gerencia os vigilantes de entrada e saída |
| K2L2 | Representa o subsistema de encaminhamento L2 do software Cisco IOS Catalyst 4500 Esses processos são responsáveis pela manutenção das várias tabelas L2. |
| Revisão do K2PortMan | Gerencia as várias funções de programação relacionadas a portas |
| K2Fib | gestão FIB1 |
| K2FibFlowCache | Gerenciamento de cache PBR2 |
| K2FibAdjMan | gerenciamento de tabela de adjacência FIB |
| K2FibMulticast | Gerencia entradas FIB multicast |
| Revisão do K2MetStatsMan | Gerencia estatísticas MET3 |
| Revisão do K2QosDblMan | Gerencia QoS DBL4 |
| IrmFibThrottler Thor | módulo de roteamento IP |
| Tabela de vencimento do L2 do K2 Re | Gerencia a função de envelhecimento de L2 |
| GalChassisVp-review | Monitoramento do estado do gabinete |
| S2w-JobEventSchedule | Gerencia os protocolos S2W5 para monitorar o estado das placas de linha |
| Stub-JobEventSchedule | Monitoramento e manutenção de placas de linha com base em ASIC de stub |
| Porta RkiosPortMan Re | Monitoramento e manutenção do estado das portas |
| Estado R do módulo Rkios | Monitoramento e manutenção da placa de linha |
| EthHoleLinecardMan | Gerencia GBICs 6 em cada uma das placas de linha |
1 FIB = Forwarding Information Base (Base de informações de encaminhamento).
2 PBR = roteamento baseado em políticas.
3 MET = Tabela de Expansão Multicast.
4 DBL = Dynamic Buffer Limiting.
5 S2W = serial para fio.
6 GBIC = Gigabit Interface Converter.
Solucionar problemas comuns de alta utilização da CPU
Esta seção aborda alguns dos problemas comuns de alta utilização da CPU nos switches Catalyst 4500.
Alta utilização da CPU devido a pacotes comutados por processo
Uma das razões comuns para a alta utilização da CPU é que a CPU do Catalyst 4500 está ocupada com o processo de pacotes para pacotes de software encaminhados ou pacotes de controle. Exemplos de pacotes encaminhados por software são IPX ou pacotes de controle, como BPDUs. Normalmente, um pequeno número desses pacotes é enviado à CPU. No entanto, um número consistentemente grande de pacotes pode indicar um erro de configuração ou um evento de rede. Você deve identificar a causa dos eventos que levam ao encaminhamento de pacotes para a CPU para processamento. Essa identificação permite depurar os problemas de alta utilização da CPU.
Algumas das razões comuns para a alta utilização da CPU devido aos pacotes comutados por processo são:
Outros motivos para a comutação de pacotes para a CPU são:
-
Fragmentação de MTU—Certifique-se de que todas as interfaces ao longo do caminho do pacote tenham a mesma MTU.
-
ACL com sinalizadores de TCP diferentes dos estabelecidos
-
Roteamento IP versão 6 (IPv6)—Isso é suportado somente pelo caminho de switching de software.
-
GRE—Isso é suportado somente pelo caminho de switching de software.
-
Negação de tráfego na ACL do roteador de entrada ou saída (RACL)
Observação: isso é limitado à taxa no Cisco IOS Software Release 12.1(13)EW1 e posterior.
Emita o comando no ip unreachables na interface da ACL.
-
O excesso de tráfego ARP e DHCP atinge a CPU para processamento devido a um grande número de hosts conectados diretamente
Se você suspeitar de um ataque DHCP, use o rastreamento DCHP para limitar a taxa de tráfego DHCP de qualquer porta de host específica.
-
Excesso de polling SNMP por uma estação final legítima ou com comportamento incorreto
Um alto número de instâncias de Spanning-Tree Port
O Catalyst 4500 suporta 3000 instâncias de porta spanning-tree ou portas ativas no modo Per VLAN Spanning Tree+ (PVST+). O suporte está em todos os Supervisor Engines, exceto o Supervisor Engine II+ e II+TS e o Catalyst 4948. O Supervisor Engine II+ e II+TS e o Catalyst 4948 suportam até 1500 instâncias de porta. Se você exceder essas recomendações de instância do STP, o switch exibirá alta utilização da CPU.
Este diagrama mostra um Catalyst 4500 com três portas de tronco que transportam as VLANs 1 a 100. Isso equivale a 300 instâncias de porta spanning-tree. Em geral, você pode calcular instâncias de porta spanning-tree com esta fórmula:
Total number of STP instances = Number of access ports + Sum of all VLANs that are carried in each of the trunks
No diagrama, não há portas de acesso, mas os três troncos transportam VLANs de 1 a 100:
Total number of STP instances = 0 + 100 + 100 + 100 = 300
Passo 1: Verifique o processo do Cisco IOS com o comando show processes cpu.
Esta seção analisa os comandos que um administrador usa para restringir o problema de alta utilização da CPU. Se você executar o comando show processes cpu, você poderá ver que dois processos principais, Cat4k Mgmt LoPri e Spanning Tree , usam principalmente a CPU. Com apenas essas informações, você sabe que o processo de spanning tree consome uma parte considerável dos ciclos da CPU.
Switch#show processes cpu CPU utilization for five seconds: 74%/1%; one minute: 73%; five minutes: 50% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 198 20 0.00% 0.00% 0.00% 0 Chunk Manager 2 4 290 13 0.00% 0.00% 0.00% 0 Load Meter !--- Output suppressed. 25 488 33 14787 0.00% 0.02% 0.00% 0 Per-minute Jobs 26 90656 223674 405 6.79% 6.90% 7.22% 0 Cat4k Mgmt HiPri 27 158796 59219 2681 32.55% 33.80% 21.43% 0 Cat4k Mgmt LoPri 28 20 1693 11 0.00% 0.00% 0.00% 0 Galios Reschedul 29 0 1 0 0.00% 0.00% 0.00% 0 IOS ACL Helper 30 0 2 0 0.00% 0.00% 0.00% 0 NAM Manager !--- Output suppressed. 41 0 1 0 0.00% 0.00% 0.00% 0 SFF8472 42 0 2 0 0.00% 0.00% 0.00% 0 AAA Dictionary R 43 78564 20723 3791 32.63% 30.03% 17.35% 0 Spanning Tree 44 112 999 112 0.00% 0.00% 0.00% 0 DTP Protocol 45 0 147 0 0.00% 0.00% 0.00% 0 Ethchnl
Passo 2: Verifique o processo específico do Catalyst 4500 com o comando show platform health.
Para entender qual processo específico da plataforma consome a CPU, emita o comando show platform health. A partir dessa saída, você pode ver que o processo K2CpuMan Review, um trabalho para lidar com pacotes vinculados à CPU, usa a CPU:
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 30.00 37.62 30 53 100 500 41 33 1 2:12
K2AccelPacketMan: Tx 10.00 4.95 20 0 100 500 5 4 0 0:36
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
Passo 3: Verifique a fila da CPU que recebe tráfego para identificar o tipo de tráfego vinculado à CPU.
Emita o comando show platform cpu packet statistics para verificar qual fila de CPU recebe o pacote associado à CPU. A saída nesta seção mostra que a fila de controle recebe muitos pacotes. Use as informações da Tabela 1 e a conclusão que você tirou na Etapa 1. Você pode determinar que os pacotes que a CPU processa e o motivo para a alta utilização da CPU é o processamento de BPDU.
Switch#show platform cpu packet statistics !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 202760 196 173 128 28 Control 388623 2121 1740 598 16 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Control 17918 0 19 24 3
Passo 4: Identifique a causa raiz.
Emita o comando show spanning-tree summary. Você pode verificar se o recebimento de BPDUs é devido a um número alto de instâncias de porta spanning-tree. A saída identifica claramente a causa raiz:
Switch#show spanning-tree summary Switch is in pvst mode Root bridge for: none Extended system ID is enabled Portfast Default is disabled PortFast BPDU Guard Default is disabled Portfast BPDU Filter Default is disabled Loopguard Default is disabled EtherChannel misconfig guard is enabled UplinkFast is disabled BackboneFast is disabled Configured Pathcost method used is short !--- Output suppressed. Name Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------- 2994 vlans 0 0 0 5999 5999
Há um grande número de VLANs com a configuração do modo PVST+. Para resolver o problema, altere o modo STP para Multiple Spanning Tree (MST). Em alguns casos, o número de instâncias de STP é alto porque um número alto de VLANs é encaminhado em todas as portas de tronco. Nesse caso, remova manualmente as VLANs que não são necessárias do tronco para diminuir o número de portas ativas do STP para bem abaixo do valor recomendado.
Dica: certifique-se de não configurar as portas do telefone IP como portas de tronco. Este é um erro de configuração comum. Configurar portas de telefone IP com uma configuração de VLAN de voz. Essa configuração cria um pseudo tronco, mas não exige que você remova manualmente as VLANs desnecessárias. Para obter mais informações sobre como configurar portas de voz, consulte o guia de configuração do software Configuring Voice Interfaces. Os telefones IP que não são da Cisco não suportam esta VLAN de voz ou configuração de VLAN auxiliar. Você deve remover manualmente as portas com telefones IP que não sejam da Cisco.
Redirecionamentos de ICMP; Pacotes de roteamento na mesma interface
Pacotes de roteamento na mesma interface, ou entrada e saída de tráfego na mesma interface L3, podem resultar em um redirecionamento ICMP pelo switch. Se o switch souber que o dispositivo do próximo salto para o destino final está na mesma sub-rede do dispositivo emissor, o switch gera o redirecionamento ICMP para a origem. As mensagens de redirecionamento indicam à origem para enviar o pacote diretamente ao dispositivo do próximo salto. As mensagens indicam que o dispositivo do próximo salto tem uma rota melhor até o destino, uma rota de um salto a menos que esse switch.
No diagrama nesta seção, o PC A se comunica com o servidor Web. O gateway padrão do PC A aponta para o endereço IP da interface VLAN 100. No entanto, o roteador do próximo salto que permite ao Catalyst 4500 alcançar o destino está na mesma sub-rede do PC A. O melhor caminho nesse caso é enviar diretamente para o "Roteador". O Catalyst 4500 envia uma mensagem de redirecionamento ICMP para o PC A. A mensagem instrui o PC A a enviar os pacotes destinados ao Servidor Web via Roteador, em vez de através do Catalyst 4500. No entanto, na maioria dos casos, os dispositivos finais não respondem ao redirecionamento ICMP. A falta de resposta faz com que o Catalyst 4500 gaste muitos ciclos de CPU na geração desses redirecionamentos ICMP para todos os pacotes que o Catalyst encaminha através da mesma interface dos pacotes de entrada.
Por padrão, o redirecionamento ICMP está ativado. Para desabilitá-lo, use o comando no ip icmp redirects. Emita o comando na interface SVI ou L3 relevante.
Observação: como o ip icmp redirects é um comando padrão, ele não é visível na saída do comando show running-configuration.
Passo 1: Verifique o processo do Cisco IOS com o comando show processes cpu.
Emita o comando show processes cpu. Você pode ver que dois processos principais, Cat4k Mgmt LoPri e IP Input , usam principalmente a CPU. Com apenas essas informações, você sabe que o processo de pacotes IP custa uma parte considerável da CPU.
Switch#show processes cpu CPU utilization for five seconds: 38%/1%; one minute: 32%; five minutes: 32% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 63 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 60 50074 1 0.00% 0.00% 0.00% 0 Load Meter 3 0 1 0 0.00% 0.00% 0.00% 0 Deferred Events !--- Output suppressed. 27 524 250268 2 0.00% 0.00% 0.00% 0 TTY Background 28 816 254843 3 0.00% 0.00% 0.00% 0 Per-Second Jobs 29 101100 5053 20007 0.00% 0.01% 0.00% 0 Per-minute Jobs 30 26057260 26720902 975 5.81% 6.78% 5.76% 0 Cat4k Mgmt HiPri 31 19482908 29413060 662 19.64% 18.20% 20.48% 0 Cat4k Mgmt LoPri !--- Output suppressed. 35 60 902 0 0.00% 0.00% 0.00% 0 DHCP Snooping 36 504625304 645491491 781 72.40% 72.63% 73.82% 0 IP Input
Passo 2: Verifique o processo específico do Catalyst 4500 com o comando show platform health.
A saída do comando show platform health confirma o uso da CPU para processar pacotes vinculados à CPU.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 330.00 19.18 150 79 25 500 20 19 18 5794:08
K2AccelPacketMan: Tx 10.00 4.95 20 0 100 500 5 4 0 0:36
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
Passo 3: Verifique a fila da CPU que recebe tráfego para identificar o tipo de tráfego vinculado à CPU.
Emita o comando show platform cpu packet statistics para verificar qual fila de CPU recebe o pacote associado à CPU. Você pode ver que a fila L3 Fwd Low recebe bastante tráfego.
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 48613268 38 39 38 39 Control 142166648 74 74 73 73 Host Learning 1845568 2 2 2 2 L3 Fwd High 17 0 0 0 0 L3 Fwd Medium 2626 0 0 0 0 L3 Fwd Low 4717094264 3841 3879 3873 3547 L2 Fwd Medium 1 0 0 0 0 L3 Rx High 257147 0 0 0 0 L3 Rx Low 5325772 10 19 13 7 RPF Failure 155 0 0 0 0 ACL fwd(snooping) 65604591 53 54 54 53 ACL log, unreach 11013420 9 8 8 8
Passo 4: Identifique a causa raiz.
Nesse caso, use o SPAN da CPU para determinar o tráfego que atinge a CPU. Para obter informações sobre o SPAN da CPU, consulte a Ferramenta 1: Monitore o tráfego da CPU com o SPAN—Cisco IOS Software Release 12.1(19)EW e Posterior deste documento. Conclua uma análise do tráfego e uma configuração com o uso do comando show running-configuration. Nesse caso, um pacote é roteado pela mesma interface, o que leva à questão de um redirecionamento ICMP para cada pacote. Essa causa raiz é uma das razões comuns para a alta utilização da CPU no Catalyst 4500.
Você pode esperar que o dispositivo de origem atue no redirecionamento ICMP que o Catalyst 4500 envia e altere o próximo salto para o destino. No entanto, nem todos os dispositivos respondem a um redirecionamento ICMP. Se o dispositivo não responder, o Catalyst 4500 deve enviar redirecionamentos para cada pacote que o switch recebe do dispositivo emissor. Esses redirecionamentos podem consumir uma grande quantidade de recursos da CPU. A solução é desativar o redirecionamento ICMP. Emita o comando no ip redirects nas interfaces.
Esse cenário pode ocorrer quando você também tiver configurado endereços IP secundários. Quando você ativa os endereços IP secundários, o redirecionamento IP é automaticamente desativado. Certifique-se de não habilitar manualmente os redirecionamentos de IP.
Como este ICMP Redireciona; A seção Routing Packets on the Same Interface indicou que a maioria dos dispositivos finais não responde a redirecionamentos ICMP. Portanto, como uma prática geral, desative esse recurso.
Roteamento IPX ou AppleTalk
O Catalyst 4500 suporta o roteamento IPX e AppleTalk somente por caminho de encaminhamento de software. Com a configuração de tais protocolos, uma maior utilização da CPU é normal.
Observação: a comutação do tráfego IPX e AppleTalk na mesma VLAN não exige comutação de processos. Somente os pacotes que precisam ser roteados exigem o encaminhamento de caminho de software.
Passo 1: Verifique o processo do Cisco IOS com o comando show processes cpu.
Emita o comando show processes cpu para verificar qual processo do Cisco IOS consome a CPU. Nesta saída do comando, observe que o processo superior é o Cat4k Mgmt LoPri :
witch#show processes cpu CPU utilization for five seconds: 87%/10%; one minute: 86%; five minutes: 87% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 53 75 0.00% 0.00% 0.00% 0 Chunk Manager !--- Output suppressed. 25 8008 1329154 6 0.00% 0.00% 0.00% 0 Per-Second Jobs 26 413128 38493 10732 0.00% 0.02% 0.00% 0 Per-minute Jobs 27 148288424 354390017 418 2.60% 2.42% 2.77% 0 Cat4k Mgmt HiPri 28 285796820 720618753 396 50.15% 59.72% 61.31% 0 Cat4k Mgmt LoPri
Passo 2: Verifique o processo específico do Catalyst 4500 com o comando show platform health.
A saída do comando show platform health confirma o uso da CPU para processar pacotes vinculados à CPU.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 4 100 500 0 0 0 0:00
K2CpuMan Review 30.00 27.39 30 53 100 500 42 47 42 4841:
K2AccelPacketMan: Tx 10.00 8.03 20 0 100 500 21 29 26 270:4
Passo 3: Verifique a fila da CPU que recebe tráfego para identificar o tipo de tráfego vinculado à CPU.
Para determinar o tipo de tráfego que atinge a CPU, execute o comando show platform cpu packet statistics.
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 48613268 38 39 38 39 Control 142166648 74 74 73 73 Host Learning 1845568 2 2 2 2 L3 Fwd High 17 0 0 0 0 L3 Fwd Medium 2626 0 0 0 0 L3 Fwd Low 1582414 1 1 1 1 L2 Fwd Medium 1 0 0 0 0 L2 Fwd Low 576905398 1837 1697 1938 1515 L3 Rx High 257147 0 0 0 0 L3 Rx Low 5325772 10 19 13 7 RPF Failure 155 0 0 0 0 ACL fwd(snooping) 65604591 53 54 54 53 ACL log, unreach 11013420 9 8 8 8
Passo 4: Identifique a causa raiz.
Como o administrador configurou o roteamento IPX ou AppleTalk, a identificação da causa raiz deve ser direta. Mas, para confirmar, faça SPAN no tráfego da CPU e certifique-se de que o tráfego que você vê é o tráfego esperado. Para obter informações sobre o SPAN da CPU, consulte a Ferramenta 1: Monitore o tráfego da CPU com o SPAN—Cisco IOS Software Release 12.1(19)EW e Posterior deste documento.
Nesse caso, o administrador deve atualizar a CPU da linha de base para o valor atual. A CPU do Catalyst 4500 se comporta conforme esperado quando a CPU processa pacotes comutados por software.
Aprendizado de host
O Catalyst 4500 aprende os endereços MAC de vários hosts, se o endereço MAC ainda não estiver na tabela de endereços MAC. O mecanismo de switching encaminha uma cópia do pacote com o novo endereço MAC para a CPU.
Todas as interfaces VLAN (camada 3) usam o endereço de hardware base do chassi como seu endereço MAC. Como resultado, não há uma entrada na tabela de endereços MAC, e os pacotes destinados a essas interfaces VLAN não são enviados à CPU para processamento.
Se houver um número excessivo de novos endereços MAC para que o switch aprenda, pode ocorrer uma alta utilização da CPU.
Passo 1: Verifique o processo do Cisco IOS com o comando show processes cpu.
Emita o comando show processes cpu para verificar qual processo do Cisco IOS consome a CPU. Nesta saída do comando, observe que o processo superior é o Cat4k Mgmt LoPri :
Switch#show processes cpu CPU utilization for five seconds: 89%/1%; one minute: 74%; five minutes: 71% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 53 75 0.00% 0.00% 0.00% 0 Chunk Manager !--- Output suppressed. 25 8008 1329154 6 0.00% 0.00% 0.00% 0 Per-Second Jobs 26 413128 38493 10732 0.00% 0.02% 0.00% 0 Per-minute Jobs 27 148288424 354390017 418 26.47% 10.28% 10.11% 0 Cat4k Mgmt HiPri 28 285796820 720618753 396 52.71% 56.79% 55.70% 0 Cat4k Mgmt LoPri
Passo 2: Verifique o processo específico do Catalyst 4500 com o comando show platform health.
A saída do comando show platform health confirma o uso da CPU para processar pacotes vinculados à CPU.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 4 100 500 0 0 0 0:00
K2CpuMan Review 30.00 46.88 30 47 100 500 30 29 21 265:01
K2AccelPacketMan: Tx 10.00 8.03 20 0 100 500 21 29 26 270:4
Passo 3: Verifique a fila da CPU que recebe tráfego para identificar o tipo de tráfego vinculado à CPU.
Para determinar o tipo de tráfego que atinge a CPU, execute o comando show platform cpu packet statistics.
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 48613268 38 39 38 39 Control 142166648 74 74 73 73 Host Learning 1845568 1328 1808 1393 1309 L3 Fwd High 17 0 0 0 0 L3 Fwd Medium 2626 0 0 0 0 L3 Fwd Low 1582414 1 1 1 1 L2 Fwd Medium 1 0 0 0 0 L2 Fwd Low 576905398 37 7 8 5 L3 Rx High 257147 0 0 0 0 L3 Rx Low 5325772 10 19 13 7 RPF Failure 155 0 0 0 0 ACL fwd(snooping) 65604591 53 54 54 53 ACL log, unreach 11013420 9 8 8 8
Passo 4: Identifique a causa raiz.
A saída do comando show platform health mostra que a CPU vê muitos novos endereços MAC. Essa situação é geralmente o resultado da instabilidade da topologia de rede. Por exemplo, se a topologia spanning-tree mudar, o switch gera Notificações de alteração de topologia (TCNs). O problema dos TCNs reduz o tempo de envelhecimento para 15 segundos no modo PVST+. As entradas de endereço MAC serão liberadas se os endereços não forem aprendidos novamente dentro do período de tempo. No caso de Rapid STP (RSTP) (IEEE 802.1w) ou MST (IEEE 802.1s), as entradas expiram imediatamente se a TCN vem de outro switch. Esse tempo limite faz com que os endereços MAC sejam aprendidos novamente. Esse não é um problema principal se as alterações de topologia forem raras. Mas pode haver um número excessivo de alterações de topologia devido a um link oscilante, a um switch defeituoso ou a portas de host que não estão ativadas para PortFast. Um grande número de liberações de tabela MAC e consequente reaprendizado podem resultar. A próxima etapa na identificação da causa raiz é solucionar problemas na rede. O switch funciona como esperado e envia os pacotes para a CPU para o aprendizado de endereço de host. Identifique e corrija o dispositivo defeituoso que resulta em TCNs excessivos.
Sua rede pode ter muitos dispositivos que enviam tráfego em surtos, o que faz com que os endereços MAC sejam obsoletos e subsequentemente reaprendidos no switch. Nesse caso, aumente o tempo de envelhecimento da tabela de endereços MAC para fornecer algum alívio. Com um tempo de envelhecimento mais longo, os switches retêm os endereços MAC do dispositivo na tabela por um período mais longo antes do vencimento.
Cuidado: faça essa mudança de idade somente depois de uma cuidadosa consideração. A alteração pode levar a um buraco negro de tráfego se você tiver dispositivos na rede que sejam móveis.
Recursos de hardware (TCAM) para ACL de segurança
O Catalyst 4500 programa as ACLs configuradas com o uso do Cisco TCAM. O TCAM permite a aplicação das ACLs no caminho de encaminhamento de hardware. Não há impacto no desempenho do switch, com ou sem ACLs no caminho de encaminhamento. O desempenho é constante apesar do tamanho da ACL, pois o desempenho das pesquisas da ACL está na taxa de linha. No entanto, o TCAM é um recurso finito. Portanto, se você configurar um número excessivo de entradas de ACL, você excederá a capacidade de TCAM. A Tabela 3 mostra o número de recursos TCAM disponíveis em cada um dos Catalyst 4500 Supervisor Engines e switches.
Tabela 3 - Capacidade de TCAM em Catalyst 4500 Supervisor Engines/Switches| Produto | Recurso TCAM (por direção) | TCAM de QoS (por direção) |
|---|---|---|
| Supervisor Engine II+/II+TS | 8192 entradas com 1024 máscaras | 8192 entradas com 1024 máscaras |
| Supervisor Engine III/IV/V e Catalyst 4948 | 16.384 entradas com 2.048 máscaras | 16.384 entradas com 2.048 máscaras |
| Supervisor Engine V-10GE e Catalyst 4948-10GE | 16.384 entradas com 16.384 máscaras | 16.384 entradas com 16.384 máscaras |
O switch usa o recurso TCAM para programar a ACL de segurança, como RACL e VLAN ACL (VACL). O switch também usa o recurso TCAM para recursos de segurança como o IP Source Guard (IPSG) para ACLs dinâmicas. O switch usa a TCAM de QoS para programar a classificação e ACLs de policer.
Quando o Catalyst 4500 fica sem recursos de TCAM durante a programação de uma ACL de segurança, uma aplicação parcial da ACL ocorre através do caminho do software. Os pacotes que atingem essas ACEs são processados no software, o que causa alta utilização da CPU. A ACL é programada de cima para baixo. Em outras palavras, se a ACL não se encaixa no TCAM, a ACE na parte inferior da ACL provavelmente não é programada no TCAM.
Esta mensagem de aviso aparece quando ocorre um estouro de TCAM:
%C4K_HWACLMAN-4-ACLHWPROGERRREASON: (Suppressed 1times) Input(null, 12/Normal) Security: 140 - insufficient hardware TCAM masks. %C4K_HWACLMAN-4-ACLHWPROGERR: (Suppressed 4 times) Input Security: 140 - hardware TCAM limit, some packet processing will be software switched.
Você pode ver essa mensagem de erro na saída do comando show logging. A mensagem indica conclusivamente que algum processamento de software ocorrerá e, consequentemente, pode haver alta utilização da CPU.
Observação: se você alterar uma ACL grande, poderá ver esta mensagem brevemente antes que a ACL alterada seja programada novamente no TCAM.
Passo 1: Verifique o processo do Cisco IOS com o comando show processes cpu.
Emita o comando show processes cpu. Você pode ver que a utilização da CPU é alta porque o processo Cat4k Mgmt LoPri ocupa a maioria dos ciclos da CPU.
Switch#show processes cpu CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 11 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 9716 632814 15 0.00% 0.00% 0.00% 0 Load Meter 3 780 302 2582 0.00% 0.00% 0.00% 0 SpanTree Helper !--- Output suppressed. 23 18208 3154201 5 0.00% 0.00% 0.00% 0 TTY Background 24 37208 3942818 9 0.00% 0.00% 0.00% 0 Per-Second Jobs 25 1046448 110711 9452 0.00% 0.03% 0.00% 0 Per-minute Jobs 26 175803612 339500656 517 4.12% 4.31% 4.48% 0 Cat4k Mgmt HiPri 27 835809548 339138782 2464 86.81% 89.20% 89.76% 0 Cat4k Mgmt LoPri 28 28668 2058810 13 0.00% 0.00% 0.00% 0 Galios Reschedul
Passo 2: Verifique o processo específico do Catalyst 4500 com o comando show platform health.
Emita o comando show platform health. Você pode ver que a K2CpuMan Review, uma tarefa para lidar com pacotes vinculados à CPU, usa a CPU.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.01 2 0 100 500 0 0 0 13:45
GalChassisVp-review 3.00 0.20 10 16 100 500 0 0 0 88:44
S2w-JobEventSchedule 10.00 0.57 10 7 100 500 1 0 0 404:22
Stub-JobEventSchedul 10.00 0.00 10 0 100 500 0 0 0 0:00
StatValueMan Update 1.00 0.09 1 0 100 500 0 0 0 91:33
Pim-review 0.10 0.00 1 0 100 500 0 0 0 4:46
Ebm-host-review 1.00 0.00 8 4 100 500 0 0 0 14:01
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:20
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:01
Acl-Flattener 1.00 0.00 10 5 100 500 0 0 0 0:04
KxAclPathMan create/ 1.00 0.00 10 5 100 500 0 0 0 0:21
KxAclPathMan update 2.00 0.00 10 6 100 500 0 0 0 0:05
KxAclPathMan reprogr 1.00 0.00 2 1 100 500 0 0 0 0:00
TagMan-InformMtegRev 1.00 0.00 5 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 14 100 500 0 0 0 0:18
K2CpuMan Review 30.00 91.31 30 92 100 500 128 119 84 13039:02
K2AccelPacketMan: Tx 10.00 2.30 20 0 100 500 2 2 2 1345:30
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
Passo 3: Verifique a fila da CPU que recebe tráfego para identificar o tipo de tráfego vinculado à CPU.
Você precisa entender melhor qual fila da CPU e, portanto, que tipo de tráfego atinge a fila da CPU. Emita o comando show platform cpu packet statistics. Você pode ver que a fila de processamento de sw da ACL recebe um alto número de pacotes. Portanto, o estouro de TCAM é a causa desse problema de alta utilização da CPU.
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Control 57902635 22 16 12 3 Host Learning 464678 0 0 0 0 L3 Fwd Low 623229 0 0 0 0 L2 Fwd Low 11267182 7 4 6 1 L3 Rx High 508 0 0 0 0 L3 Rx Low 1275695 10 1 0 0 ACL fwd(snooping) 2645752 0 0 0 0 ACL log, unreach 51443268 9 4 5 5 ACL sw processing 842889240 1453 1532 1267 1179 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- L2 Fwd Low 3270 0 0 0 0 ACL sw processing 12636 0 0 0 0
Passo 4: A solucionar o problema.
Na Etapa 3, você determinou a causa raiz neste cenário. Remova a ACL que causou o estouro ou minimize a ACL para evitar o estouro. Além disso, revise a diretriz de configuração Configurando a Segurança de Rede com ACLs para otimizar a configuração e programação da ACL no hardware.
A palavra-chave do registro na ACL
O Catalyst 4500 suporta o registro de detalhes de pacotes que atingem qualquer entrada específica da ACL, mas o registro excessivo pode causar alta utilização da CPU. Evite o uso de palavras-chave log, exceto durante o estágio de descoberta de tráfego. Durante o estágio de descoberta de tráfego, você identifica o tráfego que flui pela rede para o qual não configurou explicitamente ACEs. Não use a palavra-chave log para coletar estatísticas. No Cisco IOS Software Release 12.1(13)EW e posterior, as mensagens de log são limitadas por taxa. Se você usar mensagens de log para contar o número de pacotes que correspondem à ACL, a contagem não é exata. Em vez disso, use o comando show access-list para obter estatísticas precisas. A identificação dessa causa raiz é mais fácil porque uma revisão da configuração ou das mensagens de log pode indicar o uso do recurso de registro da ACL.
Passo 1: Verifique o processo do Cisco IOS com o comando show processes cpu.
Emita a cpu show processes para verificar qual processo do Cisco IOS consome a CPU. Nesta saída do comando, você descobre que o processo superior é o Cat4k Mgmt LoPri :
Switch#show processes cpu CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 11 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 9716 632814 15 0.00% 0.00% 0.00% 0 Load Meter !--- Output suppressed. 26 175803612 339500656 517 4.12% 4.31% 4.48% 0 Cat4k Mgmt HiPri 27 835809548 339138782 2464 86.81% 89.20% 89.76% 0 Cat4k Mgmt LoPri 28 28668 2058810 13 0.00% 0.00% 0.00% 0 Galios Reschedul
Passo 2: Verifique o processo específico do Catalyst 4500 com o comando show platform health.
Verifique o processo específico da plataforma que usa a CPU. Emita o comando show platform health. Na saída, observe que o processo K2CpuMan Review usa a maioria dos ciclos da CPU. Esta atividade indica que a CPU está ocupada enquanto processa pacotes destinados a ela.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.01 2 0 100 500 0 0 0 13:45
GalChassisVp-review 3.00 0.20 10 16 100 500 0 0 0 88:44
S2w-JobEventSchedule 10.00 0.57 10 7 100 500 1 0 0 404:22
Stub-JobEventSchedul 10.00 0.00 10 0 100 500 0 0 0 0:00
StatValueMan Update 1.00 0.09 1 0 100 500 0 0 0 91:33
Pim-review 0.10 0.00 1 0 100 500 0 0 0 4:46
Ebm-host-review 1.00 0.00 8 4 100 500 0 0 0 14:01
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:20
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:01
Acl-Flattener 1.00 0.00 10 5 100 500 0 0 0 0:04
KxAclPathMan create/ 1.00 0.00 10 5 100 500 0 0 0 0:21
KxAclPathMan update 2.00 0.00 10 6 100 500 0 0 0 0:05
KxAclPathMan reprogr 1.00 0.00 2 1 100 500 0 0 0 0:00
TagMan-InformMtegRev 1.00 0.00 5 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 14 100 500 0 0 0 0:18
K2CpuMan Review 30.00 91.31 30 92 100 500 128 119 84 13039:02
K2AccelPacketMan: Tx 10.00 2.30 20 0 100 500 2 2 2 1345:30
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
Passo 3: Verifique a fila da CPU que recebe tráfego para identificar o tipo de tráfego vinculado à CPU.
Para determinar o tipo de tráfego que atinge a CPU, execute o comando show platform cpu packet statistics. Nesta saída do comando, você pode ver que o recebimento de pacotes é devido à palavra-chave log da ACL:
Switch#show platform cpu packet statistics !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ----------------- -------------------- --------- --------- --------- ---------- Control 1198701435 35 35 34 35 Host Learning 874391 0 0 0 0 L3 Fwd High 428 0 0 0 0 L3 Fwd Medium 12745 0 0 0 0 L3 Fwd Low 2420401 0 0 0 0 L2 Fwd High 26855 0 0 0 0 L2 Fwd Medium 116587 0 0 0 0 L2 Fwd Low 317829151 53 41 31 31 L3 Rx High 2371 0 0 0 0 L3 Rx Low 32333361 7 1 2 0 RPF Failure 4127 0 0 0 0 ACL fwd (snooping) 107743299 4 4 4 4 ACL log, unreach 1209056404 1987 2125 2139 2089 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ----------------- -------------------- --------- --------- --------- ---------- ACL log, unreach 193094788 509 362 437 394
Passo 4: A solucionar o problema.
Na Etapa 3, você determinou a causa raiz neste cenário. Para evitar esse problema, remova a palavra-chave log das ACLs. No Cisco IOS Software Release 12.1(13)EW1 e posterior, os pacotes são limitados por taxa para que a utilização da CPU não fique muito alta. Use os contadores da lista de acesso como uma forma de controlar os acertos da ACL. Você pode ver os contadores da lista de acesso na saída do comando show access-list acl_id.
Loops de encaminhamento da camada 2
Os loops de encaminhamento da camada 2 podem ser causados pela implementação inadequada do Spanning Tree Protocol (STP) e por vários problemas que podem afetar o STP.
Passo 1: Verifique o processo do Cisco IOS com o comando show processes cpu
Esta seção analisa os comandos que um administrador usa para restringir o problema de alta utilização da CPU. Se você executar o comando show processes cpu, você poderá ver que dois processos principais, Cat4k Mgmt LoPri e Spanning Tree , usam principalmente a CPU. Com apenas essas informações, você sabe que o processo de spanning tree consome uma parte considerável dos ciclos da CPU.
Switch#show processes cpu CPU utilization for five seconds: 74%/1%; one minute: 73%; five minutes: 50% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 198 20 0.00% 0.00% 0.00% 0 Chunk Manager 2 4 290 13 0.00% 0.00% 0.00% 0 Load Meter !--- Output suppressed. 25 488 33 14787 0.00% 0.02% 0.00% 0 Per-minute Jobs 26 90656 223674 405 6.79% 6.90% 7.22% 0 Cat4k Mgmt HiPri 27 158796 59219 2681 32.55% 33.80% 21.43% 0 Cat4k Mgmt LoPri 28 20 1693 11 0.00% 0.00% 0.00% 0 Galios Reschedul 29 0 1 0 0.00% 0.00% 0.00% 0 IOS ACL Helper 30 0 2 0 0.00% 0.00% 0.00% 0 NAM Manager !--- Output suppressed. 41 0 1 0 0.00% 0.00% 0.00% 0 SFF8472 42 0 2 0 0.00% 0.00% 0.00% 0 AAA Dictionary R 43 78564 20723 3791 32.63% 30.03% 17.35% 0 Spanning Tree 44 112 999 112 0.00% 0.00% 0.00% 0 DTP Protocol 45 0 147 0 0.00% 0.00% 0.00% 0 Ethchnl
Passo 2: Verifique o processo específico do Catalyst 4500 com o comando show platform health
Para entender qual processo específico da plataforma consome a CPU, emita o comando show platform health. A partir dessa saída, você pode ver que o processo K2CpuMan Review, um trabalho para lidar com pacotes vinculados à CPU, usa a CPU:
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 30.00 37.62 30 53 100 500 41 33 1 2:12
K2AccelPacketMan: Tx 10.00 4.95 20 0 100 500 5 4 0 0:36
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
Passo 3: Verifique a fila da CPU que recebe tráfego para identificar o tipo de tráfego vinculado à CPU
Emita o comando show platform cpu packet statistics para verificar qual fila de CPU recebe o pacote associado à CPU. A saída nesta seção mostra que a fila de controle recebe muitos pacotes. Use as informações da Tabela 1 e a conclusão que você tirou na Etapa 1. Você pode determinar que os pacotes que a CPU processa e o motivo para a alta utilização da CPU é o processamento de BPDU.
Switch#show platform cpu packet statistics !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 202760 196 173 128 28 Control 388623 2121 1740 598 16 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Control 17918 0 19 24 3
Passo 4: Identificar a causa raiz e corrigir o problema
Geralmente, você pode concluir estas etapas para solucionar problemas (dependendo da situação, algumas etapas não são necessárias):
-
Identifique o loop.
-
Descubra o escopo do loop.
-
Interromper o loop.
-
Corrija a causa do loop.
-
Restaurar redundância.
Cada uma das etapas é explicada em detalhes em Troubleshooting de Loops de Encaminhamento - Troubleshooting de STP em Catalyst Switches com Cisco IOS System Software.
Passo 5: Implementar recursos avançados de STP
-
BDPU Guard —Protege o STP de dispositivos de rede não autorizados conectados a portas habilitadas para portfast. Consulte Aprimoramento do Protetor de BPDU do PortFast do Spanning Tree para obter mais informações.
-
Protetor de loop—Aumenta a estabilidade das redes da camada 2. Consulte Aprimoramentos do Spanning Tree Protocol usando os Recursos de Detecção de Desvio de Loop Guard e BPDU para obter mais informações.
-
Protetor de Raiz — Aplica o posicionamento da bridge raiz na rede. Consulte Aprimoramento do Protetor de Raiz do Spanning Tree Protocol para obter mais informações.
-
UDLD — Detecta links unidirecionais e evita loops de encaminhamento. Consulte Compreendendo e Configurando o Recurso Unidirectional Link Detection Protocol para obter mais informações.
Outras causas de alta utilização da CPU
Estas são algumas outras causas conhecidas da alta utilização da CPU:
-
Spikes na utilização da CPU devido à verificação de consistência FIB
-
Alta utilização da CPU quando conectada a um telefone IP com o uso de portas de tronco
-
Alta utilização da CPU com RSPAN e pacotes de controle de Camada 3
-
Spike durante programação de ACL grande
O pico na utilização da CPU ocorre durante a aplicação ou remoção de uma ACL grande de uma interface.
Flaps de link excessivos
O Catalyst 4500 exibe alta utilização da CPU quando um ou mais dos links conectados começa a oscilar excessivamente. Essa situação ocorre em versões do Cisco IOS Software anteriores à versão 12.2(20)EWA do Cisco IOS Software.
Passo 1: Verifique o processo do Cisco IOS com o comando show processes cpu.
Emita o comando show processes cpu para verificar qual processo do Cisco IOS consome a CPU. Nesta saída do comando, observe que o processo superior é o Cat4k Mgmt LoPri :
Switch#show processes cpu CPU utilization for five seconds: 96%/0%; one minute: 76%; five minutes: 68% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 9840 463370 21 0.00% 0.00% 0.00% 0 Load Meter 3 0 2 0 0.00% 0.00% 0.00% 0 SNMP Timers !--- Output suppressed. 27 232385144 530644966 437 13.98% 12.65% 12.16% 0 Cat4k Mgmt HiPri 28 564756724 156627753 3605 64.74% 60.71% 54.75% 0 Cat4k Mgmt LoPri 29 9716 1806301 5 0.00% 0.00% 0.00% 0 Galios Reschedul
Passo 2: Verifique o processo específico do Catalyst 4500 com o comando show platform health.
A saída do comando show platform health indica que o processo de criação do KxAclPathMan utiliza a CPU. Esse processo é para criação de caminho interno.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.03 2 0 100 500 0 0 0 9:49
GalChassisVp-review 3.00 1.11 10 62 100 500 0 0 0 37:39
S2w-JobEventSchedule 10.00 2.85 10 8 100 500 2 2 2 90:00
Stub-JobEventSchedul 10.00 5.27 10 9 100 500 4 4 4 186:2
Pim-review 0.10 0.00 1 0 100 500 0 0 0 2:51
Ebm-host-review 1.00 0.00 8 4 100 500 0 0 0 8:06
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:14
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:00
Acl-Flattener 1.00 0.00 10 5 100 500 0 0 0 0:00
KxAclPathMan create/ 1.00 69.11 10 5 100 500 42 53 22 715:0
KxAclPathMan update 2.00 0.76 10 6 100 500 0 0 0 86:00
KxAclPathMan reprogr 1.00 0.00 2 1 100 500 0 0 0 0:00
TagMan-InformMtegRev 1.00 0.00 5 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 227 100 500 0 0 0 0:00
K2CpuMan Review 30.00 8.05 30 57 100 500 6 5 5 215:0
K2AccelPacketMan: Tx 10.00 6.86 20 0 100 500 5 5 4 78:42
Passo 3: Identifique a causa raiz.
Ative o registro para mensagens de link ativo/inativo. Esse registro não está habilitado por padrão. A habilitação ajuda a restringir os links ofensivos muito rapidamente. Emita o comando logging event link-status em todas as interfaces. Você pode usar o comando interface range para habilitar convenientemente em um intervalo de interfaces, como mostrado neste exemplo:
Switch#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#interface range gigabitethernet 5/1 - 48 Switch(config-if-range)#logging event link-status Switch(config--if-range)#end
Switch#show logging !--- Output suppressed. 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to down 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to up 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to down 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to up 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to down 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to up
Depois de identificar a interface com falha ou oscilante, desligue a interface para resolver o problema de alta utilização da CPU. O Cisco IOS Software Release 12.2(20)EWA e posterior melhorou o comportamento do Catalyst 4500 para essa condição de links oscilantes. Portanto, o impacto na CPU não é tão grande quanto antes da melhora. Lembre-se de que esse processo é um processo em segundo plano. A alta utilização da CPU devido a esse problema não causa efeitos adversos nos switches Catalyst 4500.
Spikes na utilização da CPU devido à verificação de consistência FIB
O Catalyst 4500 pode mostrar picos momentâneos na utilização da CPU durante uma verificação de consistência da tabela FIB. A tabela FIB é a tabela de encaminhamento L3 criada pelo processo CEF. A verificação de consistência mantém a consistência entre a tabela FIB do software Cisco IOS e as entradas de hardware. Essa consistência garante que os pacotes não sejam roteados incorretamente. A verificação ocorre a cada 2 segundos e é executada como um processo em segundo plano de baixa prioridade. Esse processo é um comportamento normal e não interfere em outros processos ou pacotes de alta prioridade.
A saída do comando show platform health mostra que o K2Fib Consistency Ch consome a maior parte da CPU.
Observação: a utilização média da CPU para esse processo é insignificante em um minuto ou uma hora, o que confirma que a verificação é uma breve revisão periódica. Esse processo em segundo plano usa apenas os ciclos ociosos da CPU.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
!--- Output suppressed.
K2Fib cam usage revi 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib IrmFib Review 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Default Ro 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib AdjRepop Revie 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Unpunt Rev 2.00 0.01 15 0 100 500 0 0 0 0:23
K2Fib Consistency Ch 1.00 60.40 5 2 100 500 0 0 0 100:23
K2FibAdjMan Stats Re 2.00 0.30 10 4 100 500 0 0 0 6:21
K2FibAdjMan Host Mov 2.00 0.00 10 4 100 500 0 0 0 0:00
K2FibAdjMan Adj Chan 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibMulticast Signa 2.00 0.01 10 2 100 500 0 0 0 2:04
Alta utilização da CPU no processo de movimentação do host K2FibAdjMan
O Catalyst 4500 pode exibir alta utilização da CPU no processo K2FibAdjMan Host Move. Essa alta utilização aparece na saída do comando show platform health. Muitos endereços MAC frequentemente expiram ou são aprendidos em novas portas, o que causa essa alta utilização da CPU. O valor padrão de mac-address-table aging-time é 5 minutos ou 300 segundos. A solução para esse problema é aumentar o tempo de envelhecimento do endereço MAC ou você pode projetar a rede para evitar o alto número de movimentações de endereço MAC. O Cisco IOS Software Release 12.2(18)EW e posteriores aprimoraram esse comportamento de processo para consumir menos CPU. Consulte o bug da Cisco ID CSCed15021 
(somente clientes registrados) .
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
S2w-JobEventSchedule 10.00 0.32 10 7 100 500 0 0 0 10:14
!--- Output suppressed.
K2FibAdjMan Stats Re 2.00 0.30 10 4 100 500 0 0 0 6:21
K2FibAdjMan Host Mov 2.00 18.68 10 4 100 500 25 29 28 2134:39
K2FibAdjMan Adj Chan 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibMulticast Signa 2.00 0.01 10 2 100 500 0 0 0 2:04
K2FibMulticast Entry 2.00 0.00 10 7 100 500 0 0 0 0:00
Você pode modificar o tempo máximo de envelhecimento de um endereço MAC no modo de configuração global. A sintaxe do comando é mac-address-table aging-time seconds para um roteador e mac-address-table aging-time seconds [vlan vlan-id] para um Switch Catalyst. Para obter mais informações, consulte o Guia de Referência de Comandos do Cisco IOS Switching Services.
Alta utilização da CPU no processo de revisão da porta RkiosPortMan
O Catalyst 4500 pode exibir alta utilização da CPU no processo RkiosPortMan Port Review na saída do comando show platform health no Cisco IOS Software Release 12.2(25)EWA e 12.2(25)EWA1. O bug da Cisco ID CSCeh08768 (somente clientes registrados) causa a alta utilização, que o Cisco IOS Software Release 12.2(25)EWA2 resolve. Esse processo é um processo em segundo plano e não afeta a estabilidade dos switches Catalyst 4500.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
S2w-JobEventSchedule 10.00 0.32 10 7 100 500 0 0 0 10:14
!--- Output suppressed.
K2 Packet Memory Dia 2.00 0.00 15 8 100 500 0 1 1 45:46
K2 L2 Aging Table Re 2.00 0.12 20 3 100 500 0 0 0 7:22
RkiosPortMan Port Re 2.00 87.92 12 7 100 500 99 99 89 1052:36
Rkios Module State R 4.00 0.02 40 1 100 500 0 0 0 1:28
Rkios Online Diag Re 4.00 0.02 40 0 100 500 0 0 0 1:15
Alta utilização da CPU quando conectada a um telefone IP com o uso de portas de tronco
Se uma porta estiver configurada para a opção de VLAN de voz e para a opção de VLAN de acesso, a porta atuará como uma porta de acesso multi-VLAN. A vantagem é que somente as VLANs configuradas para as opções de VLAN de voz e acesso são entroncadas.
As VLANs que estão entroncadas no telefone aumentam o número de instâncias de STP. O switch gerencia as instâncias do STP. O gerenciamento do aumento nas instâncias do STP também aumenta a utilização da CPU do STP.
O entroncamento de todas as VLANs também faz com que tráfego desnecessário de broadcast, multicast e unicast desconhecido atinja o link do telefone.
Switch#show processes cpu CPU utilization for five seconds: 69%/0%; one minute: 72%; five minutes: 73% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 165 24 0.00% 0.00% 0.00% 0 Chunk Manager 2 29012 739091 39 0.00% 0.00% 0.00% 0 Load Meter 3 67080 13762 4874 0.00% 0.00% 0.00% 0 SpanTree Helper 4 0 1 0 0.00% 0.00% 0.00% 0 Deferred Events 5 0 2 0 0.00% 0.00% 0.00% 0 IpSecMibTopN 6 4980144 570766 8725 0.00% 0.09% 0.11% 0 Check heaps 26 539173952 530982442 1015 13.09% 13.05% 13.20% 0 Cat4k Mgmt HiPri 27 716335120 180543127 3967 17.61% 18.19% 18.41% 0 Cat4k Mgmt LoPri 33 1073728 61623 17424 0.00% 0.03% 0.00% 0 Per-minute Jobs 34 1366717824 231584970 5901 38.99% 38.90% 38.92% 0 Spanning Tree 35 2218424 18349158 120 0.00% 0.03% 0.02% 0 DTP Protocol 36 5160 369525 13 0.00% 0.00% 0.00% 0 Ethchnl 37 271016 2308022 117 0.00% 0.00% 0.00% 0 VLAN Manager 38 958084 3965585 241 0.00% 0.01% 0.01% 0 UDLD 39 1436 51011 28 0.00% 0.00% 0.00% 0 DHCP Snooping 40 780 61658 12 0.00% 0.00% 0.00% 0 Port-Security 41 1355308 12210934 110 0.00% 0.01% 0.00% 0 IP Input
Alta utilização da CPU com RSPAN e pacotes de controle de Camada 3
Os pacotes de controle de Camada 3 que são capturados com RSPAN são destinados à CPU, em vez de apenas à interface de destino RSPAN, que causa alta CPU. Os pacotes de controle L3 são capturados por entradas CAM estáticas com ação de encaminhamento para a CPU. As entradas CAM estáticas são globais para todas as VLANs. Para evitar inundação desnecessária de CPU, use o recurso Interceptação de tráfego de controle por VLAN, disponível nas versões 12.2(37)SG e posteriores do software Cisco IOS.
Switch(config)# access-list hardware capture mode vlan
As ACLs estáticas são instaladas na parte superior do recurso de entrada TCAM para capturar pacotes de controle destinados a endereços IP multicast conhecidos no intervalo 224.0.0.*. As ACLs estáticas são instaladas no momento da inicialização e aparecem antes de qualquer ACL configurada pelo usuário. As ACLs estáticas são sempre atingidas primeiro e interceptam o tráfego de controle para a CPU em todas as VLANs.
O recurso de interceptação de tráfego de controle por VLAN fornece o modo seletivo de gerenciamento de caminho por VLAN para capturar o tráfego de controle. As entradas CAM estáticas correspondentes no recurso de entrada TCAM são invalidadas no novo modo. Os pacotes de controle são capturados pela ACL específica do recurso conectada às VLANs nas quais os recursos de rastreamento ou roteamento estão ativados. Não há uma ACL específica de recurso conectada à VLAN de RSPAN. Portanto, todos os pacotes de controle da camada 3 recebidos da VLAN RSPAN não são encaminhados à CPU.
Ferramentas de identificação e solução de problemas para analisar o tráfego destinado à CPU
Como mostrado neste documento, o tráfego destinado à CPU é uma das principais causas da alta utilização da CPU no Catalyst 4500. O tráfego destinado à CPU pode ser intencional devido à configuração ou não intencional devido a uma configuração incorreta ou a um ataque de negação de serviço. A CPU tem um mecanismo de QoS interno para evitar quaisquer efeitos adversos na rede devido a esse tráfego. No entanto, identifique a causa raiz do tráfego vinculado à CPU e elimine o tráfego se ele for indesejável.
Ferramenta 1: Monitore o tráfego da CPU com SPAN—Cisco IOS Software Release 12.1(19)EW e Posterior
O Catalyst 4500 permite o monitoramento do tráfego associado à CPU, de entrada ou saída, com o uso da função de SPAN padrão. A interface de destino se conecta a um monitor de pacote ou a um laptop administrador que executa o software de sniffer de pacotes. Essa ferramenta ajuda a analisar de forma rápida e precisa o tráfego que a CPU processa. A ferramenta permite monitorar filas individuais vinculadas ao mecanismo de pacote da CPU.
Observação: o mecanismo de switching tem 32 filas para o tráfego da CPU e o mecanismo de pacote da CPU tem 16 filas.
Switch(config)#monitor session 1 source cpu ?
both Monitor received and transmitted traffic
queue SPAN source CPU queue
rx Monitor received traffic only
tx Monitor transmitted traffic only
<cr>
Switch(config)#monitor session 1 source cpu queue ?
<1-32> SPAN source CPU queue numbers
acl Input and output ACL [13-20]
adj-same-if Packets routed to the incoming interface [7]
all All queues [1-32]
bridged L2/bridged packets [29-32]
control-packet Layer 2 Control Packets [5]
mtu-exceeded Output interface MTU exceeded [9]
nfl Packets sent to CPU by netflow (unused) [8]
routed L3/routed packets [21-28]
rpf-failure Multicast RPF Failures [6]
span SPAN to CPU (unused) [11]
unknown-sa Packets with missing source address [10]
Switch(config)#monitor session 1 source cpu queue all rx
Switch(config)#monitor session 1 destination interface gigabitethernet 1/3
Switch(config)#end
4w6d: %SYS-5-CONFIG_I: Configured from console by console
Switch#show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
RX Only : CPU
Destination Ports : Gi1/3
Encapsulation : Native
Ingress : Disabled
Learning : Disabled
Se você conectar um PC que executa um programa de farejador, poderá analisar rapidamente o tráfego. Na saída exibida na janela desta seção, você pode ver que a causa da alta utilização da CPU é um número excessivo de BPDUs STP.
Observação: BPDUs STP no sniffer de CPU é normal. Mas se você vir mais do que o esperado, talvez tenha excedido os limites recomendados para o Supervisor Engine. Consulte a seção Um Alto Número de Instâncias de Portas Spanning-Tree deste documento para obter mais informações.
Ferramenta 2: Sniffer de CPU integrado—Cisco IOS Software Release 12.2(20)EW e Mais Recente
O Catalyst 4500 fornece um farejador e decodificador de CPU integrados para identificar rapidamente o tráfego que atinge a CPU. Você pode habilitar esse recurso com o comando debug, como mostrado no exemplo desta seção. Esse recurso implementa um buffer circular que pode reter 1024 pacotes de cada vez. À medida que chegam novos pacotes, eles sobrescrevem os pacotes mais antigos. Esse recurso é seguro para ser usado quando você soluciona problemas de alta utilização da CPU.
Switch#debug platform packet all receive buffer platform packet debugging is on Switch#show platform cpu packet buffered Total Received Packets Buffered: 36 ------------------------------------- Index 0: 7 days 23:6:32:37214 - RxVlan: 99, RxPort: Gi4/48 Priority: Crucial, Tag: Dot1Q Tag, Event: Control Packet, Flags: 0x40, Size: 68 Eth: Src 00-0F-F7-AC-EE-4F Dst 01-00-0C-CC-CC-CD Type/Len 0x0032 Remaining data: 0: 0xAA 0xAA 0x3 0x0 0x0 0xC 0x1 0xB 0x0 0x0 10: 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 0x63 0x28 20: 0x62 0x0 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 30: 0x63 0x28 0x62 0x80 0xF0 0x0 0x0 0x14 0x0 0x2 40: 0x0 0xF 0x0 0x0 0x0 0x0 0x0 0x2 0x0 0x63 Index 1: 7 days 23:6:33:180863 - RxVlan: 1, RxPort: Gi4/48 Priority: Crucial, Tag: Dot1Q Tag, Event: Control Packet, Flags: 0x40, Size: 68 Eth: Src 00-0F-F7-AC-EE-4F Dst 01-00-0C-CC-CC-CD Type/Len 0x0032 Remaining data: 0: 0xAA 0xAA 0x3 0x0 0x0 0xC 0x1 0xB 0x0 0x0 10: 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 0x63 0x28 20: 0x62 0x0 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 30: 0x63 0x28 0x62 0x80 0xF0 0x0 0x0 0x14 0x0 0x2 40: 0x0 0xF 0x0 0x0 0x0 0x0 0x0 0x2 0x0 0x63
Observação: a utilização da CPU ao emitir um comando debug é sempre quase 100%. É normal ter alta utilização da CPU ao emitir um comando debug.
Ferramenta 3: Identificar a Interface que Envia Tráfego à CPU—Cisco IOS Software Release 12.2(20)EW e Posterior
O Catalyst 4500 fornece outra ferramenta útil para identificar as principais interfaces que enviam tráfego/pacotes para o processamento da CPU. Essa ferramenta ajuda a identificar rapidamente um dispositivo de erro que envia um alto número de ataques de broadcast ou de negação de serviço à CPU. Esse recurso também é seguro para ser usado quando você soluciona problemas de alta utilização da CPU.
Switch#debug platform packet all count platform packet debugging is on Switch#show platform cpu packet statistics !--- Output suppressed. Packets Transmitted from CPU per Output Interface Interface Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Gi4/47 1150 1 5 10 0 Gi4/48 50 1 0 0 0 Packets Received at CPU per Input Interface Interface Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Gi4/47 23130 5 10 50 20 Gi4/48 50 1 0 0 0
Observação: a utilização da CPU ao emitir um comando debug é sempre quase 100%. É normal ter alta utilização da CPU ao emitir um comando debug.
Summary
Os switches Catalyst 4500 lidam com uma alta taxa de encaminhamento de pacotes IP versão 4 (IPv4) em hardware. Alguns dos recursos ou exceções podem causar o encaminhamento de alguns pacotes através do caminho do processo da CPU. O Catalyst 4500 usa um mecanismo de QoS sofisticado para lidar com pacotes vinculados à CPU. Esse mecanismo garante a confiabilidade e a estabilidade dos switches e, ao mesmo tempo, maximiza a CPU para o encaminhamento de pacotes por software. O Cisco IOS Software Release 12.2(25)EWA2 e posterior fornece aprimoramentos adicionais para o tratamento de pacotes/processos, bem como contabilidade. O Catalyst 4500 também tem comandos e ferramentas poderosas suficientes para auxiliar na identificação da causa raiz de cenários de alta utilização da CPU. Mas, na maioria dos casos, a alta utilização da CPU no Catalyst 4500 não é uma causa de instabilidade de rede nem um motivo de preocupação.
Informações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
20-Mar-2008 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)