Switches : Switches Cisco Catalyst 6500 Series

Alta Utilização de CPU no Switch Catalyst 6500/6000

2 Abril 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (27 Agosto 2012) | Feedback


Índice

Introdução
Pré-requisitos
     Requisitos
     Componentes Usados
     Convenções
Diferença entre os Softwares de Sistema CatOS e Cisco IOS
Compreensão da Utilização da CPU nos Switches Catalyst 6500/6000
Situações e Recursos que Disparam a Transferência do Tráfego para o Software
     Pacotes que São Destinados ao Switch
     Pacotes e Condições que Exigem Processamento Especial
     Recursos baseados em ACL
     Recursos baseados em Netflow
     Tráfego multicast
     Outros Recursos
     Situações de IPv6
     Módulo DFC
Causas Comuns e Soluções para os Problemas de Alta Utilização de CPU
     Inalcançáveis IP
     Uso do Espaço da Tabela FIB no CEF na Tabela de Cache de Fluxo
     Log de ACL Otimizado
     Limite de Taxa de Pacotes para a CPU
     Fusão Física de VLANs Devido a Erros de Cabeamento
     Tempestade de Broadcast
     Rastreamento do Endereço do Nó Seguinte no BGP (Processo de Scanner do BGP)
     Comandos show
     Processos Exec
Verificação da Utilização da CPU
Utilitários e Ferramentas para Determinação do Tráfego Lançado na CPU
     Cisco IOS System Software
     Software de Sistema CatOS
Recomendações
Discussões relacionadas da comunidade de suporte da Cisco
Informações Relacionadas

Introdução

Este documento descreve as causas da alta utilização da CPU em Cisco Catalyst 6500/6000 Series Switches. Como os roteadores Cisco, os switches usam o comando show processes cpu para mostrar a utilização da CPU pelo processador do Supervisor Engine do switch. Entretanto, devido às diferenças na arquitetura e em mecanismos de encaminhamento entre os roteadores e os switches Cisco, a saída típica do comando show processes cpu difere significativamente. Os significados dessas saídas são também diferentes. Este documento esclarece essas diferenças. O documento descreve o uso da CPU nos switches e como interpretar o comando de saída 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 Usados

As informações mostradas neste documento são baseadas nas versões de hardware e software para os Switches Catalyst 6500/6000.

As informações apresentadas neste documento foram criadas a partir dos dispositivos em um ambiente de laboratório específico. Todos os dispositivos usados neste documento começaram com uma configuração vazia (padrão). Se a sua rede estiver ativa, certifique-se de entender o impacto potencial de todos os comandos.

Convenções

Consulte Convenções de Dicas Técnicas da Cisco para obter mais informações sobres as convenções de documentos.

Diferença entre os Softwares de Sistema CatOS e Cisco IOS

Catalyst OS (CatOS) no Supervisor Engine e Cisco IOS® Software na Multilayer Switch Feature Card (MSFC) (Híbrido): Você pode usar uma imagem do CatOS como software do sistema para executar o Supervisor Engine nos Switches Catalyst 6500/6000. Se a MSFC opcional estiver instalada, será usada uma imagem do Cisco IOS Software separada para executar a MSFC.

Cisco IOS Software no Supervisor Engine e na MSFC (Nativo): Você pode usar uma única imagem do Cisco IOS Software como software do sistema para executar tanto o Supervisor Engine como a 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.

Compreensão da Utilização da CPU nos Switches Catalyst 6500/6000

Os roteadores baseados em software Cisco usam o software para processar e rotear pacotes. A utilização da CPU em um roteador Cisco tende a aumentar à medida que o roteador executa mais processamentos e roteamentos de pacotes. Portanto, o comando show processes cpu pode oferecer uma indicação razoavelmente precisa da carga de processamento de tráfego no roteador.

Os Switches Catalyst 6500/6000 não usam a CPU do mesmo modo. Esses switches tomam decisões de encaminhamento em hardware e não em software. Portanto, quando os switches tomam a decisões de switching ou de encaminhamento para a maioria dos quadros que passam pelo switch, o processo não envolve a CPU do o Supervisor Engine.

