10Gb/s Ethernet: Migrating to a Broadcom SFP+ Module

Following an upgrade to my home local area network (LAN) back in April to support 10Gb/s speeds, I encountered some thermal hurdles. Because my existing in-wall wiring consists of CAT-6 (or a similar standard), I was required to utilize 10GBASE-T.

The Hardware Challenge

My current network topology relies on a router and a study-based switch, both of which utilize SFP+ cages for 10Gb/s connectivity. To bridge these to my copper cabling, I needed 10GBASE-T SFP+ modules.

As many enthusiasts know, these specific modules are notorious for generating significant heat—occasionally to the point of failure.

Thermal Performance Comparison

Device	Module Status	Observed Temperature	Result
`reggie` (Router)	Stable	Within limits	Operational
`nigel` (Study Switch)	Critical	$\approx 93^\circ\text{C}$	Unstable

To combat the heat in nigel, I attempted to apply some miniature heatsinks. While this provided a marginal improvement, it wasn't enough to withstand the rising seasonal temperatures.

The "Flapping" Phenomenon

Eventually, the module reached its thermal limit and began to overheat. This resulted in a loss of internet connectivity in my study. Upon reviewing the metrics, I observed a pattern known as "flapping":

The module hits a critical thermal threshold (likely around $95^\circ\text{C}$ ), triggers a protective shutdown, cools down, re-activates, and then heats up again in a continuous loop.

~~I tried solving this by leaving the air conditioning on 24/7 in the study.~~ While this worked, it felt like an inefficient and incorrect solution for a hardware problem.

Finding a Better Chipset

After a productive discussion on Hacker News, a user named xxpor pointed out that there are two distinct generations of 10GBASE-T SFP+ modules:

Marvell-based: Known for high power consumption and excessive heat.
Broadcom-based: Much more efficient and cooler.

I verified that the MikroTik S+RJ10 installed in nigel used the older Marvell silicon. The solution was clear: I needed a Broadcom-based replacement.

The Replacement: 10Gtek ASF-10G-T80

I sourced a module from 10Gtek. Their documentation (though slightly poorly translated) highlighted the benefits:

"10Gtek's ASF-10G-T80 is a newest version copper transceiver, its biggest feature are ultra lowpower consumption and longer transmission distance ( $1.6\text{W}$ C10Gbps 30m, $2.0\text{W}$ 110Gbps 80m). ASF-10G-T80 is a 10GBase mult-rate Copper RJ45 SFP+ transceiver, designed in with BROADCOM BCM84891 PHY chip..."

Key Specifications:

Chipset: BROADCOM BCM84891 PHY
Standards: IEEE 802.3an/az and SFP+ MSA
Max Distance: 80 meters (via CAT.6a or CAT.7)
Power Draw: $\le 2.0\text{W}$

The module arrived in an attractive small metal case.

Installation Process

The physical swap was more difficult than anticipated. Removing the old MikroTik module proved to be a struggle.

Research removal method (Watched Willie Howe's YouTube tutorial)
Disengage the locking latch
Fiddle with the module to extract it
Insert the new Broadcom module
Reconnect network cables
Power cycle the switch

After a tense few moments waiting for the boot sequence, the network successfully returned to an operational state.

Monitoring the Results

Once the system was live, I checked my monitoring dashboard, but I noticed a problem: no data was being reported.

To understand why, we have to look at the data pipeline I constructed for these metrics:

I had been tracking the values using a specific configuration in Telegraf, similar to this:

[[inputs.snmp]]
  agents = ["192.168.1.x"]
  version = 2
  [[inputs.snmp.field]]
    name = "module_temp"
    oid = "1.3.6.1.4.1.XXXX.X"

I realized that because I had changed the hardware, the way the metrics were being reported had changed...