Routers : Routers de agregación de servicios Cisco ASR de la serie 9000

Los errores del trayecto de datos de la tela de la batea de las 9000 Series ASR resuelven problemas la guía

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

Contenido

Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Este documento describe los mensajes de error del trayecto de datos de la tela de la batea considerados durante la operación de las 9000 Series del router de los servicios de la agregación de Cisco (ASR). El mensaje aparece en este formato:

RP/0/RSP0/CPU0:Sep  3 13:49:36.595 UTC: pfm_node_rp[358]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)

Este documento se piensa para cualquier persona que quiera entender el mensaje de error, y medidas que deben ser tomadas si se considera el problema.

Contribuido por Mahesh Shirshyad, los poderes de David, y Jean Christophe montaron, los ingenieros de Cisco TAC.

Prerrequisitos

Requisitos

Cisco recomienda que usted tiene un conocimiento de alto nivel de estos temas:

  • Linecards ASR 9000
  • Placas de fábrica
  • Route Processor
  • Arquitectura del chasis

Sin embargo, este documento no requiere a los lectores ser familiares con los detalles del hardware. Se proporciona la información previa necesaria antes de que se explique el mensaje de error. Este documento describe el error en el linecards del tridente y Tifón-basado. Vea los tipos del linecard de las 9000 Series ASR para una explicación de esos términos.

Componentes Utilizados

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

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Cómo utilizar este documento

Considere estas sugerencias sobre cómo utilizar este documento para espigar los detalles esenciales y como un guía de referencia en el proceso del Troubleshooting:

  • Cuando no hay urgencia a la causa raíz al error del trayecto de datos de la tela de la batea, lea todas las secciones de este documento. Este documento construye el fondo necesario necesario para aislar a un componente defectuoso cuando ocurre tal error.

  • Utilice la sección FAQ si usted tiene una pregunta específica en la mente para la cual una respuesta rápida es necesaria.  Si la pregunta no se incluye en la sección FAQ, después control si el documento principal dirige la pregunta.

  • Utilice todas las secciones del analizan los incidentes encendido para aislar el problema a un componente defectuoso cuando un router experimenta un incidente o para marcar si es un problema conocido.

Antecedentes

Un paquete puede atravesar o dos saltos o tres saltos a través del Switch Fabric basado sobre el linecard teclean. El linecards de la generación del tifón agrega un elemento adicional del Switch Fabric, mientras que Switch Trident-basado del linecards todo el tráfico con la tela en el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor solamente. Estos elementos de la tela de la demostración de los diagramas para ambos tipos del linecard, así como Conectividad de la tela al indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor:

Trayectoria del paquete de diagnóstico de la tela de la batea

La aplicación de diagnóstico que se ejecuta en el indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor inyecta los paquetes de diagnóstico destinados a cada procesador de red (NP) periódicamente. El paquete de diagnóstico es circuito hecho atrás dentro del NP, y reinyectado hacia el indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor que originado el paquete. Esta revisión médica periódica de cada NP con un paquete único por el NP por la aplicación de diagnóstico en el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor proporciona una alerta para cualquier error funcional en el trayecto de datos durante la operación del router. Es esencial observar que la aplicación de diagnóstico en el procesador de la ruta activa y el Route Processor espera inyecta un paquete por el NP periódicamente y mantiene a por el éxito o la cuenta de fallas NP. Cuando un umbral de los paquetes de diagnóstico caídos se alcanza, la aplicación aumenta un incidente.

Vista conceptual de la trayectoria de diagnóstico

Antes de que el documento describa la trayectoria de diagnóstico en el linecards del tridente y Tifón-basado, esta sección proporciona a un general delinea de la trayectoria de diagnóstico de la tela de los indicadores luminosos LED amarillo de la placa muestra gravedad menor activos y espera del Route Processor hacia el NP en el linecard.

Trayecto de paquete entre la placa del procesador de la ruta activa y el linecard

Los paquetes de diagnóstico inyectados del procesador de la ruta activa en la tela hacia el NP son tratados como paquetes de unidifusión por el Switch Fabric. Con los paquetes de unidifusión, el Switch Fabric elige el link saliente basado en la carga de tráfico actual del link, que ayuda a sujetar los paquetes de diagnóstico a la carga de tráfico en el router. Cuando hay links salientes múltiples hacia el NP, el Switch Fabric ASIC elige un link que sea actualmente cargados lo más menos posible.

Este diagrama representa la trayectoria del paquete de diagnóstico originada del procesador de la ruta activa.

Nota: El primer link que conecta el Fabric Interface ASIC (FIA) en el linecard con la barra transversal (XBAR) en el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor se elige todo el tiempo para los paquetes destinados al NP. Los paquetes de respuesta del NP se sujetan a un algoritmo de distribución de la link-carga (si Tifón-se basa el linecard). Esto significa que el paquete de respuesta del NP hacia el procesador de la ruta activa puede elegir los links uces de los de la tela que conectan el linecards con el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor basado en la carga de link de la tela.

Trayecto de paquete entre el indicador luminoso LED amarillo de la placa muestra gravedad menor espera del Route Processor y el linecard

Los paquetes de diagnóstico inyectados del Route Processor espera en la tela hacia el NP son tratados como paquetes de multidifusión por el Switch Fabric. Aunque sea un paquete de multidifusión, no hay replicación dentro de la tela. Cada paquete de diagnóstico originado del Route Processor espera todavía alcanza solamente un en un momento NP. El paquete de respuesta del NP hacia el Route Processor es también un paquete de multidifusión sobre la tela sin la replicación. Por lo tanto, la aplicación de diagnóstico en el Route Processor espera recibe un solo paquete de respuesta de los NP, un en un momento del paquete. La aplicación del diagnóstico sigue cada NP en el sistema, porque inyecta un paquete por el NP, y cuenta con las respuestas de cada NP, un en un momento del paquete. Con un paquete de multidifusión, el Switch Fabric elige el link saliente basado en un valor de campo en el encabezado de paquete, que las ayudas para inyectar los paquetes de diagnóstico sobre cada link de la tela entre el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor y el linecard. El Route Processor del recurso seguro sigue la salud NP sobre cada link de la tela que conecte entre el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor y el slot del linecard.

El diagrama anterior representa la trayectoria del paquete de diagnóstico originada del Route Processor espera. Note que, a diferencia de la caja del procesador de la ruta activa, todos los links que conectan el linecard con XBAR encendido el Route Processor se ejercitan. Los paquetes de respuesta del NP toman el mismo link de la tela que fue utilizado por el paquete en el Route Processor a la dirección del linecard. Esta prueba se asegura de que todos los links que conectan el Route Processor espera con el linecard estén monitoreados continuamente.

Trayectoria del paquete de diagnóstico de la tela de la batea en el linecard Trident-basado

Este diagrama representa los paquetes de diagnóstico originados del Route Processor destinados a un NP que sea circuito hecho atrás hacia el Route Processor. Es importante observar a todos los NP, así como los links y los componentes del trayecto de datos los links y Asics que son comunes que son específicos a un subconjunto de NP. Por ejemplo, el Bridge ASIC 0 (B0) es común a NP0 y a NP1, mientras que FIA0 es común a todos los NP. En el extremo del Route Processor, todos los links, el trayecto de datos Asics, y el Field Programmable Gate Array (FPGA) son comunes a todo el linecards, y por lo tanto a todos los NP en un chasis.

Trayectoria del paquete de diagnóstico de la tela de la batea en el linecard Tifón-basado

Este diagrama representa los paquetes de diagnóstico originados del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor destinados a un NP que sea circuito hecho atrás hacia el Route Processor. Es importante observar los links y Asics del trayecto de datos que son comunes a todos los NP así como links y componentes que sean específicos a un subconjunto de NP. Por ejemplo, FIA0 es común a NP0 y a NP1. En el extremo del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor, todos los links, el trayecto de datos Asics, y los FGPA son comunes a todo el linecards, y por lo tanto a todos los NP en un chasis.

Las secciones próximas intentan representar el trayecto de paquete a cada NP. Esto es necesario para entender el mensaje de error del trayecto de datos de la tela de la batea, y también para localizar la punta del error.

Información de la alarma de diagnóstico y del error de la tela de la batea