Nos Switches Catalyst 6500/6000, existem duas CPUs. Uma CPU é a do Supervisor Engine, chamada de Processador de Gerenciamento de Rede (NMP) ou Processador de Switch (SP). A outra CPU é a do engine de roteamento da Camada 3, chamada de MSFC ou de Processador de Rotas (RP).

A CPU do SP executa funções como:

  • Auxiliar no gerenciamento do tempo de envelhecimento e na aprendizagem de endereços MAC

    Observação: A aprendizagem de endereços MAC também é chamada de configuração de caminho.

  • Executar protocolos e processos que forneçam controle da 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).

  • Processar o tráfego de gerenciamento de rede destinado à CPU do switch

    Exemplos incluem tráfego Telnet, HTTP e Simple Network Management Protocol (SNMP).

A CPU do RP executa funções como:

  • Criar e atualizar tabelas de Address Resolution Protocol (ARP) e de roteamento da Camada 3.

  • Gerar as tabelas Forwarding Information Base (FIB) do Cisco Express Forwarding (CEF) e as tabelas de adjacência e fazer download das tabelas para a Policy Feature Card (PFC).

  • Processar 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 a Transferência do Tráfego para o Software

Pacotes que São Destinados ao Switch

Todo pacote destinado ao switch vai para o software. Entre esses pacotes, estão incluídos:

  • Pacotes de controle

    Os pacotes de controle são recebidos por STP, CDP, VTP, Hot Standby Router Protocol (HSRP), PAgP, Link Aggregation Control Protocol (LACP) e UniDirectional Link Detection (UDLD).

  • Atualizações de protocolos de roteamento

    São exemplos desses protocolos o Routing Information Protocol (RIP), o Interior Gateway Routing Protocol (EIGRP), o Border Gateway Protocol (BGP) e o Open Shortest Path First Protocol (OSPF).

  • Tráfego SNMP destinado ao switch

  • Tráfego Telnet e Secure Shell Protocol (SSH) para o switch

  • Respostas ARP para solicitações ARP

Pacotes e Condições que Exigem Processamento Especial

Esta lista fornece tipos de pacotes específicos e condições que forçam os pacotes a serem processados em software:

  • Pacotes com opções de IP, duração (Time do Live, TTL) expirada ou encapsulamento não-ARPA (Advanced Research Projects Agency)

  • Pacotes com processamento especial, como tunelamento

  • Fragmentação de IP

  • Pacotes que exigem mensagens Internet Control Message Protocol (ICMP) do RP ou do SP

  • Falha da verificação de unidade de transmissão máxima (MTU)

  • Pacotes com erros de IP, inclusive erros de checksum de IP e erros de comprimento

  • Mesma interface com adjacência

  • Pacotes que falham na verificação de Reverse Path Forwarding (RPF) — rpf-failure

  • Glean/receive

    Glean refere-se a pacotes que exigem resolução ARP e receive refere-se a pacotes que caem no caso de recebimento.

  • Tráfego de Internetwork Packet Exchange (IPX) que seja comutado por software no Supervisor Engine 720, tanto no Cisco IOS Software como 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 plenas de recurso de hardware

    Esses recursos incluem FIB, memórias de conteúdo endereçavel (CAM) e CAM ternária (TCAM).

