Este documento explica como resolver o motivo da saída do comando show interfaces em um Cisco 12000 Series Internet Router exibir um número cada vez maior de erros ignorados. Igualmente fornece dicas de Troubleshooting para um número de aumento de nenhumas gotas do mem na saída dos controladores da mostra do <slot-> do execute-on slot (frfab | tofab) qm stat. Ao Troubleshoot algum desses erros, verifique se o contador está incrementando e se não é apenas um valor histórico.
Este documento requer o conhecimento da arquitetura do Roteador de Internet da Série Cisco 12000, especialmente das filas ToFab e FrFab. Veja como ler a saída do frfab dos controladores da mostra | comandos de fila tofab para a referência.
As informações neste documento são baseadas nas versões de software e hardware abaixo.
Qualquer Cisco IOS® Software Release que suporte o roteador de Internet do Cisco 12000 Series. Normalmente são as versões 12.0S e 12.0ST.
Todas as plataformas Cisco 12000 são abordadas por este documento. Eles incluem o 12008, 12012, 12016, 12404, 12410 e o 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 você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
O Cisco 12000 Series Internet Router usa uma arquitetura distribuída para assegurar o desempenho de encaminhamento o melhor. Para oferecer suporte a taxas altas de encaminhamento, ele mantém buffers de pacotes nas placas de linha de entrada e de saída. Estes buffers de pacotes variam em tamanho e são projetados geralmente apoiar a unidade de transmissão máxima (MTU) - quadros feitos sob medida.
Depois que determina a interface externa para um pacote, o Forwarding Processor faz o seguinte:
O processador de encaminhamento envia um ponteiro com informações sobre o pacote (incluindo seu local na memória) para a fila de saída virtual da interface de saída.
O programador da placa de linha emite uma solicitação para o programador. O agendador emite um grant e o pacote é enviado da memória do buffer pela estrutura de switching de entrada para a saída de dados para o cartão de linha de saída.
A placa de linha de saída coloca os pacotes em buffer.
O processador L3 e os ASICs (Circuitos integrados específicos do aplicativo) associados no LC de saída transmitem o pacote para fora da interface.
Se a interface externa é oversubscribed, começa a proteger os pacotes adicionais. Durante períodos de oversubscription contínuos, os transmitir fila do LC de partida enchem-se. Nessa condição, pode acontecer o seguinte, dependendo do LC de saída:
Tipo de Engine do LC de saída | Resposta ao Congestionamento de Saída | Contador de erros |
---|---|---|
Motor 0 e 1 | Envia um sinal de pressão contrária. A interface de entrada começa a proteger os pacotes adicionais. | Erros ignorados na saída do comando show interfaces e/ou na saída do comando no mem drops in execute-on slot <slot#> show controllers tofab QM stat do LC de entrada, dependendo do seu Mecanismo de Encaminhamento L3. ¹ |
Engine 2, 3, 4 | Deixa cair todos os pacotes adicionais na saída. | Nenhum mem deixa cair no comando execute-on slot <slot-> show controllers frfab QM stat output no LC de partida. |
¹Você receberá erros ignorados para os LCs dos Mecanismos L3 0, 1 e 2 de entrada. No entanto, para quatro, 16 ou mais portas nos LCs do Mecanismo 2, o contador ignorado não sofrerá aumento.
Em qualquer dispositivo de rede inteligente, quando um ou mais interfaces de alta velocidade alimentam uma interface de relativamente baixa velocidade, ocorre uma incompatibilidade em taxas de interface. Como a interface externa de velocidade mais lenta não pode possivelmente retornar os buffers tão rápido quanto a interface de entrada mais rápida os esteja enviando para a fila de contenção de emissor, um retardo no retorno do buffer leva a alguns tipos de quedas. Esse fluxo de pacote quebra a suposição de que a interface de saída retorna o buffer para a taxa de tempo de gerenciamento de buffer.
Além do que uma má combinação em taxas da relação, os erros ignorados podem incrementar quando a taxa de pacotes chegando é maior do que o CPU podem os processar. Essa condição é muito rara no Cisco 12000 e, em geral, é resultante de uma ampla quantidade de pacotes muito pequenos ou de quando um recurso que consome muita CPU, como Listas de Controle de Acesso (ACLs) ou a vigilância de tráfego, está habilitada em um LC que implementa esses recursos em softwares. Esta é a caixa para o motor 0 LC onde os lotes das características são executados no software. Contudo, em uns motores mais atrasados, quase todas as características são executadas no hardware. Por exemplo, Engine 3 (motor dos Serviços IP - O ISE) e placas de linha do motor 4+ é projetado para aplicativos de ponta e executa serviços do IP aprimorado (tais como Qualidade de Serviço - QoS) no hardware sem o impacto no desempenho. Exemplos deste hardware: CHOC-48 ISE de 1 porta, CHOC-12 ISE de 4 portas, OC-3 POS ISE de 16 portas, OC-12 POS ISE de 4 portas, OC-48 POS ISE de 1 porta e OC-48 POS ISE de uma porta.
O contador ignorado também pode ser aumentado sempre que um pacote chegar a uma placa de linha de ingresso e que um buffer de pacotes de tamanho apropriado não estiver disponível para manejar esse pacote. No entanto, essa condição é muito rara e não é abordada neste documento.
A solução aos erros ignorados e às nenhumas gotas do mem causados pela sobreassinatura da interface de saída é a mesma para qualquer tipo do Engine de L3 -- impeça a inanição do buffer. Em outras palavras, precisamos de um mecanismo que impeça que as filas FrFab sejam preenchidas.
Para simplificar, o contador ignorado é incrementado quando um pacote chega a uma placa de linha (LC) de ingresso e um buffer de pacote de tamanho apropriado não está disponível para processar esse pacote. Portanto, os pacotes ignorados em geral não apontam para um bug no software Cisco IOS.
Está aqui um exemplo de saída do comando show interfaces com um contador ignorado NON-nulo em um Cisco 12000 Series Router:
router#show interfaces G3/0GigabitEthernet3/0 is up, line protocol is up Hardware is GigMac GigabitEthernet, address is 0030.71f5.7980 (bia 0030.71f5.7980) MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex mode, link type is force-up, media type is SX output flow-control is unsupported, input flow-control is unsupported 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:00:07 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 99000 bits/sec, 74 packets/sec 5 minute output rate 104000 bits/sec, 68 packets/sec 478 packets input, 71057 bytes, 0 no buffer Received 19 broadcasts, 0 runts, 0 giants, 0 throttles 2 input errors, 2 CRC, 0 frame, 0 overrun, 25 ignored !--- Ignored counter is > 0. Ensure it is incrementing. 0 watchdog, 53 multicast, 0 pause input 541 packets output, 139133 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out
Quando o LC de saída é um Engine 0 ou 1, ele envia uma mensagem de backpressure aos outros LCs informando-lhes que já não é necessário enviar dados a esse LC especial. A interface de entrada protege então os pacotes adicionais em suas filas do tofab que correspondem a este slot de destino.
Para isolar a causa mais provável do contador ignorado estar aumentando, é necessário ver as filas ToFab no LC de entrada. Você também pode anexar ao LC no MBUS (Barramento de Manutenção), usando o comando attach ou o comando execute-on slot <slot#> show controllers tofab queue para verificar as filas ToFab. Execute este comando em alguns minutos e procure pelos seguintes sintomas:
Um valor decrescente e baixo ou valor de 0 na coluna #Qelem de uma fila livre não-IPC
Um valor alto na coluna #Qelem em uma fila de slot de destino.
As placas de linha que usam uma arquitetura mais recente do Engine de L3 não usam um mecanismo de pressão contrária. Em vez disso, quando a interface estiver com excesso de assinatura e uma fila FrFab ficar esgotada, os pacotes serão simplesmente desconectados à medida que chegarem na placa de linha de saída.
Os Engine 2 LCs não recuam para o próximo maior conjunto de buffers quando um conjunto menor se esgota. O mecanismo recuar foi executado somente para o Engine 2 LC no lado do tofab (RX). Se isso ocorrer, o contador de "instabilidade" será incrementado na saída do comando execute-on slot <slot> show controller tofab QM stat.
Esses cancelamentos são contados como no mem drops na saída do comando execute-on slot <slot#> show controllers frfab QM stat, conforme ilustrado abaixo:
Router#execute-on slot 1 show controllerfrfab QM stat========= Line Card (Slot 1) =======174 no mem drop, 0 soft drop, 0 bump count !--- Look for an incrementing value for the "no mem drop" counter0 rawq drops, 0 global red drops, 0 global force drops0 no memory (ns), 0 no memory hwm (Ns)no free queue0 0 0 00 0 0 00 0 0 00 0 0 00 multicast dropsTx Counts Interface 08390658710246 TX bytes, 2098330790 TX pkts, 212452 kbps, 6641 pps Interface 10 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 20 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 30 TX bytes, 0 TX pkts, 0 kbps, 0 PPS
Você precisa de encontrar uma maneira de impedir o lado do frfab da proteção ao ponto onde o LC qualquer um suporta à interface de entrada ou deixa cair simplesmente os pacotes.
Uma solução simples para todas as placas de linha, exceto o Engine 2 LC, é reduzir o número de buffer disponível a uma interface de saída particular em uma multi-relação LC. Por padrão, uma interface pode usar todos os buffers FrFab gravados. Use o comando tx-queue-limit para configurar um valor fora de padrão. Impede que o LC de entrada coloque em buffer mais do que o número configurado de pacotes na fila de interface para essa porta específica. Certifique-se de que este número esteja configurado baixo o suficiente, de modo que não contenha todas as filas FwFab para esta interface. Observe que esse método não diferencia entre pacotes de alta e baixa prioridade e simplesmente implementa a queda traseira mais agressivamente para uma interface específica.
Placas de ingresso do tipo Engine 3 exigem o uso de uma CLI de QoS Modular (MQC) em vez da Interface de Linha de Comando (CLI) anterior. Este comando não é apoiado em placas de linha do motor 2-based.
Segue um exemplo de configuração usando a configuração de Classe de Serviço (CoS) existente:
interface POS 0/0 tx-queue-limit <max Q length in packets>
Segue um exemplo de configuração usando o MQC:
policy-map TX_QUEUE_LIMIT class class-default queue-limit interface POS 0/0 service-policy out TX_QUEUE_LIMIT
Uma outra solução é executar uma interface de saída mais rápida, que nos dê uma tubulação maior. Mas as tubulações maiores podem encher-se rapidamente. Assim, a solução recomendada é executar mecanismos do Qualidade de Serviço (QoS) no LC de partida.
A característica do Weighted Random Early Detection (WRED) de Cisco executa um mecanismo de queda diferenciado ou inteligente. Ele foi projetado para funcionar com tráfego adaptativo, como fluxos TCP. Ela monitora o tamanho da fila e trabalha para manter um tamanho de fila médio consistente por meio de lançamentos aleatórios de pacotes a partir de vários fluxos, à medida que a fila média calculada é elevada acima do limite mínimo configurável.
Quando implementado no Cisco 12000 Series, o WRED pode impedir que as filas de FrFab sejam preenchidas e escolham quais pacotes desejam reduzir. Os LCs de Engine 0 suportam WRED em software, considerando que os LCs de Engine 1 não suportam WRED. O outro Engine de L3 LC apoia o WRED no hardware.
Para obter mais informações sobre de configurar o WRED, refira estes documentos:
Detecção antecipada aleatória ponderada no Cisco 12000 Series Router
Configurando MPLS CoS em um roteador GSR do Cisco 12000 Series
Este mecanismo de prevenção de congestionamento funciona apenas em um ambiente baseado em TCP. O TCP responde a quedas de tráfego adequadamente - mesmo de forma robusta através da diminuição de sua transmissão de tráfego. Veja como o TCP segura a perda de tráfego e como o roteador interage com o TCP para detalhes sobre como o TCP reage à perda de pacotes.
Um outro mecanismo de QoS apoiado no Cisco 12000 Series é Policiamento de tráfego usando o Committed Access Rate (CAR) no motor 0 e no motor 1 LC, e uma versão modificada do CAR conhecida conforme o controle de taxa de relação (PIRC) no Engine 2 LC. Configure a vigilância de tráfego na interface de saída.
Essa situação é muito rara!
Você pode verificar se a CPU está sobre carregada no LC de recebimento usando o comando execute-on slot <slot#> show controllers tofab queues. Se você vir um número muito grande na coluna #Qelem da linha Raw Queue, significa que pacotes excessivos devem ser manipulados pela CPU (localizada na própria LC). Você começará obter pacotes ignorados porque o CPU não pode prosseguir com a quantidade de pacotes. Estes pacotes são dirigidos ao CPU do LC, não ao Gigabit Route Processor (GRP)!
O que você precisa fazer neste momento é deslocar uma parte do tráfego desse LC de entradas para que sua CPU tenha menor impacto.
Você também deve observar a configuração da LC para verificar se há alguns recursos configurados nela que possam causar impacto na CPU. Alguns recursos (como CAR, ACL e NetFlow) podem degradar o desempenho do LC quando implementado no software (apenas em LCs de Mecanismo 0). Se este é o caso, você deve atuar em conformidade removendo a característica ou promovendo o Cisco IOS Software a uma liberação mais atrasada onde a mesma aplicação da característica seja melhorada (como o turbocompressor ACL). Consulte Release Notes of the Cisco 12000 Series Routers para descobrir quais recursos foram implementados ou aprimorados para diferentes LCs.
Finalmente, a única solução pode ser trocar o LC por um mais recente em que o recurso solicitado seja implementado no hardware. Isto depende realmente do tipo de Engine do LC.
Você pode usar o seguinte comando de atalho para determinar o tipo de mecanismo de L3 de um LC:
Router#show diag | i (SLOT | Engine)...SLOT 1 (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode L3 Engine: 0 - OC12 (622 Mbps)SLOT 3 (RP/LC 3 ): 3 Port Gigabit Ethernet L3 Engine: 2 - Backbone OC48 (2.5 Gbps)...
Nota: As placas de linha do Mecanismo 3 (Mecanismo de serviços IP - ISE) e Mecanismo 4+ são projetadas para aplicativos Edge e implementam serviços IP aperfeiçoados (como QoS) no hardware sem afetar o desempenho.
Utilize ACLs Turbo, que otimizam o desempenho, permitindo que o roteador compile os ACLs antes de fazer download deles para o processador LC.
Evite usar a palavra-chave "log" nas ACLs.
Evite ACLs externas quando possível. Em um sistema com motor 0, 1 e 2 LC, todo o processamento dos ACL são feitos no LC de entrada. Até mesmo a filtração de ACL de saída é feita na placa de entrada, já que ela sabe para qual interface de saída o pacote é destinado. Por esse motivo, a configuração de um ACL de saída na interface afeta todos os LCs no sistema. Além disso, os LCs do Engine 2 podem executar ACLs de entrada ou saída, mas não os dois simultaneamente no ASIC que efetua o encaminhamento de hardware. Caso configure ACLs de entrada e de saída, o LC volta para o encaminhamento baseado em CPU para sair das listas de acesso, causando impacto no desempenho de switching do LC. Entretanto, Engines mais novas, como Engine 3 e Engine 4+ são altamente otimizadas para serviços IP avançados como ACLs e ACLs de saída de processo no LC de saída.
Atribua o tráfego que exige características específicas a um grupo de LC.
Atribua tráfego que não exija recursos de outro conjunto de LCs para manter o desempenho de encaminhamento de pacote de pico.
Utilize LCs com tipos de Mecanismos superiores quando alto desempenho for necessário.
Projete o backbone ou o núcleo adequado às LCs, a fim de executar os recursos suportados pelo hardware ou pelo microcódigo.
Estes Casos Práticos mostram como solucionar erros ignorados de incrementação em uma interface de um LC no slot 6.
Router#exec slot 6 show controllers tofab queue========= Line Card (Slot 6) =======Carve information for ToFab buffers SDRAM size: 134217728 bytes, address: 30000000, carve base: 30019100 134115072 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize, 2 carve(s) max buffer data size 4544 bytes, min buffer data size 80 bytes 174538/174538 buffers specified/carved 110797216/110797216 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 4 non-IPC free queues: 88964/88964 (buffers specified/carved), 50.97%, 80 byte data size 1 21120 84604 81074 262143 54076/54076 (buffers specified/carved), 30.98%, 608 byte data size 2 122270 116965 49567 262143 26165/26165 (buffers specified/carved), 14.99%, 1568 byte data size 3 164160 145355 19518 262143 !-- Out of the 26165 buffers that are carved, only 19518 are available 5233/5233 (buffers specified/carved), 2.99%, 4544 byte data size 4 172325 172088 5233 262143 IPC Queue: 100/100 (buffers specified/carved), 0.5%, 4112 byte data size 30 61 60 100 262143 Raw Queue: 31 44229 88895 0 43634 !-- The Raw Queue has a low or 0 value for the #Qelem column, indicating !-- that the CPU is not overwhelmed with packets destined to it. ToFab Queues: Dest Slot 0 73769 60489 0 262143 1 7909 27395 0 262143 2 61416 71346 0 262143 3 80352 14567 0 262143 4 138236 107121 18955 262143 !-- 18955 packets are waiting for space in the outbound queues !-- on the LC in slot 4. 5 4852 48171 0 262143 6 98318 111757 0 262143 7 44229 88895 0 262143 8 0 0 0 262143 9 0 0 0 262143 10 0 0 0 262143 11 0 0 0 262143 12 0 0 0 262143 13 0 0 0 262143 14 0 0 0 262143 15 0 0 0 262143 Multicast 0 0 0 262143
Desde que as saídas de fila tofab indicaram um grande número pacotes em fila destinados para o LC no entalhe 4, verifique as filas FrFab neste LC.
Router#exec slot 4 show controllers frfab queue========= Line Card (Slot 4) =======Carve information for FrFab buffers SDRAM size: 67108864 bytes, address: 20000000, carve base: 2002D100 66924288 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize, 2 carve(s) max buffer data size 4544 bytes, min buffer data size 80 bytes 65534/65534 buffers specified/carved 66789056/66789056 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 4 non-IPC free queues: 26174/26174 (buffers specified/carved), 39.93%, 80 byte data size 1 10123 4332 14515 65535 19630/19630 (buffers specified/carved), 29.95%, 608 byte data size 2 27898 37167 12279 65535 13087/13087 (buffers specified/carved), 19.96%, 1568 byte data size 3 0 52275 0 65535 !-- Zero buffers available for this pool 6543/6543 (buffers specified/carved), 9.98%, 4544 byte data size 4 60805 60804 6543 65535 IPC Queue: 100/100 (buffers specified/carved), 0.15%, 4112 byte data size 30 75 74 100 65535 Raw Queue: 31 0 80 0 65535 Interface Queues: 0 0 39413 0 65535 1 0 44192 0 65535 2 48426 58230 32111 65535 !-- Interface 2 is using half or 32111 of the carved packet buffers 3 0 41219 0 65535
Faça a correspondência da interface com excesso de assinaturas indicada na saída de show controllers frfab queue com a saída de show interfaces da mesma interface. A saída a seguir confirma que a taxa da interface de saída está na taxa da linha e possui excesso de assinaturas:
Router#show interfaces POS 4/2POS4/2 is up, line protocol is up Hardware is Packet over SONET Description: Pacbell OC3 to other ISP... Internet address is 10.10.10.10/30 MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, rely 255/255, load 156/255 Encapsulation HDLC, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled Last input 00:00:01, output 00:00:03, output hang never Last clearing of "show interface" counters never Queueing strategy: FIFO Output queue 0/300, 0 drops; input queue 0/300, 0 drops 5 minute input rate 20274000 bits/sec, 6263 packets/sec 5 minute output rate 148605000 bits/sec, 28776 packets/sec !-- The output interface rate is at line rate which means that the interface !-- is oversubscribed. 1018621328 packets input, 2339977099 bytes, 0 no buffer Received 0 broadcasts, 1 runts, 0 giants, 0 throttles 0 parity 1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 378645 packets output, 156727974 bytes, 0 underruns 0 output errors, 0 applique, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 1 carrier transitions
Consulte as seções de soluções deste documento para obter as próximas etapas para resolver o incremento de erros ignorados baseado na arquitetura de uma interface de saída específica. Por exemplo, em uma LC do Engine 0, tente desviar algum tráfego para outra interface ou, como medida temporária, reduza o número de buffers de pacote que esta interface particular pode usar a partir das filas livres da placa de linha. Utilize o seguinte comando:
Router(config)#int POS 4/2Router(config-if)#tx-queue-limit 5000
Às vezes, os contadores são incrementados devido a um defeito do software Cisco IOS. Certifique-se de estar executando o train de Cisco IOS Software Release mais recente disponível para eliminar todos os erros que já foram corrigidos. Se você ainda vê os pacotes ignorados, e a informação neste documento não resolve sua edição, contactam o centro de assistência técnica (TAC) de Cisco para o auxílio.