Módulos e interfaces de Cisco : Adaptador de puerto Cisco ATM

Descripción del resultado del comando debug atm event en interfaces de router ATM

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Procesadores múltiples que residen en un módulo del procesador del sistema dedicado así como localmente en el trabajo del hardware de la interfaz junto para asegurar la transmisión exitosa y el recibo de los paquetes sobre los circuitos virtuales ATM (VCs). Estos procesadores comunican entre ellos mismos por las publicaciones de mensajes para realizar las funciones tales como la configuración y desmontaje del VC, recolección de estadísticas de la Capa física, y generación de alarma. Estos mensajes, llamados las cartas de amor o los mensajes del amor, son escritos por un procesador en un bloque de memoria. Un procesador de recepción entonces lee el mensaje. La salida del comando debug atm events proporciona una ventana en este mecanismo de mensajería, tal como el producto siguiente de un 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

El propósito de este documento es ilustra la salida del evento del debug ATM de la muestra para ayudar a distinguir entre los mensajes de información y los mensajes que señalan a un problema de funcionamiento. Este documento también revisa la arquitectura de software estándar de la interfaz ATM.

precaución Precaución: Antes de publicar los comandos debug, refiera por favor a la información importante en los comandos Debug. El comando debug atm events puede imprimir una gran cantidad de salida de los debugs perturbadora en un router de producción dependiendo del número de VCs para el cual necesita señalar las estadísticas así como la cantidad de eventos VC-relacionados.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Información sobre bloques funcionales de software

Todas las interfaces ATM utilizan una arquitectura de software que consta de múltiples bloques. Antes de que recorramos a través de estos Bloques del software, primero necesitamos entender los driveres de software del ½ del ¿Â de Cisco IOSï y el arquitectura de bus PCI dentro de su router.

Un driver permite que los ingenieros de software implementen algo abstracción de hardware llamada. Permite que los ingenieros creen un conjunto fundamental de los Bloques del software que se ejecutan en cualquier plataforma, y después utiliza los drivers para adaptar este código independiente de la plataforma a una plataforma específica tal como las 7200 Series o las 3600 Series.

El PA-A3 soporta un driver del host PCI que permita que el procesador de la segmentación y del nuevo ensamble (SAR) interconecte con los busses del Interconexión de componentes periféricos (PCI) que funcionan con la longitud de las 7200/7400 Series, así como el procesador de interfaz versátil (VIP) en las plataformas RSP. Los busses PCI sirven como trayecto de datos entre los adaptadores de puerto y la memoria del host en el VIP o en el motor de los servicios del /Network del Network Processing Engine (NPE) (NSE). El siguiente diagrama muestra la arquitectura de VIP2 y la ubicación de los buses PCI:

/image/gif/paws/10437/debugevents1.gif

Esta tabla enumera los Bloques del software en el PA-A3:

Bloque del software Función
Base atmósfera Funciones del software de la plataforma o de la PA-independiente que todas las interfaces ATM utilizan. Por ejemplo, la base atmósfera maneja el OAM y la administración ILMI.
Driver de plataforma Funciones del software dependientes de la plataforma que “interligue” el software del núcleo general atmósfera con el software del driver del host PCI. Base atmósfera y los comandos pci host driver exchange, las actualizaciones del estado, y las estadísticas vía el Bridge. El driver de la plataforma ATM también maneja el reenvío de paquetes de recepción, la inicialización específica de la plataforma funciona, y las estadísticas de la Capa física tal y como se muestra en de la visualización del regulador ATM de la demostración.
Driver del host PCI Proporciona la interfaz del host PCI para el chip SAR en el PA-A3. Realiza varias funciones claves:
  • Descarga el firmware al SAR
  • Transporta los paquetes
  • Reúne estadístico
  • Monitorea las alarmas del fundador
Interfaz del host Parte de bloque funcional del hardware cada SAR. Realiza varias acciones dominantes:
  • Las descargas inician el código para configurar los SAR y los habilitan a los datos de control de intercambio con el driver del host PCI.
  • Genera las interrupciones cuando el SAR necesita escribir las células en la memoria en la trayectoria de la recepción y las células del horario en la trayectoria del transmitir.
  • Las devoluciones vacian los buffers al driver del host PCI.
  • Los comandos de los procesos enviados del driver del host y de las retransmisiones PCI localmente recogieron las estadísticas al driver del host PCI.
Firmware El código del lanzamiento o del inicio así como las imágenes de tiempo de ejecución optimizadas para la unidad de procesamiento atmósfera (APU) en la recepción y transmiten los SAR. Descargado del driver del host PCI.

En la plataforma RSP/VIP, el driver de plataforma reside en la imagen del sistema RSP y la imagen del sistema VIP, mientras que el driver del host PCI es parte de la imagen del sistema VIP. En la plataforma 7200, ambos drivers son parte de la imagen del sistema.

El software PA-A3-specific se lía con el software VIP o con el software del sistema para otras plataformas de soporte.

¿Qué es una casilla de correo?

