Comment chaque NOS valide un module
Entre « module détecté » et « port up », chaque OS réseau effectue une vérification sur l’identité du module. Ce qu’il compare, ce qu’il fait quand la comparaison échoue et si un administrateur peut la contourner diffèrent selon le constructeur, la plateforme et la version — et cette différence constitue tout le sujet de la compatibilité des transceivers. Cette page met les comportements côte à côte, tels que documentés par les constructeurs et observés sur le terrain, afin qu’un module lu sur l’établi puisse être jugé au regard du boîtier auquel il est destiné.
Ce qui peut être vérifié
| Vérification | Octets concernés | Qui la fait |
|---|---|---|
| Sommes de contrôle CC_BASE / CC_EXT | SFP 63/95, QSFP 191/223, CMIS 222/255 | presque tout le monde — un échec donne invalid EEPROM (Sommes de contrôle) |
| Cohérence identifiant / connecteur / encodage | SFP 0, 2, 11 ; QSFP 0, 130, 139 | la plupart ; les types inconnus sont signalés comme tels |
| Codes de conformité vs port | SFP 3–10, 36 ; QSFP 131–138, 192 ; applications CMIS | la plupart — speed and type not supported (Codes de conformité) |
| Nom du constructeur + référence comparés à une liste | SFP 20–35, 40–55 ; QSFP 148–163, 168–183 | plateformes strictes et semi-strictes (Numérotation des références) |
| Signature propre au constructeur | zone constructeur (SFP 96–127, QSFP 224–255, CMIS custom) | quelques OEM ; un hachage lié au numéro de série |
| Format du numéro de série / code date | SFP 68–91 ; QSFP 196–219 | rare ; les ingénieurs support les vérifient manuellement |
| Classe de puissance vs port | SFP 64 ; QSFP 129/107 ; CMIS 200–201 | tous ceux qui implémentent la gestion de la puissance (Puissance et thermique) |
Comportement par constructeur
Commandes et comportements publics à la date des versions récentes ; les détails varient selon la plateforme et la version.
| Constructeur / NOS | Vérifications | En cas d’échec | Contournement | DDM pour le tiers |
|---|---|---|---|---|
| Cisco IOS / IOS-XE (Catalyst, ISR) | liste constructeur/PN et vérification propre au constructeur ; sommes de contrôle | %PHY-4-UNSUPPORTED_TRANSCEIVER, port errdisabled (gbic-invalid), laser coupé | service unsupported-transceiver (caché) + no errdisable detect cause gbic-invalid ; pas sur toutes les plateformes ; non pris en charge par le TAC | affiché une fois accepté ; certains champs vides |
| Cisco NX-OS (Nexus) | comme ci-dessus, moins strict sur de nombreuses plateformes DC | souvent up avec une trace ; les références strictes passent en errdisable | service unsupported-transceiver | généralement affiché |
| Cisco IOS-XR | liste d’optiques par plateforme, classe de puissance | état unsupported, le port peut rester down | limité ; selon la plateforme | partiel |
| Arista EOS | sommes de contrôle, cohérence du type | trace unsupported ; la liaison monte | aucun nécessaire | complet |
| Juniper Junos | liste constructeur/PN pour l’étiquette « supported », sommes de contrôle | liaison généralement up ; show chassis pic marque unsupported ; certaines plateformes EX/QFX retiennent le DDM ou les débits pour les PN inconnues | aucun officiel | complet pour les PN connues, partiel pour les inconnues |
| Huawei VRP | constructeur/PN ; non-Huawei → alarme | liaison up avec des alarmes transceiver phony récurrentes ; certaines plateformes restreignent | transceiver phony-alarm-disable (system view) | complet |
| H3C Comware | comme VRP | alarme | transceiver phony-alarm-disable | complet |
| HPE Aruba AOS-S / AOS-CX | liste constructeur/PN | unsupported, port down | allow-unsupported-transceiver | complet |
| Dell OS10 / OS9 / PowerConnect | sommes de contrôle ; vérifications de liste sur certains équipements plus anciens | traces ; anciens : errdisable | service unsupported-transceiver (anciens) | complet |
| Extreme EXOS / VOSS | sommes de contrôle, type | traces, up | — | complet |
| Ruckus/Brocade ICX (FastIron) | sommes de contrôle ; surveillance optique réservée aux PN Brocade sur certains modèles | up ; le DDM peut être absent | — | partiel |
| Brocade FOS (SAN) | PN et numéro de série de marque Brocade requis sur la plupart des plateformes Gen 5/6/7 | port Mod_Inv, non activé | aucun | optiques Brocade uniquement |
| Nvidia/Mellanox (Onyx, Cumulus, IB) | Ethernet : sommes de contrôle, type ; InfiniBand : infos du câble validées par le fabric manager | Ethernet up avec trace ; IB peut fonctionner à vitesse réduite ou être signalé | — | complet |
| SONiC / white-box | plugin de plateforme : sommes de contrôle, analyse CMIS | up ; champs inconnus affichés bruts | — | complet (selon le plugin) |
| MikroTik RouterOS / SwOS | aucune au-delà de l’analyse | up | — | complet |
| Ubiquiti | aucune au-delà de l’analyse | up | — | complet |
| NIC serveur (Intel, Broadcom, Mellanox) | listes blanches de pilote sur certaines familles Intel | le pilote refuse d’activer le port | paramètre de module allow_unsupported_sfp=1 (Intel ixgbe/i40e) | via ethtool -m |
Lorsqu’un contournement constructeur existe, il est généralement proposé en l’état : le module fonctionne, mais le constructeur ne s’engage pas à soutenir la combinaison. Les décisions de parc reviennent au propriétaire du réseau (Optiques tierces).
Ce que doit satisfaire un module « codé pour le constructeur X »
| Classe de plateforme | Minimum pour l’acceptation | Également recommandé |
|---|---|---|
| Permissive (Arista, SONiC, MikroTik, Extreme…) | sommes de contrôle valides, codes de type cohérents | vrai nom de constructeur et vraie PN — rien à gagner à coder en OEM |
| Vérification de liste (Juniper, Aruba, Huawei/H3C, NX-OS sur de nombreuses références) | nom de constructeur et PN exactement comme dans la liste de la plateforme, codes de conformité corrects pour le port | suffixe/grade de PN correspondant ; numéro de série et code date réalistes |
| Vérification de signature (Cisco IOS/IOS-XE, certains XR) | tout ce qui précède plus la zone propre au constructeur calculée pour ce numéro de série | champs d’identité cohérents avec la PN (longueur d’onde, portée, technologie) |
| Marque uniquement (Brocade FOS) | chaîne constructeur Brocade et famille de PN, format de numéro de série | — |
Comment fonctionne le volet établi : Verrouillage constructeur et codage, Recodage de l’EEPROM.
Lire le rejet
| Texte de trace / d’état | Signification | Étape suivante |
|---|---|---|
unsupported transceiver, Mod_Inv, phony | identité absente de la liste | contourner, ou coder vers une PN listée |
invalid EEPROM, checksum error | CC_BASE/CC_EXT incorrect | recalculer (Sommes de contrôle) |
speed and type not supported, unknown media type | les codes de conformité ne correspondent pas au port | corriger les codes ou utiliser un autre mode de port (Débit et vitesse) |
power class exceeds, bloqué en LowPwr | classe de puissance vs cage | Puissance et thermique |
Module not ready, l’état DP bloque | démarrage CMIS | Problèmes CMIS |
Commandes par NOS pour voir ces états : Vérifier les optiques sur un commutateur.
Changements lors des mises à jour logicielles
Les constructeurs durcissent ou assouplissent les vérifications d’une version à l’autre : nouvelle validation de signature, nouvelles listes d’optiques prises en charge, commandes cachées supprimées, gestion du DDM modifiée. Un parc d’optiques tierces ou codées qui fonctionnait hier peut se retrouver en errdisable après une mise à jour (Matrices de compatibilité et firmware).
Dans CodingBox
CodingBox affiche les octets exacts que lit chacune des vérifications ci-dessus — nom du constructeur, PN, sommes de contrôle, codes de conformité, classe de puissance — et la code database conserve les identités qu’accepte une classe de plateforme donnée. Vérifiez sur un port de test après codage ; c’est le commutateur, pas l’établi, qui a le dernier mot (Check transceiver).
Le pendant côté serveur — listes blanches de pilote par constructeur de NIC, contournements Intel, comportement Windows et ESXi : Compatibilité des transceivers sur les NIC.