El error conseguir las respuestas de un NP en un 9000-based Router ASR da lugar a una alarma. La decisión para aumentar una alarma por la aplicación del diagnóstico en línea que ejecuta en el Route Processor ocurre cuando hay tres errores consecutivos. La aplicación de diagnóstico mantiene una ventana del error de tres paquetes para cada NP. El procesador de la ruta activa y el Route Processor espera diagnostican independientemente y paralelamente. El procesador de la ruta activa, el Route Processor espera, o ambos indicadores luminosos LED amarillo de la placa muestra gravedad menor del Route Processor pudieron señalar el error. La ubicación del incidente y la pérdida del paquete determinan que el Route Processor señala a alarma.

La frecuencia predeterminada del paquete de diagnóstico hacia cada NP es un paquete por 60 segundos o uno por el minuto.

Aquí está el formato del mensaje de alarma:

RP/0/RSP0/CPU0:Sep  3 13:49:36.595 UTC: pfm_node_rp[358]: 
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)

El mensaje se debe leer como error alcanzar NP 1, el 2,3, 4, 5, 6, y 7 en el linecard 0/7/cpu0 del Route Processor 0/rsp0/cpu0.

De la lista de pruebas de diagnóstico en línea, usted puede ver los atributos de la prueba de Loopback de la tela de la batea con este comando:

RP/0/RSP0/CPU0:iox(admin)#show diagnostic content location 0/RSP0/CPU0


RP 0/RSP0/CPU0:

