Resolución de problemas de inestabilidad de puerto en switches Catalyst 9000
Contenido
Problema
Este documento describe cómo resolver problemas de una o más interfaces de switch que cambian repetidamente el estado entre activo y inactivo (inestabilidad de puerto o inestabilidad de link), lo que causa conectividad intermitente.
Entorno
Switches Catalyst de Cisco serie 9000 con enlaces ascendentes/descendentes de cobre o fibra. El problema puede ocurrir en puertos de acceso, enlaces ascendentes y (cuando están presentes) puertos de módulos de red extraíbles. La ruta física puede incluir paneles de conexión, dispositivos de terminales y transceptores ópticos.
- Aplicabilidad de medios: El TDR se aplica únicamente a las interfaces de cobre; DOM sólo se aplica a los transceptores ópticos compatibles.
- Tipos de interfaz: Los puertos fijos independientes y los puertos de módulo están dentro del alcance; utilice el mismo flujo de trabajo para cualquiera de ellos.
- Compatibilidad con óptica: Utilice únicamente la óptica admitida para la plataforma y la versión de software.
Causa
Entre las causas habituales se incluyen el cableado defectuoso o no compatible, los transceptores Small Form-Factor Pluggable (SFP) o Small Form-Factor Pluggable Plus (SFP+) defectuosos, las discrepancias de negociación o dúplex, el comportamiento de ahorro de energía de los terminales y otros fallos de la capa física.
Resolución
Siga el flujo de trabajo de solución de problemas de este artículo para confirmar la inestabilidad en los registros, validar la conectividad física y la óptica, revisar los contadores de interfaz y ejecutar comprobaciones de DOM de sólo cobre o TDR de sólo fibra según corresponda.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
La información de este documento se basa en los switches Catalyst de Cisco serie 9000.
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.
Antecedentes
Una inestabilidad de puerto, también conocida como inestabilidad de link, ocurre cuando una interfaz física en el switch sube y baja repetidamente. Entre las causas habituales se incluyen el cableado no estándar, no compatible o no estándar, los transceptores Small Form-Factor Pluggable (SFP) no compatibles y otros problemas de sincronización de enlaces. La condición puede ser intermitente o permanente.
Dado que los flaps de links tienden a ser un problema físico, este documento describe cómo diagnosticar el problema, recopilar registros útiles y resolver problemas de flaps de puertos en los switches Catalyst de Cisco serie 9000.
Troubleshooting de Flujo
Utilice este flujo de trabajo para aislar las causas más comunes de las inestabilidad de puertos. Comience en el paso 1 y continúe en el orden indicado. Ejecute los pasos opcionales sólo cuando el tipo de vínculo y los síntomas coincidan.
- Confirme la inestabilidad en los registros. Utilice show logging para confirmar los eventos de encendido/apagado repetidos y capturar las marcas de tiempo.
- Compruebe la conectividad física y la óptica. Verifique el cableado, los paneles de conexión y los transceptores compatibles; vuelva a colocar o cambie los componentes por otros que funcionen correctamente.
- Revise los contadores de la interfaz y las estadísticas del hardware. Utilice show interfaces y los contadores del controlador para identificar los errores de Capa 1 (CRC, errores de símbolos, errores FCS).
- Ejecute TDR (sólo enlaces de cobre). Utilice TDR para detectar condiciones ABIERTAS/CORTAS y una distancia aproximada a la falla.
- Marque DOM (sólo enlaces de fibra). Revise la potencia/temperatura/voltaje ópticos en relación con los umbrales de la hoja informativa.
- Verifique FEC (sólo óptica admitida). Confirme la configuración y la compatibilidad de Forward Error Correction cuando corresponda.
- Utilice los comandos debugsolamente si el problema persiste. Recopile la salida de debug dirigida durante una ventana de reproducción y desactívela inmediatamente después de la captura.
Cada sección incluye una breve nota que indica cuándo utilizarla.
Utilice esta sección cuando haya disponible acceso físico. Verifique que los módulos de red, los cables y los transceptores SFP o SFP+ estén correctamente instalados antes de revisar los contadores o ejecutar diagnósticos adicionales.
Referencia de instalación del módulo de red
Utilice esta referencia cuando haya un módulo de red extraíble. En la tabla se describen las prácticas recomendadas para instalar un módulo de red en un switch Catalyst de Cisco serie 9000:
| Platform |
URL |
| Catalyst 9200 Series Switches |
Guía de instalación de hardware de los switches Catalyst serie 9200 |
| Catalyst 9300 Series Switches |
Guía de Instalación de Hardware de Catalyst 9300 Series Switches |
| Catalyst 9400 Series Switches |
Guía de Instalación de Hardware de Catalyst 9400 Series Switches |
| Catalyst 9500 Series Switches |
Guía de instalación de hardware de los switches Catalyst serie 9500 |
| Catalyst 9600 Series Switches |
Guía de instalación de hardware de los switches Catalyst serie 9600 |
Verificación del cable y ambos lados de la conexión
Utilice esta sección después de que se confirme la inestabilidad en los registros. Estas tablas describen causas comunes relacionadas con el cable de las inestabilidad de link y las acciones de recuperación recomendadas.
| Causa |
Acción de recuperación |
| Cable en malas condiciones |
Cambie el cable sospechoso por otro que funcione correctamente. Busque los conectores o pins quebrados o faltantes. |
| Conexión floja |
Vuelva a colocar el cable. Desmonte el conector y vuelva a montarlo para asegurarse de que queda debidamente asentado. |
| Patch Panels |
Elimine las conexiones defectuosas del panel de conexiones. Si es posible, omita el panel de parches para descartarlo. |
| SFP incorrecto o incorrecto (específico de fibra) |
Intercambie el SFP sospechoso con un SFP de funcionalidad comprobada. Verifique el soporte de hardware y software para este tipo de SFP. |
| Puerto o puerto de módulo incorrecto |
Mueva el cable a un puerto de funcionalidad comprobada para resolver problemas de un puerto o módulo sospechoso. |
| Dispositivo de terminal antiguo o defectuoso |
Cambie el teléfono, el altavoz u otro terminal por otro que funcione correctamente o un dispositivo más reciente. |
| Modo de suspensión del dispositivo |
Esto puede ser una inestabilidad esperada. Verifique la marca de tiempo de la inestabilidad del puerto. Compárelo con otros eventos simultáneos. A continuación, determine si la causa es un ajuste de suspensión. |
Verifique la compatibilidad de SFP y SFP+
Utilice esta sección cuando el enlace inestable utilice un transceptor de fibra. La cartera de Cisco de interfaces conectables en caliente ofrece una amplia gama de opciones para velocidades, protocolos, alcances y medios de transmisión compatibles.
Utilice cualquier combinación de módulos transmisores SFP o SFP+ que admita el switch Catalyst de Cisco serie 9000. Cada puerto debe coincidir con las especificaciones de longitud de onda en el otro extremo del cable. El cable no debe exceder la longitud del cable soportado para una comunicación confiable.
Utilice únicamente módulos transmisores SFP de Cisco en el dispositivo de Cisco. Cada módulo transceptor SFP o SFP+ admite la función Cisco Quality Identification (ID). Esta función permite que un switch o router de Cisco identifique y valide que el módulo transceptor está certificado y probado por Cisco.
Identificación de inestabilidades de puerto
Requisitos previos: Acceso EXEC privilegiado (por ejemplo, enable) y acceso al buffer de registro del sistema del dispositivo o syslog remoto.
Resultado esperado: Los mensajes de arriba/abajo repetidos para la misma interfaz dentro de una ventana de tiempo corto confirman una condición de inestabilidad.
Utilice primero esta sección para confirmar que se está produciendo una inestabilidad. Ejecute el show logging | include changed comando para identificar un evento de inestabilidad de link. Este ejemplo muestra mensajes de registro del sistema de switch parcial para un evento de inestabilidad de link en la interfaz TenGigabitEthernet1/0/40:
Switch#show logging | include changed
August 17 21:06:08.431 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:06:39.058 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:06:41.968 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:06:42.969 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:07:20.041 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:07:21.041 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:07:36.534 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:06.598 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:07.628 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:08:08.628 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:08:10.943 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:11.944 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
- Identifique la marca de tiempo de cada transición hacia arriba o hacia abajo.
- Compare la marca de tiempo con otros eventos de la misma interfaz (por ejemplo, el comportamiento de ahorro de energía de los terminales).
- Determine si la inestabilidad es esperada o indica un problema de capa física.
Comandos show de la interfaz
Cuándo se debe utilizar: Después de que se confirmen los eventos de encendido/apagado repetidos y se valide la ruta física.
Comando: show interfaces y show controllers ethernet-controller interface para la interfaz afectada.
Resultado esperado: Los contadores de errores (CRC, errores de símbolos, FCS) permanecen estables o aumentan lentamente en condiciones normales.
Siguiente acción si es anormal: Cambie el cable/óptica, muévalos a un puerto que se sepa que es correcto y vuelva a comprobar los contadores; vaya a TDR (cobre) o DOM (fibra), según corresponda.
Utilice esta sección después de que se confirme la inestabilidad y se verifique la trayectoria física. El comando show interfaces proporciona información que ayuda a identificar un posible problema de Capa 1 que causa un evento de inestabilidad de link:
Switch#show interfaces tenGigabitEthernet 1/0/40
TenGigabitEthernet1/0/40 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is 00a5.bf9c.29a8 (bia 00a5.bf9c.29a8)
MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 10Gb/s, link type is auto, media type is SFP-10GBase-SR <-- SFP plugged into the port
input flow-control is on, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:03, output 00:00:00, 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
670 packets input, 78317 bytes, 0 no buffer
Received 540 broadcasts (540 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 540 multicast, 0 pause input
0 input packets with dribble condition detected
1766 packets output, 146082 bytes, 0 underruns
0 Output 0 broadcasts (0 multicasts)
0 output errors, 0 collisions, 0 interface resets
0 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
La tabla enumera algunos de los contadores del comando show interfaces:
| Contador |
Problemas y causas comunes que aumentan los contadores de errores |
| CRC |
Un elevado número de errores de verificación por redundancia cíclica (CRC) suele ser el resultado de colisiones. También puede indicar un problema físico como el cableado, un SFP, una interfaz defectuosa o una tarjeta de interfaz de red (NIC). También puede indicar una discordancia dúplex. |
| Errores de Entrada |
Estos incluyen los recuentos ignorados, de fragmentos de tramas minúsculos y gigantes, de falta de buffer, de CRC y de exceso. Otros errores relacionados con la entrada también pueden aumentar el número de errores de entrada. |
| errores de salida |
Los errores de salida pueden aumentar cuando la cola de salida está subdimensionada o cuando la interfaz está sobresuscrita. |
| Caídas totales de resultados |
Las caídas de salida son generalmente el resultado de una sobresuscripción de interfaz causada por patrones de tráfico de varios a uno o una transferencia de 10 Gbps a 1 Gbps. Los búferes de interfaz son un recurso limitado y pueden absorber una ráfaga sólo hasta un punto. Después de ese punto, los paquetes comienzan a descartarse. Los búferes se pueden ajustar para proporcionar un poco de amortiguación, pero no pueden garantizar cero caídas de salida. |
| Caídas de protocolo desconocidas |
Las caídas de protocolo desconocidas ocurren cuando la interfaz receptora no está configurada para ese protocolo o cuando el switch no reconoce el protocolo. Por ejemplo, si dos switches están conectados y Cisco Discovery Protocol (CDP) está inhabilitado en una interfaz de switch, se producen caídas de protocolos desconocidos en esa interfaz. Los paquetes CDP ya no se reconocen y el switch los descarta. |
El comando history permite que una interfaz mantenga el historial de uso en un formato gráfico similar al historial de la CPU. El historial se puede mantener como bits por segundo (bps) o paquetes por segundo (pps), como se muestra en este ejemplo:
Switch(config-if)#history ?
bps Maintain history in bits/second
pps Maintain history in packets/second
Junto con la velocidad, se pueden monitorear varios contadores de interfaz:
Switch(config-if)#history [bps|pps] ?
all Include all counters
babbles Include ethernet output babbles - Babbl
crcs Include CRCs - CRCs
deferred Include ethernet output deferred - Defer
dribbles Include dribbles - Dribl
excessive-collisions Include ethernet excessive output collisions -
ExCol
flushes Include flushes - Flush
frame-errors Include frame errors - FrErr
giants Include giants - Giant
ignored Include ignored - Ignor
input-broadcasts Include input broadcasts - iBcst
input-drops Include input drops - iDrop
input-errors Include input errors - iErr
interface-resets Include interface resets - IRset
late-collisions Include ethernet late output collisions - LtCol
lost-carrier Include ethernet output lost carrier - LstCr
multi-collisions Include ethernet multiple output collisions -
MlCol
multicast Include ethernet input multicast - MlCst
no-carrier Include ethernet output no-carrier - NoCarr
output-broadcasts Include output broadcasts - oBcst
output-buffer-failures Include output buffer failures - oBufF
output-buffers-swapped-out Include output buffers swapped out - oBSwO
output-drops Include output drops - oDrop
output-errors Include output errors - oErr
output-no-buffer Include output no buffer - oNoBf
overruns Include overruns - OvrRn
pause-input Include ethernet input pause - PsIn
pause-output Include ethernet output pause - PsOut
runts Include runts - Runts
single-collisions Include ethernet single output collisions - SnCol
throttles Include throttles - Thrtl
underruns Include underruns - UndRn
unknown-protocol-drops Include unknown protocol drops - Unkno
watchdog Include ethernet output watchdog - Wtchdg
<cr> <cr>
SW_1(config-if)#
Al igual que con el historial de la CPU, los gráficos están disponibles durante los últimos 60 segundos, los últimos 60 minutos y las últimas 72 horas. Se mantienen gráficos separados para los histogramas de entrada y salida:
Switch#show interfaces gigabitEthernet 1/0/2 history ?
60min Display 60 minute histograms only
60sec Display 60 second histograms only
72hour Display 72 hour histograms only
all Display all three histogram intervals
both Display both input and output histograms
input Display input histograms only
output Display output histograms only
| Output modifiers
<cr> <cr>
------ Sample output ---------
Switch#show interfaces tenGigabitEthernet 1/0/9 history 60sec
10
9
8
7
6
5
4
3
2
1
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
TenGigabitEthernet1/0/9 input rate(mbits/sec) (last 60 seconds)
10
9
8
7
6
5
4
3
2
1
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
TenGigabitEthernet1/0/9 output rate(mbits/sec) (last 60 seconds)
Utilice el comando show controllers ethernet-controller interface {interface{interface-number}} para mostrar los contadores de tráfico por interfaz (transmisión y recepción) y las estadísticas de error leídas del hardware. Utilice la palabra clave phy para mostrar los registros internos de la interfaz. Utilice la palabra clave port-info para mostrar información sobre el circuito integrado específico de la aplicación de puerto (ASIC).
Este es un ejemplo del resultado de show controllers ethernet-controller para una interfaz específica:
Switch#show controllers ethernet-controller tenGigabitEthernet 2/0/1
Transmit TenGigabitEthernet2/0/1 Receive
61572 Total bytes 282909 Total bytes
0 Unicast frames 600 Unicast frames
0 Unicast bytes 38400 Unicast bytes
308 Multicast frames 3163 Multicast frames
61572 Multicast bytes 244509 Multicast bytes
0 Broadcast frames 0 Broadcast frames
0 Broadcast bytes 0 Broadcast bytes
0 System FCS error frames 0 IpgViolation frames
0 MacUnderrun frames 0 MacOverrun frames
0 Pause frames 0 Pause frames
0 Cos 0 Pause frames 0 Cos 0 Pause frames
0 Cos 1 Pause frames 0 Cos 1 Pause frames
0 Cos 2 Pause frames 0 Cos 2 Pause frames
0 Cos 3 Pause frames 0 Cos 3 Pause frames
0 Cos 4 Pause frames 0 Cos 4 Pause frames
0 Cos 5 Pause frames 0 Cos 5 Pause frames
0 Cos 6 Pause frames 0 Cos 6 Pause frames
0 Cos 7 Pause frames 0 Cos 7 Pause frames
0 Oam frames 0 OamProcessed frames
0 Oam frames 0 OamDropped frames
193 Minimum size frames 3646 Minimum size frames
0 65 to 127 byte frames 1 65 to 127 byte frames
0 128 to 255 byte frames 0 128 to 255 byte frames
115 256 to 511 byte frames 116 256 to 511 byte frames
0 512 to 1023 byte frames 0 512 to 1023 byte frames
0 1024 to 1518 byte frames 0 1024 to 1518 byte frames
0 1519 to 2047 byte frames 0 1519 to 2047 byte frames
0 2048 to 4095 byte frames 0 2048 to 4095 byte frames
0 4096 to 8191 byte frames 0 4096 to 8191 byte frames
0 8192 to 16383 byte frames 0 8192 to 16383 byte frames
0 16384 to 32767 byte frame 0 16384 to 32767 byte frame
0 > 32768 byte frames 0 > 32768 byte frames
0 Late collision frames 0 SymbolErr frames <-- Usually indicates Layer 1 issues. Large amounts of symbol errors can indicate a bad device, cable, or hardware.
0 Excess Defer frames 0 Collision fragments <-- If this counter increments, this is an indication that the ports are configured at half-duplex.
0 Good (1 coll) frames 0 ValidUnderSize frames
0 Good (>1 coll) frames 0 InvalidOverSize frames
0 Deferred frames 0 ValidOverSize frames
0 Gold frames dropped 0 FcsErr frames <-- Are the result of collisions at half-duplex, a duplex mismatch, bad hardware (NIC, cable, or port)
0 Gold frames truncated
0 Gold frames successful
0 1 collision frames
0 2 collision frames
0 3 collision frames
0 4 collision frames
0 5 collision frames
0 6 collision frames
0 7 collision frames
0 8 collision frames
0 9 collision frames
0 10 collision frames
0 11 collision frames
0 12 collision frames
0 13 collision frames
0 14 collision frames
0 15 collision frames
0 Excess collision frames
LAST UPDATE 22622 msecs AGO
Utilice el comando show platform pm interface-flaps {interface{interface-number}} para mostrar el número de veces que una interfaz deja de funcionar:
Este es un ejemplo del resultado de show platform pm interface-flaps {interface{interface-number}} para una interfaz específica:
Switch#show platform pm interface-flaps tenGigabitEthernet 2/0/1 Field AdminFields OperFields =============================================================== Access Mode Static Static Access Vlan Id 1 0 Voice Vlan Id 4096 0 VLAN Unassigned 0 ExAccess Vlan Id 32767 Native Vlan Id 1 Port Mode dynamic access Encapsulation 802.1Q Native disl auto Media unknown DTP Nonegotiate 0 0 Port Protected 0 0 Unknown Unicast Blocked 0 0 Unknown Multicast Blocked 0 0 Vepa Enabled 0 0 App interface 0 0 Span Destination 0 Duplex auto full Default Duplex auto Speed auto 1000 Auto Speed Capable 1 1 No Negotiate 0 0 No Negotiate Capable 1024 1024 Flow Control Receive ON ON Flow Control Send Off Off Jumbo 0 0 saved_holdqueue_out 0 saved_input_defqcount 2000 Jumbo Size 1500 Forwarding Vlans : none Current Pruned Vlans : none Previous Pruned Vlans : none Sw LinkNeg State : LinkStateUp No.of LinkDownEvents : 12 <-- Number of times the interface flapped XgxsResetOnLinkDown(10GE): Time Stamp Last Link Flapped(U) : Aug 19 14:58:00.154 <-- Last time the interface flapped LastLinkDownDuration(sec) 192 <-- Time in seconds the interface stayed down during the last flap event LastLinkUpDuration(sec): 2277 <-- Time in seconds the interface stayed up before the last flap event
Utilice esta sección para los enlaces de fibra cuando deba verificarse el estado de los cables ópticos. Utilice el comando show idprom interface {interface-number} para mostrar la información IDPROM para el transceptor instalado en la interfaz especificada. Utilice la palabra clave detail para mostrar campos IDPROM hexadecimales detallados.
Este ejemplo muestra el resultado del comando show idprom {interface{interface-number}} para una interfaz específica. Los valores High y Low Warning|Alarm umbrales que se enumeran en este resultado del comando son los parámetros normales del transceptor óptico en funcionamiento. Estos valores se pueden verificar en la hoja de datos para la óptica específica. Consulte la Documentación de los Módulos del Transceiver de Óptica de Cisco.
Switch#show idprom interface Twe1/0/1
IDPROM for transceiver TwentyFiveGigE1/0/1 :
Description = SFP or SFP+ optics (type 3)
Transceiver Type: = GE CWDM 1550 (107)
Product Identifier (PID) = CWDM-SFP-1550 <--
Vendor Revision = A
Serial Number (SN) = SERIALNUMBER
Vendor Name = CISCO-FINISAR
Vendor OUI (IEEE company ID) = 00.90.65 (36965)
Common Language Equipment Identifier (CLEI) code = CNTRV14FAB
Cisco part number = 10-1879-03
Device State = Enabled.
Date code (yy/mm/dd) = 14/12/22
Connector type = LC.
Encoding = 8B10B (1)
Nominal bitrate = OTU-1 (2700 Mbits/s)
Minimum bit rate as % of nominal bit rate = not specified
Maximum bit rate as % of nominal bit rate = not specified
The transceiver type is 107
Link reach for 9u fiber (km) = LR-2(80km) (80)
LR-3(80km) (80)
ZX(80km) (80)
Link reach for 9u fiber (m) = IR-2(40km) (255)
LR-1(40km) (255)
LR-2(80km) (255)
LR-3(80km) (255)
DX(40KM) (255)
HX(40km) (255)
ZX(80km) (255)
VX(100km) (255)
Link reach for 50u fiber (m) = SR(2km) (0)
IR-1(15km) (0)
IR-2(40km) (0)
LR-1(40km) (0)
LR-2(80km) (0)
LR-3(80km) (0)
DX(40KM) (0)
HX(40km) (0)
ZX(80km) (0)
VX(100km) (0)
1xFC, 2xFC-SM(10km) (0)
ESCON-SM(20km) (0)
Link reach for 62.5u fiber (m) = SR(2km) (0)
IR-1(15km) (0)
IR-2(40km) (0)
LR-1(40km) (0)
LR-2(80km) (0)
LR-3(80km) (0)
DX(40KM) (0)
HX(40km) (0)
ZX(80km) (0)
VX(100km) (0)
1xFC, 2xFC-SM(10km) (0)
ESCON-SM(20km) (0)
Nominal laser wavelength = 1550 nm.
DWDM wavelength fraction = 1550.0 nm.
Supported options = Tx disable
Tx fault signal
Loss of signal (standard implementation)
Supported enhanced options = Alarms for monitored parameters
Diagnostic monitoring = Digital diagnostics supported
Diagnostics are externally calibrated
Rx power measured is "Average power"
Transceiver temperature operating range = -5 C to 75 C (commercial)
Minimum operating temperature = 0 C
Maximum operating temperature = 70 C
High temperature alarm threshold = +90.000 C
High temperature warning threshold = +85.000 C
Low temperature warning threshold = +0.000 C
Low temperature alarm threshold = -4.000 C
High voltage alarm threshold = 3600.0 mVolts
High voltage warning threshold = 3500.0 mVolts
Low voltage warning threshold = 3100.0 mVolts
Low voltage alarm threshold = 3000.0 mVolts
High laser bias current alarm threshold = 84.000 mAmps
High laser bias current warning threshold = 70.000 mAmps
Low laser bias current warning threshold = 4.000 mAmps
Low laser bias current alarm threshold = 2.000 mAmps
High transmit power alarm threshold = 7.4 dBm
High transmit power warning threshold = 4.0 dBm
Low transmit power warning threshold = -1.7 dBm
Low transmit power alarm threshold = -8.2 dBm
High receive power alarm threshold = -3.0 dBm
Low receive power alarm threshold = -33.0 dBm
High receive power warning threshold = -7.0 dBm
Low receive power warning threshold = -28.2 dBm
External Calibration: bias current slope = 1.000
External Calibration: bias current offset = 0
Esta tabla enumera los comandos que se pueden utilizar para resolver problemas de inestabilidad de link. Orden de uso recomendado: show logging, show interfaces, show controllers ethernet-controller, show platform pm interface-flaps y luego comandos específicos de fibra o cobre según corresponda.
| Comando |
Propósito |
| show interfaces counters errors |
Muestra los contadores de errores de la interfaz. |
| show interfaces capabilities |
Muestra las capacidades de la interfaz específica. |
| show interface transceivers (fibra o SFP specific) |
Muestra información acerca de los transceptores ópticos que tienen habilitada la supervisión óptica digital (DOM). |
| show interface link |
Muestra información de nivel de vínculo. |
| show interface {interface{interface-number}} platform |
Muestra información de la plataforma de interfaz. |
| show controllers ethernet-controller {interface{interface-number}} port-info |
Muestra información adicional del puerto. |
| show controllers ethernet-controller {interface{interface-number}} link status detail |
Muestra el estado del vínculo. |
| show errdisable flap-values |
Muestra el número de flaps permitidos antes del estado errdisable. |
| clear counters |
Utilice este comando para poner a cero los contadores de tráfico y de errores, de modo que pueda ver si el problema es sólo temporal o si los contadores siguen aumentando. |
| clear controllers ethernet-controller |
Utilice este comando para borrar los contadores de transmisión y recepción de hardware. |
Verificación del estado del cable con Time Domain Reflector (TDR)
La función Time Domain Reflectometer (TDR) le permite determinar si un cable está ABIERTO o CORTO cuando se produce un fallo. Con TDR, puede verificar el estado de los cables de cobre para los puertos de los switches Catalyst serie 9000. El TDR detecta un fallo de cable con una señal que se envía a través del cable y lee la señal que se refleja hacia atrás. Toda o parte de la señal puede reflejarse de nuevo debido a defectos en el cable
Use el test cable-diagnostics tdr {interface{interface-number} } para iniciar la prueba de TDR y luego use el comando show cable-diagnostics tdr {interface-interface-number}.
El ejemplo muestra un resultado de la prueba TDR para la interfaz Tw2/0/10:
Switch#show cable-diagnostics tdr interface tw2/0/10
TDR test last run on: November 05 02:28:43
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Tw2/0/10 1000M Pair A 1 +/- 5 meters Pair A Impedance Mismatch
Pair B 1 +/- 5 meters Pair B Impedance Mismatch
Pair C 1 +/- 5 meters Pair C Open
Pair D 3 +/- 5 meters Pair D Open
Directrices de TDR
Estas directrices se aplican al uso de TDR:
- No cambie la configuración del puerto mientras se esté ejecutando la prueba TDR.
- Si conecta un puerto durante una prueba de TDR a un puerto habilitado para Auto-MDIX, el resultado de TDR puede ser inválido.
- Si conecta un puerto durante una prueba TDR a un puerto 100BASE-T como el del dispositivo, los pares no utilizados (4-5 y 7-8) se notifican como defectuosos porque el extremo remoto no termina estos pares.
- Debido a las características del cable, debe ejecutar la prueba de TDR varias veces para obtener resultados precisos.
- No cambie el estado del puerto (por ejemplo, quite el cable en el extremo cercano o lejano) porque los resultados pueden ser imprecisos.
- El TDR funciona mejor si el cable de prueba se desconecta del puerto remoto. De lo contrario, puede resultar difícil interpretar los resultados correctamente.
- TDR funciona a través de cuatro cables. En función de las condiciones del cable, el estado puede mostrar que un par está ABIERTO o EN CORTO, mientras que el resto de pares de cables se muestran como defectuosos. Esta operación es aceptable porque puede declarar un cable defectuoso siempre que un par de cables sea OPEN o SHORT.
- El objetivo de TDR es determinar la deficiencia del funcionamiento de un cable en lugar de localizar un cable defectuoso.
- Cuando el TDR localice un cable defectuoso, podrá utilizar una herramienta de diagnóstico de cables fuera de línea para diagnosticar mejor el problema.
- Los resultados de TDR pueden diferir entre ejecuciones en diferentes modelos de switches de Catalyst 9300 Series Switches debido a la diferencia de resolución de las implementaciones de TDR. Cuando esto ocurra, debe consultar la herramienta de diagnóstico del cable fuera de línea.
Monitorado óptico digital (DOM)
La supervisión óptica digital (DOM) es un estándar del sector diseñado para definir una interfaz digital que permita acceder a parámetros en tiempo real como:
- Temperatura
- Voltaje de alimentación del transceptor
- Corriente de desviación del láser
- Alimentación Tx óptica
- Potencia de Rx óptica
Cómo habilitar DOM
La tabla enumera los comandos que puede utilizar para activar/desactivar DOM para todos los tipos de transceptores en el sistema:
| Pasos |
Comando o acción |
Propósito |
| Paso 1 |
enable Ejemplo: switch > enable |
Habilita el modo EXEC físico. Ingrese su contraseña si se le pide que lo haga. |
| Paso 2 |
configure terminal Ejemplo: switch#configure terminal |
Ingresa en el modo de configuración global. |
| Paso 3 |
transceiver type all Ejemplo: switch(config)#transceiver type all |
Ingresa en el modo de configuración del tipo Transceiver. |
| Paso 4 |
control Ejemplo: switch(config)#monitoring |
Permite supervisar todos los transceptores ópticos. |
Utilice el comando show interfaces {interface{interface-number}} transceiver detail para mostrar la información del transceptor:
Switch#show interfaces hundredGigE 1/0/25 transceiver detail
ITU Channel not available (Wavelength not available),
Transceiver is internally calibrated.
mA: milliamperes, dBm: decibels (milliwatts), NA or N/A: not applicable.
++ : high alarm, + : high warning, - : low warning, -- : low alarm.
A2D readouts (if they differ), are reported in parentheses.
The threshold values are calibrated.
High Alarm High Warn Low Warn Low Alarm
Temperature Threshold Threshold Threshold Threshold
Port (Celsius) (Celsius) (Celsius) (Celsius) (Celsius)
--------- ----------------- ---------- --------- --------- ---------
Hu1/0/25 28.8 75.0 70.0 0.0 -5.0
High Alarm High Warn Low Warn Low Alarm
Voltage Threshold Threshold Threshold Threshold
Port (Volts) (Volts) (Volts) (Volts) (Volts)
--------- ----------------- ---------- --------- --------- ---------
Hu1/0/25 3.28 3.63 3.46 3.13 2.97
High Alarm High Warn Low Warn Low Alarm
Current Threshold Threshold Threshold Threshold
Port Lane (milliamperes) (mA) (mA) (mA) (mA)
--------- ---- --------------- ---------- --------- --------- ---------
Hu1/0/25 N/A 6.2 10.0 8.5 3.0 2.6
Optical High Alarm High Warn Low Warn Low Alarm
Transmit Power Threshold Threshold Threshold Threshold
Port Lane (dBm) (dBm) (dBm) (dBm) (dBm)
--------- ---- --------------- ---------- --------- --------- ---------
Hu1/0/25 N/A -2.2 1.7 -1.3 -7.3 -11.3
Optical High Alarm High Warn Low Warn Low Alarm
Receive Power Threshold Threshold Threshold Threshold
Port Lane (dBm) (dBm) (dBm) (dBm) (dBm)
--------- ---- --------------- ---------- --------- --------- ---------
Hu1/0/25 N/A -16.7 2.0 -1.0 -9.9 -13.9
Mensajes de Syslog de supervisión óptica digital
Esta sección describe los mensajes de syslog de violación de umbral más relevantes:
Niveles de temperatura de cables ópticos SFP
- Explicación: Estos mensajes de registro se generan cuando la temperatura es baja o excede los valores normales de operación óptica:
%SFF8472-3-THRESHOLD_VIOLATION: Te7/3: Temperature high alarm; Operating value: 88.7 C, Threshold value: 74.0 C.
%SFF8472-3-THRESHOLD_VIOLATION: Fo1/1/1: Temperature low alarm; Operating value: 0.0 C, Threshold value: 35.0 C.
Niveles de voltaje de la óptica SFP
- Explicación: Estos mensajes de registro se generan cuando el voltaje es bajo o excede los valores normales de funcionamiento óptico:
%SFF8472-3-THRESHOLD_VIOLATION: Gi1/1/3: Voltage high warning; Operating value: 3.50 V, Threshold value: 3.50 V.
%SFF8472-5-THRESHOLD_VIOLATION: Gi1/1: Voltage low alarm; Operating value: 2.70 V, Threshold value: 2.97 V.
Niveles de luz de cables ópticos SFP
- Explicación: Estos mensajes de registro se generan cuando la potencia de la luz es baja o excede los valores de funcionamiento óptico:
%SFF8472-3-THRESHOLD_VIOLATION: Gi1/0/1: Rx power high warning; Operating value: -2.7 dBm, Threshold value: -3.0 dBm.
%SFF8472-5-THRESHOLD_VIOLATION: Te1/1: Rx power low warning; Operating value: -13.8 dBm, Threshold value: -9.9 dBm.
Óptica de Cisco y corrección de errores de reenvío (FEC)
FEC es una técnica utilizada para detectar y corregir un determinado número de errores en un flujo de bits y anexa bits redundantes y código de comprobación de errores al bloque de mensajes antes de la transmisión. Como fabricante de módulos, Cisco se encarga de diseñar nuestros transceptores para cumplir con las especificaciones. Cuando el transceptor óptico funciona en una plataforma host de Cisco, la FEC se habilita de forma predeterminada en función del tipo de módulo óptico que detecte el software del host (consulte esta tabla descargable). En la gran mayoría de los casos, la implementación de la FEC viene dictada por el estándar del sector que admite el tipo óptico.
Para obtener información detallada sobre ciertas especificaciones personalizadas, las implementaciones de FEC varían. Consulte el documento Comprensión de FEC y su implementación en Cisco Optics.
El ejemplo muestra cómo configurar FEC y algunas de las opciones disponibles:
switch(config-if)#fec? auto Enable FEC Auto-Neg cl108 Enable clause108 with 25G cl74 Enable clause74 with 25G off Turn FEC off
Use the show interface command to verify FEC configuration:
TwentyFiveGigE1/0/13 is up, line protocol is up (connected)
Hardware is Twenty Five Gigabit Ethernet, address is 3473.2d93.bc8d (bia 3473.2d93.bc8d)
MTU 9170 bytes, BW 25000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 25Gb/s, link type is force-up, media type is SFP-25GBase-SR
Fec is auto < -- The configured setting for FEC is displayed here
input flow-control is on, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
--snip--
Comandos de Debug
Esta tabla enumera los diversos comandos que se pueden utilizar para debug Port Flaps
| Comando | Propósito |
| debug pm | Depuración de Port Manager |
| debug pm port | Eventos relacionados con los puertos |
| debug platform pm | Información de depuración del administrador de puertos de plataforma NGWC |
| debug platform pm l2-control | NGWC L2 Control Infra debug |
| debug platform pm link-status | Eventos de detección de link de interfaz |
| debug platform pm pm-vectors | Funciones vectoriales del administrador de puertos |
| debug condition interface <interface name> | Habilitar debugs selectivamente para una interfaz específica |
| debug interface state | Estados y transiciones |
Este es un ejemplo parcial de salida de ejemplo de los comandos debug listados en la tabla:
SW_2#sh debugging
PM (platform):
L2 Control Infra debugging is on <-- debug platform pm l2-control
PM Link Status debugging is on <-- debug platform pm link-status
PM Vectors debugging is on <-- debug platform pm pm-vectors
Packet Infra debugs:
Ip Address Port
------------------------------------------------------|----------
Port Manager:
Port events debugging is on <-- debug pm port
Condition 1: interface Te1/0/2 (1 flags triggered)
Flags: Te1/0/2
------ Sample output ---------
*Aug 25 20:01:05.791: link up/down event : link-down on Te1/0/2
*Aug 25 20:01:05.791: pm_port 1/2: during state access, got event 5(link_down) <-- Link down event (day/time)
*Aug 25 20:01:05.791: @@@ pm_port 1/2: access -> pagp
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Vp Disable: pd=0x7F1E797914B0 dpidx=10 Te1/0/2
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: Maintains count of VP per Interface:delete, pm_vp_counter[0]: 14, pm_vp_counter[1]: 14
*Aug 25 20:01:05.792: *** port_modechange: 1/2 mode_none(10)
*Aug 25 20:01:05.792: @@@ pm_port 1/2: pagp -> dtp
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 pagp
*Aug 25 20:01:05.792: *** port_bndl_stop: 1/2 : inform yes
*Aug 25 20:01:05.792: @@@ pm_port 1/2: dtp -> present
*Aug 25 20:01:05.792: *** port_dtp_stop: 1/2
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 pagp
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 dtp
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 unknown
*Aug 25 20:01:05.792: *** port_linkchange: reason_link_change(3): link_down(0)1/2 <-- State link change
*Aug 25 20:01:05.792: pm_port 1/2: idle during state present
*Aug 25 20:01:05.792: @@@ pm_port 1/2: present -> link_down <-- State of the link
*Aug 25 20:01:06.791: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/2, changed state to down
*Aug 25 20:01:07.792: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/2, changed state to down
*Aug 25 20:01:11.098: IOS-FMAN-PM-DEBUG-LINK-STATUS: Received LINKCHANGE in xcvr message, if_id 10 (TenGigabitEthernet1/0/2)
*Aug 25 20:01:11.098: IOS-FMAN-PM-DEBUG-LINK-STATUS: if_id 0xA, if_name Te1/0/2, link up <-- Link became up
*Aug 25 20:01:11.098: link up/down event: link-up on Te1/0/2
*Aug 25 20:01:11.098: pm_port 1/2: during state link_down, got event 4(link_up)
*Aug 25 20:01:11.098: @@@ pm_port 1/2: link_down -> link_up
*Aug 25 20:01:11.098: flap count for link type : Te1/0/2 Linkcnt = 0
*Aug 25 20:01:11.099: pm_port 1/2: idle during state link_up
*Aug 25 20:01:11.099: @@@ pm_port 1/2: link_up -> link_authentication
*Aug 25 20:01:11.099: pm_port 1/2: during state link_authentication, got event 8(authen_disable)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: link_authentication -> link_ready
*Aug 25 20:01:11.099: *** port_linkchange: reason_link_change(3): link_up(1)1/2
*Aug 25 20:01:11.099: pm_port 1/2: idle during state link_ready
*Aug 25 20:01:11.099: @@@ pm_port 1/2: link_ready -> dtp
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: pm_port 1/2: during state dtp, got event 13(dtp_complete)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: dtp -> dtp
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: DTP flapping: flap count for dtp type: Te1/0/2 Dtpcnt = 0
*Aug 25 20:01:11.099: pm_port 1/2: during state dtp, got event 110(dtp_done)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: dtp -> pre_pagp_may_suspend
*Aug 25 20:01:11.099: pm_port 1/2: idle during state pre_pagp_may_suspend
*Aug 25 20:01:11.099: @@@ pm_port 1/2: pre_pagp_may_suspend -> pagp_may_suspend
*Aug 25 20:01:11.099: pm_port 1/2: during state pagp_may_suspend, got event 33(pagp_continue)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: pagp_may_suspend -> start_pagp
*Aug 25 20:01:11.099: pm_port 1/2: idle during state start_pagp
*Aug 25 20:01:11.099: @@@ pm_port 1/2: start_pagp -> pagp
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: *** port_bndl_start: 1/2
*Aug 25 20:01:11.100: stop flap timer : Te1/0/2 pagp
*Aug 25 20:01:11.100: pm_port 1/2: during state pagp, got event 34(dont_bundle)
*Aug 25 20:01:11.100: @@@ pm_port 1/2: pagp -> pre_post_pagp
*Aug 25 20:01:11.100: pm_port 1/2: idle during state pre_post_pagp
*Aug 25 20:01:11.100: @@@ pm_port 1/2: pre_post_pagp -> post_pagp
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: pm_port 1/2: during state post_pagp, got event 14(dtp_access)
*Aug 25 20:01:11.100: @@@ pm_port 1/2: post_pagp -> access
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: Maintains count of VP per Interface:add, pm_vp_counter[0]: 15, pm_vp_counter[1]: 15
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: vlan vp enable for port(Te1/0/2) and vlan:1
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: VP ENABLE: vp_pvlan_port_mode:access for Te1/0/2
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: VP Enable: vp_pvlan_native_vlanId:1 for Te1/0/2
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.101: *** port_modechange: 1/2 mode_access(1)
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: The operational mode of Te1/0/2 in set all vlans is 1
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: vp_pvlan port_mode:access vlan:1 for Te1/0/2
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: vp_pvlan port_mode:access native_vlan:1 for Te1/0/2
*Aug 25 20:01:11.102: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:13.098: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/2, changed state to up
*Aug 25 20:01:14.098: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/2, changed state to up
Errores de Cisco relacionados
| ID de falla de funcionamiento de Cisco |
Descripción |
| ID de bug de Cisco CSCvu13029 |
Intermitent Link Flaps en switches mGig Cat9300 a terminales compatibles con mGig. |
| ID de bug de Cisco CSCvt50788 |
Los problemas de interoperabilidad Cat9400 mGig con otros dispositivos mGig provocan inestabilidad de link. |
| ID de bug de Cisco CSCvu92432 |
CAT9400: Interferencias de interfaz de Mgig con AP de Mgig. |
| ID de bug de Cisco CSCve65787 |
Compatibilidad con autoneg para 100 G/40 G/25 G Cu xcvr. |
Información Relacionada
- Matriz de compatibilidad de óptica a dispositivo de Cisco
- Ficha técnica de los módulos Cisco SFP para aplicaciones Gigabit Ethernet
- Informe técnico sobre la protección de la inversión de 25 GE y 100 GE para lograr mayores velocidades en las empresas
- Hoja de datos de la solución Cisco CWDM SFP
- Innovación en soporte: Cómo Cisco TAC está transformando la documentación y simplificando el autoservicio
- Soporte técnico y descargas de Cisco
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
3.0 |
09-Sep-2026
|
Recertificación: edición actualizada, SEO, traducción automática, requisitos de estilo y formato. |
2.0 |
13-Mar-2024
|
Recertificación |
1.0 |
04-Nov-2022
|
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)