cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
cancel
6933
Visitas
94
ÚTIL
16
Respuestas

Troubleshooting en Catalyst 6000, 6500 (Supervisoras 32, 720, y 2T) - Pregunte al experto

Cisco Moderador
Community Manager
Community Manager

Botón para participar

Aclare sus dudas de cómo solucionar problemas comunes en los switches Catalyst 600 y 65000, también conozca las mejores prácticas en las Supervisoras 32, 720 y 2T. Durante esta sesión usted podrá aprender a manejar de mejor forma los retos comunes que se generan durante las fases de implementación y operación cotidiana como: los reinicios causados deliberadamente para prevenir un problema mayor, así como aquellos relacionados a la compatibilidad y configuración de los módulos, entre otros. Participe y conozca los mejores tips para troubleshooting.

Haga sus preguntas del 15 de Agosto al 26 de Agosto del 2016.



Detalles del especialista 


Eduardo Cruz es un ingeniero del TAC Backbone de México, cuenta con más de 6 años de experiencia trabajando con productos de Cisco en diversas compañías, ha resuelto problemas de redes para empresas medianas y grandes con presencia mundial. Se especializa en los switches Catalyst, desde dispositivos de acceso (3650, 3750, 3850, 4500, 4900) hasta core (6500, 6800 usando distintas supervisoras), así como tecnologías de capa 2 y otras tecnologías/problemas como QoS, ARP, high CPU, entre otros.  Eduardo es un egresado del Instituto Tecnologico y de Estudios Superiores de Monterrey (ITESM) Campus Puebla, cuenta con las certificaciones CCNA y CCNP Routing & Switching. Actualmente se está preparando para obtener el CCIE de R&S.

Eduardo puede no ser capaz de responder a todas las preguntas, debido al volumen esperado durante este evento. Recuerde que también puede hacer sus preguntas en nuestra sub-comunidad de https://supportforums.cisco.com/es/community/5551/routing-switching 

 

** ¡Las calificaciones fomentan la participación! **
Por favor asegúrese de calificar special-programs.png las respuestas a sus preguntas.

16 RESPUESTAS 16

diomedes_uli
Level 1
Level 1

Que tal buen día a todos!!!

Cuando te encuentras con un loop en la red, cual es la mejor manera o metodología para realizar Tshoot??

También que comandos avanzados o no puedo usar para rastrear el loop hasta el origen?

Saludos y gracias a todos!!

Buen dia diomedes_uli,

Muchas gracias por la pregunta. Para hacer troubleshooting de un loop de capa 2, se pueden ocupar los siguientes comandos / buenas practicas enlistadas a continuacion:

1. Contar con un diagrama de red: Es muy importante saber en terminos de Spanning-Tree (STP) quien debe ser el switch raiz (root bridge) y que puertos deben estar en cual estado. A partir de un diagrama teorico, podremos revisar que puertos estan en el estado deseado y cuales estan cambiando constantemente. 

2. Habilitar "MAC move" en todos los switches: Una buena practica, es habilitar el comando "mac address-table notification mac-move" en los switches involucrados para detectar que direcciones MAC (MAC addresses) se aprenden por mas de un puerto constantemente. Esto tambien nos ayudara a identificar si el problema viene de una direccion MAC, o es especifico de alguna VLAN.

Nota: Cabe mencionar que para usuarios Wireless, es esperado ver que las direcciones MAC se mueven de un puerto de un switch (donde hay un Access Point conectado) a otro, debido a roaming.

Switch# configure terminal

Switch(config)# mac address-table notification mac-move

Switch(config)# end