Diagnostics test suite attributes:
M/C/* - Minimal bootup level test / Complete bootup level test / NA
B/O/* - Basic ondemand test / not Ondemand test / NA
P/V/* - Per port test / Per device test / NA
D/N/* - Disruptive test / Non-disruptive test / NA
S/* - Only applicable to standby unit / NA
X/* - Not a health monitoring test / NA
F/* - Fixed monitoring interval test / NA
E/* - Always enabled monitoring test / NA
A/I - Monitoring is active / Monitoring is inactive
Test Interval Thre-
ID Test Name Attributes (day hh:mm:ss.ms shold)
==== ================================== ============ ================= =====
1) PuntFPGAScratchRegister ---------- *B*N****A 000 00:01:00.000 1
2) FIAScratchRegister --------------- *B*N****A 000 00:01:00.000 1
3) ClkCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
4) IntCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
5) CPUCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
6) FabSwitchIdRegister -------------- *B*N****A 000 00:01:00.000 1
7) EccSbeTest ----------------------- *B*N****I 000 00:01:00.000 3
8) SrspStandbyEobcHeartbeat --------- *B*NS***A 000 00:00:05.000 3
9) SrspActiveEobcHeartbeat ---------- *B*NS***A 000 00:00:05.000 3
10) FabricLoopback ------------------- MB*N****A 000 00:01:00.000 3
11) PuntFabricDataPath --------------- *B*N****A 000 00:01:00.000 3
12) FPDimageVerify ------------------- *B*N****I 001 00:00:00.000 1

RP/0/RSP0/CPU0:ios(admin)#

La salida muestra que la frecuencia de la prueba de PuntFabricDataPath es un paquete cada minuto, y el umbral del error es tres, que implica que la pérdida de tres paquetes consecutivos no está tolerada y da lugar a una alarma. Los atributos de la prueba mostrados son valores predeterminados. Para cambiar los valores por defecto, ingrese el intervalo del monitor de diagnóstico y los comandos threshold del monitor de diagnóstico en el modo de configuración de la administración.

Trayectoria Trident-basada del paquete de diagnóstico del linecard

Falla de diagnóstico NP0

Trayectoria de diagnóstico de la tela

Este diagrama representa el trayecto de paquete entre el Route Processor CPU y el linecard NP0. El link que conecta el B0 y NP0 es el único específico del link a NP0. Todos los otros links caen en la trayectoria común.

Anote el trayecto de paquete del Route Processor hacia NP0. Aunque haya cuatro links a utilizar para los paquetes destinados hacia NP0 del Route Processor, el primer link entre el Route Processor y el slot del linecard se utiliza para el paquete del Route Processor hacia el linecard. El paquete vuelto de NP0 se puede devolver al procesador de la ruta activa sobre las dos trayectorias unas de los del link de la tela entre el slot del linecard y el procesador de la ruta activa. La opción cuyo uno de los dos links a utilizar depende de la carga de link en aquel momento. El paquete de respuesta de NP0 hacia el Route Processor espera utiliza ambos links, pero un en un momento del link. La opción del link se basa en el campo del encabezado que la aplicación de diagnóstico puebla.

Análisis de la falla de diagnóstico NP0

Solo escenario del incidente

Si detectan a una falla de alarma del trayecto de datos de la tela de la batea del administrador del incidente de la plataforma única (PFM) con solamente NP0 en el mensaje de error, el incidente está solamente en la trayectoria de la tela que conecta el Route Processor y el linecard NP0. Esto es un solo incidente. Si el incidente se detecta a más de un NP, refiera a la sección múltiple del escenario del incidente.

RP/0/RSP0/CPU0:Sep  3 13:49:36.595 UTC: pfm_node_rp[358]: 
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 0)

Nota: Esta sección del documento aplica a cualquier linecard el slot en un chasis, sin importar el chasis teclea. Por lo tanto, esto se puede aplicar a todos los slots del linecard.

Como se ilustra en el diagrama de la trayectoria de datos anteriores, el incidente tiene que estar en uno o más de estas ubicaciones:

  • Conecte que conecta NP0 y el B0
  • Colas de administración del tráfico interiores B0 dirigidas hacia NP0
  • NP0 interior

Escenario múltiple del incidente

Incidentes múltiples NP

Cuando otros incidentes se observan en NP0 o el incidente PUNT_FABRIC_DATA_PATH_FAILED también es señalado por otros NP en el mismo linecard, después el aislamiento de falla es hecho correlacionando todos los incidentes. Por ejemplo, si el incidente PUNT_FABRIC_DATA_PATH_FAILED y el incidente LC_NP_LOOPBACK_FAILED ocurren en NP0, después el NP ha parado el procesar de los paquetes. Refiera a la sección de la trayectoria de diagnóstico del Loopback NP para entender el incidente del loopback. Ésta podía ser una indicación temprana de una falla crítica dentro de NP0. Sin embargo, si ocurre solamente uno de los dos incidentes, después el incidente se localiza al trayecto de datos de la tela de la batea o en el linecard CPU a la trayectoria NP.

Si más de un NP en un linecard tiene un incidente del trayecto de datos de la tela de la batea, después usted debe recorrer encima de la trayectoria del árbol de los links de la tela para aislar a un componente defectuoso. Por ejemplo, si NP0 y NP1 tienen un incidente, después el incidente tiene que estar en el B0 o el link que conecta el B0 y FIA0. Es menos probable que NP0 y NP1 encuentren un error interno crítico al mismo tiempo. Aunque sea menos probable, es posible para que NP0 y NP1 encuentren un incidente del Error crítico debido al proceso incorrecto de una clase determinada de paquete o de un mún paquete.

Ambos indicadores luminosos LED amarillo de la placa muestra gravedad menor del Route Processor señalan un incidente

Si el Route Processor activo y espera carda el informe un incidente a uno o más NP en un linecard, después marque todos los links y componentes del campo común en el trayecto de datos entre los NP afectados y ambos los indicadores luminosos LED amarillo de la placa muestra gravedad menor del Route Processor.

Falla de diagnóstico NP1

Este diagrama representa el trayecto de paquete entre el indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor y el linecard NP1. El link que conecta el Bridge ASIC 0 (B0) y NP1 es el único específico del link a NP1. Todos los otros links caen en la trayectoria común.

Anote el trayecto de paquete del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor hacia NP1. Aunque haya cuatro links a utilizar para los paquetes destinados hacia NP0 del Route Processor, el primer link entre el Route Processor y el slot del linecard se utiliza para el paquete del Route Processor hacia el linecard. El paquete vuelto de NP1 se puede devolver al procesador de la ruta activa sobre las dos trayectorias unas de los del link de la tela entre el slot del linecard y el procesador de la ruta activa. La opción cuyo uno de los dos links a utilizar depende de la carga de link en aquel momento. El paquete de respuesta de NP1 hacia el Route Processor espera utiliza ambos links, pero un en un momento del link. La opción del link se basa en el campo del encabezado que la aplicación de diagnóstico puebla.

Trayectoria de diagnóstico de la tela

Análisis de la falla de diagnóstico NP1

Refiera a la sección del análisis de la falla de diagnóstico NP0, pero aplique el mismo razonamiento para NP1 (en vez de NP0).

Falla de diagnóstico NP2

Este diagrama representa el trayecto de paquete entre el indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor y el linecard NP2. El link que conecta el B1 y NP2 es el único específico del link a NP2. Todos los otros links caen en la trayectoria común.

Anote el trayecto de paquete del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor hacia NP2. Aunque haya cuatro links a utilizar para los paquetes destinados hacia NP2 del Route Processor, el primer link entre el Route Processor y el slot del linecard se utiliza para el paquete del Route Processor hacia el linecard. El paquete vuelto de NP2 se puede devolver al procesador de la ruta activa sobre las dos trayectorias unas de los del link de la tela entre el slot del linecard y el procesador de la ruta activa. La opción cuyo uno de los dos links a utilizar depende de la carga de link en aquel momento. El paquete de respuesta de NP2 hacia el Route Processor espera utiliza ambos links, pero un en un momento del link. La opción del link se basa en el campo del encabezado que la aplicación de diagnóstico puebla.

Trayectoria de diagnóstico de la tela

Análisis de la falla de diagnóstico NP2

Refiera a la sección del análisis de la falla de diagnóstico NP0, pero aplique el mismo razonamiento para NP2 (en vez de NP0).

Falla de diagnóstico NP3

Este diagrama representa el trayecto de paquete entre el indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor y el linecard NP3. El link que conecta el Bridge ASIC 1 (B1) y NP3 es el único específico del link a NP3. Todos los otros links caen en la trayectoria común.

Anote el trayecto de paquete del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor hacia NP3. Aunque haya cuatro links a utilizar para los paquetes destinados hacia NP3 del Route Processor, el primer link entre el Route Processor y el slot del linecard se utiliza para el paquete del Route Processor hacia el linecard. El paquete vuelto de NP3 se puede devolver al procesador de la ruta activa sobre las dos trayectorias unas de los del link de la tela entre el slot del linecard y el procesador de la ruta activa. La opción cuyo uno de los dos links a utilizar depende de la carga de link en aquel momento. El paquete de respuesta de NP3 hacia el Route Processor espera utiliza ambos links, pero un en un momento del link. La opción del link se basa en el campo del encabezado que la aplicación de diagnóstico puebla.

Trayectoria de diagnóstico de la tela

Análisis de la falla de diagnóstico NP3

Refiera a la sección del análisis de la falla de diagnóstico NP0, pero aplique el mismo razonamiento para NP3 (en vez de NP0).

Trayectoria Tifón-basada del paquete de diagnóstico del linecard

Esta sección proporciona dos ejemplos para establecer el fondo para los paquetes de la batea de la tela con el linecards Tifón-basado. El primer ejemplo utiliza NP1, y el segundo ejemplo utiliza NP3. La descripción y el análisis se pueden ampliar a otros NP en cualquier linecard Tifón-basado.

Falla de diagnóstico del tifón NP1

El diagrama siguiente representa el trayecto de paquete entre el indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor y el linecard NP1. El link que conecta FIA0 y NP1 es el único específico del link a la trayectoria NP1. Todos los otros links entre el slot del linecard y el slot de placa del Route Processor caen en la trayectoria común. Los links que conectan la tela XBAR ASIC en el linecard con los FIA en el linecard son específicos a un subconjunto de NP. Por ejemplo, los links entre FIA0 y la tela local XBAR ASIC en el linecard se utilizan para el tráfico a NP1.

Anote el trayecto de paquete del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor hacia NP1. Aunque haya ocho links a utilizar para los paquetes destinados hacia NP1 del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor, un trayecto único entre el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor y el slot del linecard se utiliza. El paquete vuelto de NP1 se puede devolver al indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor sobre ocho trayectorias del link de la tela entre el slot del linecard y el Route Processor. Cada uno de estos ocho links se ejercita uno a la vez cuando el paquete de diagnóstico es destinado de nuevo al indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor.

Trayectoria de diagnóstico de la tela

Falla de diagnóstico del tifón NP3

Este diagrama representa el trayecto de paquete entre el indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor y el linecard NP3. El link que conecta FIA1 y NP3 es el único específico del link a la trayectoria NP3. Todos los otros links entre el slot del linecard y el slot de placa del Route Processor caen en la trayectoria común. Los links que conectan la tela XBAR ASIC en el linecard con los FIA en el linecard son específicos a un subconjunto de NP. Por ejemplo, los links entre FIA1 y la tela local XBAR ASIC en el linecard se utilizan para el tráfico a NP3.

Anote el trayecto de paquete del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor hacia NP3. Aunque haya ocho links a utilizar para los paquetes destinados hacia NP3 del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor, un trayecto único entre el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor y el slot del linecard se utiliza. El paquete vuelto de NP1 se puede devolver al indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor sobre ocho trayectorias del link de la tela entre el slot del linecard y el Route Processor. Cada uno de estos ocho links se ejercita uno a la vez cuando el paquete de diagnóstico es destinado de nuevo al indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor.

Trayectoria de diagnóstico de la tela

Analice los incidentes

Esta sección categoriza los incidentes en los casos duros y transitorios, y enumera los pasos usados para identificar si un incidente es un incidente duro o transitorio. Una vez que determinan al tipo del incidente, el documento especifica los comandos que se pueden ejecutar en el router para entender el incidente y qué acciones correctivas son necesarias.

Incidente transitorio

Si un mensaje del conjunto PFM es seguido por el mensaje claro PFM, después un incidente ha ocurrido, y el router ha corregido el incidente sí mismo. Los incidentes transitorios pueden ocurrir debido a las condiciones del medio ambiente y a los incidentes recuperables en los componentes de hardware. A veces puede ser difícil asociar los incidentes transitorios a cualquier evento determinado.

Un ejemplo de un incidente transitorio de la tela se enumera aquí para mayor clareza:

RP/0/RSP0/CPU0:Feb  5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0) 

RP/0/RSP0/CPU0:Feb  5 05:05:46.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0) 

Acciones correctivas transitorias del incidente

El acercamiento sugerido para los errores transitorios es monitorea solamente para el acontecimiento adicional de tales errores. Si ocurre un incidente transitorio más de una vez, después trate el incidente transitorio como incidente duro, y utilice las recomendaciones y los pasos para analizar tales incidentes descritos en la siguiente sección.

Incidente duro

Si un mensaje del conjunto PFM no es seguido por un mensaje claro PFM, después un incidente ha ocurrido y el router no ha corregido el incidente sí mismo por el incidente que manejaba el código, o la naturaleza del desperfecto de hardware no es recuperable. Los incidentes duros pueden ocurrir debido a las condiciones del medio ambiente y a los incidentes irrecuperables en los componentes de hardware. El acercamiento sugerido para los incidentes duros es utilizar las guías de consulta mencionadas en la sección de los incidentes duros del analizar.

Un ejemplo del incidente duro de la tela se enumera aquí para mayor clareza. Para este mensaje de ejemplo, no hay un mensaje claro correspondiente PFM.

RP/0/RSP0/CPU0:Feb  5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)

Acciones correctivas del incidente duro

Bajo escenario del incidente duro, recoja todos los comandos mencionados en los datos para recoger antes de la sección de la creación de la solicitud de servicio, y para abrir una solicitud de servicio. En los casos urgentes, después de que usted recoja toda la salida del comando de Troubleshooting, inicie un indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor o una recarga del linecard basada en el aislamiento de falla. Después de que la recarga, si el error no se recupera, inicie una Autorización de devolución de materiales (RMA).

Analice los incidentes transitorios

Complete estos pasos para analizar los incidentes transitorios.

  1. Ingrese la registración de la demostración | comando inc. “PUNT_FABRIC_DATA_PATH” para descubrir si ocurrió el error una vez o las épocas múltiples.

  2. Ingrese el comando all de la ubicación del pfm de la demostración para determinar el estado actual (FIJE o BORRE). ¿Está el error excepcional o borrado? Si el estado de error cambia entre el CONJUNTO y el CLARO, después uno o más incidentes dentro del trayecto de datos de la tela ocurren y son rectificados en varias ocasiones por el software o el soporte físico.

  3. Provision los desvíos del Simple Network Management Protocol (SNMP) o ejecute un script que recoge la salida del comando all de la ubicación del pfm de la demostración, y busca para la secuencia de comandos de error periódicamente para monitorear el evento futuro del incidente (cuando el estatus más reciente del error está CLARO, y ningunos nuevos incidentes ocurren).

Comandos de utilizar

Ingrese estos comandos para analizar los incidentes transitorios:

  • show logging | inc. “PUNT_FABRIC_DATA_PATH”
  • muestre la ubicación toda del pfm 

Analice los incidentes duros

Si usted ve el trayecto de datos de la tela conecta en un linecard como árbol (donde los detalles se describen en la sección de información previa), después usted debe deducir - basado sobre la punta del incidente - si uno o más NP son inaccesibles. Cuando los incidentes múltiples ocurren en los NP múltiples, después utilice los comandos enumerados en esta sección para analizar los incidentes.

Comandos de utilizar

Ingrese estos comandos para analizar los incidentes duros:

  • show logging | inc. “PUNT_FABRIC_DATA_PATH”

    La salida pudo contener uno o más NP (ejemplo: NP2, NP3).

  • muestre el <lc> de la ubicación del estado de link FIA de la tela del regulador

    Puesto que NP2 y NP3 (en la sección de la falla de diagnóstico del tifón NP3) reciben y envían con un solo FIA, es razonable deducir que el incidente está en un FIA asociado en la trayectoria.

  • muestre la ubicación <0 y 1> <LC o RSP> del caso del estado de link de la barra transversal de la tela del regulador

    Si todos los NP en el linecard no son accesibles para la aplicación de diagnóstico, después es razonable deducir que los links que conectan el slot del linecard con el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor pudieron tener un incidente en Asics un de los que tráfico delantero entre el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor y el linecard.

    muestre a caso del estado de link de la barra transversal de la tela del regulador 0 <lc> de la ubicación

    muestre a caso del estado de link de la barra transversal de la tela del regulador 0 ubicaciones 0/rsp0/cpu0

    muestre a caso del estado de link de la barra transversal de la tela del regulador 1 ubicación 0/rsp0/cpu0

    muestre a caso del estado de link de la barra transversal de la tela del regulador 0 ubicaciones 0/rsp1/cpu0

    muestre a caso del estado de link de la barra transversal de la tela del regulador 1 ubicación 0/rsp1/cpu0

  • muestre la ubicación 0/rsp*/cpu0 del estado de link FIA de la tela del regulador

    muestre la ubicación 0/rsp0/cpu0 del estado de link FIA de la tela del regulador

    muestre la ubicación 0/rsp1/cpu0 del estado de link FIA de la tela del regulador

  • muestre la ubicación 0/rsp*/cpu0 del estado de sincronización del Bridge FIA de la tela del regulador

    muestre la ubicación 0/rsp0/cpu0 del estado de sincronización del Bridge FIA de la tela del regulador

    muestre la ubicación 0/rsp1/cpu0 del estado de sincronización del Bridge FIA de la tela del regulador

    muestre la terminal de la tela de la tecnología