Recursos baseados em ACL

  • Tráfego de acesso negado na lista de controle de acesso (ACL) com o recurso de inalcançáveis ICMP ligado.

    Observação: É o padrão.

    Alguns pacotes negados pela ACL vazarão para a MSFC se os inalcançáveis IP estiverem habilitados. Os pacotes que exigem inalcançáveis ICMP são vazados a uma taxa configurável pelo usuário. A taxa padrão é de 500 pacotes por segundo (pps).

  • Filtragem de IPX na base de parâmetros não confirmados, como os do host de origem

    No Supervisor Engine 720, o processo do tráfego IPX Camada 3 está sempre no software.

  • As entradas de controle de acesso (ACEs) que exigem log, com a palavra-chave log

    Isso se aplica ao log da ACL e aos recursos de log da VLAN ACL (VACL). Os ACEs na mesma ACL que não exigem registro em log ainda são processados no hardware. O Supervisor Engine 720 com PFC3 suporta o limite de taxa dos pacotes que são redirecionados para a MSFC para log da ACL e da VACL. O Supervisor Engine 2 suporta o limite de taxa de pacotes que são redirecionados para a MSFC para log da VACL. O suporte para o logon ACL no Supervisor Engine 2 é programado para a versão da central telefônica com 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 é suportado no software. Entretanto, o parâmetro set interface null 0 é uma exceção. Esse tráfego é processado no hardware, no Supervisor Engine 2 com PFC2 e no Supervisor Engine 720 com PFC3.

  • Roteador ACLs (RACLs) Não-IP e Não-IPX

    Os RACLs Não-IP aplicam-se a todos Supervisor Engines. Os RACLs não-IPX aplicam-se somente ao Supervisor Engine 1a com PFC e ao Supervisor Engine 2 com PFC2.

  • Tráfego de broadcast que é negado em um RACL

  • Tráfego que é negado em uma verificação unicast RPF (uRPF), ACL ACE

    Essa verificação uRPF aplica-se ao Supervisor Engine 2 com PFC2 e 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 Cisco IOS Software

    O tráfego sujeito a criptografia do Cisco IOS pode ter 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. Depois que o primeiro pacote de fluxo alcança o software, os pacotes subseqüentes para o mesmo fluxo são comutados por hardware.

    Esse arranjo de fluxo aplica-se às ACLs reflexivas, ao Web Cache Communication Protocol (WCCP) e ao Server Load Balancing (SLB) do Cisco IOS.

    Observação: No Supervisor Engine 1, as ACLs reflexivas contam com entradas TCAM dinâmicas para criar atalhos de hardware para um determinado fluxo. O princípio é o mesmo: o primeiro pacote de fluxo vai para o software. Os pacotes subseqüentes para aquele fluxo são comutados por hardware.

  • Com o recurso de Interceptação de TCP, o handshake de três vias e o fechamento da sessão são processados no software. O resto do tráfego é processado no hardware.

    Observação: Os pacotes de sincronização (SYN), de reconhecimento SYN (SYN ACK) e de ACK compreendem o handshake de três vias. O fechamento de sessão ocorre com finish (FIN) ou com reset (RST).

  • Com a Network Address Translation (NAT), o tráfego é processado da seguinte maneira:

    • No Supervisor Engine 720:

      O tráfego que exige NAT é processado no hardware depois da tradução inicial. A tradução do primeiro pacote de fluxo ocorre no software e os pacotes subseqüentes do mesmo fluxo são comutados por hardware. Para pacotes TCP, um atalho de hardware é criado na tabela do NetFlow após a conclusão do handshake de três vias TCP.

    • No Supervisor Engine 2 e no Supervisor Engine 1:

      Todo tráfego que exige NAT é comutado por software.

  • O Controle de Acesso Baseado em Contexto(CBAC) usa atalhos do NetFLow para classificar o tráfego que precisa de inspeção. Então o CBAC envia somente este tráfego para o software. O CBAC é um recurso de software apenas; o tráfego sujeito a inspeção não é comutado por hardware.

    Observação: O tráfego sujeito a inspeção pode ter a taxa limitada no Supervisor Engine 720.

Tráfego multicast

  • Espionagem Multicast Independente de Protocolo (PIM)

  • Espionagem do Internet Group Management Protocol (IGMP) (TTL = 1)

    Esse tráfego é realmente destinado ao roteador.

  • Espionagem do Multicast Listener Discovery (MLD) (TTL = 1)

    Esse tráfego é realmente destinado ao roteador.

  • Perda FIB

  • Pacotes Multicast para registro que têm conexão direta com a origem do multicast

    Esses pacotes de multicast são transmitidos em túnel para um ponto de reunião.

  • Multicast de IP versão 6 (IPv6)

