Lire le DDM avec des outils : CLI, ethtool, SNMP, OpenConfig

Les mêmes octets A2h vous parviennent par de nombreuses portes : une CLI de commutateur, une NIC Linux, un outil d’interrogation SNMP, un pipeline de télémétrie en continu, ou un dump hexadécimal brut issu d’un programmateur. Cette page est le livre de recettes : les commandes, les OID et les chemins, et comment décoder un dump brut à la main quand l’outil que vous avez sous la main ne le fait pas.

CLI des commutateurs et routeurs

Plateforme	Commande DDM	Remarques
Cisco IOS / IOS-XE	`show interfaces transceiver detail`	seuils affichés à côté des valeurs ; `show idprom interface` pour l’identité
Cisco NX-OS	`show interface ethernet1/1 transceiver details`	par voie pour QSFP
Cisco IOS-XR	`show controllers optics 0/0/0/0`	inclut les alarmes et le tableau des voies
Juniper Junos	`show interfaces diagnostics optics xe-0/0/0`	seuils et état d’alarme inclus
Arista EOS	`show interfaces ethernet 1 transceiver dom`	`… transceiver detail` ajoute les seuils
Huawei VRP	`display transceiver interface XGigabitEthernet0/0/1 verbose`	—
MikroTik RouterOS	`/interface ethernet monitor sfp1`	`sfp-temperature`, `sfp-tx-power`, `sfp-rx-power`, `sfp-tx-bias-current`
Dell OS10	`show interface ethernet 1/1/1 transceiver`	—
NVIDIA Cumulus / Onyx	`l1-show swp1` / `show interfaces ethernet 1/1 transceiver`	`mlxlink -d <dev> -p <port> -m` pour les détails du module
SONiC	`show interfaces transceiver eeprom -d Ethernet0`	`sfputil show eeprom -d` ; `… presence`, `… lpmode`

Équivalents orientés identité et ce qu’il faut vérifier : Vérifier les optiques sur les commutateurs.

Linux : ethtool

ethtool -m eth0                 # identité décodée + DDM (si le pilote prend en charge l’EEPROM du module)
ethtool -m eth0 raw on hex on   # dump brut : A0h à 0x0000–0x00ff, A2h à 0x0100–0x01ff (SFP)
ethtool -m eth0 hex on offset 256 length 128   # page inférieure A2h uniquement
ethtool --show-fec eth0         # mode FEC
ethtool -S eth0 | grep -i fec   # fec_corrected_blocks / fec_uncorrectable_blocks

Pour les modules QSFP/CMIS, le dump suit la disposition paginée exposée par le pilote (page inférieure, page supérieure 00h, puis les pages 01h/02h/03h/10h/11h si prises en charge). ethtool décode entièrement SFF-8472 et SFF-8636, et CMIS partiellement selon la version du noyau.

Décoder un dump A2h brut à la main

La page inférieure d’A2h se trouve à l’offset 0x0100 d’un dump ethtool -m … raw on hex on. Les moniteurs en direct commencent à l’octet 96 d’A2h → offset 0x0160 du dump :

0x0160:  1a 80 80 e8 1b 58 0f a0 03 e8 ...
         └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘
        temp    Vcc   bias   Tx     Rx

Octets	Brut	Conversion	Valeur
96–97 température	`1A 80` = 6784 (signé)	÷ 256	26,5 °C
98–99 Vcc	`80 E8` = 33000	× 100 µV	3,300 V
100–101 bias Tx	`1B 58` = 7000	× 2 µA	14,0 mA
102–103 puissance Tx	`0F A0` = 4000	× 0,1 µW = 400 µW ; 10·log10(0,400)	−3,98 dBm
104–105 puissance Rx	`03 E8` = 1000	× 0,1 µW = 100 µW	−10,0 dBm

Ces conversions supposent un étalonnage interne (A0h octet 92 bit 5) ; avec un étalonnage externe, appliquez d’abord les constantes d’A2h 56–91 (Étalonnage). Les seuils se trouvent en A2h 0–39 selon les mêmes formats ; état/contrôle et indicateurs en 110–117 (Seuils et alarmes). QSFP : moniteurs de module aux octets 22–27, moniteurs de voie en 34–57 de la page inférieure ; CMIS : page inférieure 14–25 et page 11h 154–201 (Diagnostic par voie).

SNMP

Norme : ENTITY-SENSOR-MIB (RFC 3433)

La plupart des plateformes exposent chaque valeur DDM comme un capteur physique :