Nota: Si todos los NP en todo el linecards señalan un incidente, después el incidente es más probable en el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor (placa del procesador de la ruta activa o indicador luminoso LED amarillo de la placa muestra gravedad menor espera del Route Processor). Refiera al link que conecta el indicador luminoso LED amarillo de la placa muestra gravedad menor CPU del Route Processor con FPGA y el indicador luminoso LED amarillo de la placa muestra gravedad menor FIA del Route Processor en la sección de información previa.

Últimos errores

Históricamente, el 99 por ciento de los incidentes es recuperable, y en la mayoría de los casos la acción de recuperación software-iniciada repara los incidentes. Sin embargo, en mismo los casos pocos probables, se consideran los errores no recuperados que se pueden reparar solamente con el RMA de los indicadores luminosos LED amarillo de la placa muestra gravedad menor.

Las siguientes secciones identifican algunos últimos errores encontrados para servir como dirección si se observan los errores similares.

Error transitorio debido al oversubscription NP

Visualización de estos mensajes si el error es debido al oversubscription NP.

RP/0/RP1/CPU0:Jun 26 13:08:28.669 : pfm_node_rp[349]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0, 0)

RP/0/RP1/CPU0:Jun 26 13:09:28.692 : pfm_node_rp[349]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0,0)

Los incidentes transitorios pueden ser más duros de confirmar. Un método a determinar si un NP es actualmente oversubscribed o ha sido oversubscribed en el pasado es marcar para cierta clase de descenso dentro del NP y para saber si hay eliminaciones de cola en el FIA. Los descensos delanteros del Acceso directo a memoria del ingreso (IFDMA) dentro del NP ocurren cuando el NP es oversubscribed y no puede continuar con el tráfico entrante. Las eliminaciones de cola FIA ocurren cuando una salida NP afirma el control de flujo (pide el linecard del ingreso para enviar menos tráfico). Bajo escenario del control de flujo, el ingreso FIA tiene eliminaciones de cola.

Aquí tiene un ejemplo:

RP/0/RSP0/CPU0:RP/0/RSP0/CPU0:ASR9006-C#show controllers np counters all
Wed Feb 19 13:10:11.848 EST

Node: 0/1/CPU0:
----------------------------------------------------------------
Show global stats counters for NP0, revision v3

Read 93 non-zero NP counters:
Offset Counter FrameValue Rate (pps)
-----------------------------------------------------------------------
22 PARSE_ENET_RECEIVE_CNT 46913080435 118335
23 PARSE_FABRIC_RECEIVE_CNT 40175773071 5
24 PARSE_LOOPBACK_RECEIVE_CNT 5198971143966 0
<SNIP>

Show special stats counters for NP0, revision v3

Offset Counter CounterValue
----------------------------------------------------------------------------
524032 IFDMA discard stats counters 0 8008746088 0 <<<<<

Aquí tiene un ejemplo:

RP/0/RSP0/CPU0:ASR9006-C#show controllers fabric fia drops ingress location 0/1/cPU0
Wed Feb 19 13:37:27.159 EST
********** FIA-0 **********
Category: in_drop-0
DDR Rx FIFO-0 0
DDR Rx FIFO-1 0
Tail Drop-0 0 <<<<<<<
Tail Drop-1 0 <<<<<<<
Tail Drop-2 0 <<<<<<<
Tail Drop-3 0 <<<<<<<
Tail Drop DE-0 0
Tail Drop DE-1 0
Tail Drop DE-2 0
Tail Drop DE-3 0
Hard Drop-0 0
Hard Drop-1 0
Hard Drop-2 0
Hard Drop-3 0
Hard Drop DE-0 0
Hard Drop DE-1 0
Hard Drop DE-2 0
Hard Drop DE-3 0
WRED Drop-0 0
WRED Drop-1 0
WRED Drop-2 0
WRED Drop-3 0
WRED Drop DE-0 0
WRED Drop DE-1 0
WRED Drop DE-2 0
WRED Drop DE-3 0
Mc No Rep 0

El incidente duro debido al NP ayuna restauración

Cuando ocurre PUNT_FABRIC_DATA_PATH_FAILED, y si el error es debido a la restauración rápida NP, después registra similar a qué se enumera aquí aparece para un linecard Tifón-basado. El mecanismo del control de salud está disponible en el linecards Tifón-basado, pero no en el linecards Trident-basado.

LC/0/2/CPU0:Aug 26 12:09:15.784 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702

LC/0/2/CPU0:Aug 26 12:09:18.798 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702

LC/0/2/CPU0:Aug 26 12:09:21.812 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702

LC/0/2/CPU0:Aug 26 12:09:24.815 CEST:
prm_server_ty[303]: NP-DIAG health monitoring failure on NP0

LC/0/2/CPU0:Aug 26 12:09:24.815 CEST: pfm_node_lc[291]:
%PLATFORM-NP-0-NP_DIAG : Set|prm_server_ty[172112]|
Network Processor Unit(0x1008000)| NP diagnostics warning on NP0.

LC/0/2/CPU0:Aug 26 12:09:40.492 CEST: prm_server_ty[303]:
Starting fast reset for NP 0 LC/0/2/CPU0:Aug 26 12:09:40.524 CEST:
prm_server_ty[303]: Fast Reset NP0 - successful auto-recovery of NP