Mar 30 03:59:15.940: %SW_MATM-4-MACFLAP_NOTIF: Host dceb.942e.eb47 in vlan 1 is flapping between port Gi1/1/2 and port Gi1/1/1
Mar 30 03:59:37.960: %SW_MATM-4-MACFLAP_NOTIF: Host dceb.942e.eb47 in vlan 1 is flapping between port Gi1/1/2 and port Gi1/1/1
Mar 30 03:59:49.930: %SW_MATM-4-MACFLAP_NOTIF: Host dceb.942e.eb47 in vlan 1 is flapping between port Gi1/1/2 and port Gi1/1/1
Mar 30 04:00:03.948: %SW_MATM-4-MACFLAP_NOTIF: Host dceb.942e.eb47 in vlan 1 is flapping between port Gi1/1/2 and port Gi1/1/1
Mar 30 04:00:20.003: %SW_MATM-4-MACFLAP_NOTIF: Host dceb.942e.eb47 in vlan 1 is flapping between port Gi1/1/2 and port Gi1/1/1
Mar 30 04:00:31.932: %SW_MATM-4-MACFLAP_NOTIF: Host dceb.942e.eb47 in vlan 1 is flapping between port Gi1/1/2 and port Gi1/1/1

3. Correr el comando "show mac address-table address xxxx.xxxx.xxxx" constantemente: Esto nos permitira saber por donde se recibe la direccion MAC de algun dispositivo en especifico. En ocasiones esto nos permite saber si el loop es originado por tal.

Switch#show mac add add dceb.942e.eb47
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----
1 dceb.942e.eb47 DYNAMIC Gi1/1/2
Total Mac Addresses for this criterion: 1
Switch#show mac add add dceb.942e.eb47
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----
1 dceb.942e.eb47 DYNAMIC Gi1/1/1
Total Mac Addresses for this criterion: 1

Switch#show cdp ne Gi 1/1/2
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
F340.04.23-3850-5
Gig 1/1/2 167 S I WS-C3850- Ten 3/0/2
Switch#show cdp ne Gi1/1/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
F340.04.22-3850-6
Gig 1/1/1 152 S I WS-C3850- Ten 1/0/2

En switch #1: 

F340.04.23-3850-5#show mac add add dceb.942e.eb47
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----
1 dceb.942e.eb47 DYNAMIC Te3/0/1
Total Mac Addresses for this criterion: 1

F340.04.23-3850-5#show cdp ne Te3/0/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
F340.04.22-3850-6
Ten 3/0/1 134 S I WS-C3850- Ten 1/0/1

Total cdp entries displayed : 1

En switch #2:
F340.04.22-3850-6#show mac add add dceb.942e.eb47
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----
1 dceb.942e.eb47 STATIC Vl1
Total Mac Addresses for this criterion: 1

4. Buscar interfaces con alta utilizacion en comparacion con otras interfaces: En ocasiones, los links involcurados en un loop tienen una alta utilizacion ya sea en ingreso o egreso. Con el comando siguiente se puede identificar cuales son los enlaces de interes para aislar el problema a unos cuantos puertos:

Switch#show interface | include is up|input rate|output rate

...snip...

GigabitEthernet1/1/1 is up, line protocol is up (connected)
5 minute input rate 33408000 bits/sec, 65227 packets/sec
5 minute output rate 32430000 bits/sec, 63316 packets/sec
GigabitEthernet1/1/2 is up, line protocol is up (connected)
5 minute input rate 32435000 bits/sec, 63325 packets/sec
5 minute output rate 32422000 bits/sec, 63300 packets/sec

GigabitEthernet1/1/3 is up, line protocol is up (connected)

5 minute input rate 1200 bits/sec, 100 packets/sec

5. Buscar TCNs (Topology Change Notifications) aumentando rapidamente: En ocasiones, un loop hace que enlaces de Spanning-Tree envie tramas con una opcion llamada "Notification de Cambio de Topologia". Con el siguiente comando, se puede observar cuantos cambios en la topologia de Spanning-Tree ha habido, desde hace cuanto tiempo y cual fue el puerto que reporto el ultimo cambio. En ocasiones, muchos TCNs pueden causar inestabilidad en la red. 

Switch#show spanning-tree detail | include ieee|exec|from|occur
VLAN0001 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 11231532452352 last change occurred 00:00:08 ago
from GigabitEthernet1/1/1

6. Verificar que STP este habilitado en todos los switches. Hay veces en que con intencion de quitar STP en una VLAN, por peticion del ISP o por diseno, STP queda deshabilitado manualmente. Esto se puede verificar rapidamente con el siguiente comando:

