Roteadores : Roteadores Cisco 12000 Series

Troubleshooting de Quedas de Entrada no Cisco 12000 Series Internet Router

12 Agosto 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Abril 2015) | Feedback


Índice


Introdução

Este documento explica como pesquisar defeitos um aumento no número de caídas de entrada que aparece na saída do comando show interface em um Cisco 12000 Series Internet Router.

Pré-requisitos

Requisitos

Os leitores deste documento devem estar cientes destes tópicos:

  • Arquitetura do Cisco 12000 Series Internet Router

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • Algum software release de Cisco IOS� que apoiar o Cisco 12000 Series Internet Router. Por exemplo, Cisco IOS Software Releases12.0S e 12.0ST.

  • Todas as Plataformas do Cisco 12000, que incluem os 12008, os 12012, os 12016, os 12404, os 12410, e os 12416.

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.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Sintomas

A maioria de sintoma comum é um aumento no número de caídas de entrada. Você pode ver o número de caídas de entrada na saída do comando show interfaces no Cisco 12000 Series Internet Router. Está aqui um exemplo de saída do comando show interfaces:

Router#show interface Gig2/0
GigabitEthernet2/0 is up, line protocol is up
  Hardware is GigMac 3 Port GigabitEthernet, address is 0003.fd1a.9040
(bia 0003.fd1a.9040)
  Internet address is 203.177.3.21/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex mode, link type is force-up, media type is SX
  output flow-control is unsupported, input flow-control is off
  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 00:55:39
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 27/75, 954 drops  
  
!--- Here are the input drops.

  5 minute input rate 3000 bits/sec, 5 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     7167 packets input, 601879 bytes, 0 no buffer
     Received 2877 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 3638 multicast, 0 pause input
     992 packets output, 104698 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     1 lost carrier, 21992 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Execute o comando show interfaces os segundos cada 10 verificar se o contador de queda aumente para a fila de entrada.

Quando um pacote inscreve o roteador, o roteador tenta enviar o pacote a nível de interrupção. Se o roteador não pode encontrar um fósforo em uma tabela de cache apropriada, o roteador enfileira o pacote na fila de entrada da interface de entrada para processar o pacote mais atrasado. O roteador processa sempre alguns pacotes. Contudo, a taxa de pacotes processados nunca congestiona a fila de entrada nas redes estáveis com a configuração apropriada. Se a fila de entrada está completa, o roteador deixa cair o pacote.

No exemplo de saída, você não pode identificar exatamente que os pacotes o roteador deixam cair. A fim pesquisar defeitos quedas de fila de entrada, você precisa de encontrar que os pacotes enchem a fila de entrada. O exemplo de saída indica que 27 pacotes esperam na fila de entrada da relação GigabitEthernet2/0. A profundidade de fila é 75 pacotes, e houve 954 gotas depois que você cancelou por último os contadores de interface.

Troubleshooting

Em uma rede que cancele um grande número rotas, as quedas de fila de entrada podem causar:

  • Falhas de keepalive da camada 2

  • Protocolo da redundância de roteador do /virtual do protocolo de roteamento do standby recente (HSRP/VRRP)

  • Aletas da relação

Os valores padrão são inadequados para os sistemas que apoiam um grande número relações ou rotas, especialmente em redes de provedor de serviços maiores. Uma única desobstrução do Border Gateway Protocol (BGP) pode frequentemente conduzir aos milhares de quedas de fila de entrada na mesma relação. As grandes caídas de entrada podem severamente impedir do tempo de convergência.

Termine estas etapas a fim evitar tal situação:

  1. Use o comando global da altura livre 1000 spd aumentar a altura livre do Selective Packet Discard (SPD).

    O valor padrão para o SPD headroom é 100. O comando spd headroom especifica quantos pacotes de alta precedência você pode enviar à fila sobre o limite normal da fila de organização de entrada. Os pacotes de alta precedência incluem atualizações de protocolo de roteamento e o outro tráfego de controle importante, por exemplo, mergulha 2 Keepalives e IS-IS Hello. Quando você especifica este valor, você reserva o espaço para entrada de pacote de alta precedência. No Cisco IOS Software Release 12.0(22)S e Mais Recente, o valor padrão para o SPD headroom é 1000 para o Cisco 12000 Series Internet Router. Use o comando show ip spd verificar o valor.

  2. Use a posse-fila 1500 para cada relação para aumentar o valor da fila de contenção da relação. O valor padrão é 75.