Para el linecards Trident-basado, este registro se ve con una restauración rápida de un NP:

LC/0/1/CPU0:Mar 29 15:27:43.787 test:
pfm_node_lc[279]: Fast Reset initiated on NP3

Errores entre los Route Processor RSP440 y el linecards del tifón

Cisco ha reparado un problema donde raramente los links de la tela entre el Route Switch Processor (RSP) 440 y linecards Tifón-basado a través del backplane se reciclan. Se reciclan los links de la tela porque la potencia de la señal no es óptima. Este problema está presente en los Software Release 4.2.1, los 4.2.2, los 4.2.3, los 4.3.0, los 4.3.1, y los 4.3.2 bajos del Cisco IOS ®-XR. Una actualización del mantenimiento de software (SMU) para cada uno de estas versiones se fija en el Cisco Connection Online, y se sigue con el Id. de bug Cisco CSCuj10837 y el Id. de bug Cisco CSCul39674.

Cuando este problema ocurre en el router, ninguno de estos escenarios pueden ocurrir:

  1. El link va abajo y sube. (Transeúnte)
  2. El link va permanentemente abajo.

Reentrenamiento de la tela del Id. de bug Cisco CSCuj10837 entre RSP y LC (dirección TX)

Para confirmar, recoja las salidas del ltrace de LC y ambos los RSP (<> de la ubicación del ltrace de la barra transversal de la tela del regulador de la demostración) y marque si esta salida se considera en los ltraces RSP:

SMU está ya disponible

Aquí tiene un ejemplo:

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain

     Oct  1 08:22:58.999 crossbar 0/RSP1/CPU0 t1  detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (1,1,0),(2,1,0),1.

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain

     Oct  1 08:22:58.967 crossbar 0/0/CPU0 t1   init xbar_trigger_link_retrain:
destslot:0 fmlgrp:3 rc:0
     Oct  1 08:22:58.967 crossbar 0/0/CPU0 t1   detail xbar_pfm_alarm_callback:
xbar_trigger_link_retrain(): (2,0,7) initiated
     Oct  1 08:22:58.969 crossbar 0/0/CPU0 t1   detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (2,1,0),(2,2,0),0.

La dirección del término TX refiere a la dirección del punto de vista de la interfaz de los recursos físicos de barra cruzada RSP hacia una interfaz de la barra transversal de la tela en un linecard Tifón-basado.

El Id. de bug Cisco CSCuj10837 es caracterizado por la detección del linecard del tifón de un problema en el link RX del RSP y del lanzamiento de un reentrenamiento del link. Cualquier lado (LC o RSP) puede iniciar el evento del reentrenamiento. En el caso del Id. de bug Cisco CSCuj10837, el LC inicia el reentrenamiento y se puede detectar por el xbar_trigger_link_retrain del init: mensaje en las trazas en el LC.

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain

     Oct  1 08:22:58.967 crossbar 0/0/CPU0 t1   init xbar_trigger_link_retrain: destslot:
0 fmlgrp:3 rc:0

Cuando el LC inicia el reentrenamiento, el RSP señala un link_retrain del rcvd en el resultado de la traza.

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain

     Oct  1 08:22:58.999 crossbar 0/RSP1/CPU0 t1  detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (1,1,0),(2,1,0),1.

Reentrenamiento de la tela del Id. de bug Cisco CSCul39674 entre RSP y LC (dirección RX)

Para confirmar, recoja las salidas del ltrace del linecard y ambos los RSP (<> de la ubicación del ltrace de la barra transversal de la tela del regulador de la demostración) y marque si esta salida se considera en los ltraces RSP:

Aquí tiene un ejemplo:

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar  location 0/0/cpu0 |
in link_retrain

Jan  8 17:28:39.215 crossbar 0/0/CPU0 t1     detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (0,1,0),(5,1,1),0.

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar  location 0/rsp0/cpu0 |
in link_retrain

Jan  8 17:28:39.207 crossbar 0/RSP1/CPU0 t1       init xbar_trigger_link_retrain:
destslot:4 fmlgrp:3 rc:0
Jan  8 17:28:39.207 crossbar 0/RSP1/CPU0 t1     detail xbar_pfm_alarm_callback:
xbar_trigger_link_retrain(): (5,1,11) initiated
Jan  8 17:28:39.256 crossbar 0/RSP1/CPU0 t1     detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (5,1,1),(0,1,0),0. 

La dirección del término RX refiere a la dirección del punto de vista de la interfaz de los recursos físicos de barra cruzada RSP de una interfaz de la barra transversal de la tela en un linecard Tifón-basado.

El Id. de bug Cisco CSCul39674 es caracterizado por la detección RSP de un problema en el link RX del linecard del tifón y del lanzamiento de un reentrenamiento del link. Cualquier lado (LC o RSP) puede iniciar el evento del reentrenamiento. En el caso del Id. de bug Cisco CSCul39674, el RSP inicia el reentrenamiento y se puede detectar por el xbar_trigger_link_retrain del init: mensaje en las trazas en el RSP.

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar  location 0/rsp0/cpu0 |
in link_retrain

 Jan  8 17:28:39.207 crossbar 0/RSP1/CPU0 t1 init xbar_trigger_link_retrain: destslot:4
fmlgrp: 3 rc:0

Cuando el RSP inicia el reentrenamiento, el LC señala un evento del link_retrain del rcvd en el resultado de la traza.

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar  location 0/0/cpu0 |
in link_retrain

 Jan  8 17:28:39.215 crossbar 0/0/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (0,1,0),(5,1,1),0.

Diferencias del reentrenamiento de la tela en la versión 4.3.2 y posterior

El trabajo significativo se ha hecho para disminuir el tiempo que toma para reciclar un link de la tela en IOS-XR la versión 4.3.2 y posterior. El reentrenamiento de la tela ocurre en épocas sub-segundas y es imperceptible ahora a los flujos de tráfico. En la versión 4.3.2, esta el mensaje de Syslog se considera solamente cuando ocurrió un reentrenamiento del link de la tela.

%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT :  Fabric backplane crossbar link
underwent link retraining to recover from a transient error: Physical slot 1

Falla debido al desbordamiento del ASIC de recurso físico (Primero en Entrar, Primero en Salir FIFO)

Cisco ha reparado un problema donde el ASIC de recurso físico (FIA) pudo conseguir la restauración debido a una condición de desbordamiento irrecuperable del Primero en entrar, primero en salir (FIFO). Esto se dirige con el Id. de bug Cisco CSCul66510. Este problema afecta solamente al linecards Trident-basado y se encuentra solamente en los casos pocos probables con la congestión pesada del trayecto de ingreso. Si se encuentra este problema, se visualiza este mensaje de Syslog antes de que el linecard se reajuste para recuperarse de la condición. 

RP/0/RSP0/CPU0:asr9k-2#show log
LC/0/3/CPU0:Nov 13 03:46:38.860 utc: pfm_node_lc[284]:
%FABRIC-FIA-0-ASIC_FATAL_FAULT Set|fialc[159814]
|Fabric Interface(0x1014000)|Fabric interface asic ASIC1 encountered fatal
fault 0x1b - OC_DF_INT_PROT_ERR_0
LC/0/3/CPU0:Nov 13 03:46:38.863 utc: pfm_node_lc[284]:
%PLATFORM-PFM-0-CARD_RESET_REQ : pfm_dev_sm_perform_recovery_action,
Card reset requested by: Process ID:159814 (fialc), Fault Sev: 0, Target node:
0/3/CPU0, CompId: 0x10, Device Handle: 0x1014000, CondID: 2545, Fault Reason:
Fabric interface asic ASIC1 encountered fatal fault 0x1b - OC_DF_INT_PROT_ERR_0

Falla debido a la acumulación pesada de la cola de salida virtual (VOQ) de la congestión de la tela

Cisco ha reparado un problema donde la congestión alta extendida pudo llevar al agotamiento de recursos y a la pérdida de tráfico de la tela. La pérdida de tráfico puede incluso ocurrir en los flujos sin relación. Este problema se aborda con el Id. de bug Cisco CSCug90300 y se resuelve en IOS-XR la versión 4.3.2 y posterior. El arreglo también se entrega en la versión 4.2.3 CSMU#3, SMU CSCui33805. Este problema raro se pudo encontrar en el linecards del tridente o Tifón-basado.

