Troubleshooting de Pacotes Ignorados e Quedas Sem Memória no Cisco 12000 Series Internet Router

Introduction

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. Ele também fornece dicas de solução de problemas para um número cada vez maior de quedas de nenhum mem na saída do slot execute-on <slot#> show controllers (frfab | tofab) comando qm stat. Ao Troubleshoot algum desses erros, verifique se o contador está incrementando e se não é apenas um valor histórico.

Observação: um número cada vez maior de quedas de fila de entrada, conforme exibido na saída show interfaces, é abordado separadamente em Troubleshooting Input Drops no Cisco 12000 Series Internet Router.

Prerequisites

Requirements

Este documento requer o conhecimento da arquitetura do Roteador de Internet da Série Cisco 12000, especialmente das filas ToFab e FrFab. Consulte Como ler a saída do comando show controllers frfab Comandos | tofab queue para referência.

Componentes Utilizados

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. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Conventions

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

Sintomas

O Cisco 12000 Series Internet Router usa uma arquitetura distribuída para garantir o melhor desempenho de encaminhamento. Para oferecer suporte a taxas altas de encaminhamento, ele mantém buffers de pacotes nas placas de linha de entrada e de saída. Esses buffers de pacotes variam de tamanho e geralmente são projetados para suportar quadros do tamanho da MTU (Maximum Transmission Unit, Unidade Máxima de Transmissão).

Depois de determinar a interface de saída de um pacote, o processador de encaminhamento faz o seguinte:

1. 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.

2. 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.

3. A placa de linha de saída coloca os pacotes em buffer.

4. 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 de saída tiver excesso de assinaturas, ela começará a armazenar em buffer os pacotes em excesso. Durante os períodos de sobreassinatura sustentada, as filas de transmissão do LC de saída são preenchidas. 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
Engine 0 e 1	Envia um sinal de pressão contrária. A interface de entrada começa a armazenar em buffer os pacotes em excesso.	Erros ignorados na saída do comando show interfaces e/ou no mem drops no execute-on slot <slot#> show controllers tofab QM stat da LC de entrada, dependendo de seu L3 Forwarding Engine.¹
Mecanismo 2, 3, 4	Descarta todos os pacotes em excesso na saída.	Nenhum descarte de mem na saída do comando execute-on slot <slot#> show controllers frfab QM stat no LC de saída.

¹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 de uma incompatibilidade nas taxas de interface, erros ignorados podem aumentar quando a taxa de pacotes chegando é maior do que a CPU pode processá-los. 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. Esse é o caso das LCs do Engine 0 em que muitos recursos são implementados em software. No entanto, em mecanismos posteriores, quase todos os recursos são implementados em hardware. Por exemplo, as placas de linha Engine 3 (IP Services Engine - ISE) e Engine 4+ são projetadas para aplicações Edge e implementam serviços IP avançados (como Qualidade de Serviço - QoS) em hardware sem 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.

Gerenciando sobreassinatura de interface externa

A solução para erros ignorados e sem quedas de memória causadas pela sobreassinatura da interface de saída é a mesma para qualquer tipo de mecanismo L3 — evite a indisponibilidade do buffer. Em outras palavras, precisamos de um mecanismo que impeça que as filas FrFab sejam preenchidas.

Motores 0 e 1

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.

Aqui está um exemplo de saída do comando show interfaces com um contador ignorado não nulo em um Cisco 12000 Series Router:

router#show interfaces G3/0
GigabitEthernet3/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. Em seguida, a interface de entrada coloca em buffer os pacotes em excesso nas filas ToFab correspondentes a esse 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.

Mecanismos 2, 3, 4

As placas de linha que usam uma arquitetura de mecanismo L3 mais recente 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 de recuo foi implementado somente para LCs do Engine 2 no lado 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 controller
frfab 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" counter

0 rawq drops, 0 global red drops, 0 global force drops
0 no memory (ns), 0 no memory hwm (Ns)
no free queue
0       0       0       0
0       0       0       0
0       0       0       0
0       0       0       0
0 multicast drops
Tx Counts
 Interface 0