Switch# show running | include spanning

spanning-tree mode rapid-pvst
spanning-tree extend system-id
no spanning-tree vlan 1

Practicas a evitar:

- En ocasiones, muchas personas tienden a apagar puertos esperando que el loop desaparezca Esto puede funcionar, pero no se tendra un entendimiento total de quien causo el loop y por que, y no hay garantia de que el loop no vuelva a aparecer. 

- Reiniciar los switches. Muchas personas esperan que reiniciando un switch, el problema desaparecera. Aunque es probable, porque el comportamiendo de cada loop tiene ciera naturaleza, tampoco existe garantia de que se tendra un buen entendimiento de por que sucedio el loop, y como prevenirlo.

Espero que esta informacion sea de ayuda. Si tiene mas preguntas, por favor no dude en responder a este post y con mucho gusto le dare seguimiento.

Saludos cordiales,

Eduardo Cruz

ENGINEER.CUSTOMER SUPPORT

Cisco Services - TAC LAN Switching

Muchas gracias educruz!!

Muy clara y útil información, Excelente!!!!

miguel.anguiano
Level 1
Level 1

Eduardo, Para realizar troubleshooting con equipos en configuracion  VSS en  particular  con modelos Catalyst 6807-xl que procedimiento recomiendas?

Un saludo.

Buen dia miguel.anguiano,

Me podria explicar un poco mas a detalle la pregunta, por favor? 

Se refiere a hacer troubleshooting de loops en switches que forman un VSS? O de como hacer troubleshooting del tema de VSS tal cual?

Muchas gracias y una disculpa, quiero asegurarme de darle una respuesta concisa y clara. 

Saludos cordiales,

Eduardo Cruz

ENGINEER.CUSTOMER SUPPORT

Cisco Services - TAC LAN Switching

Gracias  por  tu  pronta  respuesta.

de como hacer troubleshooting del tema de VSS tal cual.

Un  saludo.

Muchas gracias por la aclaracion miguel.anguiano

Personalmente, esta es mi referencia principal cuando trabajamos casos de VSS en TAC:

Catalyst 6500 Release 12.2SX Software Configuration Guide

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/vss.html

La guia ayuda a comprender en que consiste un VSS, cuales son los requerimientos minimos, como configurarlo, y algunos escenarios donde el sistema puede fallar.

============================================================

Cuando se tiene un problema con el switch sobre VSS, hay que considerar los siguientes puntos:

1. Verificar si se esta cumpliendo con los requisitos minimos para un VSS:  Hay que revisar los dos switches que se intentan unir con VSS tienen el minimo software requerido: 12.2(33)SXH1, que sea el mismo en ambos switches, que las tarjetas y chasis sean compatibles. En el siguiente enlace se podra encontrar que tipo de tarjetas y software son soportados: 

Virtual Switching System (VSS) Q&A
http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-virtual-switching-system-1440/prod_qas0900aecd806ed74b.html

En caso de haber un error de software o hardware, y aun asi se procede a crear un VSS, el switch mostrara su respectivo mensaje de error explicando la causa. 

2. La redundancia de los switches debe ser SSO: Al unir switches Cat6500 con doble Supervisora, hay que tener en cuenta que la redundancia entre ellas debe ser SSO (Stateful Switchover). Este es otro requerimiento minimo para VSS, de otro modo (con redundancia RPR), los switches no podran unirse. 

3. Los switches deben estar en el mismo dominio virtual: Si se configuran los switches y estan en distinto dominio virtual, estos no podran entenderse cuando sean reiniciados/encendidos, y no podran establecer VSS adecuadamente. 

Favor de referirse a la imagen "vss1.jpg" adjunta donde se indica como debe ser configurado.

4. El Port-channel VSL debe ser distinto en ambos switches: Es muy comun configurar el enlace VSL (util para establecer comunicacion entre los switches en terminos de VSS) con el mismo Port-channel ID. Debido a que estos switches operaran como uno logicamente, si se configura el mismo Port-channel ID en ambos, el switch #1 no podra reconocer al switch #2.