Comandos relevant

Usted debe recolectar estos comandos:

  • muestre la tela del tecnología-soporte
  • la FIA de la tela del regulador de la demostración interliga el <=== regulador de corriente de la ubicación <LC> consigue esta salida para todos los LC
  • muestre a reguladores la ubicación <LC> de la q-profundidad FIA de la tela

Aquí están algunas salidas de ejemplo:

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia q-depth location 0/6/CPU0
Sun Dec 29 23:10:56.307 UTC 
********** FIA-0 **********
Category: q_stats_a-0
Voq       ddr            pri            pktcnt   
11        0              2              7
********** FIA-0 **********
Category: q_stats_b-0
Voq       ddr            pri            pktcnt
********** FIA-1 **********
Category: q_stats_a-1
Voq       ddr            pri            pktcnt
11        0              0              2491
11        0              2              5701
********** FIA-1 **********
Category: q_stats_b-1
Voq       ddr            pri            pktcnt
RP/0/RSP0/CPU0:asr9k-1#
RP/0/RSP0/CPU0:asr9k-1#show controllers pm location 0/1/CPU0 | in "switch|if"

Sun Dec 29 23:37:05.621 UTC
Ifname(2): TenGigE0_1_0_2, ifh: 0x2000200 : <==Corresponding interface ten 0/1/0/2
iftype 0x1e
switch_fabric_port 0xb <==== VQI 11
parent_ifh 0x0
parent_bundle_ifh 0x80009e0
RP/0/RSP0/CPU0:asr9k-1#

Bajo condiciones nomal, es muy poco probable ver un VOQ con los paquetes hechos cola para arriba. Este comando es una foto en tiempo real rápida de las colas de administración del tráfico FIA. Es común para que este comando no muestre ningunos paquetes hechos cola en absoluto. 

Impacto del tráfico debido a los errores de software Bridge/FPGA en el linecards Trident-basado

Los errores de software son los errores transitorios fuera de los cuales haga la máquina de estado estar sincronizan. Éstos se ven como la verificación por redundancia cíclica (CRC), la Secuencia de verificación de tramas (FCS), o paquetes errored en el lado de la tela del NP o en el lado del ingreso del FIA.

Aquí están algunos ejemplos de cómo este problema puede ser considerado:

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric  fia drops ingress location 0/3/CPU0
Fri Dec 6 19:50:42.135 UTC
********** FIA-0 **********
Category: in_drop-0
DDR Rx FIFO-0 0
DDR Rx FIFO-1 32609856 <=== Errors

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia errors ingress location 0/3/CPU0
Fri Dec 6 19:50:48.934 UTC

********** FIA-0 **********
Category: in_error-0
DDR Rx CRC-0 0
DDR Rx CRC-1 32616455 <=== Errors
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/0/CPU0
Ingress Drop Stats (MC & UC combined)
**************************************
PriorityPacket Error Threshold
Direction Drops Drops
--------------------------------------------------
LP NP-3 to Fabric 0 0
HP NP-3 to Fabric 1750 0
RP/0/RSP1/CPU0:asr9k-1#
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/6/CPU0

Sat Jan  4 06:33:41.392 CST
  ********** FIA-0 **********
Category: bridge_in-0
                                  UcH Fr Np-0                 16867506
                                  UcH Fr Np-1                   115685
                                  UcH Fr Np-2                   104891
                                  UcH Fr Np-3                   105103
                                  UcL Fr Np-0               1482833391
                                  UcL Fr Np-1              31852547525
                                  UcL Fr Np-2               3038838776
                                  UcL Fr Np-3              30863851758
                                  McH Fr Np-0                   194999
                                  McH Fr Np-1                   793098
                                  McH Fr Np-2                   345046
                                  McH Fr Np-3                   453957
                                  McL Fr Np-0                 27567869
                                  McL Fr Np-1                 12613863
                                  McL Fr Np-2                   663139
                                  McL Fr Np-3                 21276923
                                 Hp ErrFrNp-0                        0
                                 Hp ErrFrNp-1                        0
                                 Hp ErrFrNp-2                        0
                                 Hp ErrFrNp-3                        0
                                 Lp ErrFrNp-0                        0
                                 Lp ErrFrNp-1                        0
                                 Lp ErrFrNp-2                        0
                                 Lp ErrFrNp-3                        0
                                 Hp ThrFrNp-0                        0
                                 Hp ThrFrNp-1                        0
                                 Hp ThrFrNp-2                        0
                                 Hp ThrFrNp-3                        0
                                 Lp ThrFrNp-0                        0
                                 Lp ThrFrNp-1                        0
                                 Lp ThrFrNp-2                        0
                                 Lp ThrFrNp-3                        0
  ********** FIA-0 **********
Category: bridge_eg-0
                                  UcH to Np-0                   779765
                                  UcH to Np-1                  3744578
                                  UcH to Np-2                   946908
                                  UcH to Np-3                  9764723
                                  UcL to Np-0               1522490680
                                  UcL to Np-1              32717279812
                                  UcL to Np-2               3117563988
                                  UcL to Np-3              29201555584
                                UcH ErrToNp-0                        0
                                UcH ErrToNp-1                        0
                                UcH ErrToNp-2                      129 <==============
                                UcH ErrToNp-3                        0
                                UcL ErrToNp-0                        0
                                UcL ErrToNp-1                        0
                                UcL ErrToNp-2                    90359 <==========

Comandos de recolectar para los errores de software Bridge/FPGA en el linecards Trident-basado

Usted debe recolectar estos comandos:

  • muestre la tela del tecnología-soporte
  • muestre el tecnología-soporte NP
  • muestre el <> de la ubicación stats del Bridge FIA de la tela del regulador (consiga varias veces)

Recuperación de los errores de software Bridge/FPGA

El Método de recuperación es recargar el linecard afectado.

RP/0/RSP0/CPU0:asr9k-1#hw-module location 0/6/cpu0 reload

Informe de prueba de diagnóstico en línea

El comando del [test <test-id> detail] del <node> de la ubicación del resultado del diagnóstico de la demostración proporciona un resumen de todas las pruebas de diagnóstico en línea y errores así como el sello de la última vez cuando una prueba pasó. El Prueba-ID para el error del trayecto de datos de la tela de la batea es diez. Una lista de todas las pruebas junto con la frecuencia de los paquetes de prueba se puede considerar con el comando del <node> de la ubicación del contenido del diagnóstico de la demostración.

La salida del resultado de la prueba del trayecto de datos de la tela de la batea será similar a esta salida de muestra:

RP/0/RSP0/CPU0:ios(admin)#show diagnostic result location 0/rsp0/cpu0  test 10 detail
Current bootup diagnostic level for RP 0/RSP0/CPU0: minimal
Test results: (. = Pass, F = Fail, U = Untested)

___________________________________________________________________________
10 ) FabricLoopback ------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 357
Last test execution time ----> Sat Jan 10 18:55:46 2009
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> Sat Jan 10 18:55:46 2009
Total failure count ---------> 0
Consecutive failure count ---> 0

Mejoras de la recuperación automática

Según lo descrito en el Id. de bug Cisco CSCuc04493, ahora hay una manera de tener el router automáticamente apagar todos los puertos que se asocien a los errores PUNT_FABRIC_DATA_PATH.

El primer método se sigue vía el Id. de bug Cisco CSCuc04493. Para la versión 4.2.3, esto se incluye en el Id. de bug Cisco CSCui33805. En esta versión, se fija para apagar automáticamente todos los puertos que se asocien a los NP que son afectados.

Aquí está un ejemplo que muestra cómo aparecerían los Syslog:

RP/0/RSP0/CPU0:Jun 10 16:11:26 BKK: pfm_node_rp[359]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|System
Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
(0/1/CPU0, 0)
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
TenGigE0/1/0/0, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
protocol on Interface TenGigE0/1/0/0, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
TenGigE0/1/0/1, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
protocol on Interface TenGigE0/1/0/1, changed state to Down

El regulador indicará que la razón de la interfaz que está abajo es debido a DATA_PATH_DOWN. Aquí tiene un ejemplo:

