El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento proporciona una explicación breve del syslog común y los mensajes de error que ve en los Cisco Catalyst 6500/6000 seriesswitches que ejecutan Cisco IOS®system software. Utilice el Analizador de Cisco CLI (sólo para clientes registrados) si tiene un mensaje de error que no aparece en este documento. La herramienta proporciona el significado de los mensajes de error que Cisco IOS Software y el software Catalyst OS (CatOS) generan.
Nota: El formato exacto del syslog y de los mensajes de error que describe este documento puede variar ligeramente. La variación depende de la versión de software que se ejecuta en Supervisor Engine.
Nota: Se recomienda esta configuración de registro mínima en Catalyst 6500/6000:
Configure la fecha y la hora en el switch, o configure el switch para utilizar el Network Time Protocol Network (NTP) para obtener la fecha y la hora de un servidor NTP.
Asegúrese de que el registro y sellos de fecha/hora del registro estén habilitados, que es el valor predeterminado.
Configure el switch para registrar un servidor de syslog, si es posible.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
El switch señala este mensaje de error:
C6KPWR-SP-4-UNSUPPORTED: módulo no compatible en slot [num], no se permite alimentación: [chars]
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
Oct 14 16:50:13: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot 2, power not allowed: Unknown Card Type Oct 14 16:50:20: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot 2, power not allowed: Unknown Card Type
Este mensaje indica que el módulo en el slot especificado no está soportado. [num] es el número de slot, y [chars] brinda más detalles sobre el error.
Actualice el Supervisor Engine software a una versión que soporte el módulo de hardware. Consulte la sección Hardware Soportado de Notas de Versión de Cisco Catalyst 6500 Series Switches para obtener la versión adecuada. Para resolver el problema que el mensaje describe, realice una de estas acciones:
Inserte o substituya el Módulo de Entramado de Switches.
Mueva el módulo no soportado a un slot diferente.
El switch señala este mensaje de error:
%DUAL-3-INTERNAL: IP-EIGRP 1: Error interno
El mensaje de error indica que hay un bug interno en el Cisco IOS Software. El bug se ha reparado en estas versiones:
Cisco IOS Software Release 12.2(0.4)
Cisco IOS Software Release 12.1(6.1)
Cisco IOS Software Release 12.2(0.5)T
Cisco IOS Software Release 12.1(6.5)E
Versión 12.1(6.5)EC de software del IOS de Cisco
Cisco IOS Software Release 12.1(6)E02
Versión 12.2(0.18)S del software Cisco IOS
Cisco IOS Software Release 12.2(2)B
Cisco IOS Software Release 12.2(15)ZN
Actualice el Cisco IOS Software a una de estas versiones o a la última versión.
El switch señala este mensaje de error:
%EARL_L3_ASIC-SP-4-INTR_THROTTLE: aceleración "IP_TOO_SHRT"
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
Jul 25 12:00:40.228 AEST: %EARL_L3_ASIC-SP-4-INTR_THROTTLE: Throttling "IP_TOO_SHRT"Intr. Exceeded permitted 1000/100 intrs/msec
Este mensaje indica que el motor de reenvío del switch recibe un paquete IP con una longitud más corta que la longitud mínima permitida. El switch descarta el paquete. En las versiones anteriores, el paquete se descarta silenciosamente y se cuenta en las estadísticas del motor de reenvío. En versiones posteriores, el mensaje de error se registra en el syslog cada 30 minutos. Estos problemas pueden hacer que el motor de reenvío del switch reciba este tipo de paquete IP:
Un driver inadecuado de la tarjeta de interfaz de red (NIC)
Un bug del driver NIC
Una aplicación inadecuada
El switch simplemente informa que ha recibido estos paquetes “inadecuados” y pretende descartarlos.
El origen del problema es externo al switch. Lamentablemente, el motor de reenvío no rastrea la dirección IP de origen del dispositivo que envía estos paquetes inadecuados. La única manera de detectar el dispositivo es utilizar un analizador para rastrear la fuente y para, luego, substituir el dispositivo.
El switch señala este mensaje de error:
EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: interrupción no fatal [chars]
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
Apr 20 17:53:38: %EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: Non-fatal interrupt Packet Parser block interrupt Apr 20 19:13:05: %EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: Non-fatal interrupt Packet Parser block interrupt
El mensaje de error %EARL_L3_ASIC-SP-3-INTR_WARN indica que el circuito integrado específico de la aplicación (ASIC) de la Lógica de Reconocimiento de Dirección Codificada (EARL) de Capa 3 (L3) detectó una condición no fatal inesperada. Esto indica que un paquete inadecuado, probablemente un paquete que contiene un error de checksum IP de Capa 3, fue recibido y descartado. La causa del problema es un dispositivo en la red que envía paquetes inadecuados. Estos problemas, entre otros, pueden causar paquetes inadecuados:
NICs inadecuados
Drivers NIC inadecuados
Aplicaciones inadecuadas
En las versiones anteriores de Cisco IOS Software, estos paquetes normalmente se descartan sin ser registrados. La función de los mensajes de error de registro sobre este problema es una función que se encuentra en el Cisco IOS Software Release 12.2SX y posterior.
Se trata sólo de un mensaje informativo. Como solución temporal, utilice una de estas dos opciones:
Utilice un analizador de red para identificar el origen desde donde se envían los paquetes erróneos. Luego, resuelva el problema con el dispositivo o la aplicación de origen.
Inhabilite las verificaciones de error de la Capa 3 en el hardware del switch para:
Errores de checksum del paquete
Errores de la longitud del paquete
Paquetes que tienen las mismas direcciones IP de origen y de destino
Utilice el comando no mls verify parar detener estas comprobaciones de errores, como muestran los siguientes ejemplos:
Switch(config)#no mls verify ip checksum !--- This configures the switch to discontinue checks for packet
!--- checksum errors.
Switch(config)#no mls verify ip length {consistent | minimum} !--- This configures the switch to discontinue checks for packet
!--- length errors.
Switch(config)#no mls verify ip same-address !--- This configures the switch to discontinue checks for packets that have the
!--- same source and destination IP addresses.
El switch señala este mensaje de error:
EARL_NETFLOW-4-TCAM_THRLD: umbral de TCAM de NetFlow superado, utilización de TCAM [[dec]%]
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
Aug 24 12:30:53: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization [97%] Aug 24 12:31:53: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization [97%]
Nota: Si desea filtrar este mensaje de error específico, tenga en cuenta que se filtrarán todos los mensajes de error con el mismo nivel de gravedad. Un mensaje de log específico no puede ser filtrado sin afectar a otros logs con el mismo nivel de gravedad.
Este mensaje indica que la memoria direccionable de contenido ternario de Netflow (TCAM) está casi llena. El envejecimiento agresivo será habilitado temporalmente. Si cambia la máscara Netflow al modo FULL, la TCAM para el Netflow puede desbordarse debido a la gran cantidad de entradas. Ejecute el comando show mls netflow ip count para verificar esta información.
El Supervisor Engine 720 verifica cómo se llena la tabla Netflow cada 30 segundos. El Supervisor Engine activa el envejecimiento agresivo cuando los tamaños de la tabla alcanzan aproximadamente el 90 por ciento. La idea del envejecimiento agresivo es que la tabla esté casi llena, de manera que haya nuevos flujos activos que no puedan ser creados. Por lo tanto, tiene sentido el envejecimiento agresivo de los flujos menos activos (o los flujos inactivos) de la tabla para hacer espacio para los flujos activos.
La capacidad para cada tabla de la tarjeta de función de política (PFC) de NetFlow) (IPv4), para PFC3a y PFC3b, es 128,000 flujos. Para el PFC3bXL, la capacidad es 256,000 flujos.
Para prevenir este problema, inhabilite el modo NetFlow FULL. Ejecute el comando no mls flow ip.
Nota: Generalmente, el comando no mls flow ip no afecta el reenvío de paquetes porque TCAM para el reenvío de paquetes y TCAM para la contabilización de NetFlow son independientes.
Para recuperarse de este problema, habilite el envejecimiento rápido MLS. Mientras habilita el tiempo de envejecimiento rápido MLS, configure inicialmente el valor en 128 segundos. Si el tamaño de caché MLS sigue creciendo y supera las 32 mil entradas, disminuya la configuración hasta que el tamaño de caché sea inferior a 32 mil. Si el caché sigue creciendo y supera las 32 mil entradas, disminuya el tiempo de envejecimiento normal MLS. Cualquier valor de tiempo de envejecimiento que no sea un múltiplo de 8 segundos se ajusta al múltiplo más cercano de 8 segundos.
Switch#configure terminal Switch(config)#mls aging fast threshold 64 time 30
La otra solución temporal inhabilitaría el servicio interno en caso de que lo haya habilitado, y quitaría mls flow ipinterface-full en caso de que no necesite el flujo completo.
Switch(config)#no service internal Switch(config)#mls flow ip interface-full
El switch informa este mensaje de error, y el puerto se ve obligado a inactivar el link:
%ETHCNTR-3-LOOP_BACK_DETECTED: se detectó un bucle invertido de paquetes keepalive en [chars]
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
Oct 2 10:40:13: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/1 Oct 2 10:40:13: %PM-4-ERR_DISABLE: loopback error detected on Gi0/1, putting Gi0/1 in err-disable state
El problema se produce porque el paquete de keepalive se envía con loop nuevamente al puerto que envió el keepalive. Los keepalives son enviados en los switches de Catalyst para prevenir los loops en la red. El Keepalives se habilita de forma predeterminada en todas las interfaces. Observa este problema en el dispositivo que detecta e interrumpe el loop, pero no en el dispositivo que provoca el loop.
Ejecute el comando no keepalive interface para inhabilitar los keepalives. La desactivación del keepalive evita el cambio a errdisable de la interfaz, pero no quita el loop.
Nota: En las versiones basadas en SE de Cisco IOS Software Release 12.2(x)SE y posteriores, las señales de mantenimiento no se envían en las interfaces de fibra y de link ascendente de forma predeterminada.
El switch señala este mensaje de error:
loadprog: error - on file open boot: cannot load "bootflash:c6msfc2-boot-mz.121-8a.EX"
El problema se produce solamente en una escritura no alineada del dispositivo que se aproxima al límite interno de 64 bytes. El problema puede ocurrir en una de estas circunstancias:
Durante la escritura de un archivo crash dump
Algo hace que el sistema colapse durante la escritura del archivo.
Cuando el código se daña durante la migración de CatOS a Cisco IOS Software
La solución temporal es modificar el driver del dispositivo de modo que administre correctamente el acceso no alineado. Si el error se produce debido a una corrupción del código durante la migración de CatOS a Cisco IOS Software, borre la Flash y descargue una imágen nueva y válida del software CatOS.
El switch señala este mensaje de error:
%L3_ASIC-DFC3-4-ERR_INTRPT: interrupción TF_INT:FI_DATA_INT que se produce en EARL %ASIC de capa 3
Este mensaje de error indica que hay un error en el reenvío del circuito integrado de aplicación específica (ASIC) de la Capa 3 (L3). Básicamente, el switch muestra este mensaje cuando un cierto tráfico transitorio atraviesa el ASIC y el software señala simplemente la aparición de una condición de interrupción. Tan pronto como se cumpla esta condición, los contadores que muestra el comando show earl statistics se incrementan. Cada vez que el software intenta recuperarse de dicho estado, el switch genera este mensaje de syslog. Generalmente, se trata de un mensaje informativo si su aparición es infrecuente. Pero si el mensaje de error aparece con frecuencia, puede haber un problema con el hardware.
Verifique el valor de los contadores en resultado del comando show earl statistics. Si los contadores aumentan rápidamente, esto indica un posible problema con el hardware.
El switch señala este mensaje de error:
%MLS_STAT-SP-4-IP_LEN_ERR: inconsistencias de longitud MAC/IP
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
May 29 21:54:14 JST: %MLS_STAT-SP-4-IP_LEN_ERR: MAC/IP length inconsistencies May 29 23:10:44 JST: %MLS_STAT-SP-4-IP_LEN_ERR: MAC/IP length inconsistencies
Estos mensajes indican que se recibieron paquetes en los cuales la longitud del IP no corresponde con la longitud MAC del paquete. Supervisor Engine descartó estos paquetes. No hay efectos negativos en el switch porque descarta los paquetes. El switch genera el mensaje con el objeto de informar. La causa del problema es un dispositivo en la red que envía paquetes inadecuados. Estos problemas, entre otros, pueden causar paquetes inadecuados:
NICs inadecuados
Drivers NIC inadecuados
Aplicaciones inadecuadas
Utilice un analizador de red para encontrar el origen desde donde se envían los paquetes erróneos. Luego, resuelva el problema con el dispositivo o la aplicación de origen.
La otra solución temporal es una configuración del switch que detenga las comprobaciones del switch para:
Errores de checksum del paquete
Errores de la longitud del paquete
Paquetes que tienen las mismas direcciones IP de origen y de destino
Utilice estos comandos para detener las comprobaciones del switch:
Switch(config)#no mls verify ip checksum !--- This configures the switch to discontinue checks for packet checksum errors.
Switch(config)#no mls verify ip length !--- This configures the switch to discontinue checks for packet length errors.
Switch(config)#no mls verify ip same-address !--- This configures the switch to discontinue checks for packets that have the
!--- same source and destination IP addresses.
El switch señala este mensaje de error:
%MLS_STAT-SP-4-IP_CSUM_ERR: errores de suma de comprobación de IP
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
Jan 20 12:48:52: %MLS_STAT-SP-4-IP_CSUM_ERR: IP checksum errors Jan 20 14:49:53: %MLS_STAT-SP-4-IP_CSUM_ERR: IP checksum errors
Estos mensajes indican que el switch recibe los paquetes IP que tienen un valor de checksum inválido. No hay efectos negativos en el switch porque el switch descarta los paquetes. El switch genera el mensaje con el objeto de informar. La causa del problema es un dispositivo en la red que envía paquetes inadecuados. Estos problemas, entre otros, pueden causar paquetes inadecuados:
NICs inadecuados
Drivers NIC inadecuados
Aplicaciones inadecuadas
Como solución temporal, utilice una de estas dos opciones:
Utilice un analizador de red para identificar el origen desde donde se envían los paquetes erróneos. Luego, resuelva el problema con el dispositivo o la aplicación de origen.
Inhabilite las comprobaciones de error de la Capa 3 en el hardware del switch para:
Errores de checksum del paquete
Errores de la longitud del paquete
Para detener estas comprobaciones de error, utilice el comando no mls verify, como muestran estos ejemplos:
Switch(config)#no mls verify ip checksum !--- This configures the switch to discontinue checks for packet
!--- checksum errors.
Switch(config)#no mls verify ip length {consistent | minimum} !--- This configures the switch to discontinue checks for packet
!--- length errors.
El switch señala este mensaje de error:
%MCAST-SP-6-ADDRESS_ALIASING_FALLBACK:
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%MCAST-SP-6-ADDRESS_ALIASING_FALLBACK: Address Aliasing detected for group 0100.5e00.0001 on vlan 632 from possible source ip 10.158.132.185 source mac 0000.bea6.82e0
Este mensaje indica que el switch recibe tráfico multicast excesivo que está destinado a una dirección MAC multicast en el rango 01-00-5e-00-00-xx. Este rango de multicast es reservado para el tráfico de control del Internet Group Management Protocol (IGMP Protocol), por ejemplo:
Hojas
Uniones
Consultas generales
La CPU del switch procesa normalmente todo el tráfico de control IGMP. Por lo tanto, el Cisco IOS Software proporciona un mecanismo para ignorar el tráfico multicast excesivo IGMP que está destinado a las direcciones reservadas. El mecanismo se asegura de que el CPU no se sature. El uso de este mecanismo se denomina “modo de soporte”.
Busque el origen del tráfico multicast ilegal. Luego, detenga la transmisión o modifique las características de la secuencia de modo que la transmisión ya no infrinja el espacio de los datos de control IGMP. Además, utilice el mensaje de error en la sección de problemas, que proporciona un origen de red que potencialmente provoca el problema.
El switch señala este mensaje de error:
c6k_pwr_get_fru_present(): no se encuentra fru_info para el tipo de fru 6, #
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #38 Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #38 Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #43 Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #43
Este mensaje de error aparece debido a una respuesta errónea del switch al sondear del Simple Network Management Protocol (SNMP) de los adaptadores de puerto que usan los módulos de WAN Flex. Este mensaje de error es cosmético en naturaleza, y no hay problemas de rendimiento perjudiciales del switch. El problema se repara en estas versiones:
Cisco IOS Software Release 12.1(11b)E4
Cisco IOS Software Release 12.1(12c)E1
Cisco IOS Software Release 12.1(13)E
Cisco IOS Software Release 12.1(13)EC
Versiones posteriores
El switch señala este mensaje de error:
%MROUTE-3-TWHEEL_DELAY_ERR:
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%MROUTE-3-TWHEEL_DELAY_ERR: Exceeded maximum delay (240000 ms) requested: 7200000
Este mensaje aparece cuando el switch recibe paquetes de unión/exclusión de Multicast con Protocolo Independiente (PIM) que anuncian un alto valor de tiempo en espera. Los paquetes anuncian un valor más alto de tiempo en espera que el retraso máximo que el OS del switch permite, que es 4 minutos. Estos paquetes son paquetes de control multicast, tales como PIM, Distance Vector Multicast Routing Protocol (DVMRP), y otros tipos.
Las versiones posteriores del Cisco IOS Software para el Catalyst 6500/6000 han aumentado este retraso máximo a 65,535 segundos, o aproximadamente 17 minutos. El problema se repara en estas versiones:
Cisco IOS Software Release 12.1(12c)E
Cisco IOS Software Release 12.2(12)T01
Cisco IOS Software Release 12.1(13)E
Cisco IOS Software Release 12.1(13)EC
Versiones posteriores
Configure el dispositivo de otro proveedor que genera los paquetes PIM para utilizar los temporizadores que son recomendados por los estándares del protocolo.
El switch señala este mensaje de error:
%MCAST-SP-6-GC_LIMIT_EXCEEDED
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%MCAST-SP-6-GC_LIMIT_EXCEEDED: IGMP snooping was trying to allocate more Layer 2 entries than what=allowed (13000)
Se registra este mensaje de error cuando la función sondeo IGMP en el switch ha creado el número máximo de entradas permitidas de Capa 2 (L2). El número máximo predeterminado de entradas L2 que el switch puede crear para los grupos multicast es 15,488. En versiones posteriores de Cisco IOS Software, solamente las entradas multicast L2 con hardware instalado llegan al límite. Consulte Cisco bug ID CSCdx89380 ( sólo clientes registrados) para obtener más detalles. El problema se repara en Cisco IOS Software Release 12.1(13)E1 y posterior.
Puede aumentar manualmente el límite L2. Ejecute el comando ip igmp l2-entry-limit.
El switch señala este mensaje de error:
%MISTRAL-SP-3-ERROR: condición de error detectada: TM_NPP_PARITY_ERROR
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
Apr 19 22:14:18.237 EDT: %MISTRAL-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Apr 19 22:14:25.050 EDT: %MISTRAL-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Apr 19 22:15:20.171 EDT: %MISTRAL-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR
Este mensaje de error indica que se produjo un error de paridad en el puntero de la página siguiente del Administrador de la Tabla interna. Si el switch funciona con Cisco IOS Software Release 12.1(8)E o posterior, el switch detecta el error de paridad y restablece el Mistral ASIC. El switch continúa, sin la necesidad de recargar. Una descarga estática aleatoria u otros factores externos puede causar el error de paridad de memoria. Si ve el mensaje de error solamente una vez o rara vez, monitoree el syslog del switch para confirmar que el mensaje de error es un incidente aislado. Si aparecen estos mensajes de error, cree una solicitud del servicio con el Soporte Técnico de Cisco.
El switch señala este mensaje de error:
%MLS_STAT-4-IP_TOO_SHRT: paquetes IP demasiado cortos recibidos
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
*Apr 1 10:30:35 EST: %MLS_STAT-SP-4-IP_TOO_SHRT: Too short IP packets received
El mensaje indica que el motor de reenvío del switch recibe un paquete IP de una longitud más corta que la longitud mínima permitida. El switch descarta el paquete. En las versiones anteriores, el paquete se descarta silenciosamente y se cuenta en las estadísticas del motor de reenvío. Esto se aplica a las versiones de software que son anteriores a 7.x o anteriores a Cisco IOS Software Release 12.1(13E). En las versiones de software posteriores a 7.x o posteriores a Cisco IOS Software Release 12.1(13E), el mensaje se registra en el syslog cada 30 minutos.
No hay efectos del lado del switch. El switch descarta los paquetes inadecuados, que el dispositivo receptor habría descartado como consecuencia. La única preocupación es que hay un dispositivo que envía paquetes inadecuados. Las posibles causas incluyen:
Un driver NIC inadecuado
Un bug del driver NIC
Una aplicación inadecuada
Debido a las limitaciones del hardware, el Supervisor Engine no rastrea el origen el IP de origen, la dirección MAC o el puerto del dispositivo que envía los paquetes inadecuados. Debe utilizar una aplicación de rastreo de paquetes para detectar estos dispositivos y rastrear la dirección de origen.
El mensaje en la sección de Problemas es simplemente una advertencia/un mensaje informativo del switch. El mensaje no proporciona ninguna información sobre el puerto de origen, la dirección MAC, o la dirección IP.
Utilice una aplicación del rastreo de paquetes dentro de la red. Intente apagar una interfaz o quitar algún dispositivo de la red para determinar si puede aislar el dispositivo que no funciona correctamente.
El switch señala este mensaje de error:
Processor [number] of module in slot [number] cannot service session requests
Este error se produce cuando ejecuta el comando session slot number processor number con el fin de establecer una sesión en estas situaciones:
Intenta establecer una sesión en un módulo en el cual ya se había establecido una sesión al registrarse en el switch.
Intenta establecer una sesión para un módulo que no está disponible en el slot.
Intenta establecer una sesión para un procesador que no está disponible en el módulo.
El switch señala este mensaje de error:
%PM_SCP-1-LCP_FW_ERR: módulo de restablecimiento del sistema [dec] para recuperarse del error: [chars]
Estos ejemplos muestran el resultado de la consola que se visualiza cuando se produce este problema:
%PM_SCP-SP-1-LCP_FW_ERR: el sistema está restableciendo el módulo 13 para recuperarse del error: la tarjeta de línea recibió la excepción del sistema
or
%PM_SCP-SP-1-LCP_FW_ERR: reinicio del sistema del módulo 4 para recuperarse del error: error de paridad de Pb Rx en la bobina - Puerto #14
El mensaje indica que el firmware del módulo especificado ha detectado un error. El sistema reajusta automáticamente el módulo para recuperarse del error. [dec] es el número de módulo, y [chars] es el error.
Vuelva a colocar el módulo o inserte el módulo en un slot diferente y permita que el módulo pase la prueba de diagnósticos completa de la función de arranque. Para obtener más información sobre los diagnósticos en línea en los Catalyst 6500 series switches, consulte Configuración de Diagnósticos en Línea. Después de que el módulo pasa la prueba de diagnósticos, monitoree la reaparición del mensaje de error. Si el error aparece otra vez o la prueba de diagnósticos detecta un problema, cree una solicitud de servicio con el Soporte Técnico de Cisco para obtener troubleshooting adicional.
El switch señala este mensaje de error:
%PM_SCP-2-LCP_FW_ERR_INFORM: El módulo [dec] está experimentando el siguiente error: [chars]
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%PM_SCP-SP-2-LCP_FW_ERR_INFORM: El módulo 4 está experimentando el siguiente error: error Pb transitorio de Bus Asic #0
El módulo informa de una condición de error, donde [dec] es el número de módulo y [chars] es el error. Esta condición suele ser causada por una tarjeta de línea instalada incorrectamente o por una falla de hardware. Si el mensaje de error se ve en todas las tarjetas de línea, la causa es un módulo instalado incorrectamente.
Retire y vuelva a insertar la tarjeta de línea o el módulo. Luego ejecute el comando show diagnostic result module module_#."
Si el mensaje de error persiste después de restablecer el módulo, cree una solicitud de servicio con el Soporte Técnico de Cisco para obtener más información sobre la solución de problemas.
El switch señala este mensaje de error:
%PM_SCP-SP-2-LCP_FW_ERR_INFORM: El módulo 4 está experimentando el siguiente error: error de puerto #36 TX Pb transitorio
Este mensaje de error indica un error transitorio en el módulo número 4 en la ruta de datos del puerto 36. En la mayoría de los casos, se trata de un problema temporal o transitorio.
Cierre y descierre el puerto Gi4/36 y monitoree la recurrencia del problema.
Si el error vuelve a ocurrir, configure el diagnóstico para que se complete con el comando diagnostic bootup level complete. A continuación, vuelva a colocar físicamente la tarjeta de línea.
Si el mensaje de error persiste después de que el módulo se haya reinstalado, cree una solicitud de servicio con el Soporte Técnico de Cisco para obtener más información sobre la solución de problemas con estos resultados de comando:
El switch señala este mensaje de error:
%PM_SCP-SP-4-UNK_OPCODE: mensaje desconocido no solicitado recibido del módulo [dec], opcode [hex]
Estos ejemplos muestran el resultado de la consola que se visualiza cuando se produce este problema:
10 de diciembre 12:44:18.117: %PM_SCP-SP-4-UNK_OPCODE: mensaje desconocido no solicitado recibido del módulo 2, opcode 0x330
or
10 de diciembre 12:44:25.2010: %PM_SCP-SP-4-UNK_OPCODE: mensaje desconocido no solicitado recibido del módulo 2, opcode 0x114
Este mensaje de error indica simplemente que el Supervisor Engine no comprende el mensaje de control de la tarjeta de línea debido a las características que no son soportadas por la versión de Cisco IOS Software del switch.
Las tarjetas de línea envían mensajes del control al Supervisor Engine activo que indican las funciones que el software soporta. Pero si el software no soporta alguna de las funciones de la tarjeta de línea, estos mensajes de control no se reconocen y se visualiza el mensaje de error. Este mensaje es una aparición inofensiva y no afecta a ninguna de las funciones en el Supervisor Engine o las tarjetas de línea.
Actualice el software Supervisor Engine a la última versión que tiene el soporte de funciones máximo. Debido a que este mensaje de error no afecta a la producción o al tráfico, puede ignorar el mensaje.
El switch señala este mensaje de error:
%PM_SCP-SP-3-TRANSCEIVER_BAD_EEPROM: error en la comprobación de integridad del transceptor en el puerto LAN 5/2: clave incorrecta
El motivo de este mensaje de error es el uso de GBIC SFP que no es de Cisco, el cual no es compatible.
Los Cisco SFP GBIC tienen un código cifrado único (Quality ID) que permite a Cisco IOS/CAT OS identificar las piezas conectables de Cisco. Los GBIC normales no tienen esto y, por lo tanto, es posible que funcionen. Consulte %PM_SCP-SP-3-TRANSCEIVER_BAD_EEPROM para obtener más información.
El switch señala este mensaje de error:
%PM_SCP-SP-3-LCP_FW_ABLC: mensaje de colisión tardía del módulo 3, puerto:035
Colisiones tardías: se produce una colisión tardía cuando dos dispositivos se transmiten al mismo tiempo y ninguno de los lados de la conexión detecta una colisión. Esto puede ser debido a que el tiempo necesario para propagar la señal de un extremo de la red a otro es mayor que el tiempo necesario para poner todo el paquete en la red. Los dos dispositivos que causan la colisión tardía nunca ven que el otro está enviando hasta después de que éste coloca todo el paquete en la red. Las colisiones tardías no son detectadas por el transmisor hasta después del intervalo correspondiente a los primeros 64 bytes. Esto es debido a que solo se detectan durante las transmisiones de paquetes mayores de 64 bytes.
Posibles causas: las colisiones tardías se producen cuando hay una discordancia dúplex, un cableado incorrecto o un número no conforme de hubs en la red. Las NIC defectuosas también pueden provocar colisiones tardías.
El switch señala este mensaje de error:
%PM-3-INVALID_BRIDGE_PORT: Bridge Port number is out of range
Este problema parece superficial y se debe a un sondeo SNMP del mib dot1dTpFdbEntry.
Puede bloquear el OID para que no se sondee en este dispositivo. Este defecto se corrige desde Cisco IOS Release 12.2(33)SRD04 y posteriores.
El switch señala este mensaje de error:
%QM-4-TCAM_ENTRY: se superó la capacidad de entrada TCAM de hardware
El TCAM es una parte de memoria especializada diseñada para que ACL y los motores de QoS realicen búsquedas en la tabla rápidamente. Este mensaje indica el agotamiento de los recursos TCAM y el switching del software de los paquetes. Esto significa que cada interfaz tiene su propia ID en TCAM y, por lo tanto, utiliza más recursos TCAM. Este problema es causado muy probablemente por la presencia del comando mls qos marking statistics o cuando el TCAM del hardware no tiene la capacidad de administrar todas los ACL configuradas.
Inhabilite el comando mls qos marking statistics ya que está habilitado de forma predeterminada.
Intente compartir las mismas ACL a través de las interfaces múltiples para reducir la contención de los recursos TCAM.
El switch señala este mensaje de error:
%slot_earl_icc_shim_addr: la ranura [num] no es ni SuperCard ni Supervisor - Ranura no válida
Este mensaje aparece cuando un administrador SNMP sondea los datos de TCAM de una tarjeta de línea que no tiene información de TCAM. Esto ocurre solamente para una tarjeta de línea en un Catalyst 6500 Switch que ejecute Cisco IOS Software. Si la tarjeta de línea tiene información de TCAM durante el sondeo SNMP, los datos se otorgan al sistema de administración de la red (NMS) para el procesamiento adicional. Consulte Cisco bug ID CSCec39383 ( sólo clientes registrados) para obtener más detalles. Este problema se repara en el Cisco IOS Software Release 12.2(18).
Como solución temporal, puede bloquear la interrogación de los datos de TCAM por los NMSs. El objeto de MIB que proporciona los datos del uso de TCAM es cseTcamUsageTable. Siga estos pasos en el router para evitar seguimientos regresivos:
Ejecute el comando el snmp-server view tcamBlock cseTcamUsageTable excluded.
Ejecute el comando snmp-server view tcamBlock iso included.
Ejecute el comando snmp-server community public view tcamBlock ro.
Ejecute el comando snmp-server community private view tcamBlock rw.
El switch señala este mensaje de error:
%SYSTEM_CONTROLLER-SP-3-ERROR: condición de error detectada: TM_NPP_PARITY_ERROR
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
Feb 23 21:55:00: %SYSTEM_CONTROLLER-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Feb 23 22:51:32: %SYSTEM_CONTROLLER-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Feb 23 23:59:01: %SYSTEM_CONTROLLER-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR
La mayoría de los errores comunes de Mistral ASIC en el MSFC son TM_DATA_PARITY_ERROR, SYSDRAM_PARITY_ERROR, SYSAD_PARITY_ERROR, y TM_NPP_PARITY_ERROR. Las posibles causas de estos errores de paridad son la descarga estática aleatoria u otros factores externos. Este mensaje de error indica que hubo un error de paridad. Los errores de paridad de la memoria del procesador (PMPE) se dividen en dos tipos: alteración de evento único (SEU) y errores repetidos.
Estos errores de un solo bit ocurren cuando un bit en una palabra de datos cambia de forma inesperada debido a eventos externos (que provoca, por ejemplo, que un cero cambie espontáneamente a 1). Los SEUs son un fenómeno universal independientemente del proveedor o la tecnología. Los SEUs se producen con muy poca frecuencia, pero todos los sistemas de red y ordenadores, incluso un equipo, están sujetos a éstos. Los SEUs también se llaman errores de software, que son causados por el ruido y dan como resultado error transitorio, inconsistente en los datos, que no está relacionado con una falla del componente, por lo general son resultado de una radiación cósmica.
Los errores repetidos (a menudo denominados errores persistentes) son causados por componentes defectuosos. Un error persistente es causado por un componente defectuoso o un problema del nivel de dirección, como una placa de circuito impresa fabricada de forma incorrecta que provoca apariciones repetidas del mismo error.
Si ve el mensaje de error solamente una vez o rara vez, monitoree el syslog del switch para confirmar que el mensaje de error es un incidente aislado. Si ocurren de nuevo estos mensajes de error, vuelva a colocar la tarjeta de Supervisor Engine. Si los errores de detienen, se trataba de un error de paridad de hardware. Si estos mensajes de error continúan apareciendo, abra un caso con el Centro de Asistencia Técnica.
El switch señala este mensaje de error:
%SYSTEM_CONTROLLER-SW2_SPSTBY-3-ERROR: condición de error detectada: TM_NPP_PARITY_ERROR
Este mensaje de error indica que hubo un error de paridad y las causas posibles son una descarga estática aleatoria u otros factores externos, que causan el error de paridad de memoria, como una conectividad de panel posterior transitoria o que podría ocurrir debido a problemas de alimentación y a veces la tarjeta de línea no puede acceder al contenido de la PROM serial (SPROM) en el módulo para determinar la identificación de la tarjeta de línea.
Todos los sistemas informáticos y de red son susceptibles a la aparición poco frecuente de trastornos por evento único (SEU), descritos a veces como errores de paridad. Estos errores de un solo bit ocurren cuando un bit en una palabra de datos cambia inesperadamente debido a eventos externos, y así hace que, por ejemplo, un cero cambie espontáneamente a uno. Los SEU son un fenómeno universal independientemente del proveedor y la tecnología. Los SEUs se producen con muy poca frecuencia, pero todos los sistemas de red y ordenadores, incluso un equipo, están sujetos a éstos. Los SEU también se denominan errores de software, que son causados por ruido y dan lugar a un error transitorio e incoherente en los datos, y no están relacionados con un fallo de componente.
Los errores repetidos, a menudo denominados errores de hardware, son causados por componentes fallidos. Un error de hardware es causado por un componente fallido, o por un problema a nivel de placa, como una placa de circuito impreso fabricada incorrectamente que resulta en repetidos casos del mismo error.
Si se vuelven a producir estos mensajes de error, vuelva a colocar el módulo supervisor durante la ventana de mantenimiento.
El switch señala este mensaje de error:
SP: El terminal de tarjeta de línea del canal 14 perdió la sincronización con el fabric inferior e intenta recuperarse ahora.
El mensaje de error señala generalmente una tarjeta de línea mal colocada. En la mayoría de los casos, puede volver a colocar físicamente la tarjeta de línea para solucionar este problema. En algunos casos, el módulo es defectuoso.
Ejecute el comando show fabric fpoe map para identificar el módulo que causa este mensaje de error.
Switch#configure terminal Switch(config)#service internal Switch(config)#end Switch#show fabric fpoe map Switch#configure terminal Switch(config)#no service internal Switch(config)#end
Este ejemplo es el resultado del comando show fabric fpoe map. Desde el resultado, puede identificar que el módulo en el slot 12 causa el mensaje de error.
switch#show fabric fpoe map slot channel fpoe 12 0 14 << There are also related errors in "show fabric channel-counters" : slot channel rxErrors txErrors txDrops lbusDrops 1 0 1 0 0 0 2 0 16 0 0 0 3 0 16 0 0 0
Vuelva a colocar el módulo que provoca el mensaje de error.
Mientras se inicia un Cisco Catalyst 6000/6500 switch, puede generarse un mensaje de error similar:
%SYSTEM-1-INITFAIL: Network boot is not supported. Invalid device specified Booting from default device Initializing ATA monitor library... monlib.open(): Open Error = -13 loadprog: error - on file open boot: cannot load "bootdisk:s72033-ipservicesk9-mz.122-18.SXF7.bin"
Este error se produce sobre todo cuando las variables de arranque no se configuran correctamente para iniciar el switch de un dispositivo Flash válido.
En el ejemplo, observe la última línea del mensaje:
boot: cannot load "bootdisk:s72033-ipservicesk9-mz.122-18.SXF7.bin"
El nombre del dispositivo Flash mencionado es bootdisk, y la primera parte del nombre de archivo de IOS, s72033, refleja que el IOS es para el módulo de Supervisor 720. El módulo de Supervisor 720 no tiene ni soporta un dispositivo Flash llamado bootdisk. Debido a que el módulo de Supervisor 720 no tiene una flash local con ese nombre, el switch considera que desea iniciar desde la red y, por lo tanto, muestra el mensaje de error.
Configure la variable de arranque con el nombre correcto del dispositivo Flash y el nombre del archivo válido del software.
Estos dispositivos Flash son soportados por los módulos de Supervisor:
Supervisor Engine 1 y Supervisor Engine 2
Nombre del Dispositivo Flash | Descripción |
---|---|
bootflash: | Memoria Flash integrada |
slot0: | Trajeta Flash lineal para PC (slot PCMCIA) |
disk0: | Tarjeta Flash PC ATA para PC (ranura PCMCIA) |
Supervisor Engine 720
Nombre del Dispositivo Flash | Descripción |
---|---|
bootflash: | Memoria Flash integrada |
disk0: | Tarjeta CompactFlash Tipo II solamente (slot disco 0) |
disk1: | Tarjeta CompactFlash Tipo II (slot disco 1) |
Supervisor Engine 32
Nombre del Dispositivo Flash | Descripción |
---|---|
bootdisk: | Memoria Flash integrada |
disk0: | Tarjeta CompactFlash Tipo II solamente (slot disco 0) |
Si esto no resuelve el problema, consulte Recuperación de un Catalyst 6500/6000 que Ejecuta el Cisco IOS System Software de una Imagen de Cargador dañada o Perdida o Modo ROMmon.
El switch indica estos mensajes de error:
CPU_MONITOR-3-TIMED_OUT: CPU monitor messages have failed, resetting system CPU_MONITOR-6-NOT_HEARD: CPU monitor messages have not been heard for [dec] seconds
Estos mensajes indican que los mensajes del monitor CPU no se han oído durante una cantidad significativa de tiempo. Posiblemente se produzca una desconexión, que restablece el sistema. el [dec] es el número de segundos.
El problema ocurre posiblemente debido a estas razones:
Tarjeta de línea o módulo colocados de forma incorrecta
ASIC o backplane inadecuados
Bugs de software
Error de paridad
Mucho tráfico en el canal Ethernet fuera de banda (EOBC)
El canal EOBC es un canal semidúplex que mantiene muchas otras funciones, que incluye el tráfico y los paquetes del Simple Network Management Protocol (SNMP) que están destinados al switch. Si el canal EOBC está lleno de mensajes debido a una tormenta de tráfico SNMP, el canal estará sujeta a colisiones. Cuando sucede esto, el EOBC posiblemente no pueda transportar los mensajes IPC. Esto hace que el switch muestre el mensaje de error.
Vuelva a colocar la tarjeta de línea o el módulo. Si una ventana de mantenimiento puede ser programada, restablezca el switch para borrar cualquier problema transitorio.
El mensaje de error %Invalid IDPROM image for linecard es recibido en Catalyst 6500 series switches que ejecutan Cisco IOS system software.
El mensaje de error puede parecer similar a estos mensajes:
% Invalid IDPROM image for daughterboard 1 in slot 4 (error = 4) % Invalid IDPROM image for linecard in slot 5 (error = 4) % Invalid IDPROM image for daughterboard 1 in slot 5 (error = 4)
Este error indica que las tarjetas de línea instaladas no se iniciaron correctamente porque el supervisor generó una mala señal sobre el bus de control. En algunos escenarios, se observa que la colocación incorrecta también hace que el supervisor o las tarjetas de línea no se reconozcan en el chasis Cat6500. Consulte Cisco bug ID CSCdz65855 ( sólo clientes registrados) para obtener más información.
Si está disponible una configuración de supervisor redundante, realice un switchover de fuerza y vuelva a colocar al supervisor activo original.
Si es una configuración de supervisor único, programe un tiempo de inactividad, y siga estos pasos:
Mueva el módulo de Supervisor a otro slot.
Vuelva a colocar todas las tarjetas de línea y asegúrese de que estén colocadas correctamente.
El switch indica estos mensajes de error:
%CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 61 seconds [2/0] %CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 151 seconds [2/0] %CPU_MONITOR-SP-3-TIMED_OUT: CPU_MONITOR messages have failed, resetting module [2/0] %OIR-SP-3-PWRCYCLE: Card in module 1, is being power cycled off (Module not responding to
Keep Alive polling) %OIR-SP-3-PWRCYCLE: Card in module 2, is being power-cycled off (Heartbeat Messages Not
Received From Module)
El supervisor envía un ping SCP cada 2 segundos a cada tarjeta de línea. Si no se recibe ninguna respuesta después de 3 pings (6 segundos), se cuenta como el primer fallo. Después de 25 de estos fallos sucesivos, o después de 150 segundos de no recibir una respuesta de la tarjeta de línea, el supervisor apaga y enciende dicha tarjeta de línea. Después de cada 30 segundos, aparece este mensaje de error en el switch:
%CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 61 seconds [2/0] %CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 151 seconds [2/0]
Después de 150 segundos, el módulo se enciende y se reinicia con estos syslogs:
%CPU_MONITOR-SP-3-TIMED_OUT: CPU_MONITOR messages have failed, resetting module [2/0] %OIR-SP-3-PWRCYCLE: Card in module 1, is being power-cycled off (Module not responding to
Keep Alive polling) %OIR-SP-3-PWRCYCLE: Card in module 2, is being power-cycled off (Heartbeat Messages Not
Received From Module)
El switch señala este mensaje de error:
%C6KPWR-4-DISABLED: Power to module in slot [dec] set [chars]
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%C6KPWR-SP-4-DISABLED: power to module in slot 10 set off (Fabric channel errors) %C6KPWR-SP-4-DISABLED: power to module in slot 2 set off (Module Failed SCP dnld) %C6KPWR-SP-4-DISABLED: power to module in slot 9 set off (Module not responding to Keep
Alive polling)
Este mensaje indica que el módulo en el slot indicado fue apagado por la razón indicada. [dec] is the slot number, and [chars] indicates the power status.
El switch tiene sus vibraciones normales y esas vibraciones pueden hacer que el módulo se aleja un poco del backplane. Cuando sucede esto, el sondeo de keepalives de los supervisores no recibe una respuesta del módulo dentro del tiempo asignado y el supervisor reinicia el módulo para intentar obtener una mejor conexión a éste. Si el módulo todavía no responde a los sondeos, el supervisor reinicia continuamente el módulo, y finalmente lo pone en error disable y no permite que la energía llegue a este módulo.
En el 90 por ciento de los casos, este problema se soluciona simplemente volviendo a colocar el módulo. Si vuelve a colocar el módulo, realinea el entramado de switch y asegura una conexión estable al backplane.
Si el módulo en cuestión es el Content Switching Module (CS), considere la actualización del software CSM a una versión 4.1(7) o posterior. Este problema se documenta en Cisco bug ID CSCei85928 (against CSM software) ( sólo clientes registrados) y Cisco bug Id CSCek28863 (against Cisco IOS software) (sólo clientes registrados) .
El último software CSM se puede descargar de la página de descarga de software de Cisco Catalyst 600 Content Switching Module.
El switch informa el mensaje de error:
ONLINE-SP-6-INITFAIL: Module [dec]: Failed to [chars]
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%ONLINE-SP-6-INITFAIL: Module 5: Failed to synchronize Port asic
La causa del crash es que el Pinnacle ASIC no pudo sincronizarse. Esto se debe generalmente a la falta de contacto o a una tarjeta mal colocada.
El sistema se recupera sin la intervención del usuario. Si se repite el mensaje de error, vuelva a colocar la tarjeta de línea o el módulo en cuestión.
El switch informa el mensaje de error:
%FM_EARL7-4-FLOW_FEAT_FLOWMASK_REQ_FAIL: Flowmask request for the flow based feature [chars] for protocol [chars] is unsuccessful, hardware acceleration may be disabled for the feature
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%FM_EARL7-4-FLOW_FEAT_FLOWMASK_REQ_FAIL: Flowmask request for the flow based feature Reflexive ACL for protocol IPv4 is unsuccessful, hardware acceleration may be disabled for the feature
La solicitud de la máscara de flujo de la característica basada en el flujo no es exitosa. Esta condición puede ocurrir debido a una excepción de los recursos TCAM, una excepción del recurso de los registros de máscara del flujo, o un conflicto irresoluble de la máscara del flujo con otras funciones basadas en Netflow. La instalación de un acceso directo de NetFlow y la aceleración de software para la función se pueden inhabilitar con esta condición, y la función se puede aplicar en el software.
Si tiene ingreso ACL reflexivo solamente, refleje y eval configurados en la dirección de ingreso en diversas interfaces, el requisito reflexivo de máscara de flujo ACL se basa en el ACL reflexivo del ingreso. Mientras el ACL reflexivo se configure en una interfaz diferente que el control de microflujo de QoS o no se superponga con la política de control ACL del microflujo, si están en la misma interfaz, pueden coexistir en hardware. Si están en la misma interfaz y el ACL reflexivo y la política de QoS se superponen, el ACL reflexivo inhabilita la instalación del acceso directo de NetFlow y el tráfico que corresponde con el ACL reflexivo es conmutado por software. Esto es debido a los requisitos en conflicto de la máscara de flujo.
En caso de ACL reflexivo de salida, el requisito reflexivo de máscara de fujo ACL es global en todas las interfaces, puesto que hay solamente Netflow de ingreso. Si el control basado en microflujo del usuario QoS se configura en este caso, el ACL reflexivo inhabilita la instalación del acceso directo de NetFlow y el tráfico que corresponde con el ACL reflexivo es conmutado por software.
Ejecute el comando show fm fie flowmask para determinar el estado habilitar/inhabilitar de la instalación de acceso directo de NetFlow para la función. Si la instalación del acceso directo de NetFlow y la aceleración por hardware se inhabilitan para la función, utilice solamente las listas de acceso reflexivas del ingreso conjuntamente con el control de microflujo, y asegúrese de que el regulador de microflujo no se superponga con la lista de acceso reflexiva. Vuelva a aplicar la función para que la solicitud de la máscara del flujo tenga éxito, y vuelva a permitir la instalación de acceso directo de NetFlow para la función.
El switch informa el mensaje de error:
%MCAST-2-IGMP_SNOOP_DISABLE:IGMP Snooping disabled due to excessive events/packets, [dec]/[dec]; auto reenable in about 2 mins
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%MCAST-2-IGMP_SNOOP_DISABLE:IGMP Snooping disabled due to excessive events/packets, 0/19880; auto reenable in about 2 mins
Se inhabilita el sondeo IGMP, pero el sistema recibe el tráfico multicast. Esta situación obliga a los paquetes multicast a ser dirigidos al procesador de ruta y posiblemente los inunda. El sondeo IGMP puede ser automáticamente inhabilitado debido al tráfico multicast excesivo. El sondeo IGMP Snooping observa básicamente estos paquetes de control que se intercambian entre los routers y los hosts y, en función de la actualización de uniones, los abandonos y las consultas, actualiza qué puertos reciben el multicast.
Este mensaje se produce normalmente porque el procesador de ruta recibe un índice mucho más alto de lo esperado de paquetes de unión IGMP o paquetes multicast normales destinados a los rangos reservados de dirección multicast de Capa 3/Capa 2. Por lo tanto, el switch se queda sin recursos y como señalan los mensajes de registro, el switch atenúa e inhabilita el sondeo IGMP por un período breve.
Puede habilitar el índice multicast que limita la función y establecer el umbral en un número mayor.
La limitación del índice es un método más deseable de modo que la cola no sea desbordada y también significa que los paquetes IGMP válidos tienen menos posibilidad de ser descartados y, por lo tanto, el proceso del sondeo en el switch aún puede actualizarse de forma adecuada.
Complete these steps in order to troubleshoot this issue:
Inhabilite el sondeo IGMP con el comando no ip igmp snooping.
Configure una sesión SPAN en la interfaz VLAN de administración en su Catalyst 6500 para determinar que la dirección MAC pertenece al origen del tráfico excesivo.
Observe la tabla CAM para identificar el origen, y quite ese origen.
Vuelva a habilitar el sondeo IGMP.
El switch señala estos mensajes de error. El mensaje de error puede ser uno de estos dos tipos:
C6KERRDETECT-2-FIFOCRITLEVEL: System detected an unrecoverable resources error on the
active supervisor pinnacle
C6KERRDETECT-2-FIFOCRITLEVEL: System detected unrecoverable resources error on active
supervisor port-asic
La causa raíz de este error posiblemente sea un módulo defectuoso o un módulo mal colocado. También puede ser un problema de chasis con este slot determinado. Esto puede ser un problema transitorio si se debe a un módulo mal colocado.
Estos mensajes indican que el sistema detectó recursos irrecuperables, que se deben al problema Primero en Entrar, Primero en Salir [FIFO], en el Pinnacle ASIC indicado o el puerto especificado ASIC.
Ejecute el comando remote command switch show platform hardware asicreg pinnacle slot 1 port 1 err para resolver este error y configure el switch para ejecutar pruebas de hardware mejoradas con estos pasos:
Nota: Escriba el comando completo y presione la tecla Enter. No puede escribir el comando con la tecla Tab.
Ejecute el comando diagnostic bootup level complete para determinar el nivel de diagnóstico que se debe completar, y guarde la configuración.
Vuelva a colocar al supervisor e insértelo firmemente
Una vez que se conecta el supervisor, ejecute el comando show diagnostic para monitorear el switch y verificar si todavía persiste el mensaje de error
El switch indica estos mensajes de error:
%C6KERRDETECT-SP-4-SWBUSSTALL: el bus de conmutación se está parando durante 3 segundos
%C6KERRDETECT-SP-4-SWBUSSTALL_RECOVERED: se ha recuperado la parada del bus de switching y continúa la conmutación del tráfico de datos
El mensaje %C6KERDETECT-SP-4-SWBUSSTALL indica que el bus de conmutación está detenido y se pierde el tráfico de datos.
El mensaje %C6KERDETECT-SP-4-SWBUSSTALL_RECOVERED indica que el bus de conmutación ya no está detenido y que el tráfico de datos puede continuar.
Básicamente, si algún módulo del bus del sistema se cuelga, el supervisor detecta un tiempo de espera e intenta recuperarse por sí solo. Si un módulo estaba en proceso de instalación, entonces es una causa muy posible de estos mensajes ya que esto puede causar una parada de bus mientras el módulo se asienta en la placa de interconexiones.
Se recibe este mensaje de error al fallar los ping de prueba de entrada debido a utilización de CPU elevada:
SP-RP Ping Test[7]: Test skipped due to high traffic/CPU utilization
El ping de entrada SP-RP es una prueba de diagnóstico en línea y el mensaje que la prueba de ping SP-RP falló se genera sólo para informar. Indica uso elevado de CPU y puede ser el resultado de mucho tráfico que pasa al procesador de ruta o de switching el flujo de tráfico al procesador del switch. Esto también puede suceder durante cualquier actualización de la ruta. Es normal utilizar la CPU del procesador de ruta al 100 por ciento a veces.
El mensaje de error tiene como objeto informar y no tiene ningún impacto en el rendimiento del dispositivo.
El switch señala este mensaje de error:
%SW_VLAN-4-MAX_SUB_INT : The number of sub-interfaces allocated for interface [chars] has exceeded recommended limits of [dec]
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%SW_VLAN-4-MAX_SUB_INT: The number of sub-interfaces allocated for interface Gi1/1 has exceeded recommended limits of 1000
El número de subinterfaces de la Capa 3 es limitado por las VLAN internas en el switch. Las Catalyst 6500 Series tiene 4094 VLAN que se utilizan para diversos propósitos. Ejecute el comando show platform hardware capacity vlan para conocer la disponibilidad de VLAN de estado actual.
Switch#show platform hardware capacity vlan VLAN Resources VLANs: 4094 total, 9 VTP, 0 extended, 17 internal, 4068 free
El límite recomendado de subinterfaces es 1000 para cada interfaz y 2000 para cada módulo. Reduzca el número de subinterfaces asignadas a la interfaz ya que ha excedido el límite recomendado.
Nota: La consola puede bloquearse debido a la inundación de estos mensajes que se muestran en la recarga del switch. Este problema se documenta en Cisco bug ID CSCek73741 ( sólo clientes registrados) y se resuelve en Cisco IOS Software Releases 12.2(18)SXF10 y Cisco IOS Software Releases 12.2(33)SXH o posterior.
El switch señala este mensaje de error:
MCAST-6-L2_HASH_BUCKET_COLLISION: Failure installing (G,C)->index: ([enet],[dec])->[hex] Protocol :[dec] Error:[dec]
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%MCAST-SP-6-L2_HASH_BUCKET_COLLISION: Failure installing (G,C)->index: (0100.5e31.d522,802)->0xDA4 Protocol :0 Error:3
Este mensaje de error se observa normalmente junto con este mensaje:
%MCAST-SP-6-GC_LIMIT_EXCEEDED: IGMP snooping was trying to allocate more Layer 2 entries than what allowed (15488)
Este mensaje indica que una entrada de la Capa 2 no fue instalada en el hardware porque no hay bastante espacio en la cubeta de hash. Los paquetes multicast se inundan en la VLAN entrante porque la instalación de la entrada de la Capa 2 falló. Cuando se excede el límite, se produce inundación para el grupo adicional MAC.
Si no utiliza el multicast, puede inhabilitar el sondeo IGMP. De lo contrario, puede aumentar el límite de la entrada del hash con el uso del comando IP igmp snooping.
El switch señala este mensaje de error:
%QM-4-AGG_POL_EXCEEDED: QoS Hardware Resources Exceeded : Out of Aggregate policers
Solamente un número limitado de reguladores globales puede ser soportado. En los switches basados en EARL7, este límite es 1023.
En lugar de QoS basado en el puerto, puede configurar QoS basado en la VLAN. Complete estos pasos:
Aplique service-policy a cada VLAN configurada en el switchport de la Capa 2.
Quite service-policy de cada puerto que pertenezca a la VLAN específica.
Configure cada switchport de la Capa 2 para QoS basado en VLAN con el comando mls qos vlan-based.
El switch señala este mensaje de error:
%EC-SP-5-CANNOT_BUNDLE2: no es compatible con Gi2/1 y se suspenderá (MTU de Gi2/2 es 1500, Gi2/1 es 9216)
Este mensaje de error indica que la MTU del miembro del canal de puerto no es la misma, por lo que causa la falla de adición del canal de puerto. De forma predeterminada, todas las interfaces utilizaron un tamaño de MTU de 1500. Debido a la discordancia del valor de MTU, el puerto no puede agregar al canal de puerto.
Configure la misma MTU en esos puertos miembro.
El switch señala este mensaje de error:
%EC-SP-5-CANNOT_BUNDLE2: Gi1/4 no es compatible con Gi6/1 y se suspenderá (el envío de control de flujo de Gi1/4 está desactivado, Gi6/1 está activado)
Este mensaje de error indica una discordancia de velocidad o de control de flujo, por lo que la causa es una falla en la adición del canal de puerto.
Verifique que la configuración de la interfaz participe en el canal de puerto.
El switch señala este mensaje de error:
%CFIB-7-CFIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched
El mensaje de error indica que el número de entradas de ruta instaladas está a punto de alcanzar la capacidad de FIB de hardware o el límite máximo de rutas establecido para el protocolo especificado. Si se alcanza el límite, se suprimen algunos prefijos.
Recargue el router para salir del modo de excepción. Ingrese el comando mls cef maximum-routes en el modo de configuración global para aumentar el número máximo de rutas para el protocolo. De forma predeterminada, un PFC3 en SUP tiene una capacidad de 192.000 entradas, pero si utiliza el comando mls cef maximum-routes 239, esto le da la opción de utilizar el máximo de entradas TCAM disponibles. Utilice el comando show mls cef maximum-routes para verificar las rutas máximas. Utilice el comando show mls cef summary , que muestra el resumen de la información de la tabla CEF, para verificar el uso actual.
El Módulo 5 (supervisor) no supera la prueba de diagnóstico TestMatchCapture como se indica en esta salida de show diagnostic result module module_# :
TestMatchCapture ----------------> F Error code ------------------> 59 (DIAG_L2_INDEX_MISMATCH_ERROR) Total run count -------------> 1 Last test execution time ----> Jun 25 2011 04:49:10 First test failure time -----> Jun 25 2011 04:49:10 Last test failure time ------> Jun 25 2011 04:49:10 Last test pass time ---------> n/a Total failure count ---------> 1 Consecutive failure count ---> 1
La prueba TestMatchCapture es una combinación de las pruebas TestProtocolMatchChannel y TestCapture como se describe a continuación:
TestProtocolMatchChannel: La prueba TestProtocolMatchChannel verifica la capacidad de hacer coincidir protocolos específicos de Capa 2 en el motor de reenvío de Capa 2. Cuando ejecuta la prueba en el motor supervisor, el paquete de diagnóstico se envía desde el puerto dentro de la banda del motor supervisor y realiza una búsqueda de paquetes con el motor de reenvío de capa 2. Para los módulos habilitados para DFC, el paquete de diagnóstico se envía desde el puerto dentro de la banda del motor supervisor a través del entramado del switch y se devuelve en bucle desde uno de los puertos DFC. El motor de reenvío de Capa 2 verifica la función de coincidencia durante la búsqueda de paquetes de diagnóstico.
TestCapture: La prueba de TestCapture verifica que la función de captura del motor de reenvío de Capa 2 funciona correctamente. La funcionalidad de captura se utiliza para la replicación multidifusión. Cuando ejecuta la prueba en el motor supervisor, el paquete de diagnóstico se envía desde el puerto dentro de la banda del motor supervisor y realiza una búsqueda de paquetes con el motor de reenvío de capa 2. Para los módulos habilitados para DFC, el paquete de diagnóstico se envía desde el puerto dentro de la banda del motor supervisor a través del entramado del switch y se devuelve en bucle desde uno de los puertos DFC. El motor de reenvío de Capa 2 verifica la función de captura durante la búsqueda de paquetes de diagnóstico.
Vuelva a colocar el módulo cada vez que tenga una oportunidad. Dado que se trata de errores menores, se pueden ignorar si no observa ningún impacto en el rendimiento.
El switch señala este mensaje de error:
%CONST_DIAG-SP-3-HM_PORT_ERR: Port [dec] on module [dec] failed [dec] consecutive times. Disabling the port.
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%CONST_DIAG-SP-3-HM_PORT_ERR: Port 5 on module 2 failed 10 consecutive times. Disabling the port.
El mensaje de error indica que la ruta de datos que corresponde al puerto ha fallado. El puerto se pone en el estado errdisable.
Reinicie la tarjeta de línea para ver si el problema se resuelve por sí mismo.
El switch señala este mensaje de error:
%CONST_DIAG-SP-4-ERROR_COUNTER_WARNING: Module 7 Error counter exceeds threshold, system operation continue. %CONST_DIAG-SP-4-ERROR_COUNTER_DATA: ID:42 IN:0 PO:255 RE:200 RM:255 DV:2 EG:2 CF:10 TF:117
Compruebe los resultados del diagnóstico:
TestErrorCounterMonitor ---------> . Error code ------------------> 0 (DIAG_SUCCESS) Total run count -------------> 33658 Last test execution time ----> Apr 15 2012 11:17:46 First test failure time -----> Apr 03 2012 20:11:36 Last test failure time ------> Apr 08 2012 19:24:47 Last test pass time ---------> Apr 15 2012 11:17:46 Total failure count ---------> 5 Consecutive failure count ---> 0 Error Records ---------------> n/a
TestErrorCounterMonitor supervisa los errores e interrupciones de cada módulo del sistema consultando periódicamente los contadores de errores mantenidos en la tarjeta de línea.
Este mensaje de error aparece cuando un ASIC en la tarjeta de línea recibe paquetes con CRC incorrecto. El problema puede ser local para este módulo o puede ser desencadenado por algún otro módulo defectuoso en el chasis. Esto también puede deberse a tramas con CRC incorrecto recibidas por Pinnacle ASIC desde el DBUS. Es decir, los mensajes de error implican que se están recibiendo paquetes defectuosos a través del bus en el módulo 7.
Una de las razones por las que se producen los mensajes de error es la incapacidad del módulo para comunicarse correctamente con la placa de interconexiones del chasis debido a la colocación incorrecta del módulo. El problema es con la tarjeta de línea (módulo mal colocado), el supervisor o el bus de datos. Sin embargo, no es posible decir qué componente está corrompiendo los datos y causando una CRC incorrecta.
En primer lugar, vuelva a colocar el módulo 7 y asegúrese de que los tornillos están bien apretados. Además, antes de reiniciar, configure el diagnóstico para que se complete con el comando diagnostic bootup level complete.
Una vez que se haya terminado el reacomodo, se ejecutará el diagnóstico completo en el módulo. Luego, puede confirmar que no hay problemas de hardware en el módulo 7.
El switch señala este mensaje de error:
%SYS-3-PORT_RX_BADCODE:Port [dec]/[chars] detected [dec] bad code errors in last 30 minutes
Este ejemplo exhibe el resultado de la consola que se muestra cuando se produce el problema:
%SYS-3-PORT_RX_BADCODE: Port 3/43 detected 7602 bad code error(s) in last 30 minutes
Este mensaje de error indica que un puerto se ha visto afectado por un error de protocolo desconocido. Por ejemplo, un switch Catalyst serie 6500 recibe tramas con protocolo que no conoce ni reconoce. El primer [dec] es el número de módulo, [chars] es el número de puerto, y el segundo [dec] es el número de paquetes entrantes con protocolos desconocidos encontrados en los últimos 30 minutos.
Estas son las posibles causas del mensaje de error:
Debido a una configuración de dúplex y velocidad no coincidente.
CDP está habilitado en un extremo y no en el otro extremo.
Debido a DTP, esto se habilita de forma predeterminada en las interfaces del switch. Dado que los routers no entienden DTP, esto puede causar algunos problemas.
Verifique el contador de fragmentos minúsculos en la interfaz. Si aumenta, podría haber una discordancia dúplex en las interfaces.