NAPALM get_optics sur nxos_ssh ne renvoie que le DOM de la voie 1 pour les modules QSFP-100G-CWDM4

Quelle version exacte de NAPALM, et sur quelle branche NX-OS sont ces leaf ? Le code des optiques dans nxos_ssh a été retravaillé plus d'une fois, et la sortie transceiver du commutateur n'est pas non plus formatée de façon identique d'une branche à l'autre, donc les deux comptent avant de crier au bug.

Une chose qui vaut le coup avant d'écrire votre propre analyseur : appelez get_optics() sur un des ports SFP+ et mettez cette structure à côté de celle du CWDM4. Si les deux reviennent avec le même squelette et que seules les valeurs diffèrent, le pilote parcourt bien le texte mais abandonne simplement après le premier bloc qu'il trouve. Si elles sont structurées différemment, il n'atteint jamais du tout la section par voie sur les ports QSFP. Ce sont deux corrections différentes, et la sortie SFP+ est le moyen le moins coûteux de les distinguer.

Version courante depuis PyPI sur les deux collecteurs, et les leaf et les spine sont sur la même branche NX-OS, donc j'obtiens la même chose partout où je pointe - ce n'est pas un boîtier isolé.

J'ai fait la comparaison SFP+ que vous demandiez. Même squelette dans les deux cas : physical_channels.channel avec un seul élément à l'index 0, les trois valeurs remplies. Bonne réponse pour un module à une voie, mauvaise réponse pour le CWDM4. Donc l'analyseur ne rate pas la partie par voie de la sortie, il trouve un bloc, le remplit et s'arrête là. C'est ce à quoi ça ressemblait quand j'ai lu le code, je voulais juste que quelqu'un confirme que je ne me trompais pas.

C'est une lacune du pilote plutôt que quoi que ce soit de votre côté. Il existe une pull request ouverte sur nxos_ssh qui réécrit l'analyse des optiques : chaque voie revient comme son propre élément sous physical_channels.channel au lieu que le parcours s'arrête à l'index 0, et chaque élément porte son propre niveau Rx, niveau Tx et courant de polarisation du laser. Les fixtures livrées avec elle sont construites sur un QSFP-100G-CWDM4 à quatre voies, donc c'est écrit exactement pour votre module. Je ne l'ai testé que sur une machine de labo, donc considérez-la comme quelque chose à essayer plutôt que comme une recommandation pour un collecteur de production.

En attendant qu'elle arrive dans une version installable, la solution pragmatique est de sauter le getter pour les ports 100G et d'analyser vous-même show interface transceiver details, puis d'envoyer chaque voie comme sa propre série dans la supervision. Un peu plus de code à maintenir, mais vous arrêtez de jeter les trois quarts du signal.

Quelle que soit la voie choisie, alertez par voie. Une voie dégradée sur un CWDM4 va tirer tout le lien vers le bas sans jamais apparaître si vous ne surveillez que la voie 1.

La visibilité par voie compte plus sur Nexus que les gens ne l'imaginent.

Nous sommes tombés sur un défaut Cloud Scale sur un Nexus 9000 avec un QSFP-100G-SR4-S découpé en 4x25G. Un seul des quatre ports 25G était voulu, les trois autres restaient fermés, et celui qui nous intéressait ne montait jamais. Ce qui nous en a sortis a été de faire monter tout le groupe d'abord - no shutdown sur chacune des quatre sous-interfaces - laisser la voie 1 se stabiliser, puis refermer les trois voies inutilisées. Gardez aussi le FEC identique sur tout le groupe pendant que vous y êtes ; un réglage différent sur une seule voie ne reste pas poliment cantonné à cette voie.

Le point important, c'est qu'avec seulement la voie 1 dans vos tableaux de bord, vous êtes aveugle à la majeure partie de ce que fait un port 100G. L'analyse supplémentaire vaut la peine d'être maintenue.