RP/0/RSP0/CPU0:ASR9006-E#show controllers gigabitEthernet 0/0/0/13 internal
Wed Dec 18 02:42:52.221 UTC

Port Number       : 13
Port Type         : GE
Transport mode    : LAN
BIA MAC addr      : 6c9c.ed08.3cbd
Oper. MAC addr    : 6c9c.ed08.3cbd
Egress MAC addr   : 6c9c.ed08.3cbd
Port Available    : true
Status polling is : enabled
Status events are : enabled
I/F Handle        : 0x04000400
Cfg Link Enabled  : tx/rx enabled
H/W Tx Enable     : no
UDLF enabled      : no
SFP PWR DN Reason : 0x00000000
SFP Capability    : 0x00000024
MTU               : 1538
H/W Speed         : 1 Gbps
H/W Duplex        : Full
H/W Loopback Type : None
H/W FlowCtrl type : None
H/W AutoNeg Enable: Off
H/W Link Defects  : (0x00080000) DATA_PATH_DOWN <<<<<<<<<<<
Link Up           : no
Link Led Status   : Link down -- Red
Input good underflow          : 0
Input ucast underflow         : 0
Output ucast underflow        : 0
Input unknown opcode underflow: 0
Pluggable Present   : yes
Pluggable Type      : 1000BASE-LX
Pluggable Compl.    : (Service Un) - Compliant
Pluggable Type Supp.: (Service Un) - Supported
Pluggable PID Supp. : (Service Un) - Supported
Pluggable Scan Flg: false

En las versiones 4.3.1 y posterior, este comportamiento debe ser habilitado. Hay un nuevo comando config admin que se utiliza para lograr esto. Pues el comportamiento predeterminado es no más apagar los puertos, esto debe ser configurada manualmente.

RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status

El Id. de bug Cisco CSCui15435 dirige los errores de software que se consideran en el linecards Trident-basado, según lo descrito aquí. Esto utiliza un diverso Método de detección que el método de diagnóstico usual que se describe en el Id. de bug Cisco CSCuc04493.

Este bug también presentó a un nuevo comando CLI de la configuración admin:

(admin-config)#fabric fia soft-error-monitor <1|2> location <specific>

1 = shutdown the ports
2 = reload the linecard

Default behavior: no action is taken.

Cuando se encuentra este error, este Syslog puede ser observado:

RP/0/RSP0/CPU0:Apr 30 22:17:11.351 : config[65777]: %MGBL-SYS-5-CONFIG_I : Configured
from console by root
LC/0/2/CPU0:Apr 30 22:18:52.252 : pfm_node_lc[283]:
%PLATFORM-BRIDGE-1-SOFT_ERROR_ALERT_1 : Set|fialc[159814]|NPU
Crossbar Fabric Interface Bridge(0x1024000)|Soft Error Detected on Bridge instance 1
RP/0/RSP0/CPU0:Apr 30 22:21:28.747 : pfm_node_rp[348]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
(0/2/CPU0, 2) (0/2/CPU0, 3)
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINK-3-UPDOWN :
Interface TenGigE0/2/0/2, changed state to Down
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINEPROTO-5-UPDOWN :
Line protocol on Interface TenGigE0/2/0/2, changed state to Down
RP/0/RSP1/CPU0:Apr 30 22:21:35.086 : pfm_node_rp[348]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED :
Set|online_diag_rsp[237646]|System Punt/Fabric/data Path Test(0x2000004)|failure
threshold is 3, (slot, NP) failed: (0/2/CPU0, 2) (0/2/CPU0, 3)

Cuando se apagan los puertos afectados, permite que la redundancia de la red asuma el control y evite un envío a agujeros negros del tráfico. Para recuperarse, el linecard debe ser recargado.

Preguntas frecuentes (FAQ)

Q. ¿El indicador luminoso LED amarillo de la placa muestra gravedad menor primario o espera del Route Processor envía el Keepalives o los paquetes de diagnóstico en línea a cada NP en el sistema?

R.  Sí. Ambos indicadores luminosos LED amarillo de la placa muestra gravedad menor del Route Processor envían los paquetes de diagnóstico en línea a cada NP.

P..  ¿Está la trayectoria lo mismo cuando el indicador luminoso LED amarillo de la placa muestra gravedad menor uno (RSP1) del Route Processor es activo?

R.  La trayectoria de diagnóstico es lo mismo para RSP0 o el RSP1. La trayectoria es dependiente en el estado del RSP. Refiera a la sección de la trayectoria del paquete de diagnóstico de la tela de la batea de este documento para más detalles.

Q. ¿Cuantas veces los RSP envían los paquetes de diagnóstico, y cuántos paquetes de diagnóstico deben ser faltados antes de que se accione una alarma?

R.  Cada RSP envía independientemente un paquete de diagnóstico a cada NP una vez por el minuto. Cualquier RSP puede accionar una alarma si tres paquetes de diagnóstico no aknowledged.

P..  ¿Cómo usted determina si un NP es o ha sido oversubscribed?

R.  Una manera de marcar si un NP es actualmente oversubscribed o ha sido oversubscribed en el pasado es marcar para cierta clase de descenso dentro del NP y para saber si hay eliminaciones de cola en el FIA. Los descensos delanteros del Acceso directo a memoria del ingreso (IFDMA) dentro del NP ocurren cuando el NP es oversubscribed y no puede continuar con el tráfico entrante. Las eliminaciones de cola FIA ocurren cuando una salida NP afirma el control de flujo (pide el linecard del ingreso para enviar menos tráfico). Bajo escenario del control de flujo, el ingreso FIA tiene eliminaciones de cola.

P..  ¿Cómo usted determina si un NP sufre un incidente que lo requiera ser reajustado?

R.  Típicamente, un incidente NP es borrado por una restauración rápida. La razón de una restauración rápida se visualiza en los registros.

P..  ¿Qué visualiza si un NP tiene una falla de hardware NON-recuperable?

R.  Usted ve un error del trayecto de datos de la tela de la batea para ese NP así como un error de la prueba de Loopback NP. El mensaje de error de la prueba de Loopback NP se discute en la sección del apéndice de este documento.

P..  ¿Un paquete de diagnósticos que es originado a partir de un Route Processor cardará vuelto el mismo?

R.  Puesto que los paquetes de diagnóstico son originados de ambos indicadores luminosos LED amarillo de la placa muestra gravedad menor del Route Processor y se siguen en a por la base del indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor, un paquete de diagnóstico originado de un indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor es circuito hecho atrás al mismo indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor por el NP.

P..  El Id. de bug Cisco CSCuj10837 SMU proporciona un arreglo para el evento del reentrenamiento del link de la tela. ¿Está esto la causa y la solución para muchos los errores del trayecto de datos de la tela de la batea?

R.  Sí, será requerido para cargar reemplazar SMU para el Id. de bug Cisco CSCul39674 para evitar los eventos del reentrenamiento del link de la tela.

Q. ¿Cuánto tiempo admite la orden para reciclar los links de la tela una vez que la decisión a hacer tan se toma?

R.  La decisión a reciclarse se toma tan pronto como detecten a una falla de link. Antes de la versión 4.3.2, el reentrenamiento podría tardar varios segundos. Después de la versión 4.3.2, el tiempo del reentrenamiento se ha mejorado y toma perceptiblemente menos que un segundo.

P..  ¿En qué punta es el reentrenamiento de la decisión un link de la tela hizo?

A. Tan pronto como se detecte el incidente del link, la decisión a reciclarse es tomada por el driver del ASIC de recurso físico.

P..  ¿Es solamente entre el FIA en una placa del procesador de la ruta activa y la tela que usted utiliza el primer link, y entonces después que es el menos link cargado cuando hay links múltiples disponibles?

A. Correcto. El primer link que conecta con el primer XBAR caso en el procesador de la ruta activa se utiliza para inyectar el tráfico en la tela. El paquete de respuesta del NP puede alcanzar de nuevo a la placa del procesador de la ruta activa en ningunos de todos los links que conecten con el indicador luminoso LED amarillo de la placa muestra gravedad menor del Route Processor. La opción del link depende de la carga de link.

P..  ¿Durante el reentrenamiento, se pierden todos los paquetes que se envían sobre ese link de la tela?