5. Revisar el modo PFC de las Supervisoras: Al instalar un VSS, en ocasiones una tarjeta Supervisora de un switch tiene una Policy Feature Card (PFC) distinta al otro switch, por ejemplo: PFC3C y PFC3CXL. Esto se puede configurar para que ambas operen del mismo modo, siempre que lo soporten. 

Switch-1(config)# platform hardware vsl pfc mode pfc3c
Switch-2(config)# platform hardware vsl pfc mode pfc3c

Mas informacion sobre PFCs se puede encontrar en este enlace:

Understanding MSFC, PFC and DFC roles in Catalyst 6500 Series Switch

https://supportforums.cisco.com/document/85621/understanding-msfc-pfc-and-dfc-roles-catalyst-6500-series-switch#Policy_Feature_Card_PFC

6. Cuando ya esta operando, hay que revisar si ambos switches estan en un estado Active/Active:  En ocasiones como loops, o alto uso de CPU, o alto uso del enlace VSL por trafico de usuario, los paquetes de VSL que atraviesan el enlace VSL de los switches no llegan al CPU de los switches, lo que ocasiona que el switch Standby entienda que el switch Activo ya no lo es, cuando eso no es cierto. Para esto, se han creado las siguientes caracteristicas:

  • Enhanced PAgP: Utiliza el protocolo PAgP sobre un enlace Multi Chassis Port-channel (MEC) para comunicar a los switches VSS entre si ademas del enlace VSL. Requiere un switch vecino hacia donde va el MEC.
  • IP Bidirectional Forwarding Detection (BFD): Utiliza mensajes de BFD sobre un puerto Ethernet, para detectar falla entre los dos switches en VSS.
  • Dual-Active fast-hello: Utiliza mensajes de Hello sobre una conexion Ethernet para detectar si el switch Activo ha fallado o no procesa el trafico VSL correctamente.

7. Cuando existe este estado Active/Active, hay que recuperar el VSS: Si un VSS ya entro en estado Active/Active, todos los puertos de "redundancia" de un switch se apagaran y estaran en Admin Down, y el switch entrara en un "Recovery mode" en donde se tendran que reiniciar ambos switches para recuperar el enlace VSS. Esto sirve para evitar loops o inestabilidades en STP. 

Comandos utiles:

show switch virtual link - Indicara el estado actual del VSL y los puertos fisicos.
show switch virtual link port - Indicara el estado actual del VSL y los puertos fisicos con mas detalle
show redundancy - Indicara el estado de la redundnacia de las Supervisoras (SSO o RPR)
show platform hardware pfc mode - Indicara el modo de PFC en el cual operaran las Supervisoras y modulos. 

show switch virtual role - Indicara el rol del switch en cuestion.
attach switch 2 module # - Permitira acceso al switch en Standby. 

show switch virtual dual-active summary - Permitira revisar si el switch ha caido en un estado de Dual-Active (dos chassis Activos).
show switch virtual troubleshooting - Recopila toda la informacion posible del estado del enlace VSL. Este es un buen comando resumido con buena informacion. 

Espero que esta informacion sea de ayuda. Si tiene alguna duda mas especifica, por favor no dude en responder a este post.

Saludos cordiales,

Eduardo Cruz

ENGINEER.CUSTOMER SUPPORT

Cisco Services - TAC LAN Switching

Gracias pro la información

Saludos!

Hola Eduardo

¿Puedo actualizar un Catalyst 6500 con 2T por s72033-adventerprisek9-mz.151-2.SYS.bin IOS ?

Hola Sebastian, buen dia;

Asumo que el nomre de la imagen es "s72033-adventerprisek9-mz.151-2.SY5.bin" en lugar de la "S".

