Entendendo a saída debug atm event em interfaces de roteador ATM

Introduction

Vários processadores que residem em um módulo dedicado de processador de sistema, bem como localmente no hardware da interface, trabalham juntos para garantir a transmissão e o recebimento bem-sucedidos de pacotes sobre circuitos virtuais (VCs - Virtual Circuits) ATM. Esses processadores se comunicam entre si, publicando mensagens para executar funções como configuração e desmontagem de VC, coleta de estatísticas da camada física e geração de alarme. Essas mensagens, chamadas de cartas de amor ou mensagens de amor, são escritas por um processador em um bloco de memória. Um processador receptor lê a mensagem. A saída do comando debug atm events fornece uma janela para este mecanismo de mensagens, como a seguinte saída de um PA-A3.

Jun 17 12:48:50.631 BST: atmdx_mailbox_proc(ATM5/0/0): received report type 2 
Jun 17 12:48:50.631 BST: atmdx_process_love_letter(ATM5/0/0): 2 VCs core
 statistics 
Jun 17 12:48:55.631 BST: atmdx_mailbox_proc(ATM5/0/0): received report type 3 
Jun 17 12:48:55.631 BST: atmdx_process_love_letter(ATM5/0/0): 1 VCs aux
 statistics

A finalidade deste documento é ilustrar a saída de eventos de debug atm para ajudar a distinguir entre mensagens informativas e mensagens que apontam para um problema operacional. Este documento também analisa a arquitetura padrão do software da interface ATM.

Cuidado: antes de emitir comandos debug, consulte Informações importantes sobre comandos debug. O comando debug atm events pode imprimir uma grande quantidade de saída de depuração disruptiva em um roteador de produção, dependendo do número de VCs para os quais ele precisa relatar estatísticas, bem como da quantidade de eventos relacionados a VC.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Entendendo os bloqueios funcionais de software

Todas as interfaces ATM utilizam uma arquitetura de software que consiste em vários blocos. Antes de percorrermos esses blocos de software, primeiro precisamos entender os drivers do software Cisco IOS® e a arquitetura do barramento PCI dentro do roteador.

Um driver permite que os engenheiros de software implementem algo chamado abstração de hardware. Ele permite que os engenheiros criem um conjunto fundamental de blocos de software executados em qualquer plataforma e, em seguida, usem drivers para adaptar esse código independente de plataforma a uma plataforma específica, como a série 7200 ou a série 3600.

O PA-A3 suporta um driver de host PCI que permite ao processador de Segmentação e Remontagem (SARs - Segmentation and Reassembly) fazer interface com os barramentos de PCI (Peripheral Component Interconnect) que executam o comprimento da série 7200/7400, bem como com o versátil processador de interface (VIP - Versatile Interface Processor) em plataformas RSP. Os barramentos PCI servem como um caminho de dados entre adaptadores de porta e memória de host no VIP ou no NPE (Network Processing Engine, mecanismo de processamento de rede)/ NSE (Network Services Engine, mecanismo de serviços de rede). O diagrama a seguir ilustra a arquitetura do VIP2 e do local dos barramentos de PCI:

Esta tabela lista os blocos de software no PA-A3:

Bloco de software	Função
núcleo ATM	Funções de software independentes de plataforma ou PA que todas as interfaces ATM usam. Por exemplo, o núcleo ATM lida com o gerenciamento OAM e ILMI.
Driver da plataforma	Funções de software dependentes da plataforma que "fazem a ponte" entre o software central ATM geral e o software de driver de host PCI. O núcleo ATM e o driver de host PCI trocam comandos, atualizações de status e estatísticas através da bridge. O driver ATM da plataforma também lida com o encaminhamento de pacotes de recepção, as funções de inicialização específicas da plataforma e as estatísticas da camada física, como mostrado na tela show controller atm.
driver de host PCI	Fornece a interface de host PCI para o chip SAR no PA-A3. Executa várias funções principais: Transfere o firmware para o SAR Transporta pacotes Coleta estatísticas Monitora alarmes do framer
Interface do host	Parte do bloco funcional de hardware de cada SAR. Executa várias ações importantes: Downloads de código de inicialização para configurar os SARs e permitir que eles troquem dados de controle com o driver do host PCI. Gera interrupções quando o SAR precisa gravar células na memória no caminho de recebimento e programar células no caminho de transmissão. Retorna buffers vazios para o driver de host PCI. Processa os comandos enviados do driver de host PCI e retransmite as estatísticas coletadas localmente para o driver de host PCI.
Firmware	Código de inicialização ou inicialização, bem como imagens otimizadas de tempo de execução para a unidade de processador ATM (APU) nos SARs de recepção e transmissão. Baixado do driver do host PCI.

