Vérifier l’optique sur un commutateur
Une fois un module inséré dans un port, chaque NOS dispose d’une commande pour afficher son identité et son DDM. Utilisez-la pour confirmer que le commutateur voit le module comme prévu — et pour recouper avec ce que CodingBox a lu.
Commandes par NOS
| NOS | Commande |
|---|---|
| Cisco IOS / IOS-XE | show interfaces <if> transceiver detail |
| Cisco NX-OS | show interface <if> transceiver details |
| Juniper Junos | show interfaces diagnostics optics <if> |
| Arista EOS | show interfaces <if> transceiver detail |
| Huawei VRP | display transceiver interface <if> verbose |
| Aruba CX | show interface <if> transceiver detail |
Ce qu’il faut observer
- Identité — le nom du constructeur, la référence et le numéro de série correspondent à ce qui était prévu.
- DDM — température, tension, bias et puissance optique sont dans la plage (le commutateur lit les mêmes diagnostics SFF-8472 que ceux affichés par CodingBox).
- Erreurs — une mention « unsupported transceiver » renvoie au verrouillage constructeur.
Recoupement avec CodingBox
Comparez la sortie du commutateur avec le résumé transceiver de l’application. Si le commutateur diverge de ce que CodingBox a lu sur l’établi, la différence tient à la façon dont le commutateur interprète ou filtre le module — pas à la mémoire du module.
Commandes DDM spécifiques par plateforme, dumps bruts
ethtool, OID SNMP et chemins OpenConfig : Lire le DDM avec des outils.
Configurer ce que vous avez vérifié — débit, FEC, breakout, contournements par NOS : Recettes de configuration des ports ; pourquoi une plateforme a rejeté un module : Comment chaque NOS valide un module.
Les mêmes données via SNMP et la télémétrie en continu — objets MIB par constructeur, chemins OpenConfig pour les transceivers, messages syslog à surveiller : Gestion et supervision ; noms d’interface utilisés dans ces commandes : Nommage des ports et LED.