Dicha imagen solo puede ser instalada en un Catalyst 6500 con Supervisora 720 (como lo indica la nomeclatura de la misma imagen.

El equivalente para la Supervisora 2T seria: "s2t54-adventerprisek9-mz.SPA.151-2.SY5.bin" que puede ser descargada del siguiente enlace:

IOS Software-15.1.2-SY5

https://software.cisco.com/download/release.html?mdfid=283933147&softwareid=280805680&release=15.1.2-SY5&flowid=66114

Espero que esta informacion le sea de ayuda. Si tiene mas preguntas por favor no dude en responder a este post. 

Saludos cordiales,

Eduardo Cruz

ENGINEER.CUSTOMER SUPPORT

Cisco Services - TAC LAN Switching

Cisco Moderador
Community Manager
Community Manager

Hola Eduardo

Agradecemos mucho compartas con nosotros y todos aquellos interesados en esta tecnología tu conocimiento. Te proporcionamos algunas de las dudas comunes respecto al tema:

  • ¿Cuáles son los tipos más comunes de reinicios no esperados de esta plataforma y cuáles son sus causas?
  • ¿Cuáles son los problemas más comunes que ocurren en módulos o puertos y sus causas?
  • ¿Cómo hacer troubleshooting cuando existe una conectividad lenta o intermitente?

Hola Cisco Moderador, buen dia.

Con gusto respondere una pregunta por dia. 

¿Cuáles son los tipos más comunes de reinicios no esperados de esta plataforma y cuáles son sus causas?

Existen varios motivos por los que un switch Cat6500 puede reiniciarse inesperadamente:

1) Falta de alimentacion: Antes de abrir un caso con TAC, siempre es bueno revisar si existia alguna actividad planeada que involucraba reiniciar el switch o desconectarlo por mantenimiento. El comando "show version" dira cual fue la razon por la que el switch ha sido reiniciado.

513E.D.22-6500-1#show ver
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9-M), Version 15.1(2)SY6, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Thu 10-Sep-15 01:59 by prod_rel_team

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)
BOOTLDR: Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9-M), Version 15.1(2)SY6, RELEASE SOFTWARE (fc4)

513E.D.22-6500-1 uptime is 2 hours, 38 minutes
Uptime for this control processor is 2 hours, 38 minutes
System returned to ROM by power cycle at 15:03:05 UTC Wed Aug 10 2016 (SP by power on)
System image file is "disk0:s72033-adventerprisek9-mz.151-2.SY6.bin"
Last reload reason: reload <<<<<<<<<<<<<<<<<<<<
...snip...

2) Falta de comunicacion entre el RP y SP: Las Supervisoras 32 y 720 fueron disenadas con dos CPUs, los cuales se dividen ciertos procesos para una mejor administracion de recursos. El RP (Route Processor) se encarga de manejar algunos procesos mas involucrados con protocolos configurados (STP, OSPF, IP Input, SNMP, etc.), asi como trafico del usuario. El SP (Switch Processor) por otra parte, se encarga de tareas internas de la plataforma, como la comunicacion entre tarjetas y la Supervisora, el estado de sensores, entre otros. El SP y RP envian paquetes llamados "keepalive" entre si para verificar que ambos funcionan correctamente. Cuando uno de ellos deja de enviar, o el otro deja de recibir ese tipo de mensajes, el switch intentara corregir esa falla reiniciandose. En ocasiones esto puede ser causado por un error de paridad, o por una falla de software.

Si es un error de paridad, el switch solamente se reiniciara y no habra mas que monitorear el dispositivo entre 24 y 72 horas. Si el problema vuelve a suceder, muy probablemente sea un problema de hardware y la Supervisora tendra que ser reemplazada. Aqui mas informacion sobre lo que son errores de paridad. Desafortunadamente, esto puede suceder a cualquier equipo ya que la causa es ambiental o electromagnetica.

Processor Memory Parity Errors (PMPEs)
http://www.cisco.com/c/en/us/support/docs/routers/7200-series-routers/6345-crashes-pmpe.html

Parity Errors Troubleshooting Guide
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/116135-trouble-6500-parity-00.html

3) Falla de RP y SP por bus: Existen algunos casos aislados donde el switch no puede entender una instruccion, tiene problemas para leer alguna memoria, o no administra sus recursos de manera necesaria, lo que causa que intente reiniciarse para recuperarse. En estos casos, el mismo comando "show version" nos indicara de que se trata el problema. Existen varios tipos de errores de memoria, como