Na plataforma RSP/VIP, o driver da plataforma reside na imagem do sistema RSP e na imagem do sistema VIP, enquanto o driver do host PCI faz parte da imagem do sistema VIP. Na plataforma 7200, ambos os drivers fazem parte da imagem do sistema.

O software específico do PA-A3 é fornecido com o software VIP ou com o software do sistema para outras plataformas de suporte.

O que é uma caixa de correio?

Como observado acima, uma caixa de correio faz parte de um modelo de mensagens que o Cisco IOS usa para transportar mensagens entre duas CPUs. Veja como esse processo geralmente funciona:

1. Um driver aloca um buffer de mensagem.

2. Uma nota ou letra de amor preenche o buffer de mensagem.

3. O processador receptor lê o buffer de mensagem.

4. Ao terminar de ler o buffer de comando, o processador gera uma interrupção "mensagem concluída".

5. O buffer de mensagens é retornado ao pool de buffer livre.

Agora, este documento examina dois conjuntos de mensagens trocadas entre os processadores que executam os componentes do Cisco IOS Software descritos na tabela acima.

Driver de núcleo ATM para plataforma e driver de host PCI

O driver de host PCI coleta estatísticas por VC em cada pacote. O driver da plataforma VIP retransmite essas estatísticas automaticamente para o driver da plataforma RSP por meio de uma nota de amor a cada segundo. O comando show atm vc exibe os dados atuais do VC. O driver da plataforma VIP retransmite estatísticas do framer para o RSP a cada 10 segundos. Quando o sistema é inicializado, ele cria um processo de segundo plano especial que lida com as estatísticas autônomas do VIP como um processo agendado em vez de no nível de interrupção para minimizar a interrupção do sistema.

O comando debug atm events imprime a saída em eventos relacionados ao VC, como instalação e desmontagem.

Função	Descrição
setupvc	Configurar um VC. O driver dependente da plataforma fornece a solicitação ao driver do host PCI.
teardownvc	Apaga um VC existente. O driver dependente da plataforma retransmite a solicitação ao driver host PCI.
getvc_stats	Recupera estatísticas de VC a pedido; suporta apenas uma única solicitação VC.
qos_params_verify	Verifica os parâmetros de QoS antes de um VC ser configurado.

Driver de host PCI para firmware PA

O SAR consiste internamente em blocos funcionais de hardware. Um desses blocos é a unidade de processamento ATM (APU), que é um miniRISC com lógica personalizada para extensões específicas de ATM. O driver de host PCI e a APU, que executa o firmware ATM, comunicam-se através de uma caixa de correio de mensagens. A qualquer momento, um comando excepcional para cada APU é usado para instruir o firmware do PA a executar uma tarefa específica, como uma configuração de VC. O firmware retransmite estatísticas por VC e por PA ao driver de host PCI a cada 10 segundos se os dados mudarem.

A seguinte saída gerada do evento debug atm mostra os comandos enviados pelo driver do host PCI para o firmware. O firmware retorna apenas confirmações para indicar o sucesso do comando. Essas confirmações não são exibidas na saída de depuração.

7200-1.3(config)# int atm 6/0 
7200-1.3(config-if)# pvc 1/100 
7200-1.3(config-if-atm-vc)# vbr-nrt 45000 45000 
7200-1.3# 
17:07:43: atmdx_setup_vc(ATM6/0): vc:14 vpi:1 vci:100 state:2 config_status:0 
17:07:43: atmdx_pas_vc_setup(ATM6/0): vcd 14, atm hdr 0x00100640, mtu 4482 
17:07:43: VBR: pcr 96000, scr 96000, mbs 94 
17:07:43:  vc tx_limit=1600, rx_limit=480 
17:07:43:  Created 64-bit VC counterss 

7200-1.3(config)# int atm 6/0 
7200-1.3(config-if)# no pvc 1/100 
7200-1.3(config-if)# 
17:08:48: atmdx_teardown_vc(ATM6/0): idb state 4 vcd 14 state 4 
17:08:48: atmdx_pas_teardown_vc(ATM6/0): vcd 14

Arquitetura de software do módulo de rede IMA

Agora, este documento aplica as informações anteriores caminhando pela arquitetura de software do módulo de rede (NM) de multiplexação inversa sobre ATM (IMA) para as séries de roteadores 2600 e 3600.

