Power classes, low-power & overheating

Modules draw anywhere from under a watt to twenty, and ports have limits. A module that needs more than its port can give is held in low power or shut down; a module that runs hot ages fast and throttles. Both look like "flaky optics" until you read the power class and the temperature.

Power classes

Each module declares its class in the identity block; the host compares it with the port's rating before enabling high power.

Family	Where declared	Classes
SFP / SFP+ / SFP28	SFF-8472 A0h byte 64 (options), byte 93	level 1 ≤ 1.0 W · level 2 ≤ 1.5 W · level 3 ≤ 2.0 W
QSFP+ / QSFP28	SFF-8636 byte 129 (bits 7–6, 5, 1–0), max power byte 107	1 ≤ 1.5 W · 2 ≤ 2.0 · 3 ≤ 2.5 · 4 ≤ 3.5 · 5 ≤ 4.0 · 6 ≤ 4.5 · 7 ≤ 5.0 · 8 > 5.0
QSFP-DD / OSFP / SFP-DD (CMIS)	page 00h byte 200 (class), byte 201 (max power ×0.25 W)	1 ≤ 1.5 W · 2 ≤ 3.5 · 3 ≤ 7 · 4 ≤ 8 · 5 ≤ 10 · 6 ≤ 12 · 7 ≤ 14 · 8 > 14

Typical real draws: 10G SR SFP+ ~0.8 W; 100G LR4 QSFP28 ~3.5–4.5 W; 400G DR4 QSFP-DD 8–12 W; 800G OSFP 14–18 W; 400ZR coherent 15–20 W.

Low-power mode

Every QSFP-class and CMIS module starts in low-power mode (a few hundred mW, laser off) so the host can read its identity and power class safely. The host then releases it to high power — or does not:

What you see	Cause	Fix
Module identified, no Tx, host log "power class exceeds port"	class byte higher than the port supports	use a lower-class module, or a port/platform rated for it; if the byte is simply wrong for the hardware, correct it
CMIS module stuck at ModuleLowPwr (state 2)	host never asserted high power, or module firmware handshake failed	host firmware supporting the module's CMIS version; power-cycle; see CMIS issues
Module works in one switch, low-power in another	different port power budgets (e.g. 3.5 W vs 5 W QSFP28 cages)	check platform port specifications
LPMode pin asserted by design	some hosts keep LPMode high until configured	enable the port / disable forced low power

The LPMode hardware pin and the software low-power bit (SFF-8636 byte 93, CMIS byte 26) both hold the module down; either one asserted is enough.

Overheating

Modules report case temperature in DDM (typically −5…+70 °C commercial range; max case temperature declared in SFF-8636 byte 190).
Above the high-temperature warning/alarm the module raises flags; many hosts disable the port on a temperature alarm, others let the module throttle — intermittent flaps on hot days are the signature.
Heat sources: dense faceplates (every neighbour is a heater), blocked airflow, front-to-back vs back-to-front cooling mismatch, cooled EML/DWDM modules and 400G+ DSPs, and 10GBASE-T copper SFP+ modules (2.5–4 W in a 1.5 W design).
Long-term effect: laser lifetime roughly halves for every ~10 °C — see Failures.

Checklist

Read the module's power class and compare with the port's rating.
Confirm the module reached high power (Tx present; CMIS state Ready).
Read temperature and its thresholds; compare with neighbours.
Check airflow direction and blanking panels; leave empty cages capped.
For 400G+/coherent, verify the host explicitly supports the module's power class — many first-generation QSFP-DD ports stop at class 6 or 7.

In CodingBox

The Check transceiver screen shows the declared power class; DDM shows live temperature against the module's own thresholds and logs it over time, so a module that only misbehaves at 3 pm in summer can be caught in the trend. Power-class bytes are editable in the EEPROM editor — correct them only to match the real hardware, never to fool a port into powering a module it cannot cool.

What temperature does to wavelength, bias, sensitivity and lifetime, and how to read the Vcc monitor: Temperature & voltage.