- Error de bus, causado por direccion invalida
- Error de bus, causado por error de paridad en la memoria principal
- Error de bus, causado por error de paridad en la memoria I/O
- Error de direccion
- Crash causado por el software
- Falla de lectura de la memoria
- Se intento dividir sobre cero
- Memoria corrupta
- entre otros

Router#show ver
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9-M), Version 15.1(2)SY6, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Thu 10-Sep-15 01:59 by prod_rel_team

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)
BOOTLDR: Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9-M), Version 15.1(2)SY6, RELEASE SOFTWARE (fc4)

Router uptime is 2 minutes
Uptime for this control processor is 2 minutes
System returned to ROM by software NMI at PC 0xBFC2A82C, address 0x0 at 19:44:47 UTC Tue Aug 23 2016 (SP by software NMI at PC 0xBFC10494, address 0x0)
System image file is "disk0:s72033-adventerprisek9-mz.151-2.SY6.bin"
Last reload reason: unknown reload cause - reason ptr 0x10, PC 0xBFC2A82C, address 0x0 <<<<<<<<<<<<<<<<<<<<

4) Falla de RP y SP por memoria/software: En este caso, el RP y SP del switch crearan cada uno un archivo "crashinfo" en su respectivo directorio (sup-bootdisk: y bootdisk:). Es necesario obtener esta informacion de cada uno, y abrir los archivos para encontrar la causa raiz. Un archivo dira que el RP se renicio por falla del SP, y el otro dira la causa raiz, o viceversa. En ocasiones el problema es un bug o una memoria interna del switch. Con esta informacion, el ingeniero de TAC tendra mucha mas facilidad para encontrar la causa y proveer un plan de accion para evitar esto en el futuro.

NOTA: La Supervisora 2T tiene el SP y RP combinados en un mismo CPU, por lo cual solo generara un archivo "crashinfo".


513E.D.22-6500-1#show bootflash:
-#- ED ----type---- --crc--- -seek-- nlen -length- ---------date/time--------- name
...snip...
11 .. crashinfo F33C89AD 3B7C54 32 366440 Aug 23 2016 19:44:41 +00:00 crashinfo_RP_20160823-194441-UTC

62161836 bytes available (3374164 bytes used)


513E.D.22-6500-1#show sup-bootflash:
-#- --length-- -----date/time------ path
...snip...
4 326813 Apr 1 2016 22:17:12 +00:00 crashinfo_SP_20160401-221712-UTC

Para abrir los archivos:


513E.D.22-6500-1#more bootflash:crashinfo_RP_20160823-194441-UTC

...snip...

19:44:41 UTC Tue Aug 23 2016: Address Error (load or instruction fetch) exception, CPU signal 10, PC = 0x40CA6DEC   --- CAUSA RAIZ


513E.D.22-6500-1#more sup-bootflash:crashinfo_SP_20160401-221712-UTC

*Apr 1 22:17:12.679: %SYS-SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output.

*Apr 1 22:17:12.679: %CONST_DIAG-SP-3-SUP_FAILURE: Active supervisor has MAJOR online diagnostic failure 0x0: UNKNOWN
*Apr 1 22:17:12.683: %PFREDUN-SP-4-AUTOBOOT: Disable autoboot for Supervisor in slot 5
*Apr 1 22:17:12.683: %PFREDUN-SP-6-ACTIVE: Sup in slot 5 is crashing due to Supervisor online diag failure

%Software-forced reload


22:17:12 UTC Fri Apr 1 2016: Breakpoint exception, CPU signal 23, PC = 0x41D912AC

En caso de tener alguna pregunta por favor no dude en responder a este post.

Saludos cordiales,

Eduardo Cruz

ENGINEER.CUSTOMER SUPPORT

Cisco Services - TAC LAN Switching

¿Cuáles son los problemas más comunes que ocurren en módulos o puertos y sus causas?