Outros Recursos

  • Reconhecimento de Aplicativo Baseado em Rede (NBAR)

  • Inspeção ARP com apenas CatOS

  • Segurança de Porta com apenas CatOS

  • Espionagem DHCP

Situações de IPv6

  • Pacotes com um cabeçalho de opção nó a nó.

  • Pacotes com endereço IPv6 de destino igual ao dos roteadores

  • Pacotes que falharam na aplicação de escopo

  • Pacotes que excedem o MTU do link de saída

  • Pacotes com TTL menor ou igual a 1

  • Pacotes com uma VLAN de entrada igual à VLAN de saída

  • IPv6 uRPF

    Software que executa esse uRPF para todos pacotes.

  • ACLs reflexivas de IPv6

    O software processa essas ACLs reflexivas.

  • Prefixos 6to4 para túneis com Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) IPv6

    O software processa este tunelamento. Todo o tráfego restante que entra um túnel ISATAP é comutado por hardware.

Módulo DFC

Em um Distributed Forwarding Card (DFC), o lcp schedular é um processo executado na alta CPU, não é um problema e não oferece qualquer dificuldade para a operação.

Quando o lcp schedular é iniciado, ele usa todo tempo de processamento disponível. Porém, quando um processo novo precisa de tempo de processador, o lcp schedular libera tempo de processamento para o novo processo. Não há nenhum impacto no desempenho do sistema com relação a esta alta utilização da CPU. O processo simplesmente captura todos ciclos de CPU não utilizados, desde que nenhum processo de maior prioridade precise desses ciclos.

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 Comuns e Soluções para os Problemas de Alta Utilização de CPU

Inalcançáveis IP

Quando um grupo de acesso recusa um pacote, a MSFC envia mensagens de inalcancáveis ICMP. Essa ação ocorre por padrão.

Com a habilitação padrão do comando ip unreachables o Supervisor Engine descarta a maioria dos pacotes recusados no hardware. Em seguida, o Supervisor Engine envia apenas um pequeno número de pacotes, um máximo de 10 pps, à MSFC para descarte. Essa ação gera mensagens de inalcançáveis ICMP.

O descarte de pacotes negados e a geração de mensagens de inalcançáveis ICMP gera uma carga na CPU da MSFC. Para eliminar a carga, você pode executar o comando de configuração da interface no ip unreachables. Esse comando desabilita as mensagens de inalcançáveis ICMP, o que permite que o hardware descarte todos pacotes negados por grupo.

As mensagens de inalcancáveis ICMP não são enviadas se um VACL nega um pacote.

Uso do Espaço da Tabela FIB no CEF na Tabela de Cache de Fluxo

O Supervisor Engine 1 tem uma Tabela de Cache de Fluxo que suporta 128.000 entradas. Entretanto, com base na eficiência do algoritmo de hashing, essas entradas variam de 32.000 a 120.000. No Supervisor Engine 2, a tabela FIB é gerada e programada na PFC. A tabela retém até 256.000 entradas. O Supervisor Engine 720 com o PFC3-BXL suporta até 1.000.000 de entradas. Quando o espaço é excedido, os pacotes passam a ser comutados por software. Isso pode resultar em alta utilização da CPU no RP. Use os comandos a seguir para verificar o número de rotas na tabela FIB do CEF:

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

               !--- A saída é suprimida.
            
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

               !--- A saída é suprimida.
            

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

               !--- Você verá as mensagens a seguir se o espaço de TCAM for excedido:
            
%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, a quantidade de entradas FIB fica reduzida pela metade se tiver sido feita a verificação de RPF nas interfaces. Essa configuração pode levar à comutação de mais pacotes por software e, conseqüentemente, a uma alta utilização da CPU.

Consulte Compreendo a ACL em Catalyst 6500 Series Switches para obter mais informações sobre uso e a otimização de TCAM.

Log de ACL Otimizado

O Log de ACL Otimizado (OAL) fornece suporte de hardware para log da ACL. A menos que você configure o OAL, o processo de pacotes que exigem registro em log ocorre completamente no software na MSFC3. O OAL permite ou descarta pacotes no hardware na PFC3. Ele usa uma rotina otimizada para enviar informações à MSFC3 para gerar mensagens de registro em log.

