Verrouillage constructeur et codage

De nombreux commutateurs inspectent l’identité d’un transceiver — nom du constructeur, référence, parfois numéro de série — et traitent comme « non pris en charge » les modules qui ne correspondent pas à une liste approuvée. C’est le verrouillage constructeur, et c’est pourquoi une optique parfaitement bonne peut être rejetée par un commutateur tout en fonctionnant dans un autre.

Comment réagissent les commutateurs

• Certaines plateformes avertissent mais autorisent le module.
• Certaines désactivent le port ou refusent les diagnostics pour une optique non reconnue.
• Cisco IOS, par exemple, dispose d’une commande globale service unsupported-transceiver qui autorise les optiques tierces.

Ce que fait le codage

Le codage écrit dans la mémoire du module les champs constructeur et référence attendus par le commutateur cible, afin que celui-ci l’accepte. Comme ces champs sont protégés par des sommes de contrôle, elles doivent être recalculées après la modification — CodingBox recalcule automatiquement CC_BASE et CC_EXT dans l’EEPROM editor.

Le faire en toute sécurité

1. Lire le module et laisser CodingBox l’enregistrer dans la code database — une sauvegarde est effectuée avant toute écriture.
2. Modifier les champs d’identité (et déverrouiller les pages protégées si nécessaire).
3. Écrire les pages sélectionnées, puis relire pour confirmer.

Ne codez des transceivers que pour une interopérabilité à laquelle vous avez droit, et suivez les politiques de votre organisation et des constructeurs.

Pour aller plus loin

• Comment chaque NOS valide un module — ce qui est comparé, ce qui se passe en cas d’échec, les contournements documentés, par constructeur.
• Recettes de configuration des ports — débit, FEC, AN, breakout et commandes de contournement pour 12 systèmes côte à côte.
• Matrices de compatibilité et firmware — où le support est publié, comment le lire, ce qui change avec les mises à jour, pratique de parc.