8390658710246 TX bytes, 2098330790 TX pkts, 212452 kbps, 6641 pps
 Interface 1
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 2
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 3
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS

Você precisa encontrar uma maneira de impedir que o lado FrFab faça buffer até o ponto em que o LC faz backup na interface de entrada ou simplesmente descarta os pacotes.

Uma solução simples para todas as placas de linha, exceto os LCs do Engine 2, é reduzir o número de buffers disponíveis para uma interface de saída específica em um LC multiinterface. 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 é suportado em placas de linha baseadas no Engine 2.

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

Outra solução é implementar uma interface de saída mais rápida, que nos dê um tubo maior. Mas canos maiores podem ser enchidos rapidamente. Assim, a solução recomendada é implementar mecanismos de Qualidade de Serviço (QoS - Quality of Service) no LC de saída.

O recurso WRED (Weighted Random Early Detection, Detecção Antecipada Aleatória Ponderada) da Cisco implementa 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. Os outros LCs do L3 Engine suportam WRED em hardware.

Para obter mais informações sobre como configurar o WRED, consulte estes documentos:

• Detecção antecipada aleatória ponderada no Cisco 12000 Series Router

• Configurando o MPLS CoS em um Cisco 12000 Series GSR Router

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 lida com a perda de tráfego e como o roteador interage com o TCP para obter detalhes sobre como o TCP reage à perda de pacotes.

Outro mecanismo de QoS suportado no Cisco 12000 Series é a vigilância de tráfego usando a Taxa de Acesso Comprometida (CAR - Committed Access Rate) nos LCs Engine 0 e Engine 1 e uma versão modificada do CAR conhecida como Controle de Taxa de Interface (PIRC - Per Interface Rate Control) nos LCs do Engine 2. Configure a vigilância de tráfego na interface de saída.

Gerenciando CPU sobrecarregada na placa de linha de entrada

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á a obter pacotes ignorados porque a CPU não pode acompanhar a quantidade de pacotes. Esses pacotes são direcionados para a CPU do LC, não para o 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 for esse o caso, você deve agir de acordo, removendo o recurso ou atualizando o software Cisco IOS para uma versão posterior onde a mesma implementação de recurso é melhorada (como a ACL Turbo). 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. Isso realmente depende 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)
...

Observação: as placas de linha Engine 3 (IP Services Engine - ISE) e Engine 4+ são projetadas para aplicativos Edge e implementam serviços IP avançados (como QoS) em hardware sem impacto no desempenho.

Sumário das diretrizes do projeto

• 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 LCs Engine 0, 1 e 2, todo o processamento de ACLs é feito 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 recursos específicos a um conjunto de LCs.

• 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.

Casos Práticos

Estes Casos Práticos mostram como solucionar erros ignorados de incrementação em uma interface de um LC no slot 6.

Etapa 1 – Verifique as filas ToFab 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

Etapa 2 – Verifique as filas FrFab no slot 4.

Como a saída da fila ToFab indicou um grande número de pacotes em fila destinados ao LC no slot 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

Passo 3 – Compare a saída do comando show interfaces para a mesma interface ultrapassada.

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/2
POS4/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

Passo 4 – Implementar uma solução.

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/2
Router(config-if)#tx-queue-limit 5000

Bugs do Cisco IOS Software

À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 vir pacotes ignorados e as informações neste documento não resolverem seu problema, entre em contato com o Centro de Assistência Técnica (TAC) da Cisco para obter assistência.

Informações Relacionadas

• Troubleshooting de Quedas de Entrada no Cisco 12000 Series Internet Router
• Como ler a saída do comando show controllers frfab Comandos | tofab queue
• Detecção antecipada aleatória ponderada no Cisco 12000 Series Internet Router
• Configurando o MPLS CoS em um Cisco 12000 Series GSR Router
• Como o TCP Lida com a Perda de Tráfego
• Como o Roteador Interage com o TCP
• Configurando Taxa de Acesso Comprometida
• Notas de versão dos Cisco 12000 Series Routers
• Suporte Técnico e Documentação - Cisco Systems