Como mencionado mais cedo no documento, somente os pacotes destinados ao roteador alcançam a fila de entrada. O Gigabit Route Processor (GRP) deve determinar como segurar os pacotes. Todos os pacotes são comutados por processo. Consequentemente, os pacotes tomam o trajeto lento. Geralmente, todos os pacotes que o Switches do Cisco 12000 Router usa o Distributed Cisco Express Forwarding (dCEF) através das placas de linha. Este dCEF dos suportes a plataforma somente como o método de switching.

Às vezes as gotas ocorrem durante a convergência do Border Gateway Protocol (BGP) se o roteador tem um grande número pares. Contudo, há uma abundância dos motivos válidos pelas quais o GRP tem que olhar alguns pacotes. Algumas das razões são alistadas aqui:

  • O GRP recebe atualizações de roteamento.

  • O GRP segura pacotes do Internet Control Message Protocol (ICMP).

  • O GRP estabelece e mantém sessões do bgp peer.

Use o comando show interfaces stat verificar se haja algum pacote comutado por processamento.

Se o Cisco 12000 Router não está ainda na produção, você pode permitir alguns comandos debug. Os comandos Debug permitem-no de capturar mais informação sobre o tipo de pacotes que o GRP recebe. A saída do pacote debugar IP é muito útil. Contudo, seja muito cauteloso com este comando, porque este comando pode afetar o comportamento do roteador através de um cair, de um impacto, ou de umas edições similares. Desabilite logs do console para evitar uma explosão das mensagens à porta de Console. Permita o buffer de registro de reorientar a saída do comando debug a um buffer que você pode consultar mais tarde. Use o comando show logging ver o buffer. Você pode igualmente especificar uma lista de acesso para reduzir para baixo o resultado do debug. A fim especificar uma lista de acesso, use esta configuração:

no logging console
logging buffer 128000
debug ip packet <ACL #> 

!--- Warning: 
!--- Be aware that this configuration on a production router can damage the box.

undebug all (after 5-10 seconds)

Este comando debug permite-o de considerar todos os pacotes comutados por processamento que o GRP recebe. Alternativamente, você pode usar o comando show buffers input-interface [interface type] [interface number] header identificar o tipo de pacotes que enchem acima a fila de entrada.

Nota: Este comando é útil somente quando a fila de entrada contém muitos pacotes.

      Router#show buffers input-interface serial 0/0
       Buffer information for Small buffer at 0x612EAF3C
         data_area 0x7896E84, refcount 1, next 0x0, flags 0x0
         linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0
         if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None)
         inputtime 0x0, outputtime 0x0, oqnumber 65535
         datagramstart 0x7896ED8, datagramsize 728, maximum size 65436
         mac_start 0x7896ED8, addr_start 0x7896ED8, info_start 0x0
         network_start 0x7896ED8, transport_start 0x0
         source: 212.176.72.138, destination: 212.111.64.174, id: 0xAAB8, 
         ttl: 118, prot: 1
       Buffer information for Small buffer at 0x612EB1D8
         data_area 0x78A6E64, refcount 1, next 0x0, flags 0x0
         linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0
         if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None)
         inputtime 0x0, outputtime 0x0, oqnumber 65535
         datagramstart 0x78A6EB8, datagramsize 728, maximum size 65436
         mac_start 0x78A6EB8, addr_start 0x78A6EB8, info_start 0x0
         network_start 0x78A6EB8, transport_start 0x0
         source: 212.176.72.138, destination: 212.111.64.174, id: 0xA5B8, 
         ttl: 118, prot: 1

Frequentemente, o mesmo tipo de pacote esta presente em grandes quantidades. Por exemplo, o exemplo de saída indica um grande número pacotes ICMP (protocolo IP 1).

Nota: Se você é incapaz de identificar um teste padrão nas saídas dos comandos debug ou show buffers input-interface, o problema é mais provável uma configuração de roteador incorreta.

Nota: Para mais informação, refira pesquisando defeitos quedas de fila de entrada e quedas da fila de saída.

Execute as ações apropriadas baseadas na saída do comando debug ip packet detail, ou de acordo com quedas de fila de entrada e quedas da fila de saída do Troubleshooting. Para um exemplo detalhado, veja a seção dos Casos Práticos.

Casos Práticos

Às vezes, quando você verifica a relação de seu Cisco 12000 Router, você observa que a relação deixa cair pacotes recebidos. Em consequência, o valor de contador das caídas de entrada aumenta regularmente. Por exemplo, considere este exemplo de saída:

