MRV OptiSwitch OS906 : quelle commande CLI affiche la référence du SFP et la puissance RX sur un site de démarcation
Nous livrons des circuits clients sur des boîtiers de démarcation MRV OptiSwitch - surtout des OS906, avec quelques OS904 et OS912 restants sur des installations plus anciennes. Quand un ticket arrive pour un circuit down ou instable, je veux deux choses via SSH avant que quiconque se déplace : quel module est réellement dans le port (personne ne consigne ce que l'installateur a monté), et la puissance de réception, pour pouvoir dire si la lumière s'arrête de notre côté ou du leur.
- MRV OptiSwitch OS906 au point de démarcation client, OS904 et OS912 sur quelques sites plus anciens
- SFP 1G génériques, fournisseurs mélangés, ce que l'équipe terrain avait dans la camionnette
- liaison monomode jusqu'à notre POP
La seule chose que j'ai découverte jusqu'ici, c'est qu'une cage vide répond clairement :
Failed to get EEPROM Data, SFP is not inserteddonc au moins un module manquant se distingue d'un module présent mais silencieux. Ce que je n'arrive toujours pas à faire, c'est afficher le constructeur, la référence et la longueur d'onde d'un module en place, ou lire la puissance TX/RX.
Ce que j'ai essayé jusqu'ici :
- parcouru l'aide CLI sous
show portet manifestement raté la bonne sous-commande - mis un module connu bon dans un OS904 de labo pour voir si la sortie diffère - rien
Quelles commandes sur OptiSwitch me donnent le contenu de l'EEPROM et les niveaux optiques en direct ? Je préférerais éviter d'envoyer quelqu'un avec un powermètre sur un site où la CLI a déjà la réponse.
Comments 5
Deux commandes couvrent ça, et elles sont séparées comme on pourrait l'espérer : ce que le module déclare sur lui-même dans l'une, les relevés en direct dans l'autre.
show port sfp-paramsfait ressortir les champs de l'EEPROM - constructeur, référence, série, longueur d'onde, le débit nominal déclaré par le module, les portées indiquées pour chaque type de fibre, plus les octets d'identifiant et de connecteur. Ça répond à la question de ce que l'installateur a réellement monté, et si sa portée convient du tout à la liaison.show port sfp-diag <portnumber>est la moitié en direct : température du module dans les deux échelles, tension d'alimentation, courant de polarisation côté émission en mA, et les deux puissances optiques, chacune donnée deux fois, en dBm et en mW. La valeur RX en dBm est le chiffre à citer à l'opérateur distant.Faites sfp-params d'abord - une lecture en dBm ne veut pas dire grand-chose tant qu'on ne sait pas si on regarde une pièce courte portée ou longue distance.
La chaîne que vous avez déjà trouvée vaut la peine d'être retenue.
Failed to get EEPROM Data, SFP is not insertedsignifie que la cage est vide, ce qui est un défaut différent d'un module en place mais illisible. Si vous scriptez un jour ça sur un tas de boîtiers de démarcation, c'est la ligne sur laquelle faire correspondre.Le reste de la panoplie sur ces boîtiers :
detail donne la configuration et l'état du port, les deux commandes statistics donnent les compteurs de paquets, d'octets et d'erreurs avec monitor comme vue en direct, et rate avec un temps en secondes donne le débit sur cette fenêtre.
Quelle extrémité essayez-vous réellement de démontrer, et qu'y a-t-il de l'autre côté de la liaison ? Si les deux extrémités sont des OptiSwitch, vous pouvez lancer sfp-params sur chacune et comparer directement constructeur, référence et longueur d'onde, et cette comparaison attrape le cas classique où quelqu'un a mis un module longue portée d'un côté et un module courte portée de l'autre.
Si l'extrémité distante appartient au client ou à un autre opérateur, obtenez les détails de leur module dans le ticket avant de citer le moindre chiffre en dBm, sinon vous passez une semaine à discuter d'un lien qui n'allait de toute façon jamais fonctionner optiquement. Et une fois que vous avez la sortie : est-ce un seul port qui revient vide, ou tous les ports du boîtier ? Ce sont deux problèmes différents.
Même type de problème sur les routeurs Cisco, au cas où quelqu'un atterrirait ici depuis cette direction. Sur un ISR 4451, l'habitude Catalyst de taper
show interface transceiverne mène nulle part, le routeur n'accepte pas cette syntaxe, ce qui fait conclure à certains que la plateforme n'a pas de DOM du tout. Elle en a un ; on y accède plutôt via l'arborescence des modules matériels :Ce qui ressort, c'est la thermique du module, la tension d'alimentation et le courant de polarisation côté émission, puis les deux valeurs de puissance. Sur un lien mort ici, un GLC-LH-SMD affichait environ -7,1 dBm en émission et -32,2 dBm en réception, ce qui n'est pas une liaison limite, c'est l'obscurité totale - extrémité distante ou trajet fibre, rien à voir avec le routeur.
Échelle approximative que j'utilise : un saut court à l'intérieur d'un bâtiment se situe autour de -3 à -8 dBm, la longue portée varie avec la distance, en dessous d'environ -30 dBm il n'arrive rien. Et avant d'accuser la fibre : %TRANSCEIVER-3-NOT_SUPPORTED dans
show logging, ou un type de média affiché comme unknown dansshow interface, l'un ou l'autre signifie que le routeur a refusé le module.Encore une plateforme pour la collection. Sur l'Avaya VSP 7000, c'est une seule commande :
Elle affiche ce que le commutateur a lu dans le module présent dans la cage, et le chapitre de dépannage utilise cette sortie pour décider si l'appareil compte comme pris en charge.
Le détail agaçant : la liste des modules qualifiés n'est pas dans ce chapitre. Elle se trouve dans le document séparé d'installation des transceivers, NN47202-302, aux côtés des étapes d'installation et de retrait physiques. Si le module revient failed ou unsupported, la réponse documentée est de le remplacer par quelque chose de cette liste.