TL-SG3428X-M2 (V1): SFP+ cage 26 gives no link with any TL-SM5310-T, cage 27 blinks out with it
I look after a small office network, one switch closet, and the four SFP+ cages on our access switch carry the 10G links to the server rack. It ran for months without a thought and now one cage is simply gone.
- TP-Link TL-SG3428X-M2 (V1), firmware 1.20.4 Build 20241104 Rel.40746, adopted in Omada
- four TP-Link TL-SM5310-T 10GBASE-T modules in SFP+ ports 25-28
- CAT6A pach cords, far ends are two servers and a NAS
Port states as they stand now:
port 25 up, 10G
port 26 down, no link LED with any module
port 27 up, 10G, but drops for a moment whenever a cable goes into or out of port 26
port 28 up, 10GWhat I have tried:
- rotatted the modules through all four cages: the module from 26 links fine in 25 and 28, and every module I put into 26 stays dark, so the modules themselves are healthy
- new patch cords, different far-end ports, no change
- switch reboot, port disable/enable, no change
The part I cannot explain is port 27 twitching when the only thing I touch is port 26. Is cage 26 dead and worth an RMA, or is there something else to rule out first?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
This is a firmware regression in 1.20.4 Build 20241104, not dead hardware. The pattern you describe - one SFP+ cage that never lights up with known-good modules, plus a neighbour that blips when you disturb the dead one - is what that build does with TL-SM5310-T copper modules.
Roll the switch back to the previous release and the ports come back. In practice:
TP-Link's own people acknowledged that something is wrong in that release on Omada switches adapted for controller v5.14, said it was being looked into, and advised staying on the older firmware for the time being. So do not burn a support case on the hardware, spend it on the build number.
If you genuinely cannot downgrade, the only workaround is to live on the three cages that still work and keep port 26 empty. That is not a fix, just a way to stay in service until a corrected release appears.
Before you fill in an RMA form: when did this start, and did the switch pick up a firmware update around the same time? 1.20.4 Build 20241104 is fairly fresh, and the controller will happily push a new image on its own if automatic upgrades were left on.
Also worth pinning down: does port 27 twitch only while 26 has a module in it, or with 26 empty as well? A dead cage does not normally make a neighbour flap. That part smells much more like the software behind the ports than a cracked soder joint.
Same switch, same build here, so you are not alone. Port 25 was fine, port 26 gave no link LED with every module I own, and 27 and 28 came and went - one of them feeds an EAP783, so every drop was very visible. I went through exactly the same module-swapping ritual and talked myself into a dead cage.
It was not the cage. The box had taken a firmware update shortly before the trouble started, and going back to the previous image brought all four SFP+ ports back. Check the update history before you ship anything anywhere.
Confirmed, and it is embarrassing how close I was to sending the switch away. The update history shows 1.20.4 Build 20241104 landing a few days before the ports went strange, and I never started it by hand, so it came in on its own.
Rolled back to the previous release, re-adopted, and all four cages are up at 10G with port 26 included. Port 27 no longer twitches when I work on 26. Automatic upgrades are off now and the old image sits on the file server next to the config backup.
For the archive: the same family has another firmware trap worth knowing about. On a TL-SX3008F (V1) with an SM5310-T(UN) feeding a workstation, firmware 1.20.2 and 1.20.3 left the SFP+ port dead as soon as the PC went to sleep or was shut down. Moving the module to a free cage worked exactly once per cage, and once all cages had been used only a switch reboot brought the ports back. Pinning the port to 1G avoided it, at the price of the speed you paid for.
Another owner hit the same thing with RJ45 modules from 10Gtek (ASF-10G2-T), Wiitek and Xicom behind an Iocrest AQC113 adapter. Downgrading to 1.20.0 Build 20231011 Rel.42220 settled it for both of us. Different symptom, same lesson: copper SFP+ handling in these builds is where the bugs live.
Keep one more thing in the back of your head with this line of switches: an idle module can cost you more than a port. On a TL-SX3016F running 1.0.0 Build 20210730 Rel.65115 the CPU sat at 87-89% with no traffic at all and dropped a CPU RISING THRESHOLD line into the log every three minutes.
The load tracked the number of modules fitted - one module 0-1%, two 73-76%, three or more 88-90% - and it came down to Mellanox MFM1T02A-SR modules with fibre plugged in but nothing lit at the far end, so the link stayed down. Swapping those for Ubiquiti UF-MM-10G kept the CPU low whatever the port was doing, and simply pulling the unused modules cured it as well. TP-Link's own answer was that a module sitting there with its link down is just expensive for the chipset, and that the load drops back once the port is properly linked. That leaves the awkward half unexplained: change the brand, leave the module every bit as idle, and the CPU stays quiet. So once you are back on the older firmware, glance at the CPU graph too.