O IMA NM tem um lado "host" para indicar funções ou memória no módulo do processador e um lado "local" para indicar funções ou memória no próprio módulo da rede. O lado do host executa drivers independentes da plataforma e dependentes da plataforma. O lado local executa o firmware baixado pelos drivers do host para a CPU integrada do NM. Essa imagem lida com as funções da camada física, incluindo o controle do ASIC do framer, a coleta de estatísticas da camada física e a geração de loopbacks e alarmes. Os drivers do Cisco IOS e o firmware do NM se comunicam via mensagens de correio.

No lado local, a IMA do NM também executa um driver de IMA que também usa uma caixa de correio de mensagem para se comunicar com a CPU local.

As mensagens na direção do lado do host para o lado local são projetadas principalmente para configuração. Essas mensagens incluem:

• Dados de configuração da camada física E1/T1

• configuração de grupo IMA

• Configuração de loopback

• Configuração de depuração

• Consulta para status de grupo/link IMA

• Consulta para dados da base de informações de gerenciamento (MIB - Management Information Base) RFC 1406

• Consulta de dados MIB IMA

As mensagens enviadas na direção do lado local para o lado do host são usadas para comunicar alterações de estado de linha e estatísticas de desempenho, incluindo:

• Alterações de status E1/T1 da camada física

• Alterações de status do grupo IMA

• Alterações de status do link IMA

• Alterações de status de loopback

• Mensagens de depuração

• Resposta de dados MIB RFC 1406

• Resposta de dados MIB IMA

O exemplo de saída a seguir ilustra as notas de amor usadas para configurar e destruir um VC. Nós fechamos e não fechamos a interface física para forçar o desligamento. Observe que "rs8234" se refere ao SAR no NM.

3640-1.1(config)# int atm2/ima2 
3640-1.1(config-if)# pvc 1/1 
3640-1.1(config-if-atm-vc)# shut 
3640-1.1(config-if)# 
*Mar  1 00:17:20.323:  Reserved bw for 1/1 Available bw = 6000 
*Mar  1 00:17:20.323: rs8234_setup_vc(ATM2/IMA2): vc:4 vpi:1 vci:1 
*Mar  1 00:17:20.323: rs8234_setup_vc_common() VCD=260 vp/vc=17/1 etype=0 
*Mar  1 00:17:20.323: rs8234_setup_cos(ATM2/IMA2): vc:4 wred_name:- max_q:0 
*Mar  1 00:17:20.327:  Created 64-bit VC counters 
*Mar  1 00:17:20.327: rs8234_teardown_vc(ATM2/IMA2): vc:260 vpi:1 vci:1 
*Mar  1 00:17:20.327: rs8234_teardown_vc proceeds (ATM2/IMA2): vc:260 vpi:1
 vci:1 
*Mar  1 00:17:20.327: Status and ptr is 400 Status Q is 1 
*Mar  1 00:17:20.331: Resetting ATM2/IMA2 
*Mar  1 00:17:20.331: rs8234_teardown_vc(ATM2/IMA2): vc:260 vpi:1 vci:1 
*Mar  1 00:17:20.331: rs8234_teardown_vc proceeds (ATM2/IMA2): vc:260 vpi:1 vci:1 
*Mar  1 00:17:20.331:  Remove link with ports 8,links 4,channel 1 
*Mar  1 00:17:22.327: %LINK-5-CHANGED: Interface ATM2/IMA2, changed state to administratively down 
3640-1.1(config-if)# no shut 
3640-1.1(config-if)# 
*Mar  1 00:17:31.287: Resetting ATM2/IMA2 
*Mar  1 00:17:31.287: IMA config_interface ATM2/IMA2 
*Mar  1 00:17:31.287: IMA config_restart ATM2/IMA2 
*Mar  1 00:17:31.287: IMA restarting 0 VCs 
*Mar  1 00:17:31.287: rs8234_setup_vc(ATM2/IMA2): vc:4 vpi:1 vci:1 
*Mar  1 00:17:31.287: rs8234_setup_vc_common() VCD=260 vp/vc=17/1 etype=0 
*Mar  1 00:17:31.287: rs8234_setup_cos(ATM2/IMA2): vc:4 wred_name:- max_q:0

Informações Relacionadas

• Adaptador de porta ATM Cisco
• Suporte à tecnologia ATM
• Suporte Técnico - Cisco Systems

Histórico de revisões