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 ejecutan el software de sistema Cisco IOS®.
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.
Nota: Para acceder a las herramientas y los sitios web, debe estar registrado como cliente 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 de Catalyst. |
Cable en malas condiciones |
Cambie el cable que supuestamente está en malas condiciones por un cable en buenas condiciones. Revise si hay pines rotos o faltantes en los conectores. |
Conexiones débiles |
Verifique conexiones débiles. A veces un cable parece estar asentado en el conector, 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 conversores de medios defectuosos: fibra a cobre, etc. Desvíe el conversor de medios, si es posible, 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 tener el cable correcto para el tipo de conexión que desea realizar. El cable de cobre de categoría 3 se puede utilizar para conexiones de par trenzado no blindado (UTP) de 10 Mbps, pero nunca se debe utilizar para conexiones de 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 grandes cantidades 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 óptica monomodo (SMF) o fibra óptica multimodo (MMF). Asegúrese de que ambos puertos de los dispositivos que están conectados sean SMF, o que ambos sean MMF.
Nota: En el caso de las conexiones de fibra, asegúrese de que el cable de transmisión de un puerto esté conectado al cable 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 detalles sobre los diferentes tipos de cables y conectores, los requisitos de cables, los requisitos ópticos (distancia, tipo, cables de parche, etc.), cómo conectar los diferentes cables y qué cables utiliza la mayoría de los switches y módulos Cisco, consulte la Guía de cables del switch 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 |
MMF4 SMF |
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 modal (MFD), que es el diámetro de la parte de la fibra que transporta la luz. Esta zona consta del núcleo de fibra y una pequeña parte de 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. Si existen numerosos empalmes y la fibra óptica es inferior a la estándar, se 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 parche de acondicionamiento de modo evita el uso excesivo del receptor para longitudes cortas de MMF y reduce el retardo del modo diferencial en el caso de grandes longitudes 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 mucho más amplio que el que se utiliza para Ethernet 10/100 (especificación de negociación automática de Gigabit: estándar IEEE 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 enlaces cuando se ejecuta Gigabit Ethernet en cobre frente a Gigabit Ethernet en fibra. Esta diferencia en el tiempo de detección está basada en los estándares IEEE.
Advertencia: Si se deshabilita la negociación automática, se ocultan las caídas de enlaces o los problemas de la capa física. Esto se requiere solo si se usan terminales que no admiten el estándar IEEE 802.3z, como las antiguas NIC Gigabit. 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, así como los requisitos del sistema de convertidores de interfaz Gigabit (GBIC), multiplexación por división de longitud de onda gruesa (CWDM) y Small Form-Factor Pluggable (SFP), consulte estos documentos:
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 la configuración general e información adicional sobre cómo solucionar problemas, consulte Configuración y solución de problemas de negociación automática de dúplex medio/completo de Ethernet de 10/100/1000 Mb.
La mayoría de los switches Cisco tiene un puerto en estado de desconexión. 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 muestra up, line protocol is up (connected). El primer up indica el estado de la capa física de la interfaz. El mensaje line protocol up muestra el estado de la capa de enlace de datos de la interfaz e indica que la interfaz puede enviar y recibir mensajes de actividad.
Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is down, line protocol is down (notconnect)!--- 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.
En esta tabla se muestran los comandos más comunes utilizados para solucionar problemas de puertos o interfaces en switches que ejecutan el software de sistema Cisco IOS en el supervisor.
Nota: La columna de la derecha en la siguiente tabla proporciona una breve descripción de lo que hace el comando e indica las excepciones de uso por plataforma.
Si su dispositivo Cisco arroja el resultado de los comandos admitidos, puede utilizar el Analizador de CLI de Cisco para ver posibles problemas y correcciones.
Comandos de Cisco IOS | Descripción |
show version |
Este comando muestra un resultado similar al de un router Cisco, como el nombre de la imagen de software, la información de la 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 o el Asesor de software) y errores (con la Herramienta de búsqueda de errores). Nota: solo los usuarios registrados de Cisco pueden acceder a la información y las herramientas internas de Cisco. |
show module |
Este comando muestra qué tarjetas están presentes en el switch, la versión del software en ejecución y el estado de los módulos: correcto, defectuoso, etc. Es útil para diagnosticar problemas de hardware en módulos o puertos. 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 los puertos de un switch, los paquetes de entrada y salida, las fallas 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, de modo que pueda ver si el problema es solamente temporal o si los contadores continúan aumentando. Nota: Los switches Catalyst 6500/6000 Series 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 que debe utilizar en Catalyst de las series 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 que debe utilizar en Catalyst de las series 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 Catalyst de la serie 6000 y show diagnostics (con s) se introdujo para Catalyst de la serie 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 de POST del switch. Para obtener más información sobre la solución de problemas de errores relacionados con el hardware en los switches Catalyst, consulte 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 que se utilizan para encontrar este tipo de información se describen en la sección Solución de problemas de los comandos más comunes de puertos e interfaces de Cisco IOS de este documento.
Nota: Puede haber diferencias en la implementación de los contadores entre las diferentes 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 opera en la configuración de semidúplex, el aumento de algunos errores de enlace de datos en la secuencia de verificación de tramas (FCS), la alineación, los ciclos y los contadores de colisiones es normal. 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 provocar errores de alineación, fragmentos minúsculos y FCS debido a que la trama no se copia completamente en el cable, lo que produce 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 card-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 card-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
El resultado del comando show interfaces se explica hasta este punto (en orden):
up, line protocol is up (connected): el primer up indica el estado de la capa física de la interfaz. El mensaje line protocol up muestra el estado de la capa de enlace de datos de la interfaz e indica que la interfaz puede enviar y recibir mensajes de actividad.
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).
Full-duplex, 100Mb/s: dúplex completo y 100 Mbps son los ajustes de velocidad y dúplex actuales de la interfaz. Esto no indica si se ha utilizado autoneg para lograrlo. Utilice el comando show interfaces fastEthernet 6/1 status para mostrar esto:
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 sirve para saber cuándo ha fallado una interfaz inactiva.
Último borrado de 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 el routing (por ejemplo, la carga y la confiabilidad) 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. Los vaciados se utilizan para contar las caídas de descarte selectivo de paquetes (SPD) en Catalyst 6000 Series que ejecuta Cisco IOS. (El contador de vaciados se puede utilizar pero nunca se incrementa en Catalyst 4000 Series 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 enlace de ancho de banda alto que se ha pasado a un enlace de ancho de banda bajo o el tráfico de varios enlaces entrantes se ha pasado a un solo enlace saliente. Por ejemplo, si una gran cantidad de tráfico entra en una interfaz Gigabit y se pasa a una interfaz de 100 Mbps, esto podría ocasionar que aumenten los descartes en la salida de 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. Size/max significa la cantidad actual de tramas en la cola o el número máximo de tramas que la cola puede retener antes de estar completa y comenzar a descartarlas.
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 de interfaz load-interval <seconds>.
Ver la Tabla 1 para obtener las explicaciones de la salida 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 del resultado del comando show interface para una interfaz física y una interfaz VLAN. Los contadores de paquetes de entrada se incrementan en la salida del comando show interface para una interfaz VLAN cuando ese paquete es procesado por el CPU en la Capa 3 (L3). El tráfico que es conmutado en la Capa 2 (L2) nunca lo hace en el CPU y no se cuenta en los contadores show interface para la interfaz VLAN. Sería contado en la salida show interface para la interfaz física apropiada.
El comando show interfaces < card-type> <slot/port> counters errors se utiliza en Cisco IOS para mostrar solamente la salida de los errores de interfaz. Ver la Tabla 1 para obtener las explicaciones de la salida del contador de errores.
Router#show 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. Salida del contador de errores de Cisco IOS para show interfaces o show interfaces < card-type> <x/y> cuenta los 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 Verificación por redundancia cíclica (CRC) incorrecta. Causas comunes: por lo general, son el resultado de una discordancia dúplex o de un problema físico (como cableado, puerto defectuoso o NIC defectuosa). Cuando el cable primero está conectado con el puerto, pueden presentarse algunos de estos errores. También, si hay un hub conectado con el puerto, las colisiones entre los 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 el supervisor II (WS-X4013) de Catalyst de la serie 4000. |
babbles |
Descripción: show interfaces counter indica que el temporizador de transmisión de tramas Jabber ha caducado. Las tramas Jabber son tramas con más de 1518 octetos (sin contar los bits de entramado, pero sí los octetos de FCS) que no termina con un número par de octetos (error de alineación) o tiene una FCS errónea. |
Carri-Sen |
Descripción: show interfaces counters errors. El contador Carri-Sen (detección de portadora) aumenta cada vez que un controlador Ethernet quiere enviar datos a una conexión semidúplex. El controlador detecta el cable y verifica si no está ocupado antes de realizar la transmisión. Causas comunes: esto es normal en un segmento Ethernet semidúplex. |
colisiones |
Descripción: show interfaces counter. La cantidad de veces que una colisión se presenta antes de que la interfaz transmita una trama a los medios con éxito. Causas comunes: las colisiones son normales en las interfaces configuradas como semidúplex, pero no se deben dar en interfaces de 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 interfaces counter. Esto aumenta cuando la CRC generada por la estación de la LAN de origen o el dispositivo del extremo final que origina el tráfico no coinciden con la suma de comprobación calculada a partir de los datos recibidos. Causas comunes: generalmente, esto indica problemas de ruido o transmisión en la interfaz de LAN o en la LAN en sí. 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. |
deferred |
Descripción: show interfaces counter. La cantidad de tramas transmitidas con éxito luego de esperar debido a que los medios se hallaban ocupados. Causas comunes: esto suele ocurrir en entornos semidúplex donde la portadora ya está en uso al intentar transmitir una trama. |
pause input |
Descripción: show interfaces counter. Un incremento del contador pause input significa que el dispositivo conectado está solicitando que se detenga el tráfico cuando su búfer de recepción está casi lleno. Causas comunes: este contador aumenta a título informativo, 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. |
input packets with dribble condition |
Descripción: show interfaces counter. Un error de bits adicionales indica que una trama es demasiado larga.Causas comunes: este contador de error de tramas aumenta a título informativo, 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: generalmente, las colisiones excesivas son una indicación de que la carga del segmento debe dividirse en varios segmentos, pero también pueden indicar una incompatibilidad de dúplex con el dispositivo asociado. Las colisiones no se deben considerar en las interfaces configuradas como dúplex completo. |
FCS-Err |
Descripción: show interfaces counters errors. Número de tramas de tamaño válido con errores de secuencia de verificación de tramas (FCS), pero sin errores de entramado. Causas comunes: esto suele ser un problema físico (como el cableado, un puerto erróneo o una tarjeta de interfaz de red (NIC) defectuosa), pero también puede ser un indicio de incompatibilidad de 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: este suele ser el resultado de colisiones o un problema físico (como el cableado, un puerto o una NIC defectuosos), aunque también puede indicar una incompatibilidad de dúplex. |
Gigantes |
Descripción: show interfaces y show interfaces counters errors. Tramas recibidas que exceden el tamaño máximo de trama IEEE 802.3 (1518 bytes para Ethernet no jumbo) y tienen una Secuencia de verificación de tramas (FCS) incorrecta. 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 de la serie Cat4000 que ejecutan una versión de Cisco IOS anterior a la versión de software 12.1(19)EW; el contador giants se incrementa para una trama >1518 bytes. Después de la versión 12.1(19)EW, aumenta solo en show interfaces cuando se recibe una trama >1518 bytes con una FCS errónea. |
ignored |
Descripción: show 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 aumente el recuento de tramas ignoradas. |
Errores de Entrada |
Descripción: show interfaces counter. Causas comunes: incluye los recuentos de fragmentos de colisión, gigantes, no almacenados en búfer, CRC, tramas, saturación e 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. |
Late-Col |
Descripción: show interfaces y show interfaces counters. La cantidad de veces que se detecta tarde una colisión en una interfaz específica en el proceso de transmisión. Para un puerto de 10 Mbit/s, es después de los 512 bits en la transmisión de un paquete. 512 veces bits corresponde a 51.2 microsegundos en un sistema de 10 Mbit/s. Causas comunes: entre otras cosas, este error puede indicar una incompatibilidad de dúplex. En el caso de una situación de incompatibilidad de dúplex, la colisión tardía se observa en el lado de semidúplex. Dado que el lado de semidúplex está transmitiendo, el lado de dúplex completo no espera su turno y transmite de manera simultánea, 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: show interfaces counter. El número de veces que la portadora se ha perdido durante la transmisión. Causas comunes: compruebe que no haya ningún 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 en las interfaces configuradas como semidúplex, pero no se deben dar en interfaces de 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: show interfaces counter. El número de paquetes recibidos descartados porque no hay espacio de buffer. Causas comunes: compárelo con el contador de ignorados. Las tormentas de difusión pueden ser responsables de esta situación. |
sin portadora |
Descripción: show interfaces counter. La cantidad de veces que la portadora no estuvo presente durante la transmisión. Causas comunes: compruebe que no haya ningún cable defectuoso. Compruebe la conexión física en ambos lados. |
Out-Discard |
Descripción: número de paquetes salientes que se ha decidido descartar aunque no se hayan detectado errores. Causas comunes: una razón posible para descartar estos paquetes podría ser la necesidad de liberar espacio en el búfer. |
output buffer failures output buffers swapped out |
Descripción: show interfaces counter. La cantidad de memoria intermedia con errores e intercambiada. Causas comunes: el puerto almacena los paquetes en el búfer de transmisión cuando la tasa de tráfico desviada hacia el puerto es alta y no se puede manejar. 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 a fin de solucionar problemas, consulte la sección Tramas diferidas (perdidas o descartadas) de este documento. |
errores de salida |
Descripción: show interfaces counter. La suma de todos los errores que previnieron la transmisión final de la interfaz de datagramas de la interfaz. Causa común: este problema se debe al escaso tamaño de la cola de salida. |
desbordamiento |
Descripción: número de veces que el hardware de recepción no pudo entregar datos recibidos a un búfer de hardware. Causa común:La velocidad de entrada de tráfico excedió la capacidad del receptor de manejar los datos. |
packets input/output |
Descripción: show interfaces counter. El total de paquetes sin errores recibidos y transmitidos en la interfaz. Monitorear los aumentos en estos contadores es útil para determinar si el tráfico circula de forma adecuada 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: Solo para Catalyst 6000 Series - error show interfaces counters. Causas comunes: consulte Excepciones de plataforma.Excepciones de plataforma: Catalyst 5000 Series rcv-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. En Catalyst 4000 Series rcv-err = la suma de todos los errores de recepción, lo que significa, contrariamente a 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 de FCS. |
Fragmentos minúsculos |
Descripción: show interfaces y 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 un CRC incorrecto. Causas comunes: Esto puede ser causado por 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 IOS Antes de 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 enshow interfaces counters errors cuando se recibe una trama < 64 bytes con una CRC mala. Switches Catalyst de Cisco serie 3750 En las versiones anteriores a Cisco IOS 12.1(19)EA1, cuando se utiliza dot1q en la interfaz troncal en el Catalyst 3750, se pueden ver fragmentos minúsculos en la salida show interfaces porque los paquetes encapsulados dot1q válidos, que son de 61 a 64 bytes e incluyen la etiqueta q, son contados por el Catalyst 3750 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. |
Single-Col |
Descripción: show interfaces counters errors. Número de veces que se ha producido una colisión antes de que la interfaz transmitiera una trama satisfactoriamente al dispositivo. Causas comunes: las colisiones son normales en las interfaces configuradas como semidúplex, pero no se deben dar en interfaces de 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. |
throttles |
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 de contador de throttles, significa que la interfaz está throttled en el momento que se ejecuta el comando. Causas comunes: los paquetes que pueden aumentar la sobrecarga del procesador incluyen paquetes IP con opciones, TTL caducado, encapsulamiento que no es ARPA, fragmentación, túneles, paquetes ICMP, paquetes con fallas en la suma de comprobación de MTU, fallas de RPF, sumas de comprobación de IP y errores de longitud. |
underruns |
Descripción: la cantidad de veces que el transmisor se ha ejecutado más rápido de lo que puede manejar el switch. Causas comunes: esto puede ocurrir en situaciones de alto rendimiento cuando una interfaz recibe un gran 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. Tramas recibidas que son más pequeñas que el tamaño de trama mínimo de 64 bytes que indica la norma IEEE 802.3 (sin contar los bits de entramado, pero sí los octetos de FCS), pero que están bien formadas. Causas comunes: revise el dispositivo que envía estas tramas. |
Xmit-Err |
Descripción: show interfaces counters errors. Esto indica que el buffer de transmisión interno (Tx) está lleno. Causas comunes: una causa común de Xmit-Err puede ser el tráfico de un enlace de ancho de banda alto que se ha pasado a un enlace de ancho de banda bajo o el tráfico de varios enlaces entrantes que se ha pasado a un solo enlace saliente. Por ejemplo, si una gran cantidad de tráfico entra en una interfaz Gigabit y se pasa a una interfaz de 100 Mbps, esto podría 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 monitorear el tráfico de unidifusión, multidifusión y difusión entrante y saliente en el puerto, como se muestra en el siguiente resultado. El comando show interfaces card-type {slot/port} counters se usa cuando ejecuta Cisco IOS en Supervisor.
Nota: Existe un contador Out-Discard en el comando Cisco IOS show interfaces counters errors que se explica en la Tabla 1.
Router#show 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 interface card-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 el resultado del contador de tráfico y errores que es similar al resultado de los switches Catalyst de la serie 6000.
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 observa un aumento del 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 observa un aumento del número de paquetes en este campo. 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 solo las tramas que se han transmitido luego sin errores ni colisiones. |
La carga de tráfico destinada a este switch es excesiva, por lo que se descartan tramas. Reduzca la carga del switch si observa un aumento del número de paquetes en este campo. 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 colisiones de tramas indican el número de veces que se intentó y no se logró transmitir un paquete, sino que se logró en el 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 un aumento del número de paquetes 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 provocan la colisión tardía nunca ven que cada uno envía tramas hasta después de que se pone todo el paquete en la red. Las colisiones tardías no son detectadas por el transmisor hasta después del intervalo correspondiente a los primeros 64 bytes. Esto es debido a que solo se detectan durante las transmisiones de paquetes mayores de 64 bytes. |
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 superar las 15 colisiones y contarse 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.El número de veces que un puerto ha recibido un paquete de la red, pero el switch no tenía los recursos necesarios 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 un aumento del número de paquetes en estos campos. |
No buffers frames |
2900/3500XL solamente.El número de veces que un puerto ha recibido un paquete de la red, pero el switch no tenía los recursos necesarios 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 un aumento del número de paquetes 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 y esto produce tramas fragmentadas. Los errores de alineación son el resultado de colisiones de incompatibilidad de semidúplex, dúplex completo, problemas de hardware (NIC, cableado o puerto) o dispositivos conectados que generan tramas que no finalizan en un octeto y tienen una FCS errónea. |
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 de FCS son el resultado de colisiones de incompatibilidad de semidúplex, dúplex completo, problemas de hardware (NIC, cableado o puerto) o dispositivos conectados que generan tramas que no finalizan en un octeto y tienen una FCS errónea. |
Tramas de tamaño inferior al normal |
Esta es la cantidad total de paquetes recibidos con menos de 64 octetos de longitud (excluidos los bits de entramado, pero incluida la FCS) y un valor de FCS correcto. |
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 |
La cantidad total de tramas cuya longitud es inferior a 64 octetos (excluidos los bits de entramado, pero incluida la FCS) y tienen un valor de FCS incorrecto. |
El aumento del contador indica que los puertos están configurados en semidúplex. Cambie el dúplex completo por semidúplex. |
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 |
La cantidad total de tramas de recepción que se descartan debido a que el bit de la ruta de origen está establecido 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 |
La cantidad total de tramas recibidas cuya longitud supera la MTU del sistema aunque tengan valores de FCS correctos. |
Esta estadística cuenta las tramas que exceden la MTU del sistema configurado, pero que pueden haber aumentado de 1518 bytes para permitir el encapsulamiento de 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 consultar los Mensajes 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 satura la interfaz Ethernet, revise la configuración de velocidad y dúplex. Además, utilice un programa analizador de protocolos para revisar los paquetes que entran y salen de la interfaz Fast Ethernet del router. Para evitar los descartes de paquetes en el dispositivo conectado con el switch de Catalyst, ejecute el comando ip cef en la interfaz Fast Ethernet del dispositivo conectado con el 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 admiten interfaces de L3 y el puerto de switch de L2, se muestra el mensaje “Comando rechazado: [interfaz] no es un puerto de switching” cuando intenta ingresar un comando relacionado con la capa 2 en un puerto configurado como interfaz de capa 3.
Para convertir la interfaz de modo de capa 3 a 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 los puertos de la plataforma funcionan de manera diferente con respecto a STP. Por ejemplo, Catalyst 1900/2820 muestra los puertos en color naranja cuando se encuentran en el modo de bloqueo de 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 interface y verifique si la interfaz está en un estado de apagado:
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 el modo de apagado inmediatamente después del 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 observa 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 las interfaces están apagados como resultado de la deshabilitación por error, se conocen como causas en Cisco IOS. Las causas de esto varían entre una configuración incorrecta de EtherChannel que provoca una intermitencia de PAgP, una incompatibilidad de dúplex, la protección de puertos BPDU y PortFast configurados al mismo tiempo, la UDLD que detecta un enlace unidireccional, etc.
Debe habilitar manualmente el puerto o la interfaz de nuevo 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 Recuperación del estado de deshabilitación por error de un puerto en las plataformas Cisco IOS para obtener más información sobre el estado de deshabilitación por error en los switches que ejecutan Cisco IOS.
En esta tabla se muestra un ejemplo de los comandos utilizados para configurar, verificar y solucionar problemas del estado de deshabilitación por error en los switches. Diríjase al enlace para obtener más información sobre los comandos en Recuperación del estado de deshabilitación por error de un puerto en las plataformas Cisco IOS:
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 la existencia de puertos inactivos en los switches que ejecutan Cisco IOS es cuando la VLAN a la que pertenecen desaparece. 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 (ámbar) fija en cada puerto cuando esto ocurre.
Utilice el comando show interfaces card-type {slot/port} switchport junto con show vlan para verificar.
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í. ConsulteComprensión y Configuración del VLAN Trunk Protocol (VTP) para obtener más información sobre el VTP.
Nota: Si la salida del comando show interface <interface> switchport muestra el puerto como puerto trunk incluso después de configurar el puerto como puerto de acceso con el comando switchport access vlan <vlan> , ejecute el comando switchport mode access 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 interfaces 10-Gigabit Ethernet y Gigabit Ethernet SFP, 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 funcionalidad 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 suele ocurrir en entornos semidúplex donde la portadora ya está en uso al intentar 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 del contador de diferidos aumenta en Gigabit Ethernet del 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 una PC; el switch solo sabe que el puerto ha cambiado de 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, por lo que la función solo sirve para los puertos de host.
Verifique el modo de trunking en cada lado del link. Asegúrese de que ambos lados estén en el mismo modo (ambos enlaces troncales con el mismo método: ISL u 802.1q o ambos sin enlace troncal). 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 coincidir en el formato que utilizan en el enlace o no se entenderán entre sí.
Para Cisco IOS, use el comando show interfaces card-type {mod/port} trunk para verificar la configuración de trunking y la VLAN Nativa.
Router#show 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 enviando primero un ping desde el switch conectado directamente y, luego, regrese puerto por puerto, interfaz por interfaz, enlace troncal por enlace troncal hasta encontrar el origen del problema de conectividad. Compruebe que todos los switches puedan ver la dirección MAC del dispositivo final en la 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 realmente tiene la dirección MAC del dispositivo en la tabla de CAM, determine si este dispositivo está en la misma VLAN o en una diferente desde la que intenta hacer ping.
Si el dispositivo final está en una VLAN diferente desde la que intenta hacer ping, se debe configurar un switch o router de 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. Verifique la dirección IP, la máscara de subred, el gateway predeterminado, la configuración del protocolo de routing dinámico, las rutas estáticas, etc.
Si las estaciones no pueden comunicarse con sus servidores principales cuando se conectan a través del switch, el problema puede implicar retardos en el puerto de switch cuando intenta activarse después de que se activa el enlace de la capa física. En algunos casos, estas demoras pueden alcanzar los 50 segundos. Algunas estaciones de trabajo simplemente no pueden esperar tanto tiempo para encontrar el servidor y abandonan el intento. 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 switchport host para inhabilitar la canalización y para habilitar spanning-tree portfast y el comando switchport nonegotiate para desactivar los paquetes de negociación DTP. Use 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 global spanning-tree portfast default para aplicar de forma automática 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 usar el comando spanning-tree portfast por interfaz, para ello es necesario desactivar el trunking y EtherChannel por separado para ayudar a solucionar las demoras en el inicio de la estación de trabajo.
Nota: Refiérase a Uso de Portfast y Otros Comandos para Corregir Demoras de Conectividad de Inicio de Estación de Trabajo para obtener más información sobre cómo corregir las demoras 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 y el dúplex se produce cuando los ajustes de dúplex no coinciden entre dos switches, entre un switch y un router, o entre un switch y una estación de trabajo o un 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. El CDP es propiedad de Cisco y funciona enviando 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 6000 Series que ejecutan Cisco IOS. Estos mensajes generalmente le dicen cuál es la discordancia y dónde se produce.
Jun 2 11:16:45 %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet6/2 (not half duplex), with TBA04251336 3/2 (half duplex).
Utilice el comando show cdp neighbors card-type <slot/port> detail 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#
El ajuste de velocidad automática/dúplex en un lado y 100/dúplex completo en el otro se considera una configuración incorrecta y puede provocar una incompatibilidad de dúplex. Si el puerto de switch recibe muchas colisiones tardías, esto indica generalmente un problema de incompatibilidad de dúplex y, como resultado, puede poner al puerto en el estado de deshabilitación por error. El lado del semidúplex solo espera paquetes en ciertos 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 aparte de la incompatibilidad de dúplex, aunque esta es una de las más habituales. Siempre configure ambos lados de la conexión para que negocien automáticamente la configuración de velocidad y dúplex o ajústela 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. Use los comandos speed and duplexs del modo de configuración de interfaz para ajustar manualmente ambos lados a 10 o 100 y semidúplex o dúplex completo, según convenga.
Router#show interfaces fastEthernet 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 logró a través de la negociación automática o no.
Router#show interface 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 solucionar problemas de negociación automática suele recomendarse codificar ambos lados. Si no funciona la negociación automática ni la codificación, puede haber un problema con el firmware o el software de la 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 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 las NIC para obtener información sobre cómo resolver los problemas 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 bucle de STP cuando un puerto de bloqueo del STP en una topología redundante pasa al estado de reenvío erróneamente. Esto generalmente sucede porque uno de los puertos de una topología redundante físicamente (no necesariamente el puerto de bloqueo del STP) dejó de recibir BPDU del 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, se designa el puerto de bloqueo del puerto de respaldo o alternativo y se pasa al estado de reenvío. Esta situación crea un loop.
La función de protección de loop hace verificaciones adicionales. Si ya no se reciben BPDU en un puerto no designado y la protección contra bucles está habilitada, dicho puerto se pasa al estado de bloqueo de impedimento de bucles de STP en lugar de pasarse al 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 Configuración de STP con protección contra loops y detección de desviación de BPDU para obtener más información sobre la función de protección contra loops.
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 sobre problemas UDLD: enlace unidireccional de este documento.
Un enlace unidireccional es un enlace en el que el tráfico sale en un sentido, pero no se recibe tráfico en la dirección de entrada. El switch no sabe que la dirección de entrada del enlace es incorrecta (el puerto cree que el enlace 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 los switches que ejecutan Cisco IOS (consulte las notas de la versión para conocer la disponibilidad del comando) para las conexiones punto a punto entre switches donde no se toleran los enlaces unidireccionales. Esta función ayuda a identificar problemas con los links unidireccionales de difícil detección
Consulte Configuración de la Función de Protocolo UDLD para obtener información de configuración sobre UDLD.
Si se presenta una gran cantidad de tramas diferidas o descartadas (también denominadas "perdidas" en algunas plataformas), significa que los búferes de salida del switch se llenaron 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 error para 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
Los paquetes que envía la red a través de este puerto pueden ser demasiados para que el puerto los maneje con la configuración de velocidad/dúplex actual. 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 enlaces de 10 Mbps a enlaces de 100 Mbps 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 Gigabit conectado que utiliza el protocolo de datagramas de usuario (UDP) con un tamaño de ventana de 32 K es un ejemplo de configuración de aplicación que puede provocar este tipo de problema. Si ha revisado o intentado lo que indican otras sugerencias de este documento (la configuración de velocidad/dúplex, que no haya errores físicos en el enlace, que todo el tráfico sea normal y válido, etc.), reduzca el tamaño de la unidad que envía la aplicación para aliviar este problema.
Si observa un comportamiento que solo puede considerarse extraño, puede aislarlo en un cuadro específico y, si ha analizado todo lo sugerido hasta ahora, esto 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 version para verificar la versión de software actual junto con el comando dir flash : o dir bootflash : (depende de la plataforma) para verificar la memoria flash disponible para la actualización:
Router#show version Cisco Internetwork Operating System Software Cisco 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, abra el enlace, elija su plataforma y consulte la sección Configuración de 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 estar dañada. Para obtener información sobre la recuperación de imágenes dañadas, elija el switch de su plataforma y consulte la sección Solució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 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 switches Catalyst 3750, 3550, 2970, 2950/2955 y 2900/3500XL Series utilice el comando show post, que indica un simple paso o falla para el estado de 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 obtener información sobre posibles problemas relacionados con avisos importantes, consulte Avisos Importantes para Switches LAN y ATM.
De forma predeterminada, todos los puertos capa 2 se encuentran en el modo deseable dinámico, por lo que el puerto capa 2 intenta formar un link de trunk y envía paquetes 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 acceso estático o trunk según su requisito.
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, algunos incrementos de descarte de paquetes son normales y son 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 multiplexan de manera eficaz el grupo en una única conexión Gigabit Ethernet de dúplex completo sin bloqueo a la estructura de switch interna. 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 un flujo de ráfagas de tráfico cortas cuando algunos paquetes llenan el 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 switching Gigabit Ethernet no se utiliza por completo, puede equilibrar las conexiones de puertos en las agrupaciones 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.
Los descartes de protocolo desconocido son un contador en la interfaz. Se debe a protocolos que el router o el switch no comprenden. Este ejemplo del comando show run interface muestra las caídas de protocolo desconocido 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 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 Módulo/Interfaz para obtener más información sobre la suscripción en exceso.
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 el encapsulamiento dot1q en una subinterfaz, ya no puede utilizar esa VLAN en el sistema porque 6500 o 7600 asignan internamente la VLAN y hacen que esa subinterfaz sea su único miembro. Para resolver este problema, cree puertos de enlace troncal en lugar de subinterfaces. De esa manera, la VLAN se puede considerar en todas las interfaces.
Por lo general, los descartes en la salida pueden ocurrir si la QoS está configurada y no proporciona suficiente ancho de banda a cierta clase de paquetes. También ocurre cuando el hardware alcanza una suscripción excesiva.
Por ejemplo, aquí puede ver una gran cantidad de descartes en la salida en la interfaz Gigabit Ethernet 8/9 en un switch Catalyst de la serie 6500:
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 capacity
mostrar el medidor de tráfico de Catalyst6000
show platform hardware capacity rewrite-engine drop
Este ejemplo del comando show interface muestra el Last input never en 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 de paquetes de interfaz exitosa a otro punto final o terminal. Esto significa generalmente que no hubo transferencia de paquetes en relación con esa entidad.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
03-Nov-2023 |
Recertificación |
1.0 |
04-Dec-2001 |
Versión inicial |