Comment chaque NOS valide un module · Compatibilité des transceivers · Cartes réseau et commutateurs · Documentation · CodingBox
CodingBox Documentation

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érificationOctets concernésQui la fait
Sommes de contrôle CC_BASE / CC_EXTSFP 63/95, QSFP 191/223, CMIS 222/255presque tout le monde — un échec donne invalid EEPROM (Sommes de contrôle)
Cohérence identifiant / connecteur / encodageSFP 0, 2, 11 ; QSFP 0, 130, 139la plupart ; les types inconnus sont signalés comme tels
Codes de conformité vs portSFP 3–10, 36 ; QSFP 131–138, 192 ; applications CMISla plupart — speed and type not supported (Codes de conformité)
Nom du constructeur + référence comparés à une listeSFP 20–35, 40–55 ; QSFP 148–163, 168–183plateformes strictes et semi-strictes (Numérotation des références)
Signature propre au constructeurzone 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 dateSFP 68–91 ; QSFP 196–219rare ; les ingénieurs support les vérifient manuellement
Classe de puissance vs portSFP 64 ; QSFP 129/107 ; CMIS 200–201tous 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 / NOSVérificationsEn cas d’échecContournementDDM 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 TACaffiché une fois accepté ; certains champs vides
Cisco NX-OS (Nexus)comme ci-dessus, moins strict sur de nombreuses plateformes DCsouvent up avec une trace ; les références strictes passent en errdisableservice unsupported-transceivergénéralement affiché
Cisco IOS-XRliste d’optiques par plateforme, classe de puissanceétat unsupported, le port peut rester downlimité ; selon la plateformepartiel
Arista EOSsommes de contrôle, cohérence du typetrace unsupported ; la liaison monteaucun nécessairecomplet
Juniper Junosliste constructeur/PN pour l’étiquette « supported », sommes de contrôleliaison généralement up ; show chassis pic marque unsupported ; certaines plateformes EX/QFX retiennent le DDM ou les débits pour les PN inconnuesaucun officielcomplet pour les PN connues, partiel pour les inconnues
Huawei VRPconstructeur/PN ; non-Huawei → alarmeliaison up avec des alarmes transceiver phony récurrentes ; certaines plateformes restreignenttransceiver phony-alarm-disable (system view)complet
H3C Comwarecomme VRPalarmetransceiver phony-alarm-disablecomplet
HPE Aruba AOS-S / AOS-CXliste constructeur/PNunsupported, port downallow-unsupported-transceivercomplet
Dell OS10 / OS9 / PowerConnectsommes de contrôle ; vérifications de liste sur certains équipements plus ancienstraces ; anciens : errdisableservice unsupported-transceiver (anciens)complet
Extreme EXOS / VOSSsommes de contrôle, typetraces, up—complet
Ruckus/Brocade ICX (FastIron)sommes de contrôle ; surveillance optique réservée aux PN Brocade sur certains modèlesup ; 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/7port Mod_Inv, non activéaucunoptiques Brocade uniquement
Nvidia/Mellanox (Onyx, Cumulus, IB)Ethernet : sommes de contrôle, type ; InfiniBand : infos du câble validées par le fabric managerEthernet up avec trace ; IB peut fonctionner à vitesse réduite ou être signalé—complet
SONiC / white-boxplugin de plateforme : sommes de contrôle, analyse CMISup ; champs inconnus affichés bruts—complet (selon le plugin)
MikroTik RouterOS / SwOSaucune au-delà de l’analyseup—complet
Ubiquitiaucune au-delà de l’analyseup—complet
NIC serveur (Intel, Broadcom, Mellanox)listes blanches de pilote sur certaines familles Intelle pilote refuse d’activer le portparamè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 plateformeMinimum pour l’acceptationÉgalement recommandé
Permissive (Arista, SONiC, MikroTik, Extreme…)sommes de contrôle valides, codes de type cohérentsvrai 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 portsuffixe/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ériechamps 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’étatSignificationÉtape suivante
unsupported transceiver, Mod_Inv, phonyidentité absente de la listecontourner, ou coder vers une PN listée
invalid EEPROM, checksum errorCC_BASE/CC_EXT incorrectrecalculer (Sommes de contrôle)
speed and type not supported, unknown media typeles codes de conformité ne correspondent pas au portcorriger les codes ou utiliser un autre mode de port (Débit et vitesse)
power class exceeds, bloqué en LowPwrclasse de puissance vs cagePuissance et thermique
Module not ready, l’état DP bloquedémarrage CMISProblè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.


Si vous trouvez une inexactitude ou une erreur dans cet article, sélectionnez le passage concerné et appuyez sur Ctrl+Enter pour .