El Zyxel XS1930-10 no enlaza un DAC 10Gtek de 5 m que sigue funcionando en un XGS1250-12
Rack doméstico pequeño, un servidor y un switch. Sustituí un XGS1250-12 por un XS1930-10 y lo único que no sobrevivió al cambio es el enlace del servidor.
- Zyxel XS1930-10, puerto SFP+ con el tipo de medio configurado como DAC10G
- Asus XG-C100F en el servidor
- 10Gtek CAB-10GSFP-P5M, twinax pasivo de 5 m, AWG26
- un segundo DAC 10Gtek, de 1,5 m, que se guarda como repuesto
El puerto del switch se queda caído mientras la tarjeta de red está convencida de que tiene enlace:
XS1930-10, SFP+ port: media type DAC10G link status Down
server, XG-C100F:
Speed: 10000Mb/s
Duplex: Full
Link detected: yesQué he probado:
- el DAC 10Gtek de 1,5 m en el mismo puerto, misma tarjeta - enlaza de inmediato
- tipo de medio configurado explícitamente como DAC10G en vez de dejarlo en auto - sin cambios
- el cable de 5 m de vuelta en el XGS1250-12 - sigue funcionando ahí, así que el cable no está muerto
¿Son simplemente 5 m de AWG26 pasivo más de lo que este switch puede soportar, o hay algún ajuste de puerto en el XS1930-10 que se me sigue escapando?
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
Espera que ese loopback suba y que el enlace con la tarjeta de red se quede caído de todos modos -esa es la forma habitual de este problema.
El tipo de medio es un requisito previo, no una solución. Dejado en auto, un puerto SFP+ tiende a no enlazar con un DAC en absoluto, así que hay que fijar DAC10G. Una vez fijado y con el puerto todavía caído, se acaban los ajustes y se entra en el presupuesto físico del puerto.
Cinco metros de AWG26 pasivo es mucha pérdida de cobre para esta clase de switch. La postura final de Zyxel sobre el XS1930-10 es que un tramo pasivo tan largo pierde demasiada señal para su SerDes y que cualquier cosa más allá de unos 3 m pertenece a la fibra; la garantía nunca se extendió más allá de sus propios módulos y cables DAC de marca de todos modos. Eso también cubre tu otra observación -que el mismo cable funcione en el XGS1250-12 no prueba nada sobre el XS1930-10, porque un tramo de twinax que se comporta bien en la jaula de un modelo dice muy poco sobre el siguiente modelo, incluso dentro de la gama del mismo fabricante.
Ruta práctica: conserva el cable de 1,5 m para ese enlace, y si realmente necesitas la distancia de 5 m pon óptica SR y un latiguillo dúplex LC en lugar de twinax. Si quieres dejarlo por escrito, fija el tipo de medio, confirma que sigue fallando y abre un ticket de soporte -en el XGS1930-52HP esa es exactamente la ruta que da su propio FAQ para un DAC que sigue caído tras fijar el tipo de medio, y pasa por el Nebula Control Center, así que esperaría el mismo trato aquí. Yo no me quedaría esperando una versión de firmware que cambie la pérdida de un cable.
Antes de decidir nada sobre el cable, hazle un bucle: ambos extremos del DAC de 5 m en los dos puertos SFP+ del propio XS1930-10, tipo de medio DAC10G en los dos. Si sube en bucle, entonces el cable y las jaulas están bien y lo que tienes es un problema de pareja, no un problema de cable.
Dos cosas que no has dicho. ¿El puerto está forzado a 10G full duplex, o se dejó en auto después de fijar el tipo de medio? ¿Y en qué estaba el puerto del XGS1250-12 cuando el mismo cable funcionaba ahí -auto o DAC? Si estaba en auto, cambia ese a DAC antes de comparar los dos switches: el tipo de medio es un ajuste por puerto en ambos equipos, así que una prueba en la que uno de ellos se deja en auto no es realmente la misma prueba.
Otro fabricante, la misma categoría de sorpresa. Tuve un DAC SFP+ que no enlazaba entre un TL-SG2210MP, donde la jaula es un SFP de 1G normal, y un TL-SX3008F con firmware 1.2. Forzar ambos puertos a 1000 Mbps full duplex no cambió nada, y el mismo cable funcionaba bien entre dos equipos capaces de 10G.
La explicación ahí era de codificación más que de longitud: bastantes ensamblados SFP+ pasivos anuncian solo 10G y nada más, sin ningún respaldo a 1000BASE-X, así que se quedan apagados en una jaula de 1G mientras un cable de doble tasa sí enlaza. Alguien en la misma discusión tenía un DAC SFP+ Unifi funcionando entre un ER8411 y un SG2428P sin ningún drama.
No es tu caso, ya que ambos extremos son de 10G. El punto es que 'ahí funciona' pesa mucho menos con twinax que con fibra.
Vale la pena saber cómo el host se entera siquiera de un cable twinax: un DAC pasivo lleva su longitud y su atenuación en la EEPROM, según SFF-8472, y el puerto opera la jaula según lo que declara el ensamblado. No se mide nada por el cable. Esa es buena parte de por qué un mismo cable de 5 m se comporta distinto en dos switches de la misma marca -receptores distintos, tolerancia distinta a lo que esa declaración realmente cuesta en pérdida.
Tampoco cuentes con el twinax cuando necesitas un enlace más lento que su tasa. En un Netgate 6100 un DAC te da un enlace de 10G y nada más lento, sin forma de bajarlo a 1 Gbps; la interfaz simplemente sube como 10Gbase-Twinax full duplex, así que si lo que hay en el otro extremo está fijado a gigabit, el twinax no te llevará ahí y toca volver a óptica de 1G. Los cables cortos en esa marca son en general poco notables -un CAB-10GSFP-P1M y un Ubiquiti UACC-DAC-SFP10 corren ambos a 10 GbE en un USW-Enterprise-8-PoE aquí. La longitud es la variable a probar primero, no la marca.