Observação: Para obter informações sobre o OAL, consulte a seção Log de ACL Otimizado com uma PFC3 de Compreendendo o Suporte a ACL do Cisco IOS.

Limite de Taxa de Pacotes para a CPU

No Supervisor Engine 720, limitadores de taxa podem controlar a taxa com que os pacotes passam 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

Segue um exemplo:

Router(config)#mls rate-limit layer2 l2pt 3000
         

Para limitar a taxa de todos pacotes direcionados no CEF para a MSFC, execute o comando que se encontra no exemplo a seguir:

Router(config)#mls ip cef rate-limit 50000
         

Fusão Física de VLANs Devido a Erros de Cabeamento

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, uma alta utilização de CPU pode ocorrer se o STP estiver desabilitado nessas portas onde ocorre a fusão da VLAN.

Para resolver esse problema, identifique e corrija os erros de cabeamento. Se seu requisito permitir, você poderá também habilitar o STP naquelas portas.

Tempestade de Broadcast

Uma tempestade de broadcast de LAN ocorre quando pacotes de broadcast ou de multicast inundam a LAN, o que cria um tráfego excessivo e degrada o desempenho da rede. Erros na implantação da pilha do protocolo ou na configuração da rede podem causar uma tempestade de broadcast.

A supressão de broadcast evita a interferência das interfaces LAN por uma tempestade de broadcast. A supressão de broadcast usa uma filtragem que mede a atividade de broadcast em uma LAN durante o tempo de 1 segundo e compara essa medida com um limite definido previamente. Se o limite for atingido, o prosseguimento da atividade de broadcast será suprimido durante determinado período. A supressão do broadcast é desabilitada por padrão.

Para compreender como a supressão do broadcast funciona e habilitar o recurso, consulte:

Rastreamento do Endereço do Nó Seguinte no BGP (Processo de Scanner do BGP)

O processo de Scanner do BGP passa pela tabela de BGP e confirma a possibilidade de alcançar os próximos nós. Esse processo também verifica anúncios condicionais para determinar se o BGP deve ou não anunciar prefixos de condição ou executar retardamento de rota. Por padrão, o processo faz a varredura a cada 60 segundos.

Pode-se esperar alta utilização da CPU durante um curto período devido ao processo de varredura do BGP em um roteador que tenha uma grande tabela de roteamento da Internet. Uma vez por minuto, a varredura do BGP passa pela tabela Routing Information Base (RIB) do BGP e executa importantes tarefas de manutenção. Essas tarefas incluem:

  • Verificação do próximo nó indicado na tabela do BGP do roteador

  • Verificação de que os dispositivos do próximo nós podem ser alcançados

Portanto, uma tabela grande do BGP demora um bom tempo para ser examinada e validada. O processo de varredura do BGP passa pela tabela do BGP para atualizar as estruturas de dados e passa pela tabela de roteamento com a finalidade de redistribuir rotas. Ambas as tabelas são armazenadas separadamente na memória do roteador. Ambas as tabelas podem ser muito grandes e, portanto, consomir ciclos de CPU.

Para mais informações sobre o uso do processo de varredura do BGP, consulte a seção Alto Uso de CPU Devido ao Scanner do BGP de Solução de problemas de alta CPU causados pelo scanner do BGP ou pelo processo de roteador de BGP.

Para obter mais informações sobre o recurso de Rastreamento do Endereço do Nó Seguinte no BGP e o procedimento para habilitar/desabilitar ou ajustar o intervalo de rastreamento, consulte Suporte do BGP ao Rastreamento do Endereço do Nó Seguinte.

Comandos show

A utilização da CPU ao executar um comando show quase sempre é de 100%. É normal ter alto nível de utilização da CPU ao emitir um comando show e isso geralmente permanece por alguns segundos.

Por exemplo, é normal que o processo Virtual Exec aumente de volume quando você executa um comando show tech-support, pois essa saída é direcionada por interrupções. Sua única preocupação é ter alta utilização da CPU em outros processos além de comandos show.

