Un Catalyst 3850 pone el puerto en err-disable cuando un ThinkSystem SR650 usa ópticos SR Lenovo 46C3447
Nuevo host ESXi entrando a un rack que cuelga de un 3850 de campus. La gestión por cobre subió sin drama, los uplinks de 10G no: en cuanto el servidor arranca, el puerto del switch cae en err-disable y el host no ve nada en ese vmnic.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, con un adaptador Emulex VFA5.2 2x10GbE SFP+
- módulos Lenovo 10GBASE-SR, 46C3447, en el adaptador
- Cisco WS-C3850-24XS-S con Cisco SFP-10G-SR del lado del switch
- patch OM3 LC-LC entre ambos
Te1/0/7: entra en err-disable a los pocos segundos de encender el servidor
ESXi: el uplink muestra DISCONNECTED
Mismo latiguillo, Cisco SFP-10G-SR en ambos extremos switch a switch: enlace sube y estableYa probé:
- moví el servidor a otro puerto del mismo switch, mismo comportamiento
- cambié el 46C3447 por su gemelo del otro puerto del adaptador
- latiguillo nuevo, ambos extremos limpiados y reasentados
La fibra y el óptico del lado del switch claramente están bien, así que algo está objetando al módulo Lenovo. ¿Qué lado está objetando aquí, el servidor o el switch, y hay forma de hacer que el 3850 conviva con esto?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Ese log lo resuelve.
gbic-invalides el switch rechazando lo que lee como un módulo no autorizado, y la comprobación que se dispara vive del lado de Cisco, no en el SR650 ni en ESXi. Objeta al óptico SR con código Lenovo en ese enlace y mata el puerto antes de que el enlace siquiera se evalúe, que es también por qué mover puertos y cambiar cables no cambió nada para ti.Dos líneas en configuración global:
La primera le dice al switch que siga adelante con un módulo que no reconoce, la segunda evita que err-disable dispare contra el puerto cuando esa comprobación CRC falla. Ninguna es retroactiva, así que reinicia el puerto después y reasienta la fibra mientras está caído:
Guarda la configuración una vez que esté arriba. Si solo vive en la configuración en ejecución, el puerto vuelve en err-disable tras el siguiente reload y te toca depurar esto de nuevo en un momento mucho peor.
Dos advertencias. Ahora estás fuera de la configuración soportada por Cisco: consideran los ópticos de terceros como no probados y TAC puede rechazar un caso de interoperabilidad que involucre uno, lo cual importa si este enlace está bajo un contrato. Y
service unsupported-transceiverno es una solución universal. El mismo mensaje de bad crc sobrevive a esto cuando el obstáculo es el puerto en sí, por ejemplo un slot SFP solo de 1G con un módulo de 10G forzado dentro, así que si el puerto sigue caído después del reinicio, revisa a qué velocidad está corriendo realmente cada extremo antes de volver a culpar al óptico.Antes de que alguien adivine: ¿qué registra realmente el switch cuando el puerto cae? Err-disable siempre nombra su causa, y la causa cambia por completo la respuesta. Una queja de seguridad o CRC sobre un módulo es un problema distinto de un flapeo o un disparo de protocolo, y el remedio de uno no hace nada por el otro.
Saca
show loggingde alrededor del momento en que el servidor enciende y publica las líneas para ese puerto. Confirma también qué hay físicamente en Te1/0/7, dices Cisco SFP-10G-SR, entonces ¿el 46C3447 es la única pieza no-Cisco en toda esa ruta?Log del momento en que cae, dos líneas para ese puerto:
Así que es la comprobación de seguridad la que dispara, no un flapeo. Y sí, el extremo del switch es un Cisco SFP-10G-SR genuino de una caja Cisco, el 46C3447 en el servidor es la única pieza con código Lenovo en toda la ruta. Lo cual me confundió, porque el mensaje nombra el puerto del switch en vez de algo del lado del servidor.