Según lo observado arriba, un buzón es parte de al modelo de mensajería que el Cisco IOS utiliza para transportar los mensajes entre dos CPU. Aquí es cómo este proceso trabaja generalmente:

  1. Un driver afecta un aparato un búfer del mensaje.

  2. Una nota o una carta del amor llena el búfer del mensaje.

  3. El procesador de recepción lee el búfer del mensaje.

  4. Cuando está acabado de leer el búfer de comando, el procesador genera una interrupción hecha “mensaje”.

  5. El búfer del mensaje se vuelve al pool de almacén libre.

Ahora este documento examina dos conjuntos de los mensajes intercambiados entre los procesadores que funcionan con los componentes de Cisco IOS Software descritos en la tabla arriba.

Base atmósfera al driver de plataforma y al driver del host PCI

/image/gif/paws/10437/debugevents2.gif

El driver del host PCI recoge las estadísticas por VC sobre cada paquete. El driver de la plataforma VIP autónomo retransmite estas estadísticas al driver de la plataforma RSP vía un amor observa cada segundo. El comando show atm vc visualiza los datos actuales del VC. Las estadísticas del creador de tramas de relés del driver de la plataforma VIP al RSP cada 10 segundos. Cuando el sistema se inicializa, crea un proceso subordinado especial que maneje las estadísticas autónomas del VIP como proceso planificado bastante que en el nivel de interrupción para minimizar la interrupción del sistema.

El comando debug atm events imprime la salida en los eventos VC-relacionados tales como configuración y desmontaje.

Función Descripción
setupvc Configure un VC. El driver basado en la plataforma entrega la petición al driver del host PCI.
teardownvc Derriba un VC existente. El driver basado en la plataforma retransmite la petición al driver del host PCI.
getvc_stats Extrae las estadísticas del VC a pedido; soportes solamente una sola petición del VC.
qos_params_verify Verifica los paramters de QoS antes de que se configure un VC.

Driver del host PCI al Firmware PA

El SAR internamente consiste en los bloques funcionales del hardware. Un tal bloque es la unidad de procesamiento atmósfera (APU), que es un miniRISC con la lógica personalizada para las Extensiones Específicas del ATM. El driver del host PCI y el APU, que funciona con el firmware ATM, comunican vía una casilla de correo de mensajería. En cualquier momento, un comando excepcional para cada APU se utiliza para dar instrucciones el Firmware PA para realizar una tarea específica, tal como una configuración del VC. El firmware retransmite por VC y las estadísticas por-PA al driver del host PCI cada 10 segundos si los datos cambian.

El producto siguiente generado del evento del debug ATM muestra los comandos enviados por el driver del host PCI al firmware. El firmware vuelve solamente los acuses de recibo para indicar el éxito del comando. Estos acuses de recibo no se visualizan en la salida de los debugs.

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

Arquitectura del software del módulo de red IMA

Ahora este documento aplica la información precedente recorriendo con la arquitectura de software del network module (NM) del Inverse Multiplexing over ATM (IMA) para la serie del 2600 y 3600 Router.

El IMA NM tiene un lado del “host” para indicar las funciones o la memoria en el módulo del procesador y un lado del “local” para indicar las funciones o la memoria en el módulo de red sí mismo. El lado del host funciona con independiente de la plataforma y los driveres basados en la plataforma. El lado local ejecuta el firmware descargado por los driveres del host al CPU a bordo NM. Esta imagen maneja las funciones de la Capa física, incluyendo el control del ASIC de encuadre, colección de estadísticas de la Capa física, y generación de Loopbacks y las alarmas. Los drivers del Cisco IOS y el firmware NM comunican vía los mensajes del correo.

En el lado local, el NM IMA también funciona con un driver IMA que utilice semejantemente una casilla de mensajes de correo para comunicar al CPU local.

Los mensajes en dirección del lado del host al lado local se diseñan sobre todo para la configuración. Estos mensajes incluyen:

  • Datos de configuración de la Capa física E1/T1

  • Configuración del grupo IMA

  • Loopback Configuration

  • Configuración del debug

  • Interrogación para el grupo IMA/estado de link

  • Pregunte para los datos de la Base de información para administración (MIB) del RFC 1406 (MIB)

  • Interrogación para los datos MIB IMA

Los mensajes enviados en dirección del lado local al lado del host se utilizan para comunicar la línea cambios de estado y estadísticas de rendimiento, incluyendo éstos:

  • Cambios de estado de la Capa física E1/T1

  • Cambios de estado del grupo IMA

  • Cambios del estado de link IMA

  • Cambios del Loopback Status

  • Mensajes del debug

  • Respuesta de los datos MIB del RFC 1406

  • Respuestas de datos MIB IMA

La salida de muestra siguiente ilustra las notas del amor usadas para poner y el desmontaje un VC. Cerramos y ningún cerrado la interfaz física para forzar el desmontaje. Observe que el "rs8234" refiere al SAR en el 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

Información Relacionada


Document ID: 10437