L'uplink 100GE d'un Huawei CE6800 vers un Profitap XX-3200G ne monte jamais avec des optiques SR4
Remplacement de la paire d'agrégation existante d'un client par du matériel CloudEngine, et le seul lien qui refuse de monter est l'alimentation 100GE vers leur packet broker. Tout le reste sur le switch s'est mis en place sans drame.
- Huawei CloudEngine 6800, port 100GE
- modules QSFP28 100GBASE-SR4, pièces Huawei, une à chaque extrémité
- packet broker Profitap XX-3200G de l'autre côté
Les deux extrémités voient leur module. Le journal du switch ne contient que des entrées d'insertion et de retrait de transceiver, de quand je réinsérais les choses, aucune alarme du tout, et l'interface reste simplement down :
<CE6800> display interface 100GE1/0/1
...
FEC : RS-FECDéjà essayé :
- remplacé les deux modules par des pièces de rechange et nettoyé les extrémités MPO, aucun changement ;
- déplacé le lien vers un autre port 100GE du switch ;
- vérifié côté broker, il détecte son module et ne signale rien d'anormal.
Donc les optiques sont reconnues des deux côtés, rien ne se plaint, et il n'y a pas de lien. Qu'est-ce qui doit encore correspondre entre un port 100GE CloudEngine et un boîtier tiers avant que le lien ne s'entraîne ?
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
C'est une incohérence de FEC. CloudEngine active le RS-FEC par défaut sur les ports 100GE avec des optiques SR4, le broker n'a aucun réglage FEC et tourne donc sans, et deux extrémités en désaccord sur le FEC ne finissent jamais leur entraînement. Rien n'est cassé, donc rien n'est journalisé, ce qui explique pourquoi le journal ne contient que vos messages d'insertion et de retrait.
Désactivez-le sur le switch, dans la vue interface :
undo fec modefait la même chose. La deuxième ligne est celle qui compte. CE est en configuration à deux étapes, et unfec mode nonenon validé a l'air parfaitement correct quand on relit la config pendant que le port reste exactement aussi down qu'avant. J'ai vu un dossier client durer un jour de plus pour cette raison, tout le monde convaincu que le FEC avait déjà été désactivé.Après le commit,
display interfacedevrait montrer FEC: NONE et le port devrait s'entraîner.Si jamais l'extrémité distante finit par obtenir un réglage FEC, le meilleur correctif est d'activer le RS-FEC là-bas et de laisser le switch sur son défaut, puisqu'en 100G on veut réellement la correction. Entre deux vendors différents, je réglerais le FEC explicitement des deux côtés plutôt que de faire confiance à une quelconque négociation.
Que dit le broker sur le FEC de son côté, s'il dit quoi que ce soit ? Vous avez déjà posté vous-même la moitié intéressante : le port du switch tourne en RS-FEC. Huawei est explicite sur le fait que les deux extrémités d'un lien 100GE doivent utiliser le même mode FEC, sinon les interfaces ne montent jamais, et cette panne ressemble exactement à la vôtre, les deux modules sains, aucune alarme, aucun journal, port down.
La plupart des packet brokers et des taps avec lesquels j'ai travaillé n'exposent aucun réglage FEC du tout, ce qui signifie qu'ils tournent sans, et c'est le switch qui doit céder. Confirmez ça d'abord, puis changez une seule chose.
Ça vaut la peine d'ajouter que le défaut CloudEngine n'est pas une valeur unique, ça dépend du module. Le QSFP28-100G-LR4 et le QSFP28-100G-LR1 tournent avec le FEC désactivé selon IEEE 802.3, alors que tous les autres types QSFP28 ont le FEC activé par défaut. Donc le conseil de simplement le désactiver est faux sur un lien LR4, où le switch est déjà désactivé et où l'incohérence se trouve de l'autre côté.
Deux autres règles du même chapitre qui m'ont eu :
Donc vérifiez ce que vous avez réellement en main avec
display transceiver interface 100GE1/0/1 verboseavant de décider dans quel sens pousser le FEC, et n'oubliez le commit dans les deux cas.