Instability and port blocking on the SX3016F switch
Instability and port blocking on the SX3016F switch
Dear all,
I would like to share a case we are facing with the TP-Link Omada SX3016F model (Hardware v1.20, Firmware 1.20.5 Build 20250121 Rel.52254), involving recurring failures on SFP ports and possible compatibility issues with third-party modules — and even with TP-Link modules.
Environment and Context
We have two TP-Link SX3016F switches operating as edge aggregators in an institutional environment. In both devices, we have experienced episodes of SFP port lockup, requiring a full reboot of the switch to restore connectivity — even applying shutdown/no shutdown on the affected interface does not resolve the issue.
Summary of the Issue
The most recent problem occurred on port 1/0/2, which entered a failure state, stopped responding to administrative commands, and only recovered after a physical reboot of the switch.
The SFP module used in these ports is the FlexMedia FMP88 2MM0,6C-LC, which operates normally on several other ports of the same device.
It is important to note that both switches have previously been replaced due to port-related issues, highlighting the need for close attention to this product line.
Support and Tests Performed
Contact with TP-Link support resulted in a recommendation to update the firmware (Build 20241206), which was applied, but the problem persisted.
The technical team confirmed that port 1/0/2 was flapping (frequent up/down state), as evidenced through the show logging buffer command.
The show ddm stats command did not return DDM readings for the installed module.
We moved the module from port 2 to port 13, where it resumed normal operation.
In addition, we conducted tests with two TP-Link SFP modules, and even in these cases, DDM readings were not displayed, indicating a possible compatibility issue or inconsistency in DDM support on specific ports or firmware builds.
Request for Feedback
We would like to know if other users have experienced similar instabilities, especially regarding DDM readings and intermittent failures on specific ports.
In our practical experience, even when applying shutdown and no shutdown commands to the affected interface, the port does not return to normal operation on the SX3016F, requiring a full switch reboot to restore service.
We operate a network with equipment from various manufacturers (such as Cisco, HP, Huawei, etc.), and in similar port lockup cases, it has always been possible to recover the port with administrative commands, without the need to reboot the entire device.
Thus, is there any particular behavior in the SX3016F that explains why shutdown/no shutdown is not sufficient to unlock a port in the event of an SFP module failure?
Is there any specific procedure or additional configuration that could be applied to avoid the need for a complete reboot in such cases?
I appreciate any contributions in advance.
Best regards,
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
hello @Clive_A
Thank you for your reply and for confirming that the SX3016F can operate with all 16 SFP+ ports active under full load — even if only in a test environment. That was one of the core questions, and I appreciate finally having a clear answer on that point.
That said, I feel it’s important to address the tone and direction this conversation is taking.
I understand this is the forum you're responsible for, and I respect that. Likewise, I hope you can also recognize that I’m not here to argue — I’m here to solve a recurring issue that is impacting a production environment. I’ve followed a structured troubleshooting approach, provided data, logs, test results, environmental conditions, and module details.
This isn’t about "having a conclusion in my heart" — it’s about drawing logical conclusions from consistent technical evidence.
I understand and accept that your process involves checking step-by-step, but some suggestions — like removing most fiber links in a production switch — are simply not feasible in a live institutional network. That doesn’t mean I’m unwilling to troubleshoot. It means we need to adapt the method to reality, and base our steps on what’s both technically valid and operationally viable.
As for the questions you raised earlier — most of them have already been addressed:
-
Fiber conditions were shared (attenuation levels),
-
Module models and brands were specified,
-
Environmental factors (temperature, cooling) were ruled out with full documentation.
To conclude, I’ve kept this discussion technical and transparent from the beginning. If TP-Link prefers to continue this via private ticket, I’m fine with that too — but I will not ignore repeated and confirmed signs of failure in a product that’s expected to perform under enterprise conditions.
Since we haven’t experienced further issues over the last few days, we will continue monitoring the situation. If the problem happens again, we will consider testing the suggestion from user @kash_.
Best regards,
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 764
Replies: 11
Voters 0
No one has voted for it yet.