Objet	OID	Signification
entPhySensorType	1.3.6.1.2.1.99.1.1.1.1	4 voltsDC, 5 amperes, 8 celsius, 14 dBm
entPhySensorScale	1.3.6.1.2.1.99.1.1.1.2	8 = units, 7 = milli, 6 = micro…
entPhySensorPrecision	1.3.6.1.2.1.99.1.1.1.3	nombre de décimales de la valeur
entPhySensorValue	1.3.6.1.2.1.99.1.1.1.4	la mesure
entPhySensorOperStatus	1.3.6.1.2.1.99.1.1.1.5	1 ok, 2 unavailable, 3 nonoperational

L’index du capteur correspond à un port via ENTITY-MIB (entPhysicalDescr, entPhysicalContainedIn). Une valeur de type 14 (dBm), échelle 8, précision 2 et valeur −1234 signifie −12,34 dBm.

MIB des constructeurs

Constructeur	MIB / exemple d’objet
Cisco	CISCO-ENTITY-SENSOR-MIB `entSensorValue` (1.3.6.1.4.1.9.9.91.1.1.1.1.4), seuils dans `entSensorThresholdTable`
Juniper	JUNIPER-DOM-MIB : `jnxDomCurrentRxLaserPower` (…2636.3.60.1.1.1.1.5, 0,01 dBm), `jnxDomCurrentTxLaserBiasCurrent` (.6), `jnxDomCurrentTxLaserOutputPower` (.7), `jnxDomCurrentModuleTemperature` (.8)
Arista, Dell, et beaucoup d’autres	ENTITY-SENSOR-MIB uniquement
Huawei	objets optiques HUAWEI-ENTITY-EXTENT-MIB (puissance Rx/Tx, bias, température)
MikroTik	MIKROTIK-MIB `mtxrOpticalTable` (puissance Rx/Tx, température, tension, bias)

Les NMS open source (LibreNMS, modèles Zabbix, Observium) les détectent automatiquement et les représentent sous forme de graphique ; Prometheus utilise snmp_exporter avec les mêmes OID.

Télémétrie en continu (gNMI / OpenConfig)

openconfig-platform-transceiver modélise un module comme un composant à canaux physiques :

/components/component[name=Ethernet1/1]/transceiver/state/…            vendor, part, serial, form-factor
/components/component[name=…]/transceiver/physical-channels/channel[index=0]/state/input-power/instant
/components/component[name=…]/transceiver/physical-channels/channel[index=0]/state/output-power/instant
/components/component[name=…]/transceiver/physical-channels/channel[index=0]/state/laser-bias-current/instant
/components/component[name=…]/state/temperature/instant

Chaque leaf porte instant, avg, min, max sur l’intervalle d’échantillonnage. Abonnez-vous en mode SAMPLE à 10–60 s ; gnmic → Prometheus/InfluxDB → Grafana est le pipeline courant. Les modèles propres à chaque constructeur (Cisco, Juniper, Arista) exposent les mêmes données sous leurs propres chemins et ajoutent généralement des compteurs FEC et l’état des alarmes.

Windows et autres hôtes

Windows ne propose pas d’outil DDM natif ; les utilitaires constructeur des NIC (adaptateurs serveur) affichent parfois les données du module. FreeBSD affiche l’identité SFP et le DDM avec ifconfig <if> -v sur les pilotes pris en charge. Sur un hôte incapable de lire le module, le banc reste la solution de repli.

Fréquence d’interrogation et bonnes pratiques

Les moniteurs du module se rafraîchissent plusieurs fois par seconde ; interroger toutes les 1–5 minutes suffit pour suivre la tendance et reste léger pour le bus à deux fils.
Certaines plateformes sérialisent toutes les lectures de modules via un seul CPU de gestion : un balayage SNMP agressif sur des centaines de ports peut ralentir le système ou expirer.
N’exécutez jamais un second maître (pince de programmateur, outil in-band) sur un bus que l’hôte interroge (Interface à deux fils).

Comparer les sources

La CLI, le SNMP et la télémétrie lisent tous les mêmes octets ; des écarts de quelques dixièmes de dB entre eux relèvent du timing, pas d’une erreur. Une différence entre la lecture de l’hôte et celle du banc pour le même module mérite d’être comprise : la température, la Vcc et la gestion de l’étalonnage font varier les chiffres (Précision et limites).

Dans CodingBox

CodingBox est la porte du banc : DDM affiche les moniteurs et indicateurs décodés, avec les octets bruts à un clic dans l’EEPROM editor, et l’export CSV alimente les mêmes tableaux de bord que ceux consommés par SNMP ou la télémétrie : un module a ainsi un historique unique, du contrôle à réception jusqu’à la mise hors service (Surveillance).

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