Un DAC 25G Fortinet monte entre FortiSwitch identiques mais pas entre un FS2048 et un FS648
On regroupe deux rangées d'agrégation sur FortiSwitch, et la dernière pièce est une interconnexion 25G entre un FS2048 et un FS648 dans des baies adjacentes. Tout le reste de la conception est monté du premier coup ; cette seule liaison refuse.
- FortiSwitch 2048, port en face avant 25G
- FortiSwitch 648, port en face avant 25G
- Fortinet FN-CABLE-SFP28-5, DAC passif, câble constructeur, pas tiers
- Les deux ports sinon intacts à part la config VLAN
Ce que j'obtiens :
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, stableDéjà fait :
- remplacé par un second FN-CABLE-SFP28-5 de la même boîte, aucun changement
- déplacé les deux extrémités vers d'autres ports 25G sur chaque châssis, aucun changement
- prouvé que le câble est bon en le branchant entre deux FS648 identiques, où il monte immédiatement
Donc le câble va bien et les ports vont bien, mais pas la combinaison. Y a-t-il quelque chose sur les ports 25G qui doit correspondre entre les deux modèles avant que le lien puisse s'entraîner (train) ?
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
C'est exactement ça. Les deux châssis sont construits sur des générations d'ASIC et de PHY différentes, et la correction d'erreur sur laquelle chacun se cale de lui-même à 25G n'est pas la même des deux côtés, donc le lien ne finit jamais son entraînement. Il vous reste un down/down propre et rien à se mettre sous la dent dans les logs.
Fixez le même mode FEC à la main sur les deux ports :
Faites-le sur le FS2048 et sur le FS648, en utilisant le nom de port propre à chaque côté. CL91 est la variante Reed-Solomon et nettoie nettement plus que l'option firecode CL74, mais lequel des deux vous choisissez compte beaucoup moins que le fait de choisir le même deux fois : les deux PHY doivent encoder et décoder avec un schéma identique ou l'entraînement ne se termine jamais, et « auto » sur deux familles de PHY différentes n'est pas un schéma identique.
Le port devrait monter dès que le second côté est validé. Si vous mélangez plus tard un troisième modèle là-dedans, réglez-le explicitement là aussi plutôt que de supposer que le défaut s'est reporté.
Un câble qui monte entre des unités identiques et meurt entre des modèles différents, c'est la couche physique qui n'arrive pas à s'entendre sur quelque chose, et sur du cuivre 25G c'est presque toujours le FEC.
Avant tout, postez ce que fec-state a actuellement configuré sur les deux ports. Le défaut n'est pas le même selon les générations de FortiSwitch, et les deux modèles que vous reliez ne sont pas de la même famille d'ASIC/PHY, donc « réglages d'usine des deux côtés » ne veut pas dire « le même réglage des deux côtés ».
Si les deux ports vous renvoient des valeurs différentes là, vous avez votre réponse avant de toucher à quoi que ce soit d'autre.
Rien n'a été touché d'aucun côté, donc les deux ports tournent avec ce que l'image règle par défaut. Le côté FS2048 est nu :
Pareil sur le FS648. Vitesse et auto-négociation intactes aussi, j'ai juste mis les ports dans le bon VLAN. Si les défauts diffèrent selon le modèle, ça expliquerait pourquoi le même câble est parfaitement content entre deux boîtiers identiques.
Même catégorie de problème bien en dehors de Fortinet, pour ce que ça vaut. J'avais un DAC SFP28 25G passif qui montait sans souci entre un UniFi USW-Pro-Aggregation et un serveur avec une carte Intel SFP28, et qui ne donnait absolument rien sur sfp28-2 d'un MikroTik CCR2004-1G-12S+2XS - aucune erreur d'un côté ou de l'autre, juste pas de lien. Essayé un Ubiquiti UACC-DAC-SFP28-3M et un Lenovo 7Z57A03558, même résultat. À un moment le port est monté puis retombé après environ deux secondes, ce qui était l'indice que quelque chose échouait à s'entraîner plutôt qu'un câble mort.
Encore le FEC : le côté Ubiquiti garde le FEC activé sans moyen supporté de le changer, et RouterOS a fait passer le défaut de fec91 à pas de FEC en 6.49. Ce qui a fonctionné ici, c'est passer à RouterOS 7.4, où les options FEC sont exposées, en lançant
puis en réglant le port sur fec74 avec l'auto-négociation désactivée, le contrôle de flux désactivé dans les deux sens, 25 Gbps full duplex, plus une surcharge de profil de port côté UniFi fixant 25G FDX. C'est mon matériel et mon firmware, donc considérez cette recette exacte comme un point de départ et vérifiez sur le vôtre.
Utile d'ajouter que le même réglage porte un nom différent selon la CLI dans laquelle vous vous trouvez, ce qui rend ça pénible dès qu'une baie contient plus d'un fabricant. Sur des liens Cisco 25G entre une pile Catalyst 9300 et une paire Catalyst 9500, fec cl108 des deux côtés est ce qui les a fait monter ; sur le 100G entre cette paire 9500 et un Nexus 9000, ce qui a fonctionné c'était fec off des deux côtés. Même décision, mots-clés différents.
Et le FEC n'est pas toujours quelque chose qu'on active. Sur un Nexus 93180YC-EX avec un SFP-H25GB-SR relié à un adaptateur Cavium 25G, le port du switch restait en FEC auto et attendait du FEC à cause de l'optique, tandis que la carte réseau ne rapportait aucune capacité FEC du tout, donc les deux bouts ne se sont jamais mis d'accord et les interfaces sont restées down avec les modules reconnus. Là, fec off sur l'interface du switch était la correction, et show interface confirme le mode passant de Auto à Off.
Donc la règle n'est pas « utilisez cl91 », c'est « décidez du mode, puis réglez-le explicitement aux deux extrémités ».
Confirmé. set fec-state cl91 sur le port FS2048 n'a rien changé à lui seul, puis pareil sur le port FS648 et le lien est monté en quelques secondes. Les compteurs bougent des deux côtés, et ça a survécu à un redémarrage de chaque châssis.
Désormais le réglage reste explicite sur chaque port 25G de cette paire plutôt que de faire confiance à un défaut. Deux soirées à échanger des câbles parfaitement bons pour une ligne de config.