Processos Exec

O processo Exec no Cisco IOS Software é responsável pela comunicação nas linhas TTY (console, auxiliares e assíncronos) do roteador. O processo Virtual Exec é responsável pelas linhas de VTY (sessões de Telnet). Os processos Exec e Virtual são processos de prioridade média, portanto, caso existam outros processos com prioridade mais alta (Alta ou Crítica), os processos de maior prioridade ficarão com os recursos da CPU.

Se muitos dados forem transferidos nessas sessões, a utilização da CPU para os Processos Exec aumentará. Isso ocorre porque, quando o roteador quer enviar um caractere simples através dessas linhas, ele usa apenas 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 tem que criar um pacote TCP por cada caractere.

Estas são algumas das razões comuns para o alto nível de utilização da CPU no processo Exec:

  • Muitos dados são enviados através da porta do console.

    1. Verifique se houve início de depurações no roteador. Para isso, use o comando show debugging .

    2. Desabilite o log do console no roteador com a variação no do comando no logging console .

    3. Verifique se o console exibe uma longa saída. Por exemplo, um comando show tech-support ou show memory .

  • O comando exec é configurado para linhas auxiliares e assíncronas.

    1. Se uma linha apenas tiver tráfego de saída, desabilite o processo Exec para essa linha. Isso é porque se o dispositivo (por exemplo, um modem) conectado a essa linha enviar algum dado não solicitado, o processo Exec será iniciado nessa linha.

    2. Se o roteador for usado como um servidor de terminal (para Telnet reverso com outros consoles de dispositivos), é recomendável que você configure o comando no exec nas linhas conectadas ao console de outros dispositivos. Caso contrário, os dados que voltam do console podem iniciar o processo Exec, que usa recursos da CPU.

Estas são algumas das possíveis razões para o alto nível de utilização da CPU no processo Exec:

  • Há muitos dados sendo enviados pelas sessões de Telnet.

    A razão mais comum para uma alta utilização da CPU no processo Virtual Exec é o excesso de dados transferidos do roteador para a sessão de Telnet. Isso pode acontecer quando comandos com saídas longas, como show tech-support, show memory e outros semelhantes, são executados pelas sessões de Telnet. A quantidade de dados transferida em cada sessão VTY pode ser verificada com o comando show tcp vty <line number> .

Verificação da Utilização da CPU

Se a utilização da CPU for alta, execute primeiramente o comando show processes cpu. A saída exibe a utilização da CPU no switch e o consumo de CPU devido a cada processo em execução.

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

               !--- A saída é suprimida.
            
 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

               !--- A saída é suprimida.
            
         

Nessa saída, a utilização total da CPU é de 57% e o uso da CPU para interrupção é de 48%. Aqui essas porcentagens aparecem em negrito. O switch de interrupção do tráfego pela CPU causa a interrupção do uso 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 Supervisor Engine que executa o CatOS a saída se parece com:

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

               !--- A saída é suprimida.
            
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

Nessa saída, o primeiro processo é Kernel and Idle, que mostra a ociosidade da utilização da CPU. O consumo desse processo usualmente é elevado, salvo se outro processo consumir ciclos de CPU. Neste exemplo, o processo SptBpduRx causa alta utilização da CPU.

Se o uso da CPU for alto devido a um desses processos, você poderá executar a solução de problemas para determinar por que a execução do processo consome tanta CPU. Porém, se o uso for alto devido ao tráfego que está entrando na CPU você deverá determinar porque o tráfego está forçando a entrada. Essa determinação pode lhe ajudar a identificar qual é o tráfego.

Utilitários e Ferramentas para Determinação do Tráfego Lançado na CPU

Esta seção identifica alguns utilitários e ferramentas que podem ser úteis para observar esse tráfego.

Cisco IOS System Software

No Cisco IOS Software, o processador do switch no Supervisor Engine é chamado de SP e a MSFC é chamada de RP.

O show interface comando fornece a informação básica 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 chegada está na Camada 3 comutada, em vez de estar na Camada 2 comutada. Isso indica que o tráfego está sendo lançado para a CPU.