Router#show interface Gig2/0
GigabitEthernet2/0 is up, line protocol is up 
Hardware is GigMac 3 Port GigabitEthernet, address is 0003.fd1a.9040
(bia 0003.fd1a.9040)
  Internet address is 203.177.3.21/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex mode, link type is force-up, media type is SX
  output flow-control is unsupported, input flow-control is off
  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 00:55:39
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 27/75, 954 drops  

  !--- This is the input drops counter value.

  5 minute input rate 3000 bits/sec, 5 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     7167 packets input, 601879 bytes, 0 no buffer
     Received 2877 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 3638 multicast, 0 pause input
     992 packets output, 104698 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     1 lost carrier, 21992 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Algumas caídas de entrada aparecem na saída do comando show interfaces. Se você emite este comando os segundos cada 10, você pode verificar se o contador de queda aumente para a fila de entrada.

Use o comando show interface stat verificar para ver se há a presença de pacotes comutados por processamento:

Router#show interfaces stat
.....
GIG2/0
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out           
               Processor      45354    1088496          0          0
           !--- Here are the packets that are process-switched (sent to the GRP)
             Route cache          0          0          0          0
         Distributed cef          0          0       8575     207958
                   Total      45354    1088496       8575     207958
....

Se o Cisco 12000 Router não está ainda na produção, você pode permitir alguns comandos debug capturar mais informação no tipo de pacotes que o GRP recebe. A saída do comando debug ip packet é interessante. Com este comando debug, você pode ver todos os pacotes comutados por processamento que o GRP recebe. Emita o comando show logging após alguma hora:

Router#show log
 Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
 Console logging: disabled
 Monitor logging: level debugging, 1110 messages logged
 Logging to: vty2(572) vty3(538)
 Buffer logging: level debugging, 107 messages logged
 Trap logging: level informational, 162 message lines logged
 Log Buffer (10000 bytes):
 *Jan 13 08:03:51.550: %SYS-5-CONFIG_I: Configured from console by vty2 (144.254.2.215)
 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 79,
 sending
 1w5d: IP: s=203.177.3.62 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=0.0.0.0 (GigabitEthernet2/0), d=255.255.255.255, len 328, rcvd 2
 1w5d: IP: s=203.177.3.15 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=144.254.2.215 (GigabitEthernet2/0), d=203.177.3.21 (GigabitEthernet2/0), 
  len 40, rcvd 3
 1w5d: IP: s=203.177.3.1 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.2 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.10 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.6 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.62 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.1 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.15 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 69, unroutable
 1w5d: IP: s=203.177.3.2 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.10 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 89, unroutable
 1w5d: IP: s=203.177.3.6 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.62 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.15 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.1 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=144.254.2.215 (GigabitEthernet2/0), d=203.177.3.21 (GigabitEthernet2/0), 
  len 41, rcvd 3
 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 41,
 sending
 1w5d: IP: s=203.177.3.2 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.10 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=144.254.2.215 (GigabitEthernet2/0), d=203.177.3.21 (GigabitEthernet2/0), 
  len 41, rcvd 3
 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 41,
 sending
 1w5d: IP: s=203.177.3.8 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=203.177.3.6 (GigabitEthernet2/0), d=224.0.0.10, len 60, unroutable
 1w5d: IP: s=144.254.2.215 (GigabitEthernet2/0), d=203.177.3.21 (GigabitEthernet2/0), 
  len 43, rcvd 3
 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 41,
 sending
 1w5d: IP: s=203.177.3.21 (local), d=144.254.2.215 (GigabitEthernet2/0), len 41,
 sending

Neste exemplo, a relação GigabitEthernet2/0 recebe muitos pacotes do Enhanced Interior Gateway Routing Protocol (EIGRP). O EIGRP usa o endereço de multicast 224.0.0.10, mas você não configurou o roteador para segurar tais pacotes. Consequentemente, o roteador envia estes pacotes ao GRP. O GRP toma uma decisão para deixar cair os pacotes, porque o GRP não pode segurar estes pacotes rapidamente bastante.

A fim assegurar-se de que o GRP não receba estes pacotes EIGRP, você pode executar uma destas ações:

  • Especifique a relação como a voz passiva no outro Roteadores.

  • Especifique roteadores vizinho diferentes.

Bugs do Cisco IOS Software

Às vezes, o número de caídas de entrada aumenta devido a um defeito do Cisco IOS Software. Por exemplo, no Cisco IOS Software Release 12.0(11)S, o Cisco 12000 Series Internet Router incrementa incorretamente as caídas de entrada contra devido a uma edição da contabilidade. A saída não reflete corretamente o número de pacotes descartado durante a congestão. Todas as relações podem indicar esta edição, mas a edição não afeta o serviço ou a funcionalidade das relações. Não há nenhuma solução conhecida.

Assegure-se de que você execute o Cisco IOS Software Release disponível o mais atrasado em seu trem para eliminar os erros que são fixos. Se você ainda vê gotas mais tarde, abra um pedido do serviço com.

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: 18004