1) Reinicios inesperados: Todas las tarjetas se comunican con la Supervisora fisicamente por medio de conectores que existen en el chassis, y logicamente por protocolos como IPC (Interprocess Communication), a trves de un canal "Ethernet out of band" (EOBC). Las Supervisoras deben enviar mensajes "keepalive" para asegurar que las tarjetas estan operando, ademas de enviar otra informacion de gestion interna. Si la supervisora no recibe respuesta de las tarjetas en un cierto intervalo, intentara mostrar un mensaje via "show log". De detectar un problema o no reconocer la tarjeta despues de cierto numero de intentos, intentara reiniciarla para recuperar control. En algunas ocasiones, la tarjeta puede generar un archivo "crashinfo" para revision, en el directorio de la misma tarjeta ("show dfc9#-bootflash:). Para mas informacion, uno puede referirse al siguiente enlace.

Common Error Messages on Catalyst 6500/6000 Series Switches Running Cisco IOS Software
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/41265-186-ErrormsgIOS-41265.html#anc114

2) Output queue drops: Por definicion, un "output queue drop" es un paquete que el switch intento enviar de salida (hacia el usuario final) pero detecto que el enlace estaba congestionado, e intento guardar el paquete en un buffer. Como usualmente estos buffers son pequenos, el paquete no dura mucho tiempo ahi y despues es descartado. Usualmente, existe una creencia popular la cual indica que solamente si veo que el enlace sobrepase la capacidad del puerto constantemente, esperare output drops. Esto no es correcto, puesto que algunas transferencias de informacion que atraviesan un puerto, no envian la informacion con una tasa fija de transferencia, como se puede observar en la grafica adjunta a esta respuesta. Este concepto se llama "microbursts". Para mas informacion uno puede referirse al siguiente enlace:

Wireshark Use to Identify Bursty Traffic on Catalyst Switches
http://www.cisco.com/c/en/us/support/docs/lan-switching/switched-port-analyzer-span/116260-technote-wireshark-00.html

Otra causa de output drops es la saturacion de un enlace de acuerdo al diseno de la tarjeta. En ocasiones la tarjeta tiene un numero de puertos internamente conectados a una memoria ASIC para que los paquetes sean enviados a un destino. Este "mapping" de puertos internamente termina en un cuello de botella, lo que lleva a output drops en varios puertos en el mismo grupo. Al adquirir un modulo, hay que revisar un valor que se llama "oversubscription rate" que indicara cuantos puertos estan internamente conectados a un mismo ASIC para saber cuanta capacidad tienen los puertos dentro del grupo. Mas informacion sobre este caso conocido se puede encontrar en el siguiente enlace:

Connectivity Problem or Packet Loss with WS-X6548-GE-TX and WS-X6148-GE-TX Modules used in a Server Farm
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/24053-193.html#ASIC


3) Overruns: Un overrun usualmente indica un problema de fabric en el switch. Como se explico anteriormente, los switches tienen ciertos puertos agrupados a una memoria ASIC, y despues existen dos canales llamados "Fabric channels" que tienen cierta capacidad. Cuando el trafico agregado de varios puertos excede la capacidad de canales fabric, existe una congestion interna en la tarjeta del switch. La manera mas facil de resolver este problema, es identificar que canal Fabric tiene mas paquetes descartados con "show fabric usage" y distribuir el trafico entre tarjetas. Mas informacion puede ser encontrada en el siguiente enlace:

Overruns counter in the show interfaces command output is increasing
https://supportforums.cisco.com/document/13796/overruns-counter-show-interfaces-command-output-increasing

4) Errores de diagnosticos de hardware: En ocasiones, los switches mostraran un log indicando que una tarjeta ha fallado un test como "TestLoopback" o "TestSPRPInbandPing". Dependiendo del test, implicara si el problema es de una tarjeta o de un puerto en especifico de la tarjeta. Generalmente TAC indica seguir este plan de accion para resolver el problema.

1. Si el problema es pertinente a un puerto, apagarlo administrativamente y encenderlo (shut/no shut) y monitorear.
2. Si el problema es especifico a la tarjeta, remover la tarjeta e insertarla de nuevo y monitorear.
3. Si el problema persiste, contactar a TAC con un "show tech" para revisar si existe algun paso adicional dependiendo del test.
4. Se procede con el reemplazo de la pieza, considerando que el problema es de hardware.

