Alta Utilização da CPU do Switch Catalyst 6500/6000
Contents
Introdução
Este documento descreve as causas da utilização elevada da CPU nos Cisco Catalyst 6500/6000 Series Switches e nos sistemas com base no Sistema de Switching Virtual (VSS) 1440. Como os roteadores Cisco, os switches usam o comando show processes cpu para mostrar a utilização da CPU para o processador do mecanismo supervisor do switch. Contudo, devido às diferenças na arquitetura e nos mecanismos de encaminhamento entre roteadores e switches Cisco, as saídas típicas do comando show processes cpu diferem significativamente. O significado da saída também difere. Este documento esclarece essas diferenças e descreve a utilização da CPU nos switches e como interpretar a saída do comando show processes cpu.
Observação: neste documento, as palavras "switch" e "switches" referem-se aos Switches Catalyst 6500/6000.
Pré-requisitos
Requisitos
Não existem requisitos específicos para este documento.
Componentes Utilizados
As informações neste documento são baseadas nas versões de software e hardware para os Switches Catalyst 6500/6000 e sistemas baseados em VSS (Virtual Switching System) 1440.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Observação: o software suportado para sistemas baseados no Virtual Switching System (VSS) 1440 é o Cisco IOS® Software Release 12.2(33)SXH1 ou posterior.
Conventions
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Diferença entre os softwares dos sistemas CatOS e Cisco IOS
Catalyst OS (CatOS) no Supervisor Engine e Cisco IOS® Software no Multilayer Switch Feature Card (MSFC) (Híbrido): É possível usar uma imagem CatOS como o Software do sistema para executar o Mecanismo supervisor nos Switches Catalyst 6500/6000. Se o MSFC opcional está instalado, uma imagem de Cisco IOS Software separada é utilizada para executar o MSFC.
Cisco IOS Software em Supervisor Engine e MSFC (Nativo): É possível usar uma única imagem de Cisco IOS Software como o Software do sistema para executar o mecanismo supervisor e MSFC nos Switches Catalyst 6500/6000.
Observação: Consulte Comparação dos Sistemas Operacionais Cisco Catalyst e Cisco IOS para o Cisco Catalyst 6500 Series Switch para obter mais informações.
Entender a utilização da CPU nos Switches Catalyst 6500/6000
Os roteadores baseados em software da Cisco usam software para processar e rotear pacotes. A utilização da CPU em um roteador Cisco tende a aumentar à medida que o roteador executa mais processamento e roteamento de pacotes. Portanto, o comando show processes cpu pode oferecer uma indicação regularmente precisa da carga de processamento de tráfego no roteador.
Os Switches Catalyst 6500/6000 não usam a CPU da mesma maneira. These Switches make forwarding decisions in Hardware, not in Software. Portanto, quando os switches tomam a decisão de encaminhamento ou comutação para a maioria dos quadros que passam pelo switch, o processo não envolve a CPU do mecanismo supervisor.
Nos Switches Catalyst 6500/6000, há duas CPUs. Uma CPU é a do mecanismo supervisor, chamada de NMP (Network Management Processor Processador de Gerenciamento de Rede) ou SP (Switch Processor Processador de Switch). A outra CPU é a CPU do mecanismo de roteamento de Camada 3, chamada MSFC ou RP (Route Processor).
A CPU da controladora executa funções que incluem:
-
Auxilia na aprendizagem e no envelhecimento de endereços MAC
Observação: o aprendizado de endereço MAC também é chamado de configuração de caminho.
-
Executa protocolos e processos que fornecem controle de rede
Os exemplos incluem Spanning Tree Protocol (STP), Cisco Discovery Protocol (CDP), VLAN Trunk Protocol (VTP), Dynamic Trunking Protocol (DTP) e Port Aggregation Protocol (PAgP).
-
Lida com o tráfego de gerenciamento de rede destinado à CPU do switch
Os exemplos incluem tráfego Telnet, HTTP e Simple Network Management Protocol (SNMP).
A CPU do RP executa funções que incluem:
-
Cria e atualiza as tabelas de roteamento de Camada 3 e ARP (Address Resolution Protocol)
-
Gera a Base de Informações de Encaminhamento (FIB - Forwarding Information Base) do Cisco Express Forwarding (CEF) e as tabelas de adjacência e faz o download das tabelas na Placa de Recurso de Política (PFC - Policy Feature Card).
-
Lida com o tráfego de gerenciamento de rede destinado ao RP
Os exemplos incluem tráfego Telnet, HTTP e SNMP.
Situações e recursos que disparam o tráfego para ir para o software
Pacotes Destinados ao Switch
Qualquer pacote destinado ao switch vai para o software. Esses pacotes incluem:
-
Controlar pacotes
Os pacotes de controle são recebidos para STP, CDP, VTP, Hot Standby Router Protocol (HSRP), PAgP, Link Aggregation Control Protocol (LACP) e UniDirectional Link Detection (UDLD).
-
Atualizações do protocolo de roteamento
Exemplos desses protocolos são Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Border Gateway Protocol (BGP) e Open Shortest Path First Protocol (OSPF Protocol).
-
Tráfego SNMP destinado ao switch
-
Tráfego Telnet e Secure Shell Protocol (SSH) para o switch.
A alta utilização da CPU devido ao SSH é vista como:
00:30:50.793 SGT Tue Mar 20 2012 CPU utilization for five seconds: 83%/11%; one minute: 15%; five minutes: 8% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 3 6468 8568 754 69.30% 7.90% 1.68% 1 SSH Process
Inclua estes comandos no script EEM para verificar o número de sessões SSH estabelecidas quando a CPU fica alta:
-
Respostas ARP para solicitações ARP
Pacotes e Condições que Exigem Processamento Especial
Esta lista fornece tipos e condições de pacotes específicos que forçam os pacotes a serem tratados no software:
-
Pacotes com opções de IP, um Time to Live (TTL) expirado ou encapsulamento não Advanced Research Projects Agency (ARPA)
-
Pacotes com tratamento especial, como tunelamento
-
Fragmentação de IP
-
Pacotes que exigem mensagens do Internet Control Message Protocol (ICMP) do RP ou SP
-
Falha de verificação da unidade máxima de transmissão (MTU)
-
Pacotes com erros de IP, que incluem erros de checksum de IP e erros de comprimento
-
Se os pacotes de entrada retornarem um erro de bit (como o erro de bit único (SBE)), os pacotes serão enviados à CPU para processamento de software e corrigidos. O sistema aloca um buffer para eles e usa o recurso da CPU para corrigi-lo.
-
Quando o PBR e a lista de acesso reflexiva estão no caminho de um fluxo de tráfego, o pacote é comutado por software, o que requer um ciclo de CPU adicional.
-
Adjacência na mesma interface
-
Pacotes que falham na verificação Reverse Path Forwarding (RPF)—rpf-failure
-
Obter/receber
Glean refere-se a pacotes que requerem resolução ARP e receive refere-se a pacotes que caem no caso de recepção.
-
Tráfego de Internetwork Packet Exchange (IPX) que é comutado por software no Supervisor Engine 720 no Cisco IOS Software e no CatOS
O tráfego IPX também é comutado por software no Supervisor Engine 2/Cisco IOS Software, mas o tráfego é comutado por hardware no Supervisor Engine 2/CatOS. O tráfego IPX é comutado por hardware no Supervisor Engine 1A para ambos os sistemas operacionais.
-
tráfego AppleTalk
-
Condições completas dos recursos de hardware
Esses recursos incluem FIB, CAM (content-addressable memory) e TCAM (ternary CAM).
Recursos baseados em ACL
-
Tráfego negado pela lista de controle de acesso (ACL) com o recurso de inalcançáveis ICMP ativado
Observação: este é o padrão.
Alguns pacotes negados por ACL vazam para o MSFC se IP inalcançável estiver habilitado. Os pacotes que requerem inalcançáveis ICMP são vazados a uma taxa configurável pelo usuário. Por padrão, a taxa é de 500 pacotes por segundo (pps).
-
Filtragem IPX com base em parâmetros não suportados, como o host de origem
No Supervisor Engine 720, o processo do tráfego IPX de Camada 3 está sempre no software.
-
Entradas de controle de acesso (ACEs) que exigem registro, com a palavra-chave log
Isso se aplica aos recursos de log da ACL e de log da VLAN ACL (VACL). As ACEs na mesma ACL que não exigem registro ainda são processadas no hardware. O Supervisor Engine 720 com PFC3 suporta o limite de taxa de pacotes que são redirecionados para o MSFC para registro de ACL e VACL. O Supervisor Engine 2 suporta o limite de taxa de pacotes que são redirecionados para o MSFC para registro de VACL. O suporte para registro de ACL no Supervisor Engine 2 está programado para a filial do Cisco IOS Software Release 12.2S.
-
Tráfego roteado por política, com uso de match length, set ip precedence ou outros parâmetros não suportados
O parâmetro set interface tem suporte no software. No entanto, o parâmetro set interface null 0 é uma exceção. Esse tráfego é tratado no hardware no Supervisor Engine 2 com PFC2 e no Supervisor Engine 720 com PFC3.
-
Roteadores ACLs (RACLs) não IP e não IPX
Os RACLs não IP aplicam-se a todos os mecanismos de supervisão. As RACLs não-IPX aplicam-se somente ao Supervisor Engine 1a com PFC e ao Supervisor Engine 2 com PFC2.
-
Tráfego de broadcast negado em um RACL
-
Tráfego negado em uma verificação de unicast RPF (uRPF), ACL ACE
Essa verificação uRPF se aplica ao Supervisor Engine 2 com PFC2 e ao Supervisor Engine 720 com PFC3.
-
Proxy de autenticação
O tráfego sujeito ao proxy de autenticação pode ter taxa limitada no Supervisor Engine 720.
-
Segurança IP (IPsec) do software Cisco IOS
O tráfego sujeito à criptografia do Cisco IOS pode ter a taxa limitada no Supervisor Engine 720.
Recursos baseados em NetFlow
Os recursos baseados em NetFlow descritos nesta seção aplicam-se somente ao Supervisor Engine 2 e ao Supervisor Engine 720.
-
Os recursos baseados em NetFlow sempre precisam ver o primeiro pacote de um fluxo no software. Quando o primeiro pacote do fluxo alcança o software, os pacotes subsequentes do mesmo fluxo são comutados por hardware.
Essa disposição de fluxo aplica-se a ACLs reflexivas, Protocolo de Comunicação de Cache da Web (WCCP - Web Cache Communication Protocol) e Balanceamento de Carga do Servidor (SLB - Server Load Balancing) do Cisco IOS.
Observação: no Supervisor Engine 1, as ACLs reflexivas dependem de entradas TCAM dinâmicas para criar atalhos de hardware para um fluxo específico. O princípio é o mesmo: o primeiro pacote de um fluxo vai para o software. Os pacotes subsequentes para esse fluxo são comutados por hardware.
-
Com o recurso TCP Intercept, o handshake triplo e o fechamento de sessão são tratados no software. O restante do tráfego é processado no hardware.
Observação: os pacotes Synchronize (SYN), SYN Acknowledgement (SYN ACK) e ACK compreendem o handshake triplo. O fechamento da sessão ocorre com término (FIN) ou redefinição (RST).
-
Com a conversão de endereço de rede (NAT), o tráfego é tratado desta maneira:
-
No Supervisor Engine 720:
O tráfego que requer NAT é tratado no hardware após a conversão inicial. A conversão do primeiro pacote de um fluxo ocorre no software e os pacotes subsequentes desse fluxo são comutados por hardware. Para pacotes TCP, um atalho de hardware é criado na tabela NetFlow após a conclusão do handshake triplo do TCP.
-
No Supervisor Engine 2 e no Supervisor Engine 1:
Todo o tráfego que requer NAT é comutado por software.
-
-
O Controle de Acesso Baseado em Contexto (CBAC - Context-Based Access Control) usa atalhos do NetFlow para classificar o tráfego que requer inspeção. Em seguida, o CBAC envia apenas esse tráfego para o software. O CBAC é um recurso somente de software; o tráfego sujeito a inspeção não é comutado por hardware.
Observação: o tráfego sujeito a inspeção pode ter taxa limitada no Supervisor Engine 720.
Tráfego Multicast
-
Rastreamento de multicast independente de protocolo (PIM)
-
Rastreamento de Internet Group Management Protocol (IGMP) (TTL = 1)
Esse tráfego é realmente destinado ao roteador.
-
Rastreamento de descoberta de ouvinte multicast (MLD) (TTL = 1)
Esse tráfego é realmente destinado ao roteador.
-
erro de FIB
-
Pacotes multicast para registro que têm conexão direta com a origem multicast
Esses pacotes multicast são enviados em túnel para o ponto de encontro.
-
Multicast IP versão 6 (IPv6)
Outros recursos
-
Reconhecimento de aplicativo baseado em rede (NBAR)
-
Inspeção ARP, somente com CatOS
-
Segurança de porta, somente com CatOS
-
rastreamento de DHCP
Situações de IPv6
-
Pacotes com um cabeçalho de opção salto por salto
-
Pacotes com o mesmo endereço IPv6 destino dos roteadores
-
Pacotes que falham na verificação de imposição de escopo
-
Pacotes que excedem a MTU do link de saída
-
Pacotes com um TTL menor ou igual a 1
-
Pacotes com uma VLAN de entrada igual à VLAN de saída
-
uRPF IPv6
O software executa esse uRPF para todos os pacotes.
-
ACLs reflexivas IPv6
O software manipula essas ACLs reflexivas.
-
Prefixos de 6to4 para túneis ISATAP (IntraSite Automatic Tunnel Addressing Protocol) IPv6
O software lida com esse tunelamento. Todo o tráfego restante que entra em um túnel ISATAP é comutado por hardware.
Programador LCP e módulo DFC
Em uma placa de encaminhamento distribuído (DFC), o processo lcp schedulular que é executado em uma CPU alta não é um problema e não representa nenhum problema para a operação. O cronograma do LCP faz parte do código do firmware. Em todos os módulos que não exigem uma DFC, o firmware é executado em um processador específico chamado LCP (Line Card Processor Processador de Placa de Linha). Esse processador é usado para programar o hardware ASIC e para se comunicar com o módulo supervisor central.
Quando o agendador lcp é iniciado, ele utiliza todo o tempo de processo disponível. Mas quando um novo processo precisa de tempo do processador, o lcp schedulular libera tempo do processo para o novo processo. Não há impacto no desempenho do sistema em relação a essa alta utilização da CPU. O processo simplesmente captura todos os ciclos de CPU não utilizados, desde que nenhum processo de prioridade mais alta os exija.
DFC#show process cpu PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 22 0 1 0 0.00% 0.00% 0.00% 0 SCP ChilisLC Lis 23 0 1 0 0.00% 0.00% 0.00% 0 IPC RTTYC Messag 24 0 9 0 0.00% 0.00% 0.00% 0 ICC Slave LC Req 25 0 1 0 0.00% 0.00% 0.00% 0 ICC Async mcast 26 0 2 0 0.00% 0.00% 0.00% 0 RPC Sync 27 0 1 0 0.00% 0.00% 0.00% 0 RPC rpc-master 28 0 1 0 0.00% 0.00% 0.00% 0 Net Input 29 0 2 0 0.00% 0.00% 0.00% 0 Protocol Filteri 30 8 105 76 0.00% 0.00% 0.00% 0 Remote Console P 31 40 1530 26 0.00% 0.00% 0.00% 0 L2 Control Task 32 72 986 73 0.00% 0.02% 0.00% 0 L2 Aging Task 33 4 21 190 0.00% 0.00% 0.00% 0 L3 Control Task 34 12 652 18 0.00% 0.00% 0.00% 0 FIB Control Task 35 9148 165 55442 1.22% 1.22% 1.15% 0 Statistics Task 36 4 413 9 0.00% 0.00% 0.00% 0 PFIB Table Manag 37 655016 64690036 10 75.33% 77.87% 71.10% 0 lcp schedular 38 0 762 0 0.00% 0.00% 0.00% 0 Constellation SP
Causas e soluções comuns para problemas de alta utilização da CPU
IP Inalcançável
Quando um grupo de acesso nega um pacote, o MSFC envia mensagens de ICMP inalcançável. Essa ação ocorre por padrão.
Com a habilitação padrão do comando ip unreachables, o mecanismo supervisor descarta a maioria dos pacotes negados no hardware. Em seguida, o mecanismo supervisor envia apenas um pequeno número de pacotes, um máximo de 10 pps, para a MSFC para serem descartados. Esta ação gera mensagens de inalcançável ICMP.
O descarte de pacotes negados e a geração de mensagens de ICMP inalcançável impõem uma carga na CPU da MSFC. Para eliminar a carga, você pode executar o comando de configuração de interface no ip unreachables. Esse comando desabilita as mensagens de inalcançável ICMP, que permitem a queda no hardware de todos os pacotes negados por grupo de acesso.
As mensagens de inalcançável ICMP não serão enviadas se uma VACL negar um pacote.
Conversões de NAT
O NAT utiliza encaminhamento de hardware e software. O estabelecimento inicial das traduções NAT deve ser feito no software e o encaminhamento posterior é feito com o hardware. O NAT também utiliza a tabela Netflow (máximo de 128 KB). Portanto, se a tabela Netflow estiver cheia, o switch também começará a aplicar o encaminhamento NAT por meio do software. Isso normalmente acontece com picos de tráfego altos e causará um aumento na CPU de 6500.
Uso do Espaço de Tabela FIB do CEF na Tabela de Cache de Fluxo
O Supervisor Engine 1 tem uma Tabela de Cache de Fluxo que suporta 128.000 entradas. No entanto, com base na eficiência do algoritmo de hash, essas entradas variam de 32.000 a 120.000. No Supervisor Engine 2, a tabela FIB é gerada e programada no PFC. A tabela contém até 256.000 entradas. O Supervisor Engine 720 com PFC3-BXL suporta até 1.000.000 entradas. Quando esse espaço for excedido, os pacotes serão comutados no software. Isso pode causar alta utilização da CPU no RP. Para verificar o número de rotas na tabela FIB do CEF, use estes comandos:
Router#show processes cpu
CPU utilization for five seconds: 99.26%
one minute: 100.00%
five minutes: 100.00%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
--- ----------- ---------- -------- ------- ------- ------- --- ---------------
1 0 0 0 0.74% 0.00% 0.00% -2 Kernel and Idle
2 2 245 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat
3 0 1 0 0.00% 0.00% 0.00% -2 L2L3IntHdlr
4 0 1 0 0.00% 0.00% 0.00% -2 L2L3PatchRev
5 653 11737 1000 0.00% 0.00% 0.00% -2 SynDi
!--- Output is suppressed.
26 10576 615970 1000 0.00% 0.00% 0.00% 0 L3Aging
27 47432 51696 8000 0.02% 0.00% 0.00% 0 NetFlow
28 6758259 1060831 501000 96.62% 96.00% 96.00% 0 Fib
29 0 1 0 0.00% 0.00% 0.00% -2 Fib_bg_task
!--- Output is suppressed.
CATOS% show mls cef
Total L3 packets switched: 124893998234
Total L3 octets switched: 53019378962495
Total route entries: 112579
IP route entries: 112578
IPX route entries: 1
IPM route entries: 0
IP load sharing entries: 295
IPX load sharing entries: 0
Forwarding entries: 112521
Bridge entries: 56
Drop entries: 2
IOS% show ip cef summary
IP Distributed CEF with switching (Table Version 86771423), flags=0x0
112564 routes, 1 reresolve, 0 unresolved (0 old, 0 new)
112567 leaves, 6888 nodes, 21156688 bytes, 86771426
inserts, 86658859
invalidations
295 load sharing elements, 96760 bytes, 112359 references
universal per-destination load sharing algorithm, id 8ADDA64A
2 CEF resets, 2306608 revisions of existing leaves
refcounts: 1981829 leaf, 1763584 node
!--- You see these messages if the TCAM space is exceeded:
%MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched
%MLSCEF-SP-7-END_FIB_EXCEPTION: FIB TCAM exception cleared, all CEF entries will be
hardware switched
No Supervisor Engine 2, o número de entradas FIB será reduzido à metade se você tiver configurado a verificação de RPF nas interfaces. Essa configuração pode levar ao switch de software de mais pacotes e, consequentemente, à alta utilização da CPU.
Para resolver o problema de alta utilização da CPU, habilite o resumo da rota. A sumarização de rotas pode minimizar a latência em uma rede complexa reduzindo as cargas de trabalho do processador, os requisitos de memória e a demanda de largura de banda.
Consulte Compreendendo a ACL nos Catalyst 6500 Series Switches para obter informações adicionais sobre a utilização e a otimização da TCAM.
Registro otimizado de ACL
O OAL (Optimized ACL Logging, registro otimizado de ACL) fornece suporte de hardware para registro de ACL. A menos que você configure o OAL, o processo de pacotes que requerem registro ocorre completamente no software no MSFC3. O OAL permite ou descarta pacotes no hardware no PFC3. O OAL usa uma rotina otimizada para enviar informações ao MSFC3 para gerar as mensagens de registro.
Observação: para obter informações sobre OAL, consulte a seção Logging de ACL otimizado com um PFC3 de Compreendendo o suporte de ACL do Cisco IOS.
Limite de taxa de pacotes para a CPU
No Supervisor Engine 720, os limitadores de taxa podem controlar a taxa na qual os pacotes podem ir para o software. Esse controle de taxa ajuda a evitar ataques de negação de serviço. Você também pode usar alguns desses limitadores de taxa no Supervisor Engine 2:
Router#show mls rate-limit
Rate Limiter Type Status Packets/s Burst
--------------------- ---------- --------- -----
MCAST NON RPF Off - -
MCAST DFLT ADJ On 100000 100
MCAST DIRECT CON Off - -
ACL BRIDGED IN Off - -
ACL BRIDGED OUT Off - -
IP FEATURES Off - -
ACL VACL LOG On 2000 1
CEF RECEIVE Off - -
CEF GLEAN Off - -
MCAST PARTIAL SC On 100000 100
IP RPF FAILURE On 500 10
TTL FAILURE Off - -
ICMP UNREAC. NO-ROUTE On 500 10
ICMP UNREAC. ACL-DROP On 500 10
ICMP REDIRECT Off - -
MTU FAILURE Off - -
LAYER_2 PDU Off - -
LAYER_2 PT Off - -
IP ERRORS On 500 10
CAPTURE PKT Off - -
MCAST IGMP Off - -
Router(config)#mls rate-limit ?
all Rate Limiting for both Unicast and Multicast packets
layer2 layer2 protocol cases
multicast Rate limiting for Multicast packets
unicast Rate limiting for Unicast packets
Aqui está um exemplo:
Router(config)#mls rate-limit layer2 l2pt 3000
Para limitar a taxa de todos os pacotes direcionados por CEF para o MSFC, emita o comando que está neste exemplo:
Router(config)#mls ip cef rate-limit 50000
Para reduzir o número de pacotes direcionados para a CPU devido a TTL=1, emita este comando:
Router(config)#mls rate-limit all ttl-failure 15
!--- where 15 is the number of packets per second with TTL=1. !--- The valid range is from 10 to 1000000 pps.
Por exemplo, esta é a saída da captura netdr, que mostra que o TTL IPv4 é 1:
Source mac 00.00.50.02.10.01 3644 Dest mac AC.A0.16.0A.B0.C0 4092 Protocol 0800 4094 Interface Gi1/8 3644 Source vlan 0x3FD(1021) 3644 Source index 0x7(7) 3644 Dest index 0x380(896) 3654 L3 ipv4 source 211.204.66.117 762 ipv4 dest 223.175.252.49 3815 ipv4 ttl 1 3656 ipv6 source - 0 ipv6 dest - 0 ipv6 hoplt - 0 ipv6 flow - 0 ipv6 nexthdr - 0
A alta utilização da CPU também pode ocorrer devido a pacotes com TTL=1 que vazam para a CPU. Para limitar o número de pacotes que vazam para a CPU, configure um limitador de taxa de hardware. Os limitadores de taxa podem limitar a taxa de pacotes que vazam do caminho de dados de hardware até o caminho de dados de software. Os limitadores de taxa protegem o caminho de controle do software contra congestionamento descartando o tráfego que excede a taxa configurada. O limite de taxa é configurado usando o comando mls rate-limit all ttl-failure.
Fusão física de VLANs devido ao cabeamento incorreto
A alta utilização da CPU também pode resultar da fusão de duas ou mais VLANs devido ao cabeamento inadequado. Além disso, se o STP estiver desabilitado nas portas onde ocorre a fusão de VLANs, poderá ocorrer uma alta utilização da CPU.
Para resolver esse problema, identifique os erros de cabeamento e corrija-os. Se o seu requisito permitir, você também poderá habilitar o STP nessas portas.
Tempestade de Broadcast
Uma tempestade de broadcasts de LAN ocorre quando pacotes de broadcast ou multicast inundam a LAN, o que cria tráfego excessivo e degrada o desempenho da rede. Erros na implementação da pilha de protocolo ou na configuração da rede podem causar uma tempestade de broadcast.
Devido ao projeto arquitetônico da plataforma da série Catalyst 6500, os pacotes de broadcast são somente e sempre descartados no nível do software.
A supressão de broadcast evita a interrupção de interfaces de LAN por uma tempestade de broadcast. A supressão de broadcast usa filtragem que mede a atividade de broadcast em uma LAN durante um período de 1 segundo e compara a medição com um limite predefinido. Se o limite for atingido, outras atividades de broadcast serão suprimidas durante um período de tempo especificado. Por padrão, a supressão de difusão está desativada.
Observação: a oscilação de VRRP do backup para o mestre causada por tempestades de broadcast pode causar alta utilização da CPU.
Para entender como funciona a supressão de broadcast e para habilitar o recurso, consulte:
-
Configurando a supressão de broadcast (software do sistema Cisco IOS)
-
Configurando a Supressão de Broadcast (software do sistema CatOS)
Rastreamento de endereço de próximo salto BGP (processo de scanner BGP)
O processo do scanner BGP passa pela tabela BGP e confirma a alcançabilidade dos próximos saltos. Esse processo também verifica o anúncio condicional para determinar se o BGP deve anunciar os prefixos de condição e/ou executar o retardamento de rota. Por padrão, o processo faz a varredura a cada 60 segundos.
Você pode esperar alta utilização da CPU por curtos períodos devido ao processo do scanner BGP em um roteador que transporta uma grande tabela de roteamento da Internet. Uma vez por minuto, o scanner BGP passa pela tabela BGP Routing Information Base (RIB) e executa tarefas de manutenção importantes. Essas tarefas incluem:
-
Uma verificação do próximo salto que é referenciado na tabela BGP do roteador
-
Verificação de que os dispositivos do próximo salto podem ser alcançados
Portanto, uma ampla tabela de BGP demora um bom tempo para ser examinada e validada. O processo do scanner BGP passa pela tabela BGP para atualizar quaisquer estruturas de dados e passa pela tabela de roteamento para fins de redistribuição de rota. Ambas as tabelas são armazenadas separadamente na memória do roteador. Ambas as tabelas podem ser muito grandes e, portanto, consumir ciclos de CPU.
Para obter mais informações sobre a utilização da CPU pelo processo do scanner BGP, consulte a seção Alta utilização da CPU devido ao scanner BGP de Solução de problemas de alta utilização da CPU causados pelo scanner BGP ou pelo processo do roteador BGP.
Para obter mais informações sobre o recurso Rastreamento de Endereço do Próximo Salto BGP e o procedimento para ativar/desativar ou ajustar o intervalo de verificação, consulte Suporte BGP para Rastreamento de Endereço do Próximo Salto.
Tráfego de multicast não-RPF
O roteamento multicast (diferente do roteamento unicast) só se preocupa com a origem de um determinado fluxo de dados multicast. Ou seja, o endereço IP do dispositivo que origina o tráfego multicast. O princípio básico é que o dispositivo de origem "envia" o fluxo para um número indefinido de receptores (dentro de seu grupo multicast). Todos os roteadores multicast criam árvores de distribuição, que controlam o caminho que o tráfego multicast percorre pela rede para entregar o tráfego a todos os receptores. Os dois tipos básicos de árvores de distribuição multicast são árvores de origem e árvores compartilhadas. O RPF é um conceito-chave no encaminhamento multicast. Ele permite que os roteadores encaminhem corretamente o tráfego multicast pela árvore de distribuição. O RPF usa a tabela de roteamento unicast existente para determinar os vizinhos upstream e downstream. Um roteador encaminha um pacote multicast somente se for recebido na interface upstream. Essa verificação de RPF ajuda a garantir que a árvore de distribuição esteja sem loops.
O tráfego multicast é sempre visível por cada roteador em uma LAN com bridge (Camada 2), de acordo com a especificação IEEE 802.3 CSMA/CD. No padrão 802.3, o bit 0 do primeiro octeto é usado para indicar um quadro de broadcast e/ou multicast, e qualquer quadro da Camada 2 com esse endereço é inundado. Esse também é o caso mesmo se o CGMP ou o IGMP Snooping estiverem configurados. Isso ocorre porque os roteadores multicast devem ver o tráfego multicast, se for esperado que tomem uma decisão de encaminhamento apropriada. Se vários roteadores multicast tiverem interfaces em uma LAN comum, apenas um roteador encaminhará os dados (escolhidos por um processo de eleição). Devido à natureza de inundação das LANs, o roteador redundante (que não encaminha o tráfego multicast) recebe esses dados na interface de saída dessa LAN. O roteador redundante normalmente descarta esse tráfego, porque ele chegou à interface errada e, portanto, falha na verificação de RPF. Esse tráfego que falha na verificação de RPF é chamado de tráfego não-RPF ou pacotes de falha de RPF, porque eles foram transmitidos de volta contra o fluxo da origem.
O Catalyst 6500 com um MSFC instalado pode ser configurado para atuar como um roteador multicast completo. Utilizando Multicast Multi-Layer Switching (MLS), o tráfego RPF é normalmente encaminhado pelo hardware dentro do switch. Os ASICs recebem informações do estado de roteamento multicast ( por exemplo, (*,G) e (S,G) ), de modo que um atalho de hardware possa ser programado no Netflow e/ou na tabela FIB. Esse tráfego não-RPF ainda é necessário em alguns casos e é exigido pela CPU MSFC (no nível do processo) para o mecanismo PIM Assert. Caso contrário, ele é descartado pelo caminho de switching rápido de software (supondo que a switching rápida de software não esteja desabilitada na interface RPF).
O Catalyst 6500 que usa redundância pode não lidar eficientemente com o tráfego não-RPF em certas topologias. Para o tráfego não-RPF, geralmente não há estado (*,G) ou (S,G) no roteador redundante e, portanto, nenhum atalho de hardware ou software pode ser criado para descartar o pacote. Cada pacote multicast deve ser examinado individualmente pelo processador de rota MSFC e isso é frequentemente chamado de tráfego de interrupção da CPU. Com a comutação de hardware de Camada 3 e várias interfaces/VLANs que conectam o mesmo conjunto de roteadores, o tráfego não-RPF que atinge a CPU do MSFC redundante é amplificado "N" vezes a taxa de origem original (onde "N" é o número de LANs às quais o roteador está conectado de forma redundante). Se a taxa de tráfego não-RPF exceder a capacidade de descarte de pacotes do sistema, isso poderá causar alta utilização da CPU, estouros de buffer e instabilidade geral da rede.
Com o Catalyst 6500, há um mecanismo de lista de acesso que permite que a filtragem ocorra em velocidade de cabo. Esse recurso pode ser usado para manipular o tráfego não-RPF para grupos do Modo escasso de forma eficiente, em determinadas situações. Você só pode usar o método baseado em ACL em 'redes stub' de modo esparso, onde não há roteadores multicast downstream (e receptores correspondentes). Além disso, devido ao projeto de encaminhamento de pacotes do Catalyst 6500, os MSFCs redundantes internamente não podem usar essa implementação. Isso é descrito no bug da Cisco ID CSCdr74908 (somente clientes registrados) . Para grupos de modo denso, os pacotes não-RPF devem ser vistos no roteador para que o mecanismo PIM Assert funcione corretamente. Diferentes soluções, como CEF ou limitação de taxa baseada em Netflow e QoS, são usadas para controlar falhas de RPF em redes de modo denso e redes de trânsito de modo escasso.
No Catalyst 6500, há um mecanismo de lista de acesso que permite que a filtragem ocorra em velocidade de cabo. Esse recurso pode ser usado para controlar o tráfego não-RPF para grupos de modos esparsos eficientemente. Para implementar essa solução, coloque uma lista de acesso na interface de entrada da `rede stub' para filtrar o tráfego multicast que não se originou da `rede stub'. A lista de acesso é enviada para o hardware no switch. Essa lista de acesso impede que a CPU veja o pacote e permite que o hardware descarte o tráfego não-RPF.
Observação: não coloque essa lista de acesso em uma interface de trânsito. Destina-se somente a redes stub (redes somente com hosts).
Consulte estes documentos para obter outras informações:
comandos show
A utilização da CPU quando você emite um comando show é sempre quase 100%. É normal ter alta utilização da CPU quando você executa um comando show e normalmente permanece por apenas alguns segundos.
Por exemplo, é normal que o processo Virtual Exec aumente quando você emite um comando show tech-support, pois essa saída é uma saída acionada por interrupção. Sua única preocupação é ter alta utilização da CPU em outros processos além dos comandos show.
O comando show cef not-cef-switched mostra por que os pacotes são direcionados para o MSFC (receive, ip option, no adjacency etc) e quantos. Por exemplo:
Switch#show cef not-cef-switched CEF Packets passed on to next switching layer Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag RP 6222 0 136 0 60122 0 0 0 5 0 0 0 0 0 0 0 0 IPv6 CEF Packets passed on to next switching layer Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access MTU RP 0 0 0 0 0 0 0 0
Os comandos show ibc e show ibc brief mostram a fila da CPU e podem ser usados quando você estiver monitorando o status da CPU.
Processos Exec
O processo Exec no Cisco IOS Software é responsável pela comunicação nas linhas TTY (console, auxiliar, assíncrono) do roteador. O processo Virtual Exec é responsável pelas linhas de vty (sessões de telnet). Os processos Exec e Virtual Exec são processos de prioridade média, portanto, se houver outros processos com prioridade mais alta (Alta ou Crítica), os processos de prioridade mais alta obterão os recursos da CPU.
Se houver muitos dados transferidos através dessas sessões, a utilização da CPU para o processo Exec aumentará. Isso ocorre porque quando o roteador deseja enviar um caractere simples através dessas linhas, ele usa alguns recursos da CPU:
-
Para o console (Exec), o roteador usa uma interrupção por caractere.
-
Para a linha VTY (Virtual Exec), a sessão Telnet precisa criar um pacote TCP por caractere.
Esta lista detalha alguns dos possíveis motivos para a alta utilização da CPU no processo Exec:
-
Há muitos dados enviados através da porta de console.
-
Verifique se alguma depuração foi iniciada no roteador com o comando show debugging.
-
Desative o registro de console no roteador com a forma no do comando logging console.
-
Verifique se uma saída longa está impressa no console. Por exemplo, um comando show tech-support ou um comando show memory.
-
-
O comando exec é configurado para linhas assíncronas e auxiliares.
-
Se uma linha tiver apenas tráfego de saída, desative o processo Exec para essa linha. Isso ocorre porque se o dispositivo (por exemplo, um modem) conectado a essa linha enviar alguns dados não solicitados, o processo Exec será iniciado nessa linha.
-
Se o roteador for usado como um servidor de terminal (para Telnet reverso para outros consoles de dispositivos), é recomendável que você configure o comando no exec nas linhas que estão conectadas ao console dos outros dispositivos. Os dados que voltam do console podem, de outra forma, iniciar um processo Exec, que usa recursos da CPU.
-
Um motivo possível para a alta utilização da CPU no processo Virtual Exec é:
-
Há muitos dados enviados através das sessões Telnet.
O motivo mais comum para a alta utilização da CPU no processo Virtual Exec é que muitos dados são transferidos do roteador para a sessão Telnet. Isso pode acontecer quando comandos com saídas longas, como show tech-support, show memory, etc., são executados na sessão Telnet. A quantidade de dados transferidos através de cada sessão VTY pode ser verificada com o comando show tcp vty <line number>.
Processo de envelhecimento de L3
Quando o processo de envelhecimento de L3 exporta um grande número de valores ifindex usando a Exportação de Dados do NetFlow (NDE), o uso da CPU pode atingir 100%.
Se você encontrar esse problema, verifique se estes dois comandos estão ativados:
set mls nde destination-ifindex enable
set mls nde source-ifindex enable
Se você habilitar esses comandos, o processo deverá exportar todos os valores ifindex de destino e de origem usando o NDE. A utilização do processo de envelhecimento da L3 aumenta, pois ele deve executar uma pesquisa FIB para todos os valores de índice de destino e de origem. Por causa disso, a tabela fica cheia, o processo de envelhecimento da L3 fica alto e o uso da CPU atinge 100%.
Para resolver esse problema, desabilite estes comandos:
set mls nde destination-ifindex disable
set mls nde source-ifindex disable
Use estes comandos para verificar os valores:
Tempestade de BPDU
O spanning tree mantém um ambiente de Camada 2 sem loops em redes comutadas redundantes e de bridges. Sem o STP, os quadros entram em loop e/ou se multiplicam indefinidamente. Essa ocorrência causa um colapso da rede porque o alto tráfego interrompe todos os dispositivos no domínio de broadcast.
Em alguns aspectos, o STP é um protocolo antigo que foi inicialmente desenvolvido para as especificações lentas de bridges baseadas em software (IEEE 802.1D), mas o STP pode ser complicado para implementá-lo com êxito em grandes redes comutadas que tenham estes recursos:
-
Muitas VLANs
-
Muitos switches em um domínio STP
-
Suporte a vários fornecedores
-
Aprimoramentos mais recentes do IEEE
Se a rede enfrentar cálculos frequentes de spanning tree ou o switch tiver que processar mais BPDUs, isso pode resultar em alta utilização de CPU, bem como quedas de BPDU.
Para contornar esses problemas, execute uma ou todas estas etapas:
-
Remova as VLANs dos switches.
-
Use uma versão avançada do STP, como o MST.
-
Atualizar o hardware do switch.
Consulte também as melhores práticas para implementar o Spanning Tree Protocol na rede.
Sessões de SPAN
Com base na arquitetura dos Catalyst 6000/6500 Series Switches, as sessões de SPAN não afetam o desempenho do switch, mas, se a sessão de SPAN incluir uma porta de alto tráfego/uplink ou um EtherChannel, ela poderá aumentar a carga no processador. Se ele destacar uma VLAN específica, a carga de trabalho aumentará ainda mais. Se houver tráfego ruim no link, isso poderá aumentar ainda mais a carga de trabalho.
Em alguns cenários, o recurso RSPAN pode causar loops e a carga no processador é disparada. Para obter mais informações, consulte Por que a Sessão de SPAN Cria um Loop de Bridging?
O switch pode passar o tráfego como de costume, já que tudo está no hardware, mas a CPU pode levar uma surra se tentar descobrir por qual tráfego enviar. Recomenda-se que você configure as sessões de SPAN somente quando for necessário.
%CFIB-SP-STBY-7-CFIB_EXCEPTION : Exceção de TCAM de FIB. Algumas entradas serão comutadas por software
%CFIB-SP-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched %CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched
Esta mensagem de erro é recebida quando a quantidade de espaço disponível no TCAM é excedida. Isso resulta em alta utilização da CPU. Essa é uma limitação de TCAM de FIB. Quando a TCAM estiver cheia, um flag será definido e uma exceção FIB TCAM será recebida. Isso impede a adição de novas rotas ao TCAM. Portanto, tudo será comutado por software. A remoção de rotas não ajuda a retomar a comutação de hardware. Quando o TCAM entra no estado de exceção, o sistema deve ser recarregado para sair desse estado. As rotas máximas que podem ser instaladas no TCAM são aumentadas pelo comando mls cef maximum-routes.
O Catalyst 6500/6000 executado com alta CPU tem uma ACL IPv6 com portas L4
Ative mls ipv6 acl compress address unicast . Esse comando é necessário se a ACL IPv6 estiver correspondendo nos números de porta do protocolo L4. Se esse comando não for habilitado, o tráfego IPv6 será enviado para a CPU para processamento do software. Esse comando não é configurado por padrão.
SPFs de cobre
Nos switches Ethernet Cisco ME série 6500, os SFPs de cobre exigem mais interação de firmware do que outros tipos de SFPs, o que aumenta a utilização da CPU.
Os algoritmos de software que gerenciam SFPs de cobre foram aprimorados nas versões SXH do Cisco IOS.
IOS modular
Nos Cisco Catalyst 6500 Series Switches que executam o software IOS modular, a utilização normal da CPU é um pouco maior que a do software IOS não modular.
O software IOS modular paga um preço por atividade mais do que um preço por pacote. O software IOS modular mantém os processos ao consumir determinada CPU, mesmo que não haja muitos pacotes, de modo que o consumo da CPU não é baseado no tráfego real. No entanto, quando os pacotes foram processados atingem uma taxa alta, a CPU consumida no software IOS modular não deve ser maior do que a utilizada no software IOS não modular.
Verificar Utilização da CPU
Se a utilização da CPU estiver alta, emita o comando show processes cpu primeiro. A saída mostra a utilização da CPU no switch, bem como o consumo da CPU por cada processo.
Router#show processes cpu CPU utilization for five seconds: 57%/48%; one minute: 56%; five minutes: 48% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 5 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 12 18062 0 0.00% 0.00% 0.00% 0 Load Meter 4 164532 13717 11994 0.00% 0.21% 0.17% 0 Check heaps 5 0 1 0 0.00% 0.00% 0.00% 0 Pool Manager !--- Output is suppressed. 172 0 9 0 0.00% 0.00% 0.00% 0 RPC aapi_rp 173 243912 2171455 112 9.25% 8.11% 7.39% 0 SNMP ENGINE 174 68 463 146 0.00% 0.00% 0.00% 0 RPC pm-mp !--- Output is suppressed.
Nesta saída, a utilização total da CPU é de 57% e a utilização da CPU para interrupção é de 48%. Aqui, essas porcentagens aparecem em texto em negrito. O switch de interrupção de tráfego pela CPU causa a interrupção da utilização da CPU. A saída do comando lista os processos que causam a diferença entre as duas utilizações. Nesse caso, a causa é o processo SNMP.
No mecanismo supervisor que executa o CatOS, a saída se parece com esta:
Switch> (enable) show processes cpu
CPU utilization for five seconds: 99.72%
one minute: 100.00%
five minutes: 100.00%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
--- ----------- ---------- -------- ------- ------- ------- --- ---------------
1 0 0 0 0.28% 0.00% 0.00% -2 Kernel and Idle
2 2 261 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat
3 0 1 0 0.00% 0.00% 0.00% -2 L2L3IntHdlr
4 0 1 0 0.00% 0.00% 0.00% -2 L2L3PatchRev
!--- Output is suppressed.
61 727295 172025 18000 0.82% 0.00% 0.00% -2 SptTimer
62 18185410 3712736 106000 22.22% 21.84% 21.96% -2 SptBpduRx
63 845683 91691 105000 0.92% 0.00% 0.00% -2 SptBpduTx
Nesta saída, o primeiro processo é Kernel e Idle, que mostra a utilização de CPU ociosa. Esse processo normalmente é alto, a menos que outros processos consumam ciclos da CPU. Neste exemplo, o processo SptBpduRx causa alta utilização da CPU.
Se a utilização da CPU for alta devido a um desses processos, você poderá identificar e solucionar problemas e determinar por que esse processo é executado com alto desempenho. Mas, se a CPU estiver alta devido ao tráfego que está sendo lançado para a CPU, você precisará determinar por que o tráfego está sendo lançado. Essa determinação pode ajudá-lo a identificar o tráfego.
Para a solução de problemas, use este exemplo de script EEM para coletar a saída do switch quando você experimentar alta utilização da CPU:
event manager applet cpu_stats event snmp oid "1.3.6.1.4.1.9.9.109.1.1.1.1.3.1" get-type exact entry-op gt entry-val "70" exit-op lt exit-val "50" poll-interval 5 action 1.01 syslog msg "------HIGH CPU DETECTED----, CPU:$_snmp_oid_val%" action 1.02 cli command "enable" action 1.03 cli command "show clock | append disk0:cpu_stats" action 1.04 cli command "show proc cpu sort | append disk0:cpu_stats" action 1.05 cli command "Show proc cpu | exc 0.00% | append disk0:cpu_stats" action 1.06 cli command "Show proc cpu history | append disk0:cpu_stats" action 1.07 cli command "show logging | append disk0:cpu_stats " action 1.08 cli command "show spanning-tree detail | in ieee|occurr|from|is exec | append disk0:cpu_stats" action 1.09 cli command "debug netdr cap rx | append disk0:cpu_stats" action 1.10 cli command "show netdr cap | append disk0:cpu_stats" action 1.11 cli command "undebug all" !
Observação: o comando debug netdr capture rx é útil quando a CPU está alta devido à comutação de processos de pacotes em vez de hardware. Ele captura 4.096 pacotes que chegam à CPU quando o comando é executado. O comando é completamente seguro e é a ferramenta mais conveniente para problemas de alta utilização da CPU no 6500. Ele não causa carga extra à CPU.
Utilitários e ferramentas para determinar o tráfego que é lançado para a CPU
Esta seção identifica alguns utilitários e ferramentas que podem ajudá-lo a observar esse tráfego.
Software do sistema Cisco IOS
No Cisco IOS Software, o processador do switch no mecanismo supervisor é chamado de SP e o MSFC é chamado de RP.
O comando show interface fornece informações básicas sobre o estado da interface e a taxa de tráfego na interface. O comando também fornece contadores de erro.
Router#show interface gigabitethernet 4/1
GigabitEthernet4/1 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 000a.42d1.7580 (bia 000a.42d1.7580)
Internet address is 100.100.100.2/24
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 5/75/1/24075 (size/max/drops/flushes); Total output drops: 2
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 7609000 bits/sec, 14859 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
L2 Switched: ucast: 0 pkt, 184954624 bytes - mcast: 1 pkt, 500 bytes
L3 in Switched: ucast: 2889916 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
2982871 packets input, 190904816 bytes, 0 no buffer
Received 9 broadcasts, 0 runts, 0 giants, 0 throttles
1 input errors, 1 CRC, 0 frame, 28 overrun, 0 ignored
0 input packets with dribble condition detected
1256 packets output, 124317 bytes, 0 underruns
2 output errors, 1 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Nesta saída, você pode ver que o tráfego de entrada é comutado por Camada 3 em vez de comutado por Camada 2. Isso indica que o tráfego está sendo direcionado para a CPU.
O comando show processes cpu informa se esses pacotes são pacotes de tráfego regular ou pacotes de controle.
Router#show processes cpu | exclude 0.00 CPU utilization for five seconds: 91%/50%; one minute: 89%; five minutes: 47% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 5 881160 79142 11133 0.49% 0.19% 0.16% 0 Check heaps 98 121064 3020704 40 40.53% 38.67% 20.59% 0 IP Input 245 209336 894828 233 0.08% 0.05% 0.02% 0 IFCOM Msg Hdlr
Se os pacotes forem comutados por processo, você verá que o processo de Entrada de IP está alto. Execute este comando para ver estes pacotes:
show buffers input-interface
Router#show buffers input-interface gigabitethernet 4/1 packet Buffer information for Small buffer at 0x437874D4 data_area 0x8060F04, refcount 1, next 0x5006D400, flags 0x280 linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1 if_input 0x505BC20C (GigabitEthernet4/1), if_output 0x0 (None) inputtime 00:00:00.000 (elapsed never) outputtime 00:00:00.000 (elapsed never), oqnumber 65535 datagramstart 0x8060F7A, datagramsize 60, maximum size 308 mac_start 0x8060F7A, addr_start 0x8060F7A, info_start 0x0 network_start 0x8060F88, transport_start 0x8060F9C, caller_pc 0x403519B4 source: 100.100.100.1, destination: 100.100.100.2, id: 0x0000, ttl: 63, TOS: 0 prot: 17, source port 63, destination port 63 08060F70: 000A 42D17580 ..BQu. 08060F80: 00000000 11110800 4500002E 00000000 ........E....... 08060F90: 3F11EAF3 64646401 64646402 003F003F ?.jsddd.ddd..?.? 08060FA0: 001A261F 00010203 04050607 08090A0B ..&............. 08060FB0: 0C0D0E0F 101164 ......d
Se o tráfego for comutado por interrupção, você não poderá ver esses pacotes com o comando show buffers input-interface. Para ver os pacotes que são apontados para o RP para switching de interrupção, você pode executar uma captura Switched Port Analyzer (SPAN) da porta RP.
Observação: consulte este documento para obter informações adicionais sobre a utilização da CPU comutada por interrupção versus comutada por processo:
-
Seção Alta Utilização de CPU devido a Interrupções de Solução de Problemas de Alta Utilização de CPU em Cisco Routers
SPAN RP-Inband e SP-Inband
Um SPAN para a porta RP ou SP no Cisco IOS Software está disponível no Cisco IOS Software Release 12.1(19)E e posteriores.
Esta é a sintaxe do comando:
test monitor session 1-66 add {rp-inband | sp-inband} [rx | tx | both]
Use esta sintaxe para as versões do Cisco IOS Software 12.2 SX:
test monitor add {1..66} {rp-inband | sp-inband} {rx | tx | both}
Observação: Para a versão SXH, você deve usar o comando monitor session para configurar uma sessão SPAN local e, em seguida, usar este comando para associar a sessão SPAN à CPU:
source {cpu {rp | sp}} | single_interface | interface_list |
interface_range | mixed_interface_list | single_vlan |
vlan_list | vlan_range | mixed_vlan_list} [rx | tx | both]
Observação: Para obter mais informações sobre esses comandos, consulte Configuração do SPAN Local (Modo de Configuração de SPAN) no Guia de Configuração do Software Catalyst 6500 Versão 12.2SX.
Aqui está um exemplo em um console RP:
Router#monitor session 1 source interface fast 3/3 !--- Use any interface that is administratively shut down. Router#monitor session 1 destination interface 3/2
Agora, vá para o console do SP. Aqui está um exemplo:
Router-sp#test monitor session 1 add rp-inband rx
Observação: nas versões Cisco IOS 12.2 SX, o comando foi alterado para test monitor add 1 rp-inband rx.
Router#show monitor Session 1 --------- Type : Local Session Source Ports : Both : Fa3/3 Destination Ports : Fa3/2 SP console: Router-sp#test monitor session 1 show Ingress Source Ports: 3/3 15/1 Egress Source Ports: 3/3 Ingress Source Vlans: <empty> Egress Source Vlans: <empty> Filter Vlans: <empty> Destination Ports: 3/2
Observação: nas versões Cisco IOS 12.2 SX, o comando foi alterado para test monitor show 1.
Aqui está um exemplo em um console SP:
Router-sp#test monitor session 1 show Ingress Source Ports: 3/3 15/1 Egress Source Ports: 3/3 Ingress Source Vlans: <empty> Egress Source Vlans: <empty> Filter Vlans: <empty> Destination Ports: 3/2
Software do sistema de CatOS
Para switches que executam o software de sistema CatOS, o mecanismo supervisor executa o CatOS e o MSFC executa o Cisco IOS Software.
Se você executar o comando show mac, poderá ver o número de quadros que são lançados no MSFC. A porta 15/1 é a conexão do mecanismo supervisor com o MSFC.
Observação: a porta é 16/1 para mecanismos de supervisão no slot 2.
Console> (enable) show mac 15/1 Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast -------- -------------------- -------------------- -------------------- 15/1 193576 0 1 Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast -------- -------------------- -------------------- -------------------- 15/1 3 0 0 Port Rcv-Octet Xmit-Octet -------- -------------------- -------------------- 15/1 18583370 0 MAC Dely-Exced MTU-Exced In-Discard Out-Discard -------- ---------- ---------- ---------- ----------- 15/1 0 - 0 0
Um rápido aumento nesse número indica que os pacotes são direcionados para o MSFC, o que causa alta utilização da CPU. Você pode, então, observar os pacotes das seguintes maneiras:
Porta SPAN MSFC 15/1 ou 16/1
Configure uma sessão de SPAN na qual a origem seja a porta 15/1 (ou 16/1) da MSFC e o destino seja uma porta Ethernet.
Aqui está um exemplo:
Console> (enable) set span 15/1 5/10 Console> (enable) show span Destination : Port 5/10 Admin Source : Port 15/1 Oper Source : None Direction : transmit/receive Incoming Packets: disabled Learning : enabled Multicast : enabled Filter : - Status : active
Se você coletar um farejador de rastreamento na porta 5/10, o farejador de rastreamento mostrará os pacotes que transmitem de e para o MSFC. Configure a sessão de SPAN como tx para capturar pacotes que são destinados somente ao MSFC, e não do MSFC.
SPAN sc0
Configure uma sessão de SPAN com a interface sc0 como origem para capturar quadros que vão para a CPU do mecanismo supervisor.
Console> (enable) set span ? disable Disable port monitoring sc0 Set span on interface sc0 <mod/port> Source module and port numbers <vlan> Source VLAN numbers
Observação: para OSMs (Optical Services Modules Módulos de Serviços Ópticos), você não pode executar uma captura de SPAN do tráfego.
Recomendações
A utilização da CPU do mecanismo de supervisão não reflete o desempenho de encaminhamento de hardware do switch. Ainda assim, você deve estabelecer uma linha de base e monitorar a utilização da CPU do mecanismo de supervisão.
-
Defina a linha de base da utilização da CPU do mecanismo de supervisão para o switch em uma rede em estado estacionário com padrões de tráfego e carga normais.
Observe quais processos geram a maior utilização de CPU.
-
Ao solucionar problemas de utilização da CPU, considere estas perguntas:
-
Quais processos geram a maior utilização? Esses processos são diferentes da sua linha de base?
-
A CPU é consistentemente elevada em relação à linha de base? Ou há picos de alta utilização e, em seguida, um retorno aos níveis de linha de base?
-
Há TCNs (Topology Change Notifications, notificações de alteração de topologia) na rede?
Observação: portas não sincronizadas ou portas de host com STP PortFast desabilitado causam TCNs.
-
Há excesso de tráfego de broadcast ou multicast nas sub-redes/VLAN de gerenciamento?
-
Há excesso de tráfego de gerenciamento, como polling de SNMP, no switch?
-
-
Durante o tempo de CPU alto (quando a CPU é 75% ou superior), colete a saída destes comandos:
-
Se possível, isole a VLAN de gerenciamento das VLANs com tráfego de dados de usuário, particularmente tráfego pesado de broadcast.
Exemplos desse tipo de tráfego incluem IPX RIP/Service Advertising Protocol (SAP), AppleTalk e outros tráfegos de broadcast. Esse tráfego pode afetar a utilização da CPU do Supervisor Engine e, em casos extremos, pode interferir na operação normal do Switch.
-
Se a CPU estiver com muito tráfego devido ao punt de tráfego para o RP, determine qual é o tráfego e por que ele é pontuado.
Para fazer essa determinação, use os utilitários descritos na seção Utilitários e Ferramentas para Determinar o Tráfego que É Lançado na CPU.
Informações Relacionadas
- Comandos úteis para solucionar problemas de alta utilização da CPU em Catalyst 6500 com Sup720
- Mensagens de erro comuns de CatOS em Switches da série Catalyst 6500 ou 6000
- Mensagens de Erro Comuns nos Catalyst 6500/6000 Series Switches com Cisco IOS Software
- Troubleshooting de Falhas Comuns e de Hardware em Catalyst 6500/6000 Series Switches Executando o Cisco IOS System Software
- Inundação de Unicast em Redes de Campus Comutadas
- Suporte de produto dos switches Cisco Catalyst 6500 Series
- Script EEM para coleta de dados durante problema de alta CPU intermitente
- Suporte a Produtos de LAN
- Suporte de tecnologia de switching de LAN
- Suporte Técnico e Documentação - Cisco Systems
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
11-Feb-2005
|
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)