Un puerto de fibra del ERS 8600 está arriba a 1G full duplex pero el switch no aprende ninguna MAC en él
Un servidor físico en nuestro ERS 8600 no habla con nada, y el switch está bastante convencido de que todo está bien. El puerto ha estado en este estado desde que el servidor se pasó de cobre a fibra.
- Avaya ERS 8600, servidor en un puerto SFP de 1G en el slot 3, puerto 12
- NIC del servidor con su propio SFP, patch de fibra a través del panel del edificio
- puerto dejado en 1 Gbps full duplex, nada exótico en la configuración
Lo que reporta el switch para ese puerto:
Port 3/12: up, 1000 Mbps, full duplex
FCS errors: 0
Port errors: 0
MAC addresses learned on 3/12: none
Así que el puerto entrena, se mantiene arriba durante días, no cuenta ningún error en absoluto, y aun así la base de datos de reenvío nunca obtiene ni una sola dirección de él. El servidor es inalcanzable desde el resto de la VLAN.
Lo que probé:
- reinicié el puerto varias veces, nada cambia
- alterné el control de flujo en ambos sentidos, tampoco nada
- recorrí la FDB de la VLAN del servidor: direcciones de todos los demás puertos, ni una de 3/12
- el servidor insiste en que su propio enlace está arriba a gigabit
¿Dónde mirarían a continuación, del lado del switch o en la óptica del servidor?
Comments 3
Ese patrón - enlace arriba, full duplex, contadores limpios, base de datos de reenvío vacía - casi siempre significa que el otro extremo está poniendo luz en la fibra pero no tramas válidas. El módulo en el servidor es tu primer sospechoso, no la configuración del switch.
Descarta primero el lado del switch para que nadie pueda discutir eso después. En el shell de diagnóstico del ERS 8600 ejecuta
dumpPortStateypsDump(<port index>)para ese puerto. Cuidado con el índice: no es el slot/puerto de la CLI normal, es slot * 64 + (número de puerto - 1). Si eso vuelve con un puerto local sano y contadores limpios, el switch hizo su trabajo y el fallo vive del otro lado de la fibra.Antes de comprar nada, saca la planta de la ecuación: parchea ese puerto directo de vuelta a sí mismo a través de un módulo de repuesto del mismo tipo, luego mide con un medidor qué sale y qué vuelve y ve si ambas lecturas se mantienen estables donde la especificación del módulo dice que deberían. Después de eso, cambia el SFP en la NIC del servidor. En el caso documentado con estos síntomas eso fue toda la solución: el puerto del switch mantuvo el enlace durante días, nunca salió nada utilizable de la fibra, y las direcciones aparecieron en el momento en que se reemplazó el módulo del servidor.
Una advertencia si un módulo que se sabe bueno no cambia nada: algunas plataformas tienen un defecto de software que se ve idéntico. El ERS 5900 tiene uno documentado: cambia los módulos de uplink de 1 Gbps por SFP+ de 10 Gbps y los enlaces suben como activos sin que pase nada por ellos. Una versión de software posterior lo lista como corregido, y un reinicio de puerto o de switch te saca del apuro mientras tanto. Así que si el cambio no ayuda, lee primero las notas de versión de tu código.
Cero errores junto con cero direcciones aprendidas es una combinación muy específica, así que determina qué dirección está realmente muerta. ¿Los contadores del puerto muestran alguna trama recibida siquiera, o literalmente nada llega? Si el lado de recepción está plano mientras el de transmisión sigue subiendo, el switch está hablándole a un agujero y tu FDB vacía es un síntoma y no el problema.
También vale la pena volcar lo que sea que el switch haya logrado sacar del módulo mismo. En la línea VSP 7000 eso es
show interfaces gbic-info, acotado conport <port number>si quieres solo uno, y te dice qué dispositivo cree el equipo que está instalado y si lo considera soportado; si tu versión de ERS tiene un equivalente, publica su salida para 3/12. Y di qué módulo hay en la NIC del servidor, marca y tipo, no solo 'un SFP'.Entré al shell de diagnóstico como se sugirió. Para el slot 3 puerto 12 el índice sale 3 * 64 + 11 = 203, así que
psDump(203)másdumpPortState- puerto local sano, contadores limpios, nada mal en el switch en absoluto, exactamente como se predijo.Así que saqué el SFP de la NIC del servidor y puse uno de repuesto del mismo tipo. La dirección MAC estaba en la base de datos de reenvío antes de que volviera a mi escritorio, y el servidor ha sido alcanzable desde entonces. Un módulo muerto del lado del servidor que aun así producía suficiente luz para levantar el puerto y mantenerlo así. Gracias, habría pasado otro día releyendo la configuración del switch.