Mas informacion sobre estos diagnosticos de hardware GOLD, en los siguientes enlaces:

Generic Online Diagnostics on the Cisco Catalyst 6500 Series Switch
http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/prod_white_paper0900aecd801e659f.html

How to run GOLD diagnostic tests on Catalyst 6500/6000 series switches to troubleshoot hardware issues
https://supportforums.cisco.com/document/25451/how-run-gold-diagnostic-tests-catalyst-65006000-series-switches-troubleshoot-hardware

Saludos cordiales,

Eduardo Cruz

ENGINEER.CUSTOMER SUPPORT

Cisco Services - TAC LAN Switching

¿Cómo hacer troubleshooting cuando existe una conectividad lenta o intermitente?

1. Aislar el problema con determinados usuarios: El metodo mas efectivo para entender problemas de conectividad lenta o intermitente, es seleccionar un usuario afectado y un destino. Si existe un usuario afectado y otro que no, hay que tratar de ocupar el mismo destino y trazar el trafico que ambos toman para buscar similitudes o diferencias. Datos requeridos:


- IP o MAC de origen
- IP o MAC de destino
- Tipo de problema (latencia, perdida de paquetes, problemas de transferencia, etc.)

2. Trazar un camino del trafico: Si ya se tiene un usuario origen afectado y un destino, hay que entender el camino que deberia tomar el trafico: cada puerto, cada interface de capa 2 o 3, y cada switch o router involucrado. Un diagrama de red ayuda mucho para entende esta informacion.

3) Comandos para trazar el trafico una vez que se entiende el camino que toma el trafico de origen a destino. En ocasiones el trafico toma otro camino que no esperamos por lo cual es importante verificar esta informacion. Hay que hacer esto de origen a destino y vice versa para eliminar problemas de routing asimetrico.

- "show mac address address aaaa.aaaa.aaaa (MAC address del usuario)
- "show run" (de las interfaces en uso)
- "show span vlan xx detail" (donde xx es la VLAN en la cual se encuentra el host.
- "show ip route x.x.x.x" (donde x.x.x.x es la IP del usuario origen/destino)
- "show ip arp x.x.x.x" (donde x.x.x.x es la IP del usuario origen/destino)

4) Guardar una sesion en consola: Cada vez que se hace troubleshooting, es una excelente practica guardar toda la informacion de la sesion en un archivo de texto para futura referencia.

5) Comenzar a analizar la informacion: Una vez que ya se entendio el camino del paquete, podemos buscar por senales de perdida de paquetes. Estos usualmente aparecen como "Input queue drops", "Output queue drops", o errores en las interfaces (fisicas o interfaces VLAN). De igual manera hay que buscar algunos logs que no reconozcamos en el switch, alto procesamiento de CPU y cambios en Spanning-Tree, ya que podrian ser la causa tambien.

- show process cpu sorted
- show process cpu memory
- show process cpu history
- show log
- show spanning-tree detail | include ieee|exec|from|occur

6) Capturas: Si no existe algun problema obvio, podemos tomar capturas de paquetes en algunos puertos con SPAN (Switch Port Analyzer), para verificar que nuestro trafico es enviado y recibido en cada puerto. Tambien podemos tomar capturas simultaneas para trafico sensible y asi entender en que switch o router el problema aparece. Tambien podemos ocupar Access Lists para revisar si los paquetes son recibidos por el puerto donde se configure la ACL.

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml

Saludos cordiales,

Eduardo Cruz

ENGINEER.CUSTOMER SUPPORT

Cisco Services - TAC LAN Switching

Vamos a comenzar

¡Conecte con otros expertos de Cisco y del mundo! Encuentre soluciones a sus problemas técnicos o comerciales, y aprenda compartiendo experiencias.

Queremos que su experiencia sea grata, le compartimos algunos links que le ayudarán a familiarizarse con la Comunidad de Cisco: