El DAC 25G de Fortinet enlaza entre unidades FortiSwitch idénticas pero no entre FS2048 y FS648
Estamos colapsando dos filas de agregación sobre FortiSwitch, y la última pieza es una interconexión de 25G entre un FS2048 y un FS648 en racks adyacentes. Todo lo demás en el diseño subió al primer intento; solo este enlace se resiste.
- FortiSwitch 2048, puerto de 25G en el panel frontal
- FortiSwitch 648, puerto de 25G en el panel frontal
- DAC pasivo Fortinet FN-CABLE-SFP28-5, cable del propio fabricante, no de terceros
- Ambos puertos sin tocar salvo por la configuración de VLAN
Lo que obtengo:
FS2048 port: down, no rx/tx counters moving
FS648 port: down, no rx/tx counters moving
same FN-CABLE-SFP28-5 between two FS648 units: up at 25G, stableYa hecho:
- probé un segundo FN-CABLE-SFP28-5 de la misma caja, sin cambios
- moví ambos extremos a distintos puertos de 25G en cada chasis, sin cambios
- comprobé que el cable está bien conectándolo entre dos unidades FS648 idénticas, donde sube de inmediato
Así que el cable está bien y los puertos están bien, pero la combinación no funciona. ¿Hay algo en los puertos de 25G que tenga que coincidir entre los dos modelos antes de que el enlace pueda entrenar?
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 6
Eso es exactamente. Los dos chasis están construidos sobre generaciones distintas de ASIC y PHY, y la corrección de errores en la que cada uno se asienta por sí solo a 25G no es la misma en ambos lados, así que el enlace nunca termina de entrenar. Te quedas con un down/down limpio y nada en los registros para masticar.
Fija a mano el mismo modo FEC en ambos puertos:
Hazlo en el FS2048 y en el FS648, usando el nombre de puerto propio de cada lado. CL91 es la variante Reed-Solomon y corrige bastante más que la opción firecode CL74, pero cuál de las dos elijas importa mucho menos que elegir la misma dos veces: ambos PHY tienen que codificar y decodificar con un esquema idéntico o el entrenamiento nunca se completa, y "auto" en dos familias de PHY distintas no es un esquema idéntico.
El puerto debería subir en cuanto se confirme el segundo lado. Si más adelante mezclas un tercer modelo en esto, fíjalo explícitamente ahí también en lugar de asumir que el valor por defecto se mantuvo.
Un cable que enlaza entre unidades idénticas y muere entre modelos distintos es la capa física fallando en ponerse de acuerdo en algo, y en cobre de 25G eso casi siempre es FEC.
Antes que nada, publica qué fec-state está configurado actualmente en ambos puertos. El valor por defecto no es el mismo entre generaciones de FortiSwitch, y los dos modelos que estás uniendo no son la misma familia de ASIC/PHY, así que "ajustes de fábrica en ambos extremos" no significa "el mismo ajuste en ambos extremos".
Si los dos puertos devuelven valores distintos ahí, tienes la respuesta antes de tocar cualquier otra cosa.
No se tocó nada en ningún lado, así que ambos puertos corren lo que la imagen fija por defecto. El lado del FS2048 está limpio:
Lo mismo en el FS648. Velocidad y autonegociación también sin tocar, solo puse los puertos en la VLAN correcta. Si los valores por defecto difieren según el modelo, eso explicaría por qué el mismo cable está perfectamente contento entre dos equipos idénticos.
Misma clase de problema bien fuera de Fortinet, por si sirve. Tuve un DAC pasivo SFP28 de 25G que enlazaba felizmente entre un UniFi USW-Pro-Aggregation y un servidor con una tarjeta Intel SFP28, y no daba absolutamente nada en sfp28-2 de un MikroTik CCR2004-1G-12S+2XS -sin error en ningún lado, simplemente sin enlace. Probé un Ubiquiti UACC-DAC-SFP28-3M y un Lenovo 7Z57A03558, mismo resultado. En un momento el puerto sí subió y volvió a caer al cabo de unos dos segundos, lo cual fue la pista de que algo fallaba al entrenar en lugar de que el cable estuviera muerto.
FEC otra vez: el lado Ubiquiti mantiene FEC activo sin forma soportada de cambiarlo, y RouterOS movió el valor por defecto de fec91 a sin FEC en la 6.49. Lo que funcionó aquí fue pasar a RouterOS 7.4, donde las opciones de FEC están expuestas, ejecutar
y luego fijar el puerto a fec74 con autonegociación desactivada, control de flujo desactivado en ambas direcciones, 25 Gbps full duplex, más una anulación de perfil de puerto en el lado UniFi fijando 25G FDX. Eso es mi hardware y mi firmware, así que trata la receta exacta como punto de partida y verifícalo en el tuyo.
Vale la pena añadir que el mismo ajuste tiene un nombre distinto según en qué CLI estés parado, que es lo que hace esto doloroso en cuanto un rack tiene más de un fabricante. En enlaces Cisco de 25G entre un stack Catalyst 9300 y un par Catalyst 9500, fec cl108 en ambos extremos fue lo que los levantó; en el 100G entre ese par 9500 y un Nexus 9000, lo que funcionó fue fec off en ambos lados. Misma decisión, palabras clave distintas.
Y FEC no siempre es algo que hay que activar. En un Nexus 93180YC-EX con SFP-H25GB-SR hacia un adaptador Cavium de 25G, el puerto del switch estaba en FEC auto y esperaba FEC por la óptica, mientras que la tarjeta de red no reportaba ninguna capacidad de FEC en absoluto, así que los extremos nunca se pusieron de acuerdo y las interfaces se quedaron caídas con los módulos reconocidos. Ahí, fec off en la interfaz del switch fue la solución, y show interface confirma el modo pasando de Auto a Off.
Así que la regla no es "usa cl91", es "decide el modo, y luego fíjalo explícitamente en ambos extremos".
Confirmado. set fec-state cl91 en el puerto del FS2048 no cambió nada por sí solo, luego lo mismo en el puerto del FS648 y el enlace subió en un par de segundos. Contadores moviéndose en ambos lados, y sobrevivió a un reinicio de cada chasis.
De ahora en adelante el ajuste se queda explícito en cada puerto de 25G de este par en lugar de confiar en un valor por defecto. Dos noches cambiando cables perfectamente buenos por una línea de configuración.