Leitura de DDM com ferramentas: CLI, ethtool, SNMP, OpenConfig

Os mesmos bytes de A2h chegam até você por muitas portas: a CLI de um switch, uma NIC Linux, um coletor SNMP, um pipeline de telemetria em streaming, ou um dump hexadecimal bruto de um programador. Esta página é o livro de receitas — os comandos, os OIDs e caminhos, e como decodificar manualmente um dump bruto quando a ferramenta à sua frente não faz isso.

CLI de switches e roteadores

Plataforma	Comando DDM	Notas
Cisco IOS / IOS-XE	`show interfaces transceiver detail`	limiares mostrados junto aos valores; `show idprom interface` para identidade
Cisco NX-OS	`show interface ethernet1/1 transceiver details`	por lane para QSFP
Cisco IOS-XR	`show controllers optics 0/0/0/0`	inclui alarmes e tabela de lanes
Juniper Junos	`show interfaces diagnostics optics xe-0/0/0`	limiares e estado de alarme incluídos
Arista EOS	`show interfaces ethernet 1 transceiver dom`	`… transceiver detail` adiciona limiares
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` para detalhes do módulo
SONiC	`show interfaces transceiver eeprom -d Ethernet0`	`sfputil show eeprom -d`; `… presence`, `… lpmode`

Equivalentes voltados à identidade e o que procurar: Verificando ópticas em switches.

Linux: ethtool

ethtool -m eth0                 # identidade decodificada + DDM (quando o driver suporta a EEPROM do módulo)
ethtool -m eth0 raw on hex on   # dump bruto: A0h em 0x0000–0x00ff, A2h em 0x0100–0x01ff (SFP)
ethtool -m eth0 hex on offset 256 length 128   # apenas a página inferior de A2h
ethtool --show-fec eth0         # modo de FEC
ethtool -S eth0 | grep -i fec   # fec_corrected_blocks / fec_uncorrectable_blocks

Para módulos QSFP/CMIS o dump segue o layout paginado que o driver expõe (página inferior, superior 00h, depois as páginas 01h/02h/03h/10h/11h quando suportadas). ethtool decodifica totalmente SFF-8472 e SFF-8636, e parcialmente CMIS, dependendo da versão do kernel.

Decodificando manualmente um dump bruto de A2h

A página inferior de A2h no offset 0x0100 em um dump ethtool -m … raw on hex on. Os monitores ao vivo começam no byte 96 de A2h → offset 0x0160 do dump:

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

Bytes	Bruto	Conversão	Valor
96–97 temperatura	`1A 80` = 6784 (com sinal)	÷ 256	26,5 °C
98–99 Vcc	`80 E8` = 33000	× 100 µV	3,300 V
100–101 Tx bias	`1B 58` = 7000	× 2 µA	14,0 mA
102–103 Tx power	`0F A0` = 4000	× 0,1 µW = 400 µW; 10·log10(0,400)	−3,98 dBm
104–105 Rx power	`03 E8` = 1000	× 0,1 µW = 100 µW	−10,0 dBm

Essas conversões assumem calibração interna (A0h byte 92 bit 5); com calibração externa, aplique antes as constantes de A2h 56–91 (Calibração). Os limiares ficam em A2h 0–39 nos mesmos formatos; status/controle e flags em 110–117 (Limiares e alarmes). QSFP: monitores do módulo nos bytes 22–27, monitores de lane em 34–57 da página inferior; CMIS: página inferior 14–25 e página 11h 154–201 (Diagnóstico por lane).

SNMP

Padrão: ENTITY-SENSOR-MIB (RFC 3433)

A maioria das plataformas expõe cada valor de DDM como um sensor físico:

Objeto	OID	Significado
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 = unidades, 7 = mili, 6 = micro…
entPhySensorPrecision	1.3.6.1.2.1.99.1.1.1.3	casas decimais no valor
entPhySensorValue	1.3.6.1.2.1.99.1.1.1.4	a leitura
entPhySensorOperStatus	1.3.6.1.2.1.99.1.1.1.5	1 ok, 2 indisponível, 3 não operacional

O índice do sensor mapeia para uma porta através da ENTITY-MIB (entPhysicalDescr, entPhysicalContainedIn). Um valor do tipo 14 (dBm), escala 8, precisão 2 e valor −1234 significa −12,34 dBm.

MIBs de fabricantes

Fabricante	MIB / objeto de exemplo
Cisco	CISCO-ENTITY-SENSOR-MIB `entSensorValue` (1.3.6.1.4.1.9.9.91.1.1.1.1.4), limiares em `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 e muitos outros	apenas ENTITY-SENSOR-MIB
Huawei	objetos ópticos da HUAWEI-ENTITY-EXTENT-MIB (potência Rx/Tx, bias, temperatura)
MikroTik	`mtxrOpticalTable` da MIKROTIK-MIB (potência Rx/Tx, temperatura, tensão, bias)

NMS de código aberto (LibreNMS, templates do Zabbix, Observium) descobrem esses objetos automaticamente e os representam em gráficos; o Prometheus usa o snmp_exporter com os mesmos OIDs.

Telemetria em streaming (gNMI / OpenConfig)

openconfig-platform-transceiver modela um módulo como um componente com canais físicos:

/components/component[name=Ethernet1/1]/transceiver/state/…            fabricante, número de peça, número de série, fator de forma
/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

Cada leaf carrega instant, avg, min, max ao longo do intervalo de amostragem. Assine no modo SAMPLE a cada 10–60 s; gnmic → Prometheus/InfluxDB → Grafana é o pipeline mais comum. Os modelos nativos de cada fabricante (Cisco, Juniper, Arista) expõem os mesmos dados sob seus próprios caminhos e costumam acrescentar contadores de FEC e estado de alarme.

Windows e outros hosts

Não existe uma ferramenta de DDM nativa no Windows; utilitários de fabricantes de NIC (adaptadores de servidor) às vezes mostram os dados do módulo. O FreeBSD mostra a identidade e o DDM do SFP com ifconfig <if> -v em drivers compatíveis. Em um host que não consegue ler o módulo, a bancada é o recurso alternativo.

Taxas de sondagem e etiqueta

Os monitores do módulo se atualizam algumas vezes por segundo; sondar a cada 1–5 minutos é suficiente para tendências e é gentil com o barramento de dois fios.
Algumas plataformas serializam todas as leituras de módulo através de uma única CPU de gerenciamento — varreduras SNMP agressivas de centenas de portas podem ficar lentas ou expirar.
Nunca execute um segundo mestre (clipe de programador, ferramenta in-band) em um barramento que o host está sondando (Interface de dois fios).

Comparando fontes

A CLI, o SNMP e a telemetria leem os mesmos bytes; diferenças de alguns décimos de dB entre eles são questão de tempo de leitura, não erro. Uma diferença entre a leitura do host e a leitura na bancada do mesmo módulo vale a pena entender: temperatura, Vcc e o tratamento da calibração mudam os números (Precisão e limites).

No CodingBox

O CodingBox é a porta da bancada: o DDM mostra os monitores e as flags decodificados, com os bytes brutos a um clique de distância no EEPROM editor, e a exportação em CSV alimenta os mesmos painéis que consomem SNMP ou telemetria — assim um módulo tem um único histórico desde a inspeção de entrada até o descomissionamento (Monitoramento).

Se você encontrar uma imprecisão ou um erro neste artigo, selecione o trecho correspondente e pressione Ctrl+Enter para .