O comando show processes cpu avisa se esse pacotes provêm do tráfego regular ou de 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 estiverem sendo comutados por processo você verá que IP Input é executado em alto volume. Execute este comando para ver esses 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:Source-a 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 command. Para ver os pacotes que estão sendo lançados no RP para switching de interrupção do RP, você pode executar uma captura Switched Port Analyzer (SPAN) da porta do RP.

Observação: Para obter mais informações sobre o uso da CPU comutada por interrupção versus comutada por processo, consulte:

SPAN RP-Inband e SP-Inband

Um SPAN para a porta de RP ou de SP no Cisco IOS Software está disponível no Cisco IOS Software Release 12.1 (19)E e posteriores.

A sintaxe do comando é:

            test monitor session 1-66 add {rp-inband | sp-inband} [rx | tx | both]
         

Segue um exemplo em um console RP:

Router#monitor session 1 source interface fast 3/3
            
               !--- Use qualquer interface que possa ser desligada administrativamente.
            
Router#monitor session 1 destination interface 3/2
         

Agora, vá para o console SP. Segue um exemplo:

Router-sp#test monitor session 1 add 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

Segue 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 de Sistema CatOS

Para switches que executam o software de sistema CatOS, o Supervisor Engine executa o CatOS e a MSFC executa o Cisco IOS Software.

Se executar o comando show mac, você poderá ver o número de quadros que são lançados na MSFC. A Porta 15/1 é a conexão do Supervisor Engine com a MSFC.

Observação: A porta para Supervisor Engines no slot 2 é a 16/1.

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 aumento rápido nesse número indica que os pacotes estão sendo lançados na MSFC, o que provoca uma alta utilização da CPU. Você pode ver os pacotes das seguintes maneiras:

Porta 15/1 ou 16/1 da MSFC para SPAN

Configure uma sessão SPAN na qual a origem seja a porta 15/1 (ou 16/1) da MSFC e o destino seja uma porta Ethernet.

Segue 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 rastreamento de farejador na porta 5/10, o rastreamento de farejador mostrará os pacotes que transmite de e para a MSFC. Configure a sessão do SPAN como tx para capturar pacotes que sejam destinados apenas para a MSFC e não originados da MSFC.

SPAN sc0

Configure uma sessão de SPAN com a interfac esc0 como origem para capturar os quadros que vão para a CPU do Supervisor Engine.

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 Módulos de Serviços Óticos (OSMs), você não pode executar uma captura de tráfego SPAN.

Recomendações

A utilização de CPU do Supervisor Engine não reflete o desempenho do encaminhamento de hardware do switch. Ainda assim, você deve definir a referência e monitorar a utilização de CPU do Supervisor Engine.

  1. Defina a referência para a utilização de CPU do Supervisor Engine para o switch de uma rede em estado estável com padrões normais de tráfego e carga.

    Anote quais processos estão gerando maior utilização da CPU.

  2. Ao solucionar problemas de utilização de CPU, considere o seguinte:

    • Anote quais processos estão gerando maior utilização da CPU. Esses processos são diferentes dos que estão na sua referência?

    • A CPU está consistentemente acima da referência? Ou existem picos de alta utilização e, em seguida, um retorno aos níveis da referência?

    • Existem Topology Change Notifications (TCNs) na rede?

      Observação: Portas não sincronizadas ou portas de host com PortFast STP desabilitado causam TCNs.

    • Existe tráfego excessivo de broadcast ou de multicast nas sub-redes/VLANS de gerenciamento?

    • Existe excesso de tráfego de gerenciamento, como polling de SNMP no switch?

  3. Se possível, isole a VLAN de gerenciamento das VLANs com tráfego de dados de usuários, especialmente 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.

  4. Se o uso de CPU for alto devido ao lançamento de tráfego para o RP, determine qual é o tráfego e por que ele está sendo lançado.

    Para fazer essa determinação, use os utilitários que são descritos na seção Utilitários e Ferramentas para Determinar o Tráfego que é Lançado na CPU.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 63992