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 describe cómo determinar por qué un puerto o una interfaz experimentan problemas.
No hay requisitos específicos para este documento.
Este documento se aplica a los switches Catalyst que se ejecutan en Cisco IOS® System Software.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Consulte el documento Cisco Technical Tips Conventions (Convenciones sobre consejos técnicos de Cisco) para obtener más información sobre las convenciones de los documentos.
Nota: para acceder a herramientas y sitios web, debe ser un cliente registrado de Cisco.
Si tiene acceso físico al switch, puede save
tiempo para observar los LED de puerto que le indican el estado del link o pueden indicar una condición de error (si es rojo o naranja). La tabla describe los indicadores del estado LED para los módulos Ethernet o los switches de configuración fija:
Platform | URL |
Catalyst 6000 Series Switches |
|
Catalyst 4000 Series Switches |
|
Catalyst 3750 Series Switches |
|
Catalyst 3550 Series Switches |
|
Catalyst 2950/2955 Series Switches |
|
Catalyst 2900/3500XL Series Switches |
|
Catalyst 1900 Series Switch y 2820 Series Switch |
Asegúrese de que ambos lados tengan un link. Un solo cable dañado o un puerto apagado pueden provocar el problema en el que un lado tiene una luz de link, pero el otro no.
Una luz de link no garantiza que el cable funcione correctamente. El cable puede haber recibido tensión física, lo que lo hace ser funcional en un nivel marginal. Normalmente, puede identificar esta situación si el puerto tiene muchos errores de paquete, o el puerto se conecta y desconecta constantemente (pierde y recupera el link).
Si no aparece la luz del link para el puerto, puede considerar estas posibilidades:
Posible Causa | Acción Correctiva |
No hay cables conectados |
Conecte el cable del switch a un dispositivo conocido adecuado. |
Puerto Incorrecto |
Asegúrese de que los ambos extremos del cable estén conectados en los puertos correctos. |
El dispositivo no tiene energía |
Asegúrese de que ambos dispositivos tengan energía. |
Tipo de cable incorrecto |
Verifique la selección del cable. Consulte la Guía del Cable del Switch Catalyst. |
Cable en malas condiciones |
Cambie el cable que supuestamente está en malas condiciones por un cable en buenas condiciones. Busque pines rotos o perdidos en los conectores. |
Conexiones débiles |
Verifique conexiones débiles. A veces, parece que un cable está asentado en la toma, pero no lo está. Desenchufe el cable y vuelva a insertarlo. |
Patch Panels |
Elimine las conexiones del patch panel con fallas. Si es posible, desvíe el patch panel para descartarlo. |
Convertidores de medios |
Elimine los convertidores de medios defectuosos: de fibra a cobre, etc. Si es posible, omita el convertidor de medios para descartarlo. |
Convertidor de interfaz Gigabit (GBIC) en malas condiciones o incorrecto |
Cambie el GBIC que supuestamente está en malas condiciones por un GBIC conocido en buenas condiciones. Verifique el soporte Hw y Sw para este tipo de GBIC. |
Puerto, Puerto del Módulo o Interfaz en Malas Condiciones o Módulo No Habilitado |
Mover el cable a un puerto conocido en buenas condiciones para resolver problemas con un puerto o un módulo que supuestamente está en malas condiciones. Utilice el comando show interface para que Cisco IOS busque el estado errdisable, disable o shutdown. El comando show module puede indicar ser defectuoso, que puede indicar un problema de hardware. Consulte la sección Problemas Comunes de Puertos e Interfaces de este documento para obtener más información. |
Asegúrese de que dispone del cable correcto para el tipo de conexión que desea establecer. El cable de cobre de categoría 3 se puede utilizar para conexiones de par trenzado no apantallado (UTP) de 10 Mbps, pero nunca se debe utilizar para conexiones UTP de 10/100 o 10/100/1000 Mbps. Siempre use la categoría 5, la categoría 5e, o la categoría 6 UTP para 10/100 o las conexiones 10/100/1000Mbps.
Advertencia: los cables de las categorías 5e y 6 pueden almacenar altos niveles de electricidad estática debido a las propiedades dieléctricas de los materiales utilizados en su construcción. Siempre conecte los cables (especialmente en las nuevas extensiones de cable) a tierra física adecuada y segura antes de conectarlos al módulo.
Para la fibra, asegúrese de tener el cable correcto para las distancias involucradas y el tipo de puertos de fibra que se usen. Las dos opciones son fibra monomodo (SMF) o fibra multimodo (MMF). Asegúrese de que ambos puertos de los dispositivos que están conectados sean SMF, o que ambos sean MMF.
Nota: Para las conexiones de fibra, asegúrese de que el terminal de transmisión de un puerto esté conectado al terminal de recepción del otro puerto. Las conexiones transmisión a transmisión y recepción a recepción no funcionan.
Velocidad del Transmisor y Receptor | Tipo de Cable | Modo Dúplex | Distancia máxima entre estaciones |
10 Mbps |
Categoría 3 UTP |
Total y semi |
328 pies (100 m) |
10 Mbps |
MMF |
Total y semi |
1,2 mi (2 km) |
100 Mbps |
Categoría 5 UTP Categoría 5e UTP |
Total y semi |
328 pies (100 m) |
100 Mbps |
Categoría 6 UTP |
Total y semi |
328 pies (100 m) |
100 Mbps |
MMF |
Semi |
1312 pies (400 m) |
Total |
1,2 mi (2 km) |
||
100 Mbps |
SMF |
Semi |
1312 pies (400 m) |
Total |
6,2 mi (10 km) |
Para obtener más información sobre los diferentes tipos de cables/conectores, los requisitos de cables, los requisitos ópticos (distancia, tipo, cables de conexión, etc.), cómo conectar los diferentes cables y qué cables utilizan la mayoría de los switches y módulos de Cisco, consulte la Guía de cables de switches Catalyst.
Si conecta el dispositivo A con el dispositivo B sobre un link Gigabit, y el link aparece, realice este procedimiento.
Procedimiento Paso a Paso
Verifique que el dispositivo A y B usen el mismo GBIC, longitud de onda corta (SX), longitud de onda larga (LX), trayecto largo (LH), longitud de onda extendida (ZX), o cobre UTP (TX). Ambos dispositivos deben utilizar el mismo tipo de GBIC para establecer el link. Un SX GBIC necesita conectarse con un SX GBIC. Un SX GBIC no se conecta con un LX GBIC. Consulte Nota de Instalación del Cable Patch Acondicionador de Modo para obtener más información.
Verifique la distancia y el cable usados por el GBIC según lo definido en esta tabla.
Especificaciones del Cableado de los Puertos 1000BASE-T y 1000BASE-X
GBIC |
Longitud de onda (nm) |
Cobre/Tipo de Fibra |
Tamaño del núcleo1(micrones) |
Ancho de banda modal (MHz / km) |
Distancia del cable2 |
WS-G54831000Base - T (cobre) |
Categoría 5 UTP Categoría 5e UTP Categoría 6 UTP |
328 pies (100 m) |
|||
WS-G54841000BASE-SX3 |
850 |
MMF |
62.5 62.5 50.0 50.0 |
160 200 400 500 |
722 pies (220 m) 902 pies (275 m) 1640 pies (500 m) 1804 pies (550 m) |
WS-G54861000BASE-LX/LH |
1310 |
MMF4SMF |
62.5 50.0 50.0 8.3/9/10 |
500 400 500 - |
1804 pies (550 m) 1804 pies (550 m) 1804 pies (550 m) 6,2 millas (10 km) |
WS-G54871000BASE-ZX5 |
1550 |
MMF SMF6 |
8.3/9/10 8.3/9/10 |
43.5 millas (70 km) 762.1 millas (100 km) |
Los números otorgados para el cable de fibra óptica con varios modos se efieren al diámetro del núcleo. Para el cable de fibra óptica de modo simple, 8.3 micrones refieren al diámetro del núcleo. Los valores de 9 micrones y 10 micrones se refieren al diámetro de campo de modo (MFD), que es el diámetro de la parte de la fibra que transporta la luz. Esta área consta del núcleo de fibra más una pequeña parte que cubre el revestimiento. El MFD es una función del diámetro del núcleo, la longitud de onda del láser, y la diferencia del índice refractivo entre el núcleo y el revestimiento.
Las distancias están basadas en la pérdida de fibra. Múltiples empalmes y cable de fibra óptica de calidad inferior reducen las distancias del cable.
Use con MMF solamente.
Cuando utiliza un LX/LH GBIC con 62,5 micrones de diámetro MMF, debe instalar un cable de patch acondicionador de modo (CAB-GELX-625 o equivalente) entre el GBIC y el cable MMF en los extremos de transmisión y recepción del link. El cable de patch acondicionador de modo se requiere para las distancias inferiores a 328 pies (100 m) o superiores a 984 pies (300 m). El cable de conexión de acondicionamiento de modo evita el uso excesivo del receptor para longitudes cortas de MMF y reduce el retardo de modo diferencial para longitudes largas de MMF. Consulte Nota de Instalación del Cable Patch Acondicionador de Modo para obtener más información.
Use con SF solamente.
Cable de fibra óptica de modo simple y dispersión desplazada.
La distancia del link mínima para ZX GBIC es 6,2 millas (10 km) con un atenuador 8-dB instalado en cada extremo del link. Sin los atenuadores, la distancia del link mínima es 24,9 millas (40 km).
3. Si cualquiera de los dispositivos tiene varios puertos Gigabit, conecte los puertos entre sí. Lo anterior prueba cada dispositivo y verifica que la interfaz Gigabit funciona correctamente. Por ejemplo, tiene un switch con dos puertos Gigabit. Conecte el puerto Gigabit uno al puerto Gigabit dos. ¿El link aparece? Si es así, el puerto está en buenas condiciones. STP bloquea el puerto y evita cualquier loop (el puerto uno de recepción (RX) se dirige al puerto dos de transmisión (TX), y el TX del puerto uno se dirige al RX del puerto dos).
4. Si falla una sola conexión o el paso 3 con conectores SC, conecte el puerto nuevamente a sí mismo (el puerto uno RX va al puerto uno TX). ¿El puerto aparece? Si no, comuníquese con el TAC, ya que puede ser un puerto defectuoso.
5. Si los pasos 3 y 4 son exitosos, pero no se puede establecer una conexión entre el dispositivo A y B, conecte los puertos con el cable que linda con los dos dispositivos. Verificar que no haya un cable defectuoso.
6. Verifique que cada dispositivo admita la especificación 802.3z para la negociación automática Gigabit. Gigabit Ethernet tiene un procedimiento de negociación automática que es más extenso que el utilizado para Ethernet 10/100 (especificación de negociación automática Gigabit: IEEE Std 802.3z-1998). Cuando habilita la negociación de link, el sistema negocia automáticamente el control de flujo, el modo dúplex, y la información de falla remota. Debe habilitar o deshabilitar la negociación de link en ambos extremos del link. Ambos extremos del link se deben configurar en el mismo valor o el link no puede conectarse. Se observaron problemas cuando al conectar los dispositivos fabricados antes de que el estándar IEEE 802.3Z fuera ratificado. Si ningún dispositivo soporta la negociación automática Gigabit, se inhabilita la negociación automática Gigabit, y se fuerza la aparición del link. It takes 300msec for the card firmware to notify the software that a 10/100/1000BASE-TX link/port is down. El temporizador del debounce (eliminación de rebote) predeterminado de 300 mseg. viene del temporizador de consultas del firmware a las tarjetas de líneas, que se produce cada 300 milisegundos. Si este link se ejecuta con en el modo 1G (1000BASE-TX), la sincronización del gigabit, que se produce cada 10 mseg., debe poder detectar el link inactivo más rápidamente. Hay una diferencia en los tiempos de detección de fallas de link cuando ejecuta GigabitEthernet en cobre frente a GigabitEthernet en fibra. Esta diferencia en el tiempo de detección está basada en los estándares IEEE.
Advertencia: Inhabilite la negociación automática y esto oculta caídas de link o problemas de capa física. Esto sólo es necesario si se utilizan dispositivos finales como NIC Gigabit más antiguas que no admiten IEEE 802.3z. No inhabilite la negociación automática entre los switches a menos que se lo requieran absolutamente, ya que los problemas de la capa física pueden no detectarse, lo que resulta en loops de STP. La alternativa es comunicarse con el proveedor y solicitarle una actualización de software o hardware para obtener el soporte de negociación automática para IEEE 802.3z Gigabit.
Para conocer los requisitos del sistema GigabitEthernet y los conversores de interfaz de Gigabite (GBIC), los multiplexores por división de longitud de onda aproximada (CWDM), y los pequeños requisitos del sistema de pequeño factor de forma extraíble, consulte lo siguiente:
Requisitos del Sistema para Implementar Gigabit Ethernet en Catalyst Switches
Matriz de Compatibilidad del Switch del Conversor de Interfaz Catalyst Gigabit GigaStack
Matriz de Compatibilidad de los Módulos de Transmisor y Receptor Gigabit Ethernet de Cisco
Matriz de Compatibilidad de los Módulos de Transmisor y Receptor Cisco Ethernet de 10 gigabits
Para obtener información de configuración general e información adicional sobre cómo resolver problemas, consulte Configuración y resolución de problemas de negociación automática de dúplex medio/completo de Ethernet 10/100/1000 MB .
La mayoría de los switches Cisco tienen un puerto en el estado notconnect. Esto significa que actualmente no está conectado a nada, pero puede conectarse si tiene una buena conexión a otro dispositivo operativo. Si conecta un cable en buen estado con dos puertos del switch en el estado "notconnect", la luz de link debe ser verde para ambos puertos, y el estado del puerto debe indicar "connected". Esto significa que el puerto está activo en lo que respecta a la capa 1 (L1)
Para Cisco IOS, puede utilizar el comando show interfaces para verificar si la interfaz está activa, el protocolo de línea está activo (conectado) . El primer up se refiere al estado de la capa física de la interfaz. El mensaje line protocol up muestra el estado de la capa de link de datos de la interfaz y dice que la interfaz puede enviar y recibir señales de mantenimiento.
Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is down, line protocol is down (notconnect)
!--- The interface is down and line protocol is down. !--- Reasons: In this case, !--- 1) A cable is not properly connected or not connected at all to this port. !--- 2) The connected cable is faulty. !--- 3) Other end of the cable is not connected to an active port or device. !--- Note: For gigabit connections, GBICs need to be matched on each !--- side of the connection. !--- There are different types of GBICs, depends on the cable and !--- distances involved: short wavelength (SX), !--- long-wavelength/long-haul (LX/LH) and extended distance (ZX). !--- An SX GBIC needs to connect with an SX GBIC; !--- an SX GBIC does not link with an LX GBIC. Also, some gigabit !--- connections require conditioning cables, !--- that depend on the lengths involved.
Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is up, line protocol is down (notconnect)
!--- The interface is up (or not in a shutdown state), but line protocol down. !--- Reason: In this case, the device on the other side of the wire is a !--- CatOS switch with its port disabled.
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 notconnect 1 auto auto 10/100BaseTX
Si show interfaces muestra up/ line protocol up (connected) pero observa un incremento de errores en la salida de cualquiera de los comandos, consulte la sección Problemas Comunes de Puertos e Interfaces de este documento para obtener asesoramiento.
Esta tabla muestra los comandos más comunes utilizados para resolver problemas de puerto o interfaz en switches que ejecutan Cisco IOS System Software en el Supervisor.
Nota: La columna de la derecha de la siguiente tabla ofrece una breve descripción de lo que hace el comando y enumera cualquier excepción al uso por plataforma.
Si tiene la salida de los comandos admitidos de su dispositivo Cisco, puede utilizar Cisco CLI Analyzer para mostrar los posibles problemas y soluciones.
Comandos de Cisco IOS | Descripción |
show version |
Este comando muestra resultados similares a los de un router Cisco, como el nombre de la imagen del software, la información de versión y los tamaños de memoria del sistema. Útil para la búsqueda de incompatibilidades de software/hardware (con las notas de la versión oSoftware Advisor) y errores (con el kit de herramientas de errores de software). |
show module |
Este comando muestra qué tarjetas están presentes en el switch, la versión del software que se ejecuta y el estado en que se encuentran los módulos: correcto, defectuoso, etc. Esto es útil para diagnosticar un problema de hardware en un módulo o puerto. Para obtener más información sobre cómo resolver problemas de hardware con el comando show module, vea las secciones El estado del puerto o de la interfaz está inhabilitado o apagado o Problemas de hardware de este documento. |
show run-config |
Este comando muestra el archivo de configuración actual del switch. Los cambios son |
show interfaces |
El comando show interface muestra el estado administrativo y operativo de un puerto de switch, los paquetes de entrada y salida, los fallos de búfer, los errores, etc. |
clear counters |
Utilice el comando clear counters para poner a cero los contadores de tráfico y de errores para que pueda ver si el problema es solamente temporal o si los contadores continúan aumentando. Nota: Los Catalyst 6500/6000 Series Switches no borran los contadores de bits de una interfaz con el comando clear counters. La única manera de eliminar los contadores de bit en estos switches es a través de una recarga. |
show interfaces counters |
Este es el comando a utilizar en las series Catalyst 6000, 4000, 3550, 2950 y 3750. |
show counters interface show controllers ethernet-controller |
El comando show counters interface se introdujo en la versión de software 12.1(13)E para Catalyst 6000 Series solamente y muestra los contadores de errores de 32 bits y 64 bits. Para Cisco IOS en switches de las series 2900/3500XL, 2950/2955, 3550, 2970 y 3750, el comando show controllers Ethernet-controller muestra las tramas descartadas, las tramas diferidas, los errores de alineación, las colisiones, etc. |
show interfaces counters |
Este es el comando a utilizar en las series Catalyst 6000, 4000, 3550, 2950 y 3750. |
show diagnostic(s) show post |
El comando show diagnostic se introdujo en la versión 12.1(11b)E para la serie Catalyst 6000 y show diagnostics (con una s) se introdujo en la serie Catalyst 4000. En los switches de las series 2900/3500XL, 2950/2955, 3550, 2970 y 3750, el comando equivalente es show post , que muestra los resultados del POST del switch. Para obtener más información sobre cómo resolver los errores relacionados con el hardware en los switches Catalyst, vea la sección Problemas de Hardware de este documento. |
La mayoría de los switches tienen cierta manera de seguir los paquetes y los errores que se producen en un puerto o interfaz. Los comandos comunes utilizados para encontrar este tipo de información se describen en la sección Comandos de Troubleshooting de Interfaz y Puerto Más Comunes para Cisco IOS de este documento.
Nota: Puede haber diferencias en la implementación de los contadores entre diversas plataformas y versiones. Aunque los valores de los contadores sean en gran medida son exactos, no son muy precisos en cuanto al diseño. Para conocer las estadísticas exactas del tráfico, se sugiere que use un sniffer para monitorear las interfaces de ingreso y egreso necesarias.
Los errores excesivos para ciertos contadores en general indican un problema. Cuando se trabaja en una configuración semidúplex, algunos errores de link de datos aumentan en la Secuencia de verificación de tramas (FCS), la alineación, los fragmentos minúsculos y los contadores de colisión son normales. Generalmente, el índice del uno por ciento de errores del tráfico total es aceptable para las conexiones semidúplex. Si el índice de error a los paquetes de entrada es mayor del dos o tres por ciento, puede observarse una degradación del rendimiento.
En los entornos semidúplexes, es posible para que el switch y el dispositivo conectado detecten el cable y lo transmitan en exactamente el mismo tiempo y resultado en una colisión. Las colisiones pueden causar fragmentos minúsculos, FCS y errores de alineación debido a que la trama no se copió completamente en el cable, lo que resulta en tramas fragmentadas.
Cuando opera en un dúplex completo, los errores en el FCS, las Verificaciones Cíclicas de Redundancia (CRC), la alineación, y los contadores de fragmentos minúsculos deben ser mínimos. Si el link opera en el dúplex completo, el contador de colisiones no está activo. Si se incrementa el FCS, el CRC, la alineación, o los contadores de fragmentos minúsculos, verifique si hay discordancia dúplex. La discordancia dúplex es una situación donde el switch opera en el dúplex completo y el dispositivo conectado opera en el semidúplex, o viceversa. Los resultados de una discordancia dúplex son un rendimiento extremadamente lento, conectividad intermitente, y pérdida de conexión. Otras posibles causas de errores del link de datos en el dúplex completo son cables en malas condiciones, puertos de switch defectuosos, o problemas con el software/hardware NIC. Consulte la sección Problemas Comunes de Puertos e Interfaces de este documento para obtener más información.
El comando show interfaces card-type {slot/port} es el comando utilizado para que Cisco IOS en el Supervisor muestre los contadores de errores y las estadísticas. Una alternativa a este comando (para los switches de las series Catalyst 6000, 4000, 3550, 2970, 2950/2955 y 3750) es el comando show interfaces-type <slot/port>counters errors que sólo muestra los contadores de errores de la interfaz. Consulte la Tabla 1 para obtener explicaciones del resultado del contador de errores.
Nota: Para los switches de la serie 2900/3500XL, utilice el comando show interfaces-type {slot/port} con el comando show controllers Ethernet-controller.
Router#sh interfaces fastEthernet 6/1 FastEthernet6/1 is up, line protocol is up (connected) Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Full-duplex, 100Mb/s input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:14, output 00:00:36, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec
La salida del comando show interfaces hasta este punto se explica aquí (en orden) :
up, line protocol is up (conectado) - La primera up se refiere al estado de la capa física de la interfaz. El mensaje line protocol up muestra el estado de la capa de link de datos de la interfaz y dice que la interfaz puede enviar y recibir señales de mantenimiento.
MTU: la unidad de transmisión máxima (MTU) es de 1500 bytes para Ethernet, de manera predeterminada (para la porción de datos máxima de la trama).
Dúplex completo, 100 Mb/s: dúplex completo y 100 Mbps es la configuración de velocidad y dúplex actual de la interfaz. Esto no indica si se ha utilizado autoneg para lograrlo. Utilice el comando show interfaces fastEthernet 6/1 status para mostrar lo siguiente:
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 connected 1 a-full a-100 10/100BaseTX
!--- Autonegotiation was used to achieve full-duplex and 100Mbps.
Last input, output: el número de horas, minutos, y segundos desde que el paquete más reciente fue recibido o transmitido correctamente por la interfaz. Esto es útil para saber cuándo falló una interfaz inactiva.
Last clearing of "show interface" counters - La última vez que se ejecutó el comando clear counters desde la última vez que se reinició el switch. El comando clear counters se usa para restablecer las estadísticas de la interfaz.
Nota: Las variables que pueden afectar a la ruta (por ejemplo, carga y fiabilidad) no se borran cuando se borran los contadores.
Cola de entrada: el número de paquetes en la cola de entrada.Size/max/drops= el número actual de tramas en la cola / el número máximo de tramas que la cola puede retener antes de que comience a descartar tramas / el número real de tramas descartadas porque se excedió el tamaño máximo de la cola.Flushesis se usa para contar las caídas de descarte selectivo de paquetes (SPD) en la serie Catalyst 6000 que ejecuta Cisco IOS. (El contador de vaciados se puede usar pero nunca se incrementa en la serie Catalyst 40000 que ejecuta Cisco IOS.) SPD es un mecanismo que descarta rápidamente paquetes de baja prioridad cuando la CPU se sobrecarga para save
cierta capacidad de proceso para paquetes de alta prioridad. El contador de purga en el resultado de comando show interface se incrementa como parte del descarte de paquetes selectivos (SPD), que implementa una política para descartar paquetes selectivos en la cola del proceso del IP del router. Por lo tanto, se aplica para procesar solamente el tráfico conmutado.
El propósito del SPD es asegurarse de que los paquetes de control importantes, como actualizaciones de ruteo y keepalives, no se descarten cuando la cola de entrada del IP esté llena. Cuando el tamaño de la cola de entrada del IP se encuentre entre los umbrales mínimos y máximos, se descartan los paquetes normales del IP en función de cierta probabilidad de descarte. Este descarte al azar se denomina purga SPD.
Total output drops - La cantidad de paquetes que se descartan porque la capacidad de la cola de salida está completa. Una causa común es el tráfico de un link de ancho de banda alto que se conmuta a un link de ancho de banda bajo o el tráfico de links entrantes múltiples que se conmutan a un único link saliente. Por ejemplo, si una gran cantidad de flujo de tráfico entra en una interfaz gigabit y se conmuta a una interfaz de 100 Mbps, esto puede hacer que las caídas de salida aumenten en la interfaz de 100 Mbps. Esto ocurre porque la cola de salida en esa interfaz está saturada por el exceso de tráfico debido a la discordancia de velocidad entre los anchos de banda entrante y saliente.
Output queue: el número de paquetes en la cola de salida. Tamaño/máximo significa el número actual de tramas en la cola/el número máximo de tramas que la cola puede contener antes de que esté llena y debe comenzar a descartar las tramas.
Velocidad de entrada y salida en 5 minutos - Velocidad de entrada y salida promedio vista por la interfaz en los últimos cinco minutos. Especifique un período de tiempo más corto para obtener una lectura precisa (para detectar mejor las ráfagas de tráfico, por ejemplo, y ejecute el comando load-interval <seconds>interface.
Vea la Tabla 1para obtener explicaciones del resultado del contador de errores.
!--- ...show interfaces command output continues. 1117058 packets input, 78283238 bytes, 0 no buffer Received 1117035 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 285811 packets output, 27449284 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
Nota: Hay una diferencia entre el contador de salida del comando show interface para una interfaz física y una interfaz VLAN.Los contadores de paquetes de entrada aumentan en la salida de la interfaz deshow para una interfaz VLAN cuando ese paquete es de Capa 3 (L3) procesado por la CPU. El tráfico conmutado de Capa 2 (L2) nunca llega a la CPU y no se cuenta en los contadores de interfaz de show para la interfaz VLAN. Se contaría en la salida de la interfaz show para la interfaz física apropiada.
El comando show interfaces <card-type> <slot/port> counters errorsse utiliza en Cisco IOS para mostrar solamente la salida de los errores de interfaz. Vea la Tabla 1para obtener explicaciones del resultado del contador de errores.
Router#sh interfaces fastEthernet 6/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Fa6/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Fa6/1 0 0 0 0 0 0 0
Tabla 1. La salida del contador de errores del IOS de Cisco para show interfaces orshow interfaces<card-type> <x/y> contrarresta errores para las series Catalyst 6000 y 4000.
Contadores (en orden alfabético) | Problemas y causas comunes que aumentan los contadores de errores |
Align-Err |
Descripción:show interfaces counters errors. Los errores de alineación son una cuenta del número de tramas recibidas que no terminan con un número par de octetos y tienen una mala Verificación por redundancia cíclica (CRC).Causas comunes:Estos son generalmente el resultado de una discordancia dúplex o un problema físico (como cableado, un puerto incorrecto o una NIC incorrecta). Cuando el cable primero está conectado con el puerto, pueden presentarse algunos de estos errores. Además, si hay un hub conectado al puerto, las colisiones entre otros dispositivos en el hub pueden causar estos errores.Excepciones de plataforma:Los errores de alineación no se cuentan en el Supervisor I (WS-X4012) o Supervisor II (WS-X4013) de Catalyst serie 4000. |
balbuceos |
Descripción: el contador show interfaces indica que el temporizador jabber de transmisión expiró. Un jabber es una trama de más de 1518 octetos (que excluyen bits de trama, pero incluyen octetos FCS), que no termina con un número par de octetos (error de alineación) o tiene un error FCS incorrecto. |
Carri-Sen |
Descripción:show interfaces counters errors. El contador Carri-Sen (detección de portadora) se incrementa cada vez que un controlador Ethernet desea enviar datos en una conexión semidúplex. El controlador detecta el cable y verifica si no está ocupado antes de transmitir.Causas comunes:Esto es normal en un segmento Ethernet semidúplex. |
colisiones |
Descripciones:show interfacescounter. La cantidad de veces que ocurrió una colisión antes de que la interfaz transmitiera una trama a los medios exitosamente.Causas comunes:Las colisiones son normales para las interfaces configuradas como semidúplex pero no deben verse en las interfaces dúplex completo. Si las colisiones aumentan significativamente, hay un enlace que se usa demasiado o posiblemente una discordancia dúplex con el dispositivo adjunto. |
CRC |
Descripción:show interfacescounter. Esto aumenta cuando la CRC generada por la estación LAN o el dispositivo de extremo lejano que origina el tráfico no coincide con la suma de comprobación calculada a partir de los datos recibidos.Causas comunes:Esto generalmente indica problemas de ruido o transmisión en la interfaz LAN o la propia LAN. Un elevado número de CRC se produce por lo general como resultado de las colisiones pero también pueden indicar un problema físico (como cableado, mala interfaz o tarjeta de interfaz de red [NIC]) o un desajuste bidireccional. |
diferido |
Descripción:show interfacescounter. El número de tramas que se han transmitido correctamente después de esperar porque el medio estaba ocupado.Causas comunes:Esto se ve generalmente en entornos semidúplex donde el operador ya está en uso cuando intenta transmitir una trama. |
pause input |
Descripción:show interfacescounter. Un incremento en el contador de entrada de pausa significa que el dispositivo conectado solicita una pausa de tráfico cuando su buffer de recepción está casi lleno.Causas comunes:Este contador se incrementa para fines informativos ya que el switch acepta la trama. La petición de detener los paquetes se anula cuando el dispositivo conectado está en condiciones de recibir tráfico. |
paquetes de entrada con condición de goteo |
Descripción:show interfacescounter. Un error de bit de goteo indica que una trama es ligeramente demasiado larga.Causas comunes:Este contador de errores de trama se incrementa para fines informativos, ya que el switch acepta la trama. |
Excess-Col |
Descripción: show interfaces counters errors. Recuento de tramas cuya transmisión en una interfaz determinada falla debido a un exceso de colisiones. Se produce una colisión excesiva cuando un paquete colisiona 16 veces seguidas. De esta manera, el paquete deja de transmitirse. Causas comunes: Las colisiones excesivas son típicamente una indicación de que la carga en el segmento necesita ser dividida a través de varios segmentos pero también pueden apuntar a una discordancia dúplex con el dispositivo conectado. Las colisiones no se deben considerar en las interfaces configuradas como dúplex completo. |
FCS-Err |
Descripción: show interfaces counters errors. El número de tramas de tamaño válido con errores de Secuencia de comprobación de tramas (FCS) pero sin errores de trama. Causas comunes: esto suele ser un problema físico (como el cableado, un puerto incorrecto o una tarjeta de interfaz de red (NIC) incorrecta), pero también puede indicar una discordancia dúplex. |
trama |
Descripción: show interfaces counter. El número de paquetes que se recibió de forma incorrecta con un error CRC y un número no entero de octetos (error de alineación). Causas comunes: esto suele ser el resultado de colisiones o de un problema físico (como cableado, puerto defectuoso o NIC), pero también puede indicar una discordancia dúplex. |
Gigantes |
Descripción: show interfaces y show interfaces counters errors. Las tramas recibidas que excedieron el tamaño máximo de trama IEEE 802.3 (1518 bytes para Ethernet no jumbo) y cuentan con una Secuencia de Verificación de Tramas (FCS) mala. Causas comunes: En muchos casos, esto es el resultado de una NIC incorrecta. Intente encontrar el dispositivo con problemas y retírelo de la red. Excepciones de plataforma: Catalyst Cat4000 Series que ejecuta Cisco IOS Antes de la versión de software 12.1(19)EW, el contador de gigantes aumentaba para una trama > 1518 bytes. Después de 12.1(19)EW, un gigante en show interfaces aumenta solamente cuando se recibe una trama >1518 bytes con un FCS incorrecto. |
ignorado |
Descripción: sh interfaces counter. La cantidad de paquetes recibidos e ignorados por la interfaz porque el hardware de la interfaz no fue suficiente en los búferes internos. Causas comunes: las tormentas de difusión y las ráfagas de ruido pueden hacer que el recuento ignorado aumente. |
Errores de Entrada |
Descripción: contador show interfaces. Causas comunes: esto incluye fragmentos minúsculos, gigantes, sin búfer, CRC, trama, desbordamiento y recuentos ignorados. Otros errores relacionados con la entrada hacen aumentar el contador de errores de entrada y algunos datagramas pueden tener más de un error. Por lo tanto, esta suma no puede equilibrar con la suma de conteos enumerados de error de entrada. También consulte la sección Errores de Entrada en una Iterfaz Capa 3 Conectada a un Switchport Capa 2. |
Coronel fallecido |
Descripción: show interfaces y show interfaces counters errors. La cantidad de veces que se detecta una colisión en una interfaz determinada en la etapa tardía del proceso de transmisión. Para un puerto de 10 Mbit/s esto es posterior a 512 bits-veces en la transmisión de un paquete. 512 veces bits corresponde a 51.2 microsegundos en un sistema de 10 Mbit/s. Causas Comunes: Este error puede indicar una discordancia dúplex entre otras cosas. Para el escenario de discordancia dúplex, la colisión tardía se ve en el lado semidúplex. A medida que el lado semidúplex transmite, el lado dúplex completo no espera su turno y transmite simultáneamente lo que causa una colisión tardía. Las colisiones tardías también pueden indicar que un cable Ethernet o un segmento es demasiado largo. Las colisiones no se deben considerar en las interfaces configuradas como dúplex completo. |
lost carrier |
Descripción: contador show interfaces. El número de veces que la portadora se ha perdido durante la transmisión. Causas comunes: Compruebe si hay un cable defectuoso. Compruebe la conexión física en ambos lados. |
Multi-Col |
Descripción: show interfaces counters errors. La cantidad de veces que se produjeron colisiones múltiples antes de que la interfaz transmitiera una trama a los medios de manera exitosa. Causas comunes: Las colisiones son normales para las interfaces configuradas como semidúplex pero no deben verse en las interfaces dúplex completo. Si las colisiones aumentan significativamente, hay un enlace que se usa demasiado o posiblemente una discordancia dúplex con el dispositivo adjunto. |
no buffer |
Descripción:contador show interfaces. El número de paquetes recibidos descartados porque no hay espacio en el búfer.Causas comunes:Compare con el recuento ignorado. Las tormentas de difusión pueden ser responsables de esta situación. |
sin portadora |
Descripción:show interfacescounter. La cantidad de veces que la portadora no estuvo presente en la transmisión.Causas comunes:Verifique si hay un cable defectuoso. Compruebe la conexión física en ambos lados. |
Out-Discard |
Descripción:El número de paquetes salientes elegidos para ser descartados aunque no se hayan detectado errores.Causas comunes:Una posible razón para descartar un paquete de este tipo puede ser liberar espacio en el búfer. |
output buffer failures output buffers swapped out |
Descripción:show interfacescounter. La cantidad de búferes fallidos y la cantidad de búferes intercambiados.Causas comunes:Un puerto almacena en búfer los paquetes en el búfer Tx cuando la velocidad del tráfico conmutado al puerto es alta y no puede manejar la cantidad de tráfico. Los puertos empiezan a descartar paquetes cuando el búfer Tx está lleno, lo que aumenta los contadores de agotamiento y de errores en el buffer de salida. El aumento de los contadores de errores del buffer de salida podría indicar que los puertos tienen un ajuste inferior de velocidad o dúplex, o que hay demasiado tráfico en el puerto. Como ejemplo, supóngase una situación en que se reenvía un flujo de multicast de 1 gig a 24 puertos de 100 Mbps. Si una interfaz de egreso tiene un exceso de suscriptores, sería normal ver que los errores del búfer de salida aumentan junto con Out-Discards. Para obtener información sobre la resolución de problemas, consulte la sección Tramas Diferidas (Out-Lost o Out-Discard) de este documento. |
errores de salida |
Descripción:show interfacescounter. Suma de todos los errores que impidieron la transmisión final de datagramas fuera de la interfaz.Causa común:Este problema se debe al bajo tamaño de la cola de salida. |
desbordamiento |
Descripción:La cantidad de veces que el hardware del receptor no pudo entregar los datos recibidos a un buffer de hardware.Causa común:La velocidad de entrada de tráfico excedió la capacidad del receptor para manejar los datos. |
packets input/output |
Descripción:show interfacescounter. El total de paquetes sin errores recibidos y transmitidos en la interfaz. Supervise estos contadores en busca de incrementos, ya que es útil para determinar si el tráfico fluye correctamente a través de la interfaz. El contador de bytes incluye tanto los datos como la encapsulación MAC de los paquetes libres de errores recibidos y transmitidos por el sistema. |
Rcv-Err |
Descripción: Sólo para Catalyst 6000 Series - show interfaces counters error.Causas comunes:Vea Excepciones de Plataforma.Excepciones de Plataforma:Catalyst 5000 Seriesrcv-err = receive buffer failures. Por ejemplo, un fragmento minúsculo, un fragmento gigante o un error de no aumentarán el contador rcv-err. El contador rcv-err en un 5K aumenta solamente como resultado de un exceso de tráfico. OnCatalyst 4000 Series rcv-err = la suma de todos los errores de recepción, lo que significa, a diferencia de Catalyst 5000, que el contador rcv-err aumenta cuando la interfaz recibe un error como un fragmento minúsculo, un fragmento gigante o un error FCS. |
Fragmentos minúsculos |
Descripción:show interfaces and show interfaces counters errors. Las tramas recibidas que son más pequeñas que el tamaño mínimo de trama IEEE 802.3 (64 bytes para Ethernet) y con una CRC incorrecta.Causas comunes:Esto puede deberse a una discordancia dúplex y problemas físicos, como un cable, puerto o NIC incorrectos en el dispositivo conectado.Excepciones de plataforma:Catalyst serie 4000 que ejecuta Cisco IOSPreviso a la versión de software 12.1(19)EW, un fragmento minúsculo = tamaño inferior al normal. Tamaño inferior al normal = trama < 64 bytes. El contador de fragmentos minúsculos se incrementaba solamente si se recibía una trama inferior a 64 bytes. A partir de la versión 12.1(19)EW, un fragmento minúsculo = un fragmento. Un fragmento es una trama < 64 bytes pero con una CRC errónea. El resultado es que el contador de fragmentos minúsculos ahora se incrementa en show interfaces, junto con el contador de fragmentos inshow interfaces counters errorscuando se recibe una trama <64 bytes con un CRC incorrecto.Cisco Catalyst 3750 Series SwitchesEn versiones anteriores a Cisco IOS 12.1(19)EA1, cuando se utiliza dot1q en la interfaz troncal en Catalyst 3750, los fragmentos minúsculos pueden verse onshow interfaces output porque los paquetes encapsulados dot1q válidos, que son 61 a 61 a 6 Catalyst 3750 cuenta los 4 bytes e incluye la etiqueta q como tramas de tamaño inferior al normal, aunque estos paquetes se reenvíen correctamente. Además, estos paquetes no se informan en la categoría adecuada (unicast, multicast, o broadcast) en las estadísticas de recepción. Este problema se resuelve en Cisco IOS release 12.1(19)EA1 o 12.2(18)SE o posterior. |
Col. Única |
Descripción:show interfaces counters errors. La cantidad de veces que se produjo una colisión antes de que la interfaz transmitiera una trama a los medios exitosamente.Causas comunes:Las colisiones son normales para las interfaces configuradas como semidúplex pero no se deben ver en las interfaces dúplex completo. Si las colisiones aumentan significativamente, hay un enlace que se usa demasiado o posiblemente una discordancia dúplex con el dispositivo adjunto. |
aceleradores |
Descripción:show interfaces. La cantidad de veces que el receptor del puerto ha sido inhabilitado, posiblemente debido a una sobrecarga del buffer o procesador. Si aparece un asterisco (*) después del valor del contador de aceleradores, significa que la interfaz está regulada en el momento en que se ejecuta el comando.Causas comunes:Los paquetes que pueden aumentar la sobrecarga del procesador incluyen paquetes IP con opciones, TTL caducado, encapsulación no ARPA, fragmentación, túneles, paquetes ICMP, paquetes con falla de checksum MTU, falla RPF, errores de checksum IP y de longitud. |
sobrecama |
Descripción:El número de veces que el transmisor ha estado funcionando más rápido de lo que el switch puede manejar.Causas comunes: Esto puede ocurrir en una situación de alto rendimiento donde una interfaz es golpeada con un alto volumen de ráfagas de tráfico de muchas otras interfaces a la vez. Los restablecimientos de la interfaz pueden producirse con desbordamientos. |
Tamaño menor al normal |
Descripción:show interfaces counters errors . Las tramas recibidas que son más pequeñas que el tamaño mínimo de trama IEEE 802.3 de 64 bytes (que excluye bits de trama pero incluye octetos FCS) y que, por lo demás, están bien formadas.Causas comunes:Verifique el dispositivo que envía estas tramas. |
Xmit-Err |
Descripción:show interfaces counters errors. Ésta es una indicación de que el buffer de envío interno (Tx) está lleno.Causas comunes:Una causa común de Xmit-Err puede ser el tráfico de un link de ancho de banda alto que se conmuta a un link de ancho de banda bajo, o el tráfico de links entrantes múltiples que se conmutan a un único link saliente. Por ejemplo, si una gran cantidad de ráfagas de tráfico entra en una interfaz gigabit y se conmuta a una interfaz de 100 Mbps, esto puede hacer que Xmit-Err aumente en la interfaz de 100 Mbps. Esto ocurre porque el buffer de salida en esa interfaz está saturada por el exceso de tráfico debido a la asimetría de la velocidad entre los anchos de banda entrante y saliente. |
Para supervisar el tráfico entrante y saliente en el puerto tal y como se muestra en la siguiente salida, para el tráfico de unidifusión, multidifusión y difusión. El comando show interfaces card-type {slot/port}counters se utiliza cuando ejecuta Cisco IOS en el Supervisor.
Nota: Existe un contador Out-Discard en el comando IOSshow interfaces counters errors que se explica en la Tabla 1.
Router#sh interfaces fas 6/1 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Fa6/1 47856076 23 673028 149 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Fa6/1 22103793 17 255877 3280 Router#
!--- Cisco IOS counters used to monitor inbound and outbound unicast, multicast !--- and broadcast packets on the interface.
El comando show counters interfacecard-type {slot/port}se introdujo en la versión 12.1(13)E del software del IOS de Cisco sólo para la serie Catalyst 6000, y ofrece estadísticas aún más detalladas para los puertos y las interfaces. Este comando muestra los contadores de errores de 32 y 64 bits por puerto o interfaz.
Para los switches Catalyst 3750, 3550, 2970, 2950/2955, 2940, y 2900/3500XL, utilice el comando show controller ethernet-controller para mostrar la salida del contador de tráfico y del contador de errores que es similar a la salida para los switches Catalyst 6000 Series.
3550-1#show controller ethernet-controller fastEthernet 0/1 !--- Output from a Catalyst 3550. Transmit FastEthernet0/1 Receive 0 Bytes 0 Bytes 0 Unicast frames 0 Unicast frames 0 Multicast frames 0 Multicast frames 0 Broadcast frames 0 Broadcast frames 0 Discarded frames 0 No dest, unicast 0 Too old frames 0 No dest, multicast 0 Deferred frames 0 No dest, broadcast 0 1 collision frames 0 2 collision frames 0 FCS errors 0 3 collision frames 0 Oversize frames 0 4 collision frames 0 Undersize frames 0 5 collision frames 0 Collision fragments 0 6 collision frames 0 7 collision frames 0 Minimum size frames 0 8 collision frames 0 65 to 127 byte frames 0 9 collision frames 0 128 to 255 byte frames 0 10 collision frames 0 256 to 511 byte frames 0 11 collision frames 0 512 to 1023 byte frames 0 12 collision frames 0 1024 to 1518 byte frames 0 13 collision frames 0 14 collision frames 0 Flooded frames 0 15 collision frames 0 Overrun frames 0 Excessive collisions 0 VLAN filtered frames 0 Late collisions 0 Source routed frames 0 Good (1 coll) frames 0 Valid oversize frames 0 Good(>1 coll) frames 0 Pause frames 0 Pause frames 0 Symbol error frames 0 VLAN discard frames 0 Invalid frames, too large 0 Excess defer frames 0 Valid frames, too large 0 Too large frames 0 Invalid frames, too small 0 64 byte frames 0 Valid frames, too small 0 127 byte frames 0 255 byte frames 0 511 byte frames 0 1023 byte frames 0 1518 byte frames 3550-1#
!--- See the next table for additional counter output for 2900/3500XL Series switches.
Contador | Descripción | Posibles Causas |
Tramas Transmitidas |
||
Tramas descartadas |
La cantidad total de tramas cuyo intento de transmisión se abandonó debido a una insuficiencia de recursos. Este total incluye tramas de todos los tipos de destinos. |
La carga de tráfico en la interfaz es excesiva, por lo que se descartan tramas. Reduzca la carga de tráfico en la interfaz si hay incrementos en el número de paquetes en este campo. |
Tramas demasiado antiguas |
Número de tramas que tardaron más de dos segundos en pasar a través del switch. Por esta razón, fueron descartados por el switch. Esto solo ocurriría en condiciones extremas de mucha intensidad. |
La carga de tráfico para este switch es excesiva y hace que las tramas sean descartadas. Reduzca la carga del switch si el número de paquetes en este campo aumenta. Es posible que sea necesario modificar la topología de la red para reducir la carga de tráfico de este switch. |
Tramas diferidas |
La cantidad total de tramas cuyo primer intento de transmisión se retrasó debido al tráfico en el dispositivo de red. Este total incluye solamente las tramas que se transmiten posteriormente sin errores y no se ven afectadas por colisiones. |
La carga de tráfico destinada a este switch es excesiva, por lo que se descartan tramas. Reduzca la carga del switch si el número de paquetes en este campo aumenta. Es posible que sea necesario modificar la topología de la red para reducir la carga de tráfico de este switch. |
Tramas de colisión |
Los contadores de tramas de colisión son el número de veces que se intentó transmitir un paquete pero no fue exitoso pero fue exitoso en su siguiente intento. Esto significa que si el contador2 collision frames aumentó, el switch ha intentado enviar el paquete dos veces sin éxito pero lográndolo en el tercer intento. |
La carga de tráfico en la interfaz es excesiva, por lo que se descartan tramas. Reduzca la carga de tráfico en la interfaz si observa que el número de paquetes aumenta en estos campos. |
Colisiones excesivas |
El contador de colisiones excesivas aumenta cuando se han producido 16 colisiones tardías consecutivas. Después de 16 intentos de enviar el paquete, la trama se descartará y aumentará el contador. |
El aumento de este contador indica un problema de cableado, una red demasiado cargada o una discordancia de dúplex. Una red demasiado cargada podría ser resultado de un exceso de dispositivos en una Ethernet compartida. |
Colisiones tardías |
Una colisión tardía se produce cuando dos dispositivos transmiten al mismo tiempo y ningún punto 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 cada uno envía hasta después de que ponga el paquete completo 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. |
Las colisiones tardías son el resultado de un cableado incorrecto o de un número no soportado de hubs en la red. Las NIC defectuosas también pueden provocar colisiones tardías. |
Tramas adecuadas (1 colisión) |
El número total de tramas que experimentan exactamente una colisión y posteriormente se transmiten satisfactoriamente. |
Las colisiones en los entornos semidúplex son normales. |
Tramas adecuadas (> 1 colisión) |
El número total de tramas que experimentan entre 2 y 15 colisiones, inclusive, y posteriormente se transmiten satisfactoriamente. |
Las colisiones en los entornos semidúplex son normales. Las tramas que se incrementan en el extremo superior de este contador pueden exceder las 15 colisiones y se pueden contar como colisiones excesivas. |
Tramas descartadas VLAN |
El número de tramas descartadas en una interfaz porque el bit CFI está definido. |
El bit del Indicador de Formato Canónico (CFI) en el TCI de una trama 802.1q está definido en 0 en el formato de trama canónico de Ethernet. Si el bit CFI está definido en 1, esto indica la presencia de una trama no canónica RIF (Campo de Información de Enrutamiento) o Token Ring que se descarta. |
Tramas Recibidas |
||
No bandwidth frames |
2900/3500XL solamente.La cantidad de veces que un puerto recibió un paquete de la red, pero el switch no tenía los recursos para recibirlo. Esto sucede solamente en condiciones de tensión, pero puede suceder con ráfagas de tráfico en varios puertos. Por lo tanto, un número pequeño en el campo No bandwidth frames no es motivo de preocupación. (Aún así debería ser mucho menos del uno por ciento de las tramas recibidas). |
La carga de tráfico en la interfaz es excesiva, por lo que se descartan tramas. Reduzca la carga de tráfico en la interfaz si observa que el número de paquetes aumenta en estos campos. |
No buffers frames |
2900/3500XL solamente.La cantidad de veces que un puerto recibió un paquete de la red, pero el switch no tenía los recursos para recibirlo. Esto sucede solamente en condiciones de tensión, pero puede suceder con ráfagas de tráfico en varios puertos. Por lo tanto, una pequeña cantidad de No buffers frames no es motivo de preocupación. (Aún así debería ser mucho menos del uno por ciento de las tramas recibidas). |
La carga de tráfico en la interfaz es excesiva, por lo que se descartan tramas. Reduzca la carga de tráfico en la interfaz si observa que el número de paquetes aumenta en estos campos. |
No dest, unicast |
No destination unicast es el número de paquetes unicast que el puerto no envió a cualquier otro puerto. |
Las siguientes son descripciones breves de situaciones en las que los contadores No dest, (unicast, multicast, y broadcast) pueden incrementarse:
|
No dest, multicast |
No destination multicast es la cantidad de paquetes multicast que el puerto no reenvió a cualquier otro puerto. |
|
No dest, broadcast |
No destination broadcast es la cantidad de paquetes broadcast que el puerto no reenvió a cualquier otro puerto. |
|
Errores de alineación |
Los errores de alineación son el número de tramas recibidas que no terminan con un número par de octetos y tienen una CRC defectuosa. |
Los errores de alineación se deben a que la trama no se copia completamente en el cable, lo que resulta en tramas fragmentadas. Los errores de alineación son el resultado de colisiones en semidúplex, una discordancia dúplex, hardware incorrecto (NIC, cable o puerto) o dispositivos conectados que generan tramas que no terminan en un octeto y tienen un FCS incorrecto. |
Errores de FCS |
El error de conteo FCS es el número de tramas que se recibieron con una checksum incorrecta (valor CRC) en la trama Ethernet. Estas tramas se pierden y no se propagan en otros puertos. |
Los errores FCS son el resultado de colisiones en semidúplex, una discordancia dúplex, hardware incorrecto (NIC, cable o puerto) o dispositivos conectados que generan tramas que no terminan con un octeto y tienen un FCS incorrecto. |
Tramas de tamaño inferior al normal |
Estos son el número total de paquetes recibidos que tenían menos de 64 octetos de largo (que excluye bits de trama pero incluye FCS) y tienen un buen valor FCS. |
Esta es una indicación de una trama deficiente generada por el dispositivo conectado. Verifique que el dispositivo conectado funcione correctamente. |
Tramas de gran tamaño |
Número de paquetes recibidos en el puerto desde la red, donde los paquetes tenían más de 1514 bytes. |
Es una indicación de hardware defectuoso, dot1q o un problema de configuración ISL. |
Fragmentos de la colisión |
Número total de tramas cuya longitud es inferior a 64 octetos (que excluye bits de trama, pero incluye FCS) y tienen un valor FCS incorrecto. |
El aumento del contador indica que los puertos están configurados en semidúplex. Establezca el dúplex en dúplex completo. |
Tramas de desbordamiento |
La cantidad de veces que el hardware de recepción no pudo entregar los datos recibidos a un buffer de hardware. |
La velocidad de entrada de tráfico excedió la capacidad del receptor de manejar los datos. |
Tramas filtradas VLAN |
La cantidad total de tramas filtradas debido al tipo de información VLAN que contiene la trama. |
El puerto se puede configurar para filtrar las tramas etiquetadas 802.1Q. Cuando se recibe una trama que contiene una etiqueta 802.1Q, la trama se filtra y aumenta este contador. |
Tramas de origen ruteadas |
El número total de tramas de recepción que se descartan debido a la situación de que el bit de ruta de origen está configurado en la dirección de origen de la trama nativa. |
Este tipo de enrutamiento de origen solo se define para Token Ring y FDDI. La especificación Ethernet de IEEE prohíbe este bit en las tramas Ethernet. Por lo tanto, el switch desecha tales tramas. |
Tramas de gran tamaño válidas |
El número total de tramas recibidas cuya longitud excede la MTU del sistema, pero que tienen buenos valores de FCS. |
Esta estadística cuenta las tramas que exceden la MTU del sistema configurada, pero que se pueden haber aumentado de 1518 bytes para permitir las encapsulaciones Q-in-Q o MPLS. |
Tramas de error de símbolo |
Gigabit Ethernet (1000 Base-X) utiliza la codificación 8B/10B para traducir los datos 8bit de la subcapa MAC (capa 2) a un símbolo de 10 bit para enviar por cable. Cuando un puerto recibe un símbolo, extrae los datos de 8 bits del símbolo (10 bits). |
Un error de símbolo significa que la interfaz detecta un símbolo indefinido recibido (inválido). Puede ignorarse una pequeña cantidad de errores de símbolos. Una gran cantidad de errores de símbolo puede indicar un dispositivo, cable, o hardware desfectuoso. |
Tramas inválidas, demasiado grandes |
Las tramas gigantes o las tramas recibidas que excedieron el tamaño máximo de trama IEEE 802.3 (1518 bytes para Ethernet no jumbo) y cuentan con una Secuencia de Verificación de Tramas (FCS) defectuosa. |
En muchos casos, este es el resultado de un NIC defectuoso. Intente encontrar el dispositivo con problemas y retírelo de la red. |
Tramas inválidas, demasiado pequeñas |
Las tramas minúsculas o las tramas recibieron que son inferiores a 64 bytes (que incluye los bits FCS y excluye el encabezado de trama) y tienen un error FCS o un error de alineación. |
Esto puede estar causado por una discordancia dúplex y problemas físicos, como un cable, un puerto o una NIC incorrectos en el dispositivo conectado. |
Para el formato de mensajes del sistema Cisco IOS, puede consultar la Guía de Mensajes y Procedimientos de Recuperación para la versión del software que ejecuta. Por ejemplo, puede ver losMensajes y Procedimientos de Recuperación para las Versiones de Cisco IOS.
Este mensaje de error aparece cuando se transmite una trama, y el buffer local del chip del controlador del buffer local no recibe suficientes datos. Los datos no se pueden transferir al chip lo suficientemente rápido para ajustarse a la velocidad de salida. Normalmente, esa condición es temporal, según las cargas pico transitorias dentro del sistema. El problema ocurre cuando una cantidad excesiva de tráfico es procesada por la interfaz Fast Ethernet. Se recibe el mensaje de error cuando el nivel de tráfico alcanza aproximadamente 2.5 Mb. Esta restricción del nivel de tráfico se debe a la limitación del hardware. Debido a esto, existe la posibilidad de que el dispositivo conectado al switch de catalyst descarte paquetes.
La resolución por lo general es que el sistema se recupera de forma automática. No se requiere ninguna acción. Si el switch sobrecarga la interfaz Ethernet, verifique la configuración de velocidad y dúplex. Además, utilice un programa sabueso para analizar los paquetes que entran y salen de la interfaz Fast Ethernet del router. Para evitar caídas de paquetes en el dispositivo conectado al switch Catalyst, ejecute el comando ip cef en la interfaz Fast Ethernet del dispositivo conectado al switch.
La razón de este mensaje de error es la recepción de un paquete del switch fabric, donde el valor de CRC en el encabezado del entramado en ese paquete no se correspondió con el valor de CRC calculado por el subbloque del Controlador de Interfaz de Entramado (FIC) de Blackwater ASIC. Esto indica que una corrupción del paquete se produjo dentro de la transferencia, y Blackwater recibió el paquete corrupto.
En los switches que soportan interfaces L3 y L2 switchport, el mensaje "Comando rechazado: [interfaz] no es un puerto de conmutación" aparece cuando intenta ingresar un comando relacionado con la capa 2 en un puerto que está configurado como una interfaz de capa 3.
Para convertir la interfaz del modo de capa 3 al modo de capa 2, ejecute el comando de configuración de interfaz switchport. Después de que ejecute este comando, configure el puerto para cualquier propiedad de capa 2.
Una causa obvia pero que a veces se ignora de la falla en la conectividad del puerto es la configuración incorrecta en el switch. Si un puerto tiene una luz naranja permanente, significa que el software dentro del switch apaga el puerto, por la interfaz de usuario o por los procesos internos.
Nota: Algunos LED de puertos de la plataforma funcionan de manera diferente con respecto al STP. Por ejemplo, el Catalyst 1900/2820 cambia el color naranja de los puertos cuando están en modo de bloque STP. En este caso, una luz naranja puede indicar las funciones normales del STP. El Catalyst 6000/4000 no muestra el puerto de color naranja cuando bloquea el STP.
Asegúrese de que el puerto o el módulo no se ha inhabilitado ni se ha apagado por alguna razón. Si un puerto o un módulo se apaga manualmente en un lado del link o el otro, el link no se activa hasta que rehabilita el puerto. Revise el estado del puerto en ambos lados. Utilice el comando show run interfacecommand y verifique si la interfaz está en ashutdownstate:
Switch#show run interface fastEthernet 4/2 ! interface FastEthernet4/2 switchport trunk encapsulation dot1q switchport mode trunk shutdown duplex full speed 100 end
!--- Use the no shut command in config-if mode to re-enable this interface.
Si el puerto entra en modo apagado inmediatamente después de un reinicio del switch, la causa probable es la configuración de seguridad del puerto. Si la inundación de unicast está habilitada en ese puerto, puede hacer que el puerto se apague después de un reinicio. Cisco recomienda que inhabilite la inundación de unicast porque también garantiza que no se produzca inundación en el puerto una vez que se alcanza el límite de la dirección MAC
De forma predeterminada, los procesos de software dentro del switch pueden apagar o interconectar un puerto si se detectan ciertos errores.
Cuando vea el comando show interfacecard-type {slot/port}status para Cisco IOS:
Router#show interface fastethernet 2/4 status Port Name Status Vlan Duplex Speed Type Gi2/4 err-disabled 1 full 1000 1000BaseSX
!--- The show interfaces card-type {slot/port} status command for Cisco IOS !--- displays a status of errdisabled. !--- The show interfaces status errdisabled command shows all the interfaces !--- in this status.
El comando show logging para Cisco IOS también muestra los mensajes de error (el formato exacto de los mensajes varía) que se relacionan con el estado errdisable.
Cuando los puertos o los entrelazados se cierran como resultado de errdisable se conocen como causas en Cisco IOS. Las causas de este rango van desde la configuración incorrecta de EtherChannel que causa una inestabilidad de PAgP, discordancia dúplex, protección de puerto BPDU y portfast configurados al mismo tiempo, UDLD que detecta un link unidireccional, y así sucesivamente.
Tiene que volver a habilitar manualmente o interconectar el puerto para sacarlo del estado errdisable a menos que configure una opción de recuperación errdisable. En el software Cisco IOS, tiene la capacidad de volver a habilitar automáticamente un puerto después de una cantidad configurable de tiempo pasado en el estado errdisable. Lo importante es que incluso si configura la interfaz para recuperarse del errdisable, el problema vuelve a aparecer hasta que se determine la causa raíz.
Nota: Utilice este estado de puerto de recuperación de errdisable en plataformas Cisco IOS para obtener más información sobre el estado de errdisable en switches que ejecutan Cisco IOS.
Esta tabla muestra un ejemplo de los comandos utilizados para configurar verify y resolver problemas del estado errdisable en los switches. Navegue hasta el link para obtener más información sobre los comandos Recover Errdisable Port State on Cisco IOS Platforms:
Acción | Comandos errdisable de Cisco IOS |
---|---|
Configurar | errdisable detect cause |
Configurar | errdisable recovery cause |
Configurar | errdisable recovery interval <timer_interval_in_seconds> |
verificar y resolver problemas | show errdisable detect |
verificar y resolver problemas | show interfaces status err-disabled |
Una causa común de los puertos inactivos en los switches que ejecutan Cisco IOS es cuando desaparece la VLAN a la que pertenecen. Esto puede ocurrir cuando las interfaces se configuran como puertos de switch de capa 2 que utilizan el comando switchport.
Cada puerto en un switch de Capa 2 pertenece a una VLAN. Cada puerto en un switch de capa 3 configurado para ser un puerto de switch L2 también debe pertenecer a una VLAN. Si se elimina esa VLAN, el puerto o la interfaz se vuelve inactiva.
Nota: Algunos switches muestran una luz naranja fija (ámbar) en cada puerto cuando esto sucede.
Utilice el comando show interfacescard-type {slot/port}switchport junto con show vlanto verify.
Router#show interfaces fastEthernet 4/47 switchport Name: Fa4/47Switchport: Enabled Administrative Mode: static access Operational Mode: static access Administrative Trunking Encapsulation: negotiate Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 11 ((Inactive))
!--- FastEth 4/47 is inactive. Router#show vlan VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Gi1/1, Gi2/1, Fa6/6 10 UplinkToGSR's active Gi1/2, Gi2/2
!--- VLANs are displayed in order and VLAN 11 is not available.
30 SDTsw-1ToSDTsw-2Link active Fa6/45
Si el switch que eliminó la VLAN es un servidor VTP para el dominio VTP, se eliminará también la VLAN de todos los switches servidor y cliente del dominio en su tabla VLAN. Cuando agrega la VLAN nuevamente dentro de la tabla de VLAN de un switch del servidor VTP, los puertos de los switches en el dominio que pertenecen a esa VLAN restaurada se activan nuevamente. Un puerto recuerda qué VLAN se asigna, incluso si se elimina la VLAN en sí. Consulte Comprensión y Configuración del VLAN Trunk Protocol (VTP)para obtener más información sobre VTP.
Nota: Si la salida del comando show interface <interface> switchport visualiza el puerto como puerto trunk incluso después de configurar el puerto como puerto de acceso con el comando witchport access vlan <vlan>, ejecute el comando the switchport mode accesscommand para hacer del puerto un puerto de acceso.
En un Catalyst 4510R series switch, para habilitar los puertos de uplink SFP 10-Gigabit Ethernet o Gigabit Ethernet, existe una configuración opcional: Para habilitar el uso simultáneo de las interfaces SFP de 10 Gigabit Ethernet y Gigabit Ethernet, ejecute el comando hw-module uplink select all. Después de ejecutar el comando, reinicie el switch o, de lo contrario, la salida del comando show interface status module <module number> muestra el puerto de link ascendente como inactivo.
El Cisco IOS Software Release 12.2(25)SG soporta el uso simultáneo de las interfaces 10-Gigabit Ethernet y Gigabit Ethernet SFP en los switches Catalyst 4500.
Nota: En los switches Catalyst de las series 4503, 4506 y 4507R, esta capacidad se habilita automáticamente.
El problema se debe a que la carga de tráfico destinada al switch es excesiva y hace que se descarten tramas. Normalmente, las tramas diferidas son el número de tramas transmitidas con éxito después de esperar que el dispositivo dejara de estar ocupado. Esto se observa generalmente en entornos semidúplex donde la portadora ya está en uso cuando intenta transmitir una trama. Pero en los entornos de dúplex completo, el problema ocurre cuando la carga excesiva está destinada para el switch.
Esta es la solución temporal:
Ajustar manualmente ambos extremos del enlace a dúplex completo para evitar la discordancia en la negociación.
Cambiar el cable y las conexiones del panel para asegurarse de que no sean defectuosos.
Nota: Si el error de Contador Diferido aumenta en un GigabitEthernet de un Supervisor 720, active la negociación de velocidad en la interfaz como solución alternativa.
Esto ocurre cuando la Lógica de Reconocimiento de Dirección Codificada (EARL) no está habilitada para definir el tiempo de envejecimiento para la VLAN a la cantidad de segundos requerida. En este caso, el tiempo de envejecimiento de la VLAN ya está ajustado a envejecimiento rápido.
Si la VLAN ya se encuentra en envejecimiento rápido, EARL no puede ajustar la VLAN a envejecimiento rápido y se bloquea el proceso definido de temporizador de envejecimiento. El tiempo de envejecimiento CAM predeterminado es de cinco minutos, lo que significa que el switch restablece la tabla de direcciones MAC aprendidas cada cinco minutos. De esta forma, se garantiza que la tabla de direcciones MAC (la tabla CAM) contenga las últimas entradas.
El envejecimiento rápido ajusta temporalmente el tiempo de envejecimiento CAM al número de segundos especificado por el usuario y se utiliza junto con el proceso de Notificación de Cambios de Topología (TCN). La idea es que cuando se produce un cambio de topología, este valor es necesario para restablecer la tabla CAM más rápidamente y compensar el cambio en la topología.
Ejecute el comando show cam aging para verificar el tiempo de envejecimiento CAM en el switch. Los TCN y el envejecimiento rápido son muy poco frecuentes. Como consecuencia, el mensaje tiene un nivel de gravedad de 3. Si las VLAN se encuentran a menudo en envejecimiento rápido, investigue la causa del problema.
La causa más común de las TCN es cuando hay clientes PC conectados directamente a un switch. Al encender o apagar la PC, el puerto del switch cambia de estado y el switch empieza el proceso TCN. Esto se debe a que el switch no sabe que el dispositivo conectado es un PC; el switch solo sabe que el puerto ha cambiado el estado.
Para solucionar este problema, Cisco ha creado la función PortFast para los puertos de host. La ventaja de PortFast es que esta función elimina las TCN en los puertos de host.
Nota: PortFast también omite los cálculos del árbol de expansión en el puerto y, por lo tanto, sólo es adecuado para su uso en un puerto host.
Verifique el modo de trunking en cada lado del link. Asegúrese de que ambos lados estén en el mismo modo (ambos trunking con el mismo método: ISL o 802.1q, o ambos no trunking). Si activa el modo trunking (opuesto al modo automático o deseable) para un puerto y el otro puerto tienen el modo de trunking desactivado, no se pueden comunicar. El trunking cambia el formato del paquete. Los puertos deben estar de acuerdo en cuanto al formato que utilizan en el link o no se entienden entre sí.
Para Cisco IOS, utilice el comando show interfacescard-type {mod/port}trunk para verificar la configuración de trunking y la VLAN nativa.
Router#sh interfaces fastEthernet 6/1 trunk Port Mode Encapsulation Status Native vlan Fa6/1 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa6/1 1-4094 !--- Output truncated.
Consulte estos documentos para obtener más información sobre los diversos modos de trunking, pautas y restricciones:
De forma predeterminada, la Unidad Máxima de Transmisión (MTU) de la parte de datos de las tramas Ethernet es de 1500 bytes. Si el tráfico de MTU transmitido supera la MTU soportada, el switch no reenviará el paquete. Además, según el hardware y software, algunas plataformas de switch incrementan los contadores de error de puerto e interfaz como resultado.
Las tramas Jumbo no se definen como parte de la norma IEEE Ethernet y dependen del proveedor. Se podrían definir como las tramas que superan la trama estándar de Ethernet de 1518 bytes (incluido el encabezado de la capa 2 y la Verificación por Redundancia Cclica [CRC]). Los jumbos suelen tener un tamaño de trama mayor, generalmente > 9000 bytes.
Las tramas recibidas que excedieron el tamaño máximo de trama (1518 bytes para Ethernet no jumbo) y cuentan con una FCS mala.
Las tramas Baby Giant son ligeramente mayores que el tamaño máximo de una trama Ethernet. Generalmente se trata de tramas de hasta 1600 bytes de tamaño.
La compatibilidad con los jumbos y los baby giants en los switches Catalyst varía según la plataforma del switch, algunas veces según los módulos dentro del switch. La versión de software también es un factor.
Consulte Configuración del Soporte de Tramas Jumbo/Giant en los Switches Catalyst para obtener más información sobre los requisitos del sistema, configurar y resolver problemas de jumbo y baby giant.
Verifique el dispositivo final con un ping enviado desde el switch conectado directamente primero, luego trabaje hacia atrás puerto por puerto, interfaz por interfaz, trunk por trunk hasta que encuentre el origen del problema de conectividad. Asegúrese de que cada switch pueda ver la dirección MAC del dispositivo final en su tabla de Memoria direccionable por contenido (CAM).
Utilice el comando show mac address-table dynamic o sustituya la palabra clave interface.
Router# show mac-address-table interface fastEthernet 6/3 Codes: * - primary entry vlan mac address type learn qos ports ------+----------------+--------+-----+---+-------------------------- * 2 0040.ca14.0ab1 dynamic No -- Fa6/3
!--- A workstation on VLAN 2 with MAC address 0040.ca14.0ab1 is directly connected !--- to interface fastEthernet 6/3 on a switch running Cisco IOS.
Una vez que sepa que el switch tiene realmente la dirección MAC del dispositivo en la tabla CAM, determine si este dispositivo está en la misma VLAN o en una VLAN diferente desde la que intenta hacer ping.
Si el dispositivo final está en una VLAN diferente de la que intenta hacer ping, se debe configurar un switch o router L3 para permitir que los dispositivos se comuniquen. Compruebe que el direccionamiento L3 en el dispositivo final y en el router/switch L3 esté bien configurado. Compruebe la dirección IP, la máscara de subred, la puerta de enlace predeterminada, la configuración del protocolo de enrutamiento dinámico, las rutas estáticas, etc.
Si las estaciones no pueden comunicarse con sus servidores primarios cuando se conectan a través del switch, el problema puede implicar demoras en el puerto del switch cuando intenta activarse después de que el link de capa física aparezca. En algunos casos, estas demoras pueden alcanzar los 50 segundos. Algunas estaciones de trabajo simplemente no pueden esperar tanto tiempo para encontrar su servidor y luego se dan por vencidas. Estas demoras se deben al STP, las negociaciones de trunking (DTP), y las negociaciones de EtherChannel (PAgP). Todos estos protocolos puede inhabilitarse para los puertos de acceso cuando no son necesarios, de manera que el puerto de switch empezará a reenviar paquetes pocos segundos después de establecer un enlace con el dispositivo vecino.
En Cisco IOS, puede utilizar el comando witchport host para inhabilitar la canalización y para habilitar spanning-tree portfast y el comando witchport nonegotiate para desactivar los paquetes de negociación DTP. Utilice el comando interface-range para hacer esto en varias interfaces a la vez.
Router6k-1(config)#interface range fastEthernet 6/13 - 18 Router6k-1(config-if-range)#switchport Router6k-1(config-if-range)#switchport host switchport mode can be set to access spanning-tree portfast can be enabled channel group can be disabled !--- Etherchannel is disabled and portfast is enabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#switchport nonegotiate !--- Trunking negotiation is disabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#end Router6k-1#
Cisco IOS tiene la opción de utilizar el comando global spanning-tree portfast default para aplicar automáticamente portfast a cualquier interfaz configurada como switchport de acceso de capa 2. Verifique la Referencia de Comando para su versión de software para determinar la disponibilidad de este comando. También puede utilizar el comando spanning-tree portfast por interfaz, pero esto requiere que desactive el trunking y el etherchannel por separado para ayudar a corregir las demoras de inicio de la estación de trabajo.
Nota: Refiérase a Uso de Portfast y Otros Comandos para Corregir los Retrasos de Conectividad de Inicio de la Estación de Trabajo para obtener más información sobre cómo corregir los retrasos de inicio.
Una gran cantidad de errores de alineación, errores FCS o colisiones tardías pueden indicar lo siguiente:
discordancia dúplex
Cable dañado o defectuoso
discordancia dúplex
Un problema común con la velocidad/dúplex es cuando la configuración dúplex no coincide entre dos switches, entre un switch y un router o entre el switch y una estación de trabajo o servidor. Esto puede ocurrir cuando codifica manualmente la velocidad y el dúplex o debido a problemas de negociación automática entre los dos dispositivos.
Si la discordancia se produce entre dos dispositivos de Cisco con el Cisco Discovery Protocol (CDP) habilitado, consulte los mensajes de error del CDP en la consola o en el buffer de registro de ambos dispositivos. El CDP es útil para detectar errores, así como las estadísticas del sistema en los dispositivos de Cisco cercanos. CDP es propiedad de Cisco y funciona cuando envía paquetes a una dirección MAC conocida 01-00-0C-CC-CC-CC.
El ejemplo muestra los mensajes de registro que resultan de una discordancia dúplex entre dos switches Catalyst de la serie 6000: uno que ejecuta CatOS y el otro que ejecuta Cisco IOS. Estos mensajes generalmente le dicen cuál es la discordancia y dónde se produce.
2003 Jun 02 11:16:02 %CDP-4-DUPLEXMISMATCH:Full/half duplex mismatch detected on port 3/2 !--- CatOS switch sees duplex mismatch.
Jun 2 11:16:45 %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet6/2 (not half duplex), with TBA04251336 3/2 (half duplex). !--- Cisco IOS switch sees duplex mismatch.
Utilice el comando show cdp neighborcard-type <slot/port>para visualizar la información CDP para los dispositivos vecinos de Cisco.
Router#show cdp neighbors fastEthernet 6/1 detail ------------------------- Device ID: TBA04251336 Entry address(es): IP address: 10.1.1.1 Platform: WS-C6006, Capabilities: Trans-Bridge Switch IGMP Interface: FastEthernet6/1, Port ID (outgoing port): 3/1 Holdtime : 152 sec Version : WS-C6006 Software, Version McpSW: 6.3(3) NmpSW: 6.3(3) Copyright (c) 1995-2001 by Cisco Systems !--- Neighbor device to FastEth 6/1 is a Cisco Catalyst 6000 Switch !--- on port 3/1 running CatOS. advertisement version: 2 VTP Management Domain: 'test1' Native VLAN: 1 Duplex: full !--- Duplex is full. Router#
la configuración de velocidad/dúplex automático en un lado y 100/dúplex completo en el otro lado también es un error de configuración y puede dar lugar a una discordancia dúplex. Si el puerto del switch recibe muchas colisiones tardías, esto generalmente indica un problema de discordancia dúplex y puede colocar el puerto en un estado errdisable en un resultado. El lado semidúplex sólo espera paquetes en determinados momentos, no en cualquier momento, y por lo tanto cuenta los paquetes recibidos en el momento incorrecto como colisiones. Existen otras causas para las colisiones tardías además de la discordancia dúplex, pero esta es una de las razones más comunes. Establezca siempre ambos lados de la conexión para negociar automáticamente la velocidad/dúplex o establezca la velocidad/dúplex manualmente en ambos lados.
Utilice el comando show interfaces <card-type> <slot/port>status para mostrar la configuración de velocidad y dúplex, así como otra información. Utilice los comandos speedand duplexdel modo de configuración de la interfaz para codificar ambos lados a 10 o 100 y medio o completo según sea necesario.
Router#show interfaces fasstEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 connected 1 a-full a-100 10/100BaseTX
Si utiliza el comando show interfaces sin la opción de estado, verá una configuración para velocidad y dúplex, pero no sabrá si esta velocidad y dúplex se lograron a través de la negociación automática o no.
Router#sh int fas 6/1 FastEthernet6/1 is up, line protocol is up (connected) Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Full-duplex, 100Mb/s
!--- Full-duplex and 100Mbps does not tell you whether autoneg was used to achieve this. !--- Use the sh interfaces fas 6/1 status command to display this.
Cable dañado o defectuoso
Compruebe siempre que el cable no sufra daños o fallas marginales. El cable puede ser lo suficientemente bueno para conectarse a la capa física, pero corrompe los paquetes como resultado de pequeños daños en el cableado o los conectores. Compruebe o intercambie el cable de cobre o fibra. Intercambie las conexiones de fibra del GBIC (si es extraíble). Descarte las conexiones erróneas del patch panel o los conversores de medios entre el origen y el destino. Intente colocar el cable en otro puerto o interfaz si hay alguno disponible y verifique si el problema continúa.
Problemas de Negociación automática y con la Tarjeta NIC
Los problemas a veces se producen entre los switches de Cisco y ciertas tarjetas NIC de terceros. Los puertos de los switches Catalyst y las interfaces están predeterminados para negociar automáticamente. Es habitual que los dispositivos portátiles u otros dispositivos también estén predeterminados para negociar automáticamente, aunque a veces se producen problemas.
Para resolver problemas de negociación automática, a menudo se recomienda intentar y codificar ambos lados. Si la negociación automática o la configuración del código parecen no funcionar, puede haber un problema con el firmware o el software de la tarjeta NIC. Actualizar el driver de la tarjeta NIC a la última versión disponible en el sitio web de la fábrica para resolver el problema.
Consulte Configuración y Troubleshooting de la Negociación Automática de Semidúplex/Dúplex Completo Ethernet 10/100/1000 MB para obtener detalles sobre cómo resolver los problemas de velocidad/dúplex y negociación automática.
Consulte Resolución de Problemas de Compatibilidad entre los Switches Catalyst de Cisco y NIC para obtener detalles sobre cómo resolver problemas de NIC de terceros.
Los loops del Spanning-Tree Protocol (STP) pueden provocar problemas graves de rendimiento que se disfrazan como problemas de puerto o interfaz. En esta situación, su ancho de banda es utilizado por las mismas tramas una y otra vez, lo que deja poco espacio para el tráfico legítimo.
La función de protección de loop del STP brinda protección adicional contra los loops de reenvío de Capa 2 (loops STP). Se crea un loop STP cuando un puerto de bloque STP en una topología redundante pasa erróneamente al estado de reenvío. Esto suele suceder porque uno de los puertos de una topología físicamente redundante (no necesariamente el puerto de bloque STP) ya no recibe BPDU STP. En su operación, el STP está basado en la transmisión o en la recepción continua de las BPDU, según el rol del puerto. El puerto designado transmite los BPDU, y el puerto no designado recibe los BPDU.
Cuando uno de los puertos en una topología físicamente redundante deja de recibir BPDU, el STP considera a la topología como un loop libre. Finalmente, el puerto de bloqueo del puerto alternativo o de respaldo se designa y pasa a un estado de reenvío. Esta situación crea un loop.
La función de protección de loop hace verificaciones adicionales. Si las BPDU no se reciben en un puerto no designado, y la protección contra loops está habilitada, ese puerto se mueve al estado de bloque STP loop-inconsistent, en lugar del estado de escucha/aprendizaje/reenvío. Sin la función de protección de loop, el puerto asumiría el rol de puerto designado. El puerto se desplaza al estado de reenvío de STP y crea un loop. Consulte Mejoras del Spanning-Tree Protocol con las Funciones de Protección de Loop y Detección de Desviación de BPDU para obtener más información sobre la función de protección de loop.
Este documento abarca las razones por las que el STP puede fallar, qué información buscar para identificar el origen del problema, y qué clase de diseño minimiza los riesgos de STP.
Los loops también pueden provocarse por un link unidireccional. Para obtener más información, consulte la sección UDLD: Problemas de link unidireccional de este documento.
Un link unidireccional es un link donde el tráfico sale en un sentido, pero no se recibe tráfico en la dirección de ingreso. El switch no sabe que la dirección de ingreso del link es mala (el puerto piensa que el link está activo y funciona).
La rotura de un cable de fibra u otros problemas en los cables o el puerto pueden provocar esta comunicación unidireccional. Estos links parcialmente funcionales pueden producir problemas como los loops de STP cuando los switches involucrados no saben que el link está dañado parcialmente. El UDLD puede poner un puerto en el estado de errdisable cuando detecta un link unidireccional. El comando udld aggressive-mode se puede configurar en switches que ejecutan Cisco IOS (verifique las notas de la versión para ver la disponibilidad del comando) para conexiones punto a punto entre switches donde no se pueden tolerar links unidireccionales. Esta función ayuda a identificar problemas con los links unidireccionales de difícil detección
Consulte Comprensión y Configuración de la Función Unidirectional Link Detection Protocol (UDLD) para obtener información de configuración sobre UDLD.
Si tiene un gran número de tramas diferidas, o Out-Discard (también conocido como Out-Lost en algunas plataformas), significa que los búferes de salida del switch se han llenado y el switch tuvo que descartar estos paquetes. Esto podría indicar que este segmento opera con una velocidad o dúplex inferior, o que hay demasiado tráfico en este puerto.
Utilice el comando show interfaces counters errorpara ver OutDiscards.
Router#show interfaces counters error Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Fa7/47 0 0 0 0 0 0 Fa7/48 0 0 0 0 0 2871800 Fa8/1 0 0 0 0 0 2874203 Fa8/2 103 0 0 103 0 2878032 Fa8/3 147 0 0 185 0 0 Fa8/4 100 0 0 141 0 2876405 Fa8/5 0 0 0 0 0 2873671 Fa8/6 0 0 0 0 0 2 Fa8/7 0 0 0 0 0 0
!--- The show interfaces counters errors command shows certain interfaces !--- that increment in large amounts OutDiscards while others run clean.
Investigue las siguientes causas comunes de errores en el buffer de salida:
Velocidad o Dúplex Inferior para la Cantidad de Tráfico
La red puede enviar demasiados paquetes a través de este puerto para que el puerto los gestione con su configuración actual de dúplex/velocidad. Esto podría ocurrir cuando varios puertos de alta velocidad desembocan en un solo puerto (generalmente más lento). Puede desplazar el dispositivo que está bloqueado en este puerto a un medio más rápido. Por ejemplo, si el puerto es de 10 Mbps, desplace este dispositivo a un puerto de 100 Mbps o un puerto Gigabit. Puede cambiar la topología para rutear las tramas de forma diferente.
Problemas de congestión: segmento demasiado ocupado
Si se comparte el segmento, los otros dispositivos en este segmento pueden transmitir tanto que el switch no tiene ninguna oportunidad de transmitir. Evitar los hubs de Daisy Chain siempre que sea posible. La congestión puede provocar la pérdida de paquetes. La pérdida de paquetes causa retransmisiones en la capa de transporte, lo que a su vez hace que los usuarios experimenten el tiempo de espera en el nivel de la aplicación. Puede actualizar los links de 10 Mbps a links de 100Mbps o Gigabit Ethernet cuando sea posible. Puede quitar algunos dispositivos de los segmentos saturados a otros segmentos menos poblados. Haga que la prevención de la congestión sea una prioridad en su red.
Aplicaciones
A veces, las características de transmisión del tráfico de las aplicaciones usadas pueden causar problemas de buffer de salida. Las transferencias de archivos NFS que provienen de un servidor conectado Gigabit que utiliza el protocolo de datagramas de usuario (UDP) con un tamaño de ventana de 32 K es un ejemplo de una configuración de aplicación que puede generar este tipo de problema. Si ha comprobado o probado las otras sugerencias de este documento (velocidad/dúplex comprobado, no hay errores físicos en el link, todo el tráfico es tráfico normal válido, etc.), entonces reduzca el tamaño de la unidad que envía la aplicación, lo que puede ayudar a aliviar este problema.
Si observa un comportamiento que sólo puede considerarse extraño, puede aislar el comportamiento en un cuadro específico y ha analizado todo lo sugerido hasta el momento, lo que puede indicar problemas de software o hardware. Generalmente es más fácil actualizar el software que actualizar el hardware. Primero, cambie el software.
Utilice el comando show versioncommand para verificar la versión de software actual junto con el comando dir flash: ordir bootflash: (depende de la plataforma) para verificar la memoria flash disponible para la actualización:
Router#show version Cisco Internetwork Operating System Software IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-IS-M), Version 12.1(13)EW, EA RLY DEPLOYMENT RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Fri 20-Dec-02 13:52 by eaarmas Image text-base: 0x00000000, data-base: 0x00E638AC ROM: 12.1(12r)EW Dagobah Revision 71, Swamp Revision 24 trunk-4500 uptime is 2 weeks, 2 days, 6 hours, 27 minutes System returned to ROM by redundancy reset System image file is "bootflash:cat4000-is-mz.121-13.EW.bin"
!--- Typical Cisco IOS show version output. Router#dir bootflash: Directory of bootflash:/ 1 -rw- 8620144 Mar 22 2002 08:26:21 cat4000-is-mz.121-13.EW.bin 61341696 bytes total (52721424 bytes free)
!--- Verify available flash memory on switch running Cisco IOS.
Cómo Actualizar el Software
Para obtener información sobre cómo actualizar el software de sus switches Cisco, vaya al enlace, elija su plataforma y consulte la sección Configuración del software.
Incompatibilidad de Hardware y Software
En determinadas situaciones, el software no es compatible con el hardware. Esto ocurre cuando sale nuevo hardware que requiere un software especial de apoyo. Para obtener más información sobre la compatibilidad del software, use la herramienta Software Advisor.
Bugs de software
El sistema operativo puede tener un error. Si carga una versión de software más nueva, puede solucionar este error. Puede buscar errores de software conocidos con la Herramienta para Errores de Software.
Imágenes Dañadas
Una imagen puede haberse dañado. Para obtener información sobre la recuperación de imágenes dañadas, elija su plataforma Switch y consulte la sección Resolución de problemas.
Verifique los resultados de show module para los switches Catalyst de las series 6000 y 4000 que ejecutan Cisco IOS.
Compruebe los resultados de POST del switch para ver si se indicaron fallas para cualquier parte del switch. Las fallas de cualquier prueba de un módulo o puerto muestran una "F" en los resultados de la prueba.
Para Cisco IOS, en los switches modulares como Cat6000, utilice el comando command show diagnostics. Para ver los resultados POST por módulo, utilice el comando show diagnostics module<module>.
ecsj-6506-d2#sh diagnostic module 3 Current Online Diagnostic Level = Minimal !--- The diagnostic level is set to minimal which is a shorter, !--- but also less thorough test result. !--- You may wish to configure diagnostic level complete to get more test results. Online Diagnostic Result for Module 3 : MINOR ERROR Online Diagnostic Level when Line Card came up = Minimal Test Results: (. = Pass, F = Fail, U = Unknown) 1 . TestLoopback : Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------- . . . . . . . . . . . . . . . . . . F F F F F F
!--- Notice the MINOR ERROR test result and failed loopback test which means !--- these ports are currently unusable. !--- Use the hw-module{mod}reset command or, if necessary, physically reseat the !--- module to try and fix this problem. !--- If these steps fail, open a case with Cisco Technical Support.
Nota: Para los Catalyst 3750, 3550, 2970, 2950/2955, y 2900/3500XL Series switches utilice el comando show postcommand, que indica una simple pasada o falla para el estado hw. Use los LED en estos switches para que pueda comprender los resultados POST.
Para obtener más información sobre cómo resolver problemas de hardware en switches Catalyst que ejecutan Cisco IOS, navegue hasta las páginas de soporte de switches Cisco, elija su plataforma y consulte la Troubleshooting > Hardware
sección. Para ver los posibles problemas relacionados con Avisos de campo, consulte Avisos de campo para switches LAN y ATM.
De forma predeterminada, todos los puertos de la capa 2 son inddynamic desirable mode, por lo que el puerto de la capa 2 intenta formar un enlace troncal y envía paquetes DTP al dispositivo remoto. Cuando una interfaz de capa 3 está conectada con un switchport de capa 2, no puede interpretar estas tramas, que da lugar a errores de Entrada, errores WrongEncap, y descartes de la cola de Entrada.
Para resolver esto, cambie el modo del puerto del switch a static accessortrunkas según sus necesidades.
Switch2(config)#interface fastEthernet1/0/12 Switch2(config-if)#switchport mode access
O bien
Switch2(config)#interface fastEthernet1/0/12
Switch2(config-if)#switchport trunk encapsulation dot1q
Switch2(config-if)#switchport mode trunk
El contador Rx-No-Pkt-Buff puede incrementarse en los puertos cuando tiene conectores, como WS-X4448-GB-RJ45, WS-X4548-GB-RJ45, y WS-X4548-GB-RJ45V. Además, el incremento de algunas caídas de paquetes es normal y es el resultado de las ráfagas de tráfico.
Estos tipos de errores aumentan rápidamente, especialmente cuando el tráfico que pasa a través de ese link es alto o cuando tiene dispositivos tales como servidores conectados con esa interfaz. Esta carga alta de tráfico suscribe puertos en exceso, que agota los buffers de entrada y hace que el contador Rx-No-Pkt-Buff y los errores de entrada aumenten rápidamente.
Si un paquete no puede ser recibido totalmente porque el switch está fuera de los buffers del paquete, este contador se incrementa una vez para cada paquete descartado. Este contador indica el estado interno de los ASIC de Switching en Supervisor y no indica necesariamente una condición de error.
Tramas de Pausa
Cuando la cola Rx FIFO (primero en entrar, primero en salir) de la parte de recepción (Rx) del puerto está llena, la parte de transmisión (Tx) del puerto comienza a generar traumas de pausa con un valor de intervalo mencionado en ella. Se espera que el dispositivo remoto detenga/reduzca la transmisión de paquetes para el intervalo mencionado en la trama de pausa.
Si el Rx puede borrar la cola Rx o alcanzar la marca de agua baja dentro de este intervalo, el Tx envía una trama de pausa especial que menciona el intervalo como cero (0x0). Esto habilita el dispositivo remoto para comenzar a transmitir los paquetes.
Si el Rx todavía funciona en la cola, una vez que expira el intervalo, el Tx envía una nueva trama de pausa otra vez con un nuevo valor del intervalo.
Si Rx-No-Pkt-Buff es cero o no se incrementa y se incrementa el contador TxPauseFrames, indica que nuestro switch genera tramas de pausa y el extremo remoto obedece, por lo tanto, la cola Rx FIFO se agota.
Si Rx-No-Pkt-Buff aumenta y TxPauseFrames también aumenta, significa que el extremo remoto no tiene en cuenta las tramas de pausa (no soporta el control de flujo) y continúa enviando tráfico a pesar de las tramas de pausa. Para solucionar esta situación, configure manualmente la velocidad y dúplex, e inhabilite el control de flujo, si es necesario.
Estos tipos de errores en la interfaz se relacionan con un problema de tráfico con los puertos con un exceso de suscriptores. Los módulos de switching The WS-X4448-GB-RJ45, WS-X4548-GB-RJ45, y WS-X4548-GB-RJ45V tienen 48 puertos con suscriptores en exceso en seis grupos de ocho puertos:
Puertos 1, 2,3, 4, 5, 6, 7, 8
Puertos 9, 10, 11, 12, 13, 14, 15, 16
Puertos 17, 18, 19, 20, 21, 22, 23, 24
Puertos 25, 26, 27, 28, 29, 30, 31, 32
Puertos 33, 34, 35, 36, 37, 38, 39, 40
Puertos 41, 42, 43, 44, 45, 46, 47, 48
Los ocho puertos dentro de cada grupo utilizan circuitos comunes que efectivamente multiplexan el grupo en una sola conexión Gigabit Ethernet sin bloqueo y dúplex completo al entramado de switches interno. Para cada grupo de ocho puertos, las tramas recibidas son guardadas en buffer y se envían al link común Gigabit Ethernet, al entramado interno de switches. Si la cantidad de datos recibidos para un puerto comienza a exceder la capacidad del buffer, el control de flujo envía las tramas de pausa al puerto remoto para detener el tráfico temporalmente y evitar la pérdida de tramas.
Si las tramas recibidas en cualquier grupo exceden el ancho de banda de 1 Gbps, el dispositivo comienza a descartar las tramas. Estos descartes no son evidentes ya que se producen en el intervalo ASIC y no en las interfaces reales. Esto puede reducir la producción de paquetes a través del dispositivo.
El Rx-No-Pkt-Buff no depende de la velocidad del tráfico total. Depende de la cantidad de paquetes que se almacenan en el buffer Rx FIFO del módulo ASIC. El tamaño de este buffer es solamente 16 KB. Se cuenta con el flujo de ráfagas de tráfico cortas cuando algunos paquetes llenan este búfer. Así, Rx-No-Pkt-Buff en cada puerto puede contarse cuando la velocidad de tráfico total de este grupo de puerto ASIC excede 1 Gbps, ya que WS-X4548-GB-RJ45 es un módulo con suscriptores en exceso 8:1.
Cuando tiene dispositivos que necesiten trasladar una gran cantidad de tráfico a través de esa interfaz, considere el uso de un puerto de cada grupo para que el circuito común que comparte un solo grupo no se vea afectado por la cantidad de tráfico. Cuando el módulo de conmutación Gigabit Ethernet no se utiliza por completo, puede equilibrar las conexiones de puertos entre los grupos de puertos para maximizar el ancho de banda disponible. Por ejemplo, con el módulo de switching WS-X4448-GB-RJ45 10/100/1000, puede conectar puertos de diferentes grupos, como los puertos 4, 12, 20, o 30 (en cualquier orden), antes de conectar los puertos del mismo grupo, como los puertos 1, 2, 3, 4, 5, 6, 7, y 8. Si esto no soluciona el problema, debe considerar un módulo sin ninguna suscripción en exceso de los puertos.
El protocolo desconocido se descarta en un contador de la interfaz. Son causados por protocolos que no comprende el router/switch. Este ejemplo del comando show run interface muestra las caídas de protocolo desconocidas en la interfaz GigabitEthernet 0/1.
Switch#show run interface GigabitEthernet0/1 GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1125 Internal MAC, address is 0000.0000.0000 (via 0000.0000) MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:05, output 00:00:03, output hang never Last clearing of "show interface" counters 16:47:42 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 3031 packets input, 488320 bytes, 0 no buffer Received 3023 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 63107 multicast, 0 pause input 0 input packets with dribble condition detected 7062 packets output, 756368 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 2015 unknown protocol drops 4762 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out
Los descartes del protocolo desconocido se caen normalmente porque la interfaz donde se reciben estos paquetes no se configura para este tipo de protocolo, o puede ser cualquier protocolo que el router no reconozca. Por ejemplo, si conecta hace dos routers e inhabilita el CDP en una interfaz del router, se producen descartes del protocolo desconocido en esa interfaz. Los paquetes CDP ya no se reconocen, y se descartan.
Los links de trunk entre un switch y un router pueden hacer que el switchport quede desactivado. El trunk puede activarse después de que usted inhabilita y habilita el switchport pero, finalmente, el switchport puede desactivarse nuevamente.
Complete estos pasos para resolver el problema:
Asegúrese de que Cisco Discovery Protocol (CDP) se ejecute entre el switch y el router y que ambos pueda verse.
Inhabilite el Keepalives en la interfaz del router.
Configure de nuevo la encapsulación en ambos dispositivos.
Cuando se inhabilita keepalives, el CDP habilita el link para que funcione normalmente.
Cuando utiliza los módulos WS-X6548-GE-TX o WS-X6148-GE-TX, existe la posibilidad de que la utilización del puerto individual genere problemas de conectividad o pérdida de paquetes en las interfaces que los rodean. Consulte Problemas de Conectividad de la Interfaz/Módulo para obtener más información sobre la sobresuscripción.
En los módulos SPA, después de crear una subinterfaz con 802.1Q, la misma VLAN no se puede utilizar en el switch. Una vez que tiene encapsulation dot1q en una subinterfaz, ya no puede utilizar esa VLAN en el sistema porque el 6500 o 7600 asigna internamente la VLAN y hace que esa subinterfaz sea su único miembro. Para resolver este problema, cree puertos troncales en lugar de subinterfaces. De esa manera, la VLAN se puede considerar en todas las interfaces.
Normalmente, las caídas de salida pueden ocurrir si se configura QoS y no proporciona suficiente ancho de banda a cierta clase de paquetes. También ocurre cuando el hardware alcanza una sobresuscripción.
Por ejemplo, aquí puede ver una gran cantidad de caídas de salida en la interfaz GigabitEthernet 8/9 en un Catalyst 6500 Series Switch:
Switch#show interface GigabitEthernet8/9 GigabitEthernet8/9 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 0013.8051.5950 (bia 0013.8051.5950) Description: Connection To Bedok_Core_R1 Ge0/1 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 18/255, rxload 23/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is off Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:28, output 00:00:10, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/3/0 (size/max/drops/flushes); Total output drops: 95523364 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94024000 bits/sec, 25386 packets/sec 5 minute output rate 71532000 bits/sec, 24672 packets/sec 781388046974 packets input, 406568909591669 bytes, 0 no buffer Received 274483017 broadcasts (257355557 multicasts) 0 runts, 0 giants, 0 throttles 3 input errors, 2 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 749074165531 packets output, 324748855514195 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out
Para analizar el problema, recopile el resultado de estos comandos:
show fabric utilization detail
show fabric errors
show platform hardware capability
mostrar el medidor de tráfico de Catalyst6000
show platform hardware capability rewrite-engine drop
Este ejemplo del comando show interface muestra theLast input neveren la interfaz TenGigabitEthernet1/15.
Switch#show interface TenGigabitEthernet1/15 TenGigabitEthernet1/15 is up, line protocol is up (connected) Hardware is C6k 10000Mb 802.3, address is 0025.84f0.ab16 (bia 0025.84f0.ab16) Description: lsnbuprod1 solaris MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 10Gb/s input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:17, output hang never Last clearing of "show interface" counters 2d22h Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 46000 bits/sec, 32 packets/sec 52499121 packets input, 3402971275 bytes, 0 no buffer Received 919 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 118762062 packets output, 172364893339 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out
Esto muestra el número de horas, minutos, y segundos desde que el paquete más reciente fue recibido con éxito por una interfaz y procesado localmente en el router. Esta información es útil cuando una interfaz inactiva ha fallado. Se espera que este contador se actualice solo cuando los paquetes se conmuten por porceso, no cuando los paquetes se conmuten rápidamente. Last input never significa que no hubo una transferencia exitosa de paquetes de interfaz a otro terminal o punto final. Esto significa generalmente que no hubo transferencia de paquetes en relación con esa entidad.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
04-Dec-2001 |
Versión inicial |