R.  Sí, pero con las mejoras en la versión 4.3.2 y posterior, el reentrenamiento es virtualmente undetectible. Sin embargo, en el código anterior, podría tardar varios segundos para reciclarse, que dieron lugar a los paquetes perdidos para ese tiempo de trama.

P..  ¿Usted espera cómo con frecuencia ver XBAR un evento del reentrenamiento del link de la tela después de que usted actualice a una versión o SMU con el arreglo para el Id. de bug Cisco CSCuj10837?

R.  Incluso con el arreglo para el Id. de bug Cisco CSCuj10837 es todavía posible ver la tela conectar los reentrenamientos debido al Id. de bug Cisco CSCul39674. Pero una vez que un cliente tiene el arreglo para el Id. de bug Cisco CSCul39674, la reinstrucción del link de la tela en los links del backplane de la tela entre el RSP440 y el linecards Tifón-basado debe nunca ocurrir. Si lo hace, después aumentar una solicitud de servicio con el Centro de Asistencia Técnica de Cisco (TAC) para resolver problemas el problema.

P..  ¿El bug Cisco ID CSCuj10837 y CSCul39674 afecta al RP en el ASR 9922 con el linecards Tifón-basado?

R.  Sí

P..  ¿El bug Cisco ID CSCuj10837 y CSCul39674 afecta al Routers del ASR-9001 y ASR-9001-S?

R.  No

P.. Si usted encuentra el error de un slot que no exista con este mensaje, "PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: El umbral de la batea/de la tela/del trayecto de datos Test(0x2000004)|failure Set|online_diag_rsp[237686]|System es 3, (slot, NP) fallado: ¿(8, el 0)," en un chasis 10-slot, que el slot tiene el problema?

R. En más viejas versiones, usted debe explicar la comprobación y las asignaciones lógicas como se muestra aquí. En este ejemplo, el slot 8 corresponde a 0/6/CPU0.

For 9010 (10 slot chassis)
L            P
#0  --- #0
#1  --- #1
#2  --- #2
#3  --- #3
RSP0 --- #4
RSP1 --- #5
#4 --- #6
#5 --- #7
#6 --- #8
#7 --- #9

For 9006 (6 slot chassis)
L               P
RSP0 --- #0
RSP1 --- #1
#0 --- #2
#1 --- #3
#2 --- #4
#3 --- #5

Datos a recoger antes de la creación de la solicitud de servicio

Aquí están los comandos mínimos que usted debe recoger antes de que se tome cualquier medidas:

  • Show logging
  • Muestre la ubicación toda del pfm
  • detalle de la prueba 8 de la ubicación 0/rsp0/cpu0 del resultado del diagn de la demostración admin
  • detalle de la prueba 8 de la ubicación 0/rsp1/cpu0 del resultado del diagn de la demostración admin
  • detalle de la prueba 9 de la ubicación 0/rsp0/cpu0 del resultado del diagn de la demostración admin
  • detalle de la prueba 9 de la ubicación 0/rsp1/cpu0 del resultado del diagn de la demostración admin
  • detalle de la prueba 10 de la ubicación 0/rsp0/cpu0 del resultado del diagn de la demostración admin
  • detalle de la prueba 10 de la ubicación 0/rsp1/cpu0 del resultado del diagn de la demostración admin
  • detalle de la prueba 11 de la ubicación 0/rsp0/cpu0 del resultado del diagn de la demostración admin
  • detalle de la prueba 11 de la ubicación 0/rsp1/cpu0 del resultado del diagn de la demostración admin
  • muestre el <lc> de la ubicación del estado de link FIA de la tela del regulador
  • muestre el rsp> del <both de la ubicación del estado de link FIA de la tela del regulador
  • muestre el rsp> del <both de la ubicación del estado de sincronización del Bridge FIA de la tela del regulador
  • muestre a caso del estado de link de la barra transversal de la tela del regulador 0 <lc> de la ubicación
  • muestre a caso del estado de link de la barra transversal de la tela del regulador 0 rsp> del <both de la ubicación
  • muestre a caso del estado de link de la barra transversal de la tela del regulador 1 rsp> del <both de la ubicación
  • muestre el rsp> del <both de la ubicación de la barra transversal del ltrace de la tela del regulador
  • muestre el lc> <affected ubicación de la barra transversal del ltrace de la tela del regulador
  • muestre el <fault de la ubicación de la tela de la tecnología que muestra el <path del archivo del lc> al file>
  • muestre el <path del archivo del rsp> del <both de la ubicación de la tela de la tecnología al file>

Comandos diagnostic útiles

Aquí está una lista de comandos que sean útiles para los objetivos de hacer un diagnóstico:

  • muestre las configuraciones de diagnóstico del ondemand
  • muestre a diagnóstico la ubicación contenta < ubicación >
  • muestre la ubicación < ubicación > del resultado del diagnóstico [la prueba {identificación|id_list|todos}] [detail]
  • muestre el estatus de diagnóstico
  • prueba de diagnóstico de la < ubicación > de la ubicación del comienzo admin {identificación|id_list|conjunto de prueba}
  • ubicación de detención de diagnóstico admin < ubicación >
  • iteraciones de diagnóstico < iteración-cuenta > del ondemand admin
  • acción-en-error de diagnóstico del ondemand admin {continúe la cuenta de fallas|parada}
  • [no] prueba de la < ubicación > de la ubicación del monitor de diagnóstico admin-config# {identificación | [disable] del prueba-nombre}
  • [no] prueba de la < ubicación > de la ubicación del intervalo del monitor de diagnóstico admin-config# {identificación | hora del día del prueba-nombre}: minuto: second.millisec
  • [no] prueba de la < ubicación > de la ubicación del umbral del monitor de diagnóstico admin-config# {identificación | cuenta de fallas del prueba-nombre}

Conclusión

Del tiempo de trama de la versión 4.3.4 del Software Cisco IOS XR, se dirige la mayoría publica relacionado para llevar en batea los errores del trayecto de datos de la tela. Para el Routers afectado por el bug Cisco ID CSCuj10837CSCul39674, cargue reemplazar SMU para CSCul39674 para evitar los eventos del reentrenamiento del link de la tela.

El equipo de la plataforma ha instalado el incidente avanzado que dirigía de modo que el router se recupere en los subseconds si y cuando ocurre cualquier error recuperable del trayecto de datos. Sin embargo, este documento se recomienda para entender este problema, incluso si no se observa ningún tal incidente.

Apéndice

Trayectoria de diagnóstico del Loopback NP

La aplicación de diagnóstico que ejecuta en el linecard CPU sigue la salud de cada NP con los controles periódicos del estatus de trabajo del NP. Un paquete se inyecta del linecard CPU destinado al NP local, que el NP debe colocar - posterior y de vuelta al linecard CPU. Cualquier pérdida en tales paquetes periódicos se señala por medio de una bandera con un mensaje del registro de la plataforma. Aquí está un ejemplo de tal mensaje:

LC/0/7/CPU0:Aug 18 19:17:26.924 : pfm_node[182]: 
%PLATFORM-PFM_DIAGS-2-LC_NP_LOOPBACK_FAILED : Set|online_diag_lc[94283]|
Line card NP loopback Test(0x2000006)|link failure mask is 0x8

Este mensaje del registro significa esta prueba no podida para recibir el paquete del loopback de NP3. La máscara de la falla de link es 0x8 (mordido 3 se fija), que indica un error entre el linecard CPU para el slot 7 y NP3 en el slot 7.

Para obtener más detalles, recoja la salida de estos comandos:

  • detalle de la prueba 9 de la ubicación 0/<x>/cpu0 del resultado del diagnóstico de la demostración admin
  • muestre a reguladores la ubicación 0/<x>/cpu0 del contador NP<0-3> NP 

Comandos Debug de la tela

Los comandos enumerados en esta sección se aplican a todo el linecards Trident-basado así como al linecard Tifón-basado 100GE. El Bridge FPGA ASIC no está presente en el linecards Tifón-basado (a excepción del linecards Tifón-basado 100GE). Así pues, los comandos bridge FIA de la tela del regulador de la demostración no se aplican al linecards Tifón-basado, a excepción de las versiones 100GE.

Esta representación ilustrada ayuda a asociar cada comando show a la ubicación en el trayecto de datos. Utilice estos comandos show para aislar las caídas de paquetes y los incidentes.



Document ID: 116727