Supermicro E300-9A con pfSense Plus 22.05: ix2 e ix3 se quedan sin portadora con un DAC que enlaza bien en un USW-Aggregation
Mi firewall es un Supermicro E300-9A con pfSense Plus 22.05, y ambos puertos 10G SFP+ se niegan a subir. Ni ix2 ni ix3 muestran nunca portadora, sea lo que sea lo que ponga en la jaula.
Hardware:
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M y un cable twinax pasivo de 10Gtek
- Módulos de fibra Supermicro AXS85-192-M3 como alternativa
- Ubiquiti USW-Aggregation en el lado del switch
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 se ve igual.
Probado hasta ahora:
- ambos cables funcionan en el USW-Aggregation entre otros dispositivos, así que no están muertos
- cambié el cobre por los módulos de fibra AXS85-192-M3, mismo no carrier en ambos puertos
- reinicié el equipo varias veces, incluyendo insertar un módulo mientras estaba en marcha
¿Hay algo en esta caja que haya que "despertar" antes de que las jaulas empiecen a funcionar, o estoy ante dos puertos muertos?
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 4
Los reinicios en caliente no te llevarán a ningún sitio - esos puertos fijan un estado de medio y nunca vuelven a comprobarlo en un reinicio. Apaga el equipo correctamente, desconecta el adaptador de corriente durante un par de minutos, y luego enciéndelo de nuevo con el módulo ya insertado. Eso fue lo que devolvió ambos puertos aquí, y otra persona describió un comportamiento idéntico en un puerto Intel X552, por lo que creo que es un estado de medio obsoleto y no un problema de pfSense.
Si insertas un módulo mientras el sistema ya está en marcha, reinicia la interfaz en lugar de reiniciar el equipo:
Eso hace que el driver vuelva a mirar la jaula. No es un arreglo permanente para nada, pero ahorra un reinicio cuando estás cambiando módulos en el banco. Comprueba el resultado con
ifconfig -aen vez del panel frontal.Haz primero el corte total de alimentación y confirma ambas jaulas con un DAC antes de tocar el lado del switch. Depurar una cosa a la vez importa aquí, porque "no carrier con cada módulo" y "el enlace sube a la velocidad equivocada" suelen ser dos fallos separados que resultan estar en el mismo tramo de cable.
El corte total de alimentación funcionó. Apagué, desconecté el adaptador, esperé un par de minutos, volví a encender - ambos puertos subieron. Puse un DAC en bucle entre ix2 e ix3 y obtuve un enlace 10G limpio, y el par AXS85-192-M3 también hace 10G entre los dos puertos, así que las jaulas y los módulos están bien.
El lado del switch es otra historia. Hacia el USW-Aggregation el enlace solo negocia a 1G, y si fuerzo 10G en cualquiera de los dos extremos se cae y se queda caído. Así que la mitad del problema ha desaparecido y la mitad molesta sigue aquí.
La mitad del fallback a 1G me suena muchísimo. Perseguí el mismo síntoma en un TL-SG3428X y un TL-SX3008F: reiniciar un servidor colgado de uno de esos puertos SFP+ y volvía negociado a 1G sin importar para qué estuviera configurado el puerto del switch. Adaptadores Intel X520-DA2, Mellanox y HP, ópticas Intel E10GSFPSR y 10GTek, actualizaciones de firmware, varias versiones de driver en Linux y Windows, perfiles de puerto - nada de eso cambió algo. Un reinicio del switch, o alternar la velocidad del puerto fuera de 10G y volver, restauraba el enlace a 10G hasta el siguiente reinicio del host.
Lo que realmente lo arregló fue cambiar las ópticas en lugar de cualquier cosa en el host: módulos TP-Link SM5110-SR en el extremo del switch y el enlace volvía a 10G cada vez. Otra persona confirmó lo mismo en un SG3428XMPP. La lectura fue que el switch negocia mal con algunos módulos de terceros después de un reinicio de enlace por el lado del host.
Proveedor distinto en tu caso, pero la forma coincide. Antes de comprar un lote entero de cualquier cosa, pide prestado un solo módulo de marca Ubiquiti y prueba un puerto en el switch de agregación.
Sobre forzar 10G: hacerlo solo en un extremo empeora las cosas, no las mejora. El par sigue intentando negociar y una configuración fija no le da nada contra qué negociar, así que el enlace simplemente se queda caído - exactamente el comportamiento que describes. Fija velocidad y dúplex en ambos extremos, o en ninguno.
Dos casos relacionados del mundo MikroTik, por si suenan a algo conocido. En un RB4011 se detectó un Finisar FTLF8524P2BNV-BR con sfp-rx-loss y sfp-tx-fault mostrando ambos no, y la interfaz seguía diciendo no-link, porque un SFP de 1G en una jaula SFP+ tiene que fijarse en lugar de negociarse:
y, otra vez, en ambos extremos. El segundo fue un CCR1072 donde la autonegociación se quedaba en DONE tras una pérdida de enlace y el driver nunca la reiniciaba; desactivar autoneg y fijar la velocidad devolvió el enlace, al precio de una detección correcta de caída de enlace.