Hi @empbilly 

Thanks for posting in our business forum.

We are not able to offer firmware fixes for the compatibility issues.

We recommend modules from us or the modules they described as "tested on our switches", yet this is not a guarantee for any third-party modules.

This behavior might be caused by the chipset. The commands may be the same, but they behave differently on different chipsets and architectures.

DDM readings seem to be a different case from the up/down instability you described.

We indeed see this behavior with third-party modules. I don't think you would experience the instability with our modules.

And for a full fiber switch, we do not recommend you connect all fiber ports because it could overheat and cause something like what you described. Instability up and down.

Common Questions About SFP Module and Media Converter

Hi @Clive_A 

Thank you for your response and the clarification regarding module compatibility and chipset behavior.
 

Perhaps I failed to mention this in my original post, but we did test with two TP-Link SFP modules, and the same issue occurred. In fact, the problem happened during an active support session with a TP-Link engineer here in Brazil. These TP-Link modules also did not report DDM status, just like the third-party ones.

Because of this, I believe the issue is not strictly related to using third-party or non-certified modules, but may point to a broader compatibility or firmware-related limitation affecting some ports or behaviors under specific conditions.

We will continue to investigate, but I wanted to make it clear that TP-Link modules were also tested and exhibited the same symptoms, including both the instability and the absence of DDM readings.

Additionally, is there any specific command or procedure that could be used to recover a locked port without needing to reboot the entire device? So far, we’ve tried shutdown / no shutdown and other basic interface resets, but none of them bring the port back online — only a full reboot seems to work.

Thank you again for the attention,

Hi @empbilly 

Thanks for posting in our business forum.

empbilly wrote

Hi @Clive_A 

 

Thank you for your response and the clarification regarding module compatibility and chipset behavior.
 

Perhaps I failed to mention this in my original post, but we did test with two TP-Link SFP modules, and the same issue occurred. In fact, the problem happened during an active support session with a TP-Link engineer here in Brazil. These TP-Link modules also did not report DDM status, just like the third-party ones.

Because of this, I believe the issue is not strictly related to using third-party or non-certified modules, but may point to a broader compatibility or firmware-related limitation affecting some ports or behaviors under specific conditions.

We will continue to investigate, but I wanted to make it clear that TP-Link modules were also tested and exhibited the same symptoms, including both the instability and the absence of DDM readings.

Additionally, is there any specific command or procedure that could be used to recover a locked port without needing to reboot the entire device? So far, we’ve tried shutdown / no shutdown and other basic interface resets, but none of them bring the port back online — only a full reboot seems to work.

Thank you again for the attention,

That is to say, does the instability persist on our modules?

DDM is a whole different story. I mean, your main focus is on stability. It really seems to be strange if you say you experience the same thing in the of stability.

It could not be a module issue, instead of your setup or diagram mistake.

How do you reproduce this instability? Under what circumstances do you find it out?

So it behaves just up and down? Without touching it at all, in the status, does it show like that? 

What about the interval? How many seconds between each interval?

What does the log say? Anything in the log?

hi  @Clive_A 

Yes, to clarify: the instability has also occurred using two different TP-Link SFP+ modules. So, while DDM support is a separate topic, our main concern here is indeed stability, and we’re observing the same behavior even with TP-Link-branded modules.

I’d like to provide an update to our ongoing investigation on the TP-Link Omada SX3016F (Hardware Version: 1.20, Firmware: 1.20.4 Build 20241206 Rel.38614). The most recent failure happened on port 13, and it’s important to note that this occurred during a support session with TP-Link Brazil’s technical engineer.
 

DDM Status

TP-Link SFP module model in use (TL-SM311LM Ver.2.0).

Syslog entries


 

• The module in use was an official TP-Link SFP. We also tested a second TL-SM311LM module, and the problem was reproduced.

• The issue cannot be resolved via shutdown/no shutdown commands. Only restarting the entire switch brings the port back online.

• We operate a network that includes equipment from Cisco, HP, Huawei, and others — and this issue does not occur with any of them under similar conditions.

• This isn’t limited to one port. We've previously had similar issues with other SFP ports, and both SX3016F units we own have already been replaced in the past due to port-related problems.

We understand that some behavior may vary by chipset/architecture, but since this has occurred on multiple ports (not just one), and using TP-Link-branded modules, we’re trying to determine:
 

1. Is there any CLI or hidden command to fully reset the SFP interface without rebooting the switch?

2. Has TP-Link confirmed or reproduced this behavior internally with the same model and firmware?

3. Is this expected behavior when all fiber ports are in use simultaneously, as previously suggested?
    

We appreciate any further input or suggestions from TP-Link engineering or other users.

Best regards,

Hi @empbilly 

Thanks for posting in our business forum.

empbilly wrote

hi  @Clive_A 

Yes, to clarify: the instability has also occurred using two different TP-Link SFP+ modules. So, while DDM support is a separate topic, our main concern here is indeed stability, and we’re observing the same behavior even with TP-Link-branded modules.

 

I’d like to provide an update to our ongoing investigation on the TP-Link Omada SX3016F (Hardware Version: 1.20, Firmware: 1.20.4 Build 20241206 Rel.38614). The most recent failure happened on port 13, and it’s important to note that this occurred during a support session with TP-Link Brazil’s technical engineer.
 

DDM Status

 

TP-Link SFP module model in use (TL-SM311LM Ver.2.0).

 

Syslog entries


 

• The module in use was an official TP-Link SFP. We also tested a second TL-SM311LM module, and the problem was reproduced.

• The issue cannot be resolved via shutdown/no shutdown commands. Only restarting the entire switch brings the port back online.

• We operate a network that includes equipment from Cisco, HP, Huawei, and others — and this issue does not occur with any of them under similar conditions.

• This isn’t limited to one port. We've previously had similar issues with other SFP ports, and both SX3016F units we own have already been replaced in the past due to port-related problems.

We understand that some behavior may vary by chipset/architecture, but since this has occurred on multiple ports (not just one), and using TP-Link-branded modules, we’re trying to determine:
 

1. Is there any CLI or hidden command to fully reset the SFP interface without rebooting the switch?

2. Has TP-Link confirmed or reproduced this behavior internally with the same model and firmware?

3. Is this expected behavior when all fiber ports are in use simultaneously, as previously suggested?
    

We appreciate any further input or suggestions from TP-Link engineering or other users.

Best regards,

A few things worth attention:

1. Like I gave earlier in that link, it is not recommended to connect all 16 ports. And there is a possibility to experience the overheating when the traffic is heavy. And consequently, it leads to instability at the ports. If this is for the test, I recommend you remove it and connect it like the recommended example.

2. To confirm what you described, you mean random fiber lines from random devices occur?

Anyway, I think you should test this by following the recommended connection.

Regarding whether we have the reproduction, I have not reported this to any team. The number one thing is to use the recommended connection and see if this behavior persists.

We indeed have similar reports like this. The proper connection is required.

There are no hidden commands. All the commands are listed in the CLI User Guide.

  @Clive_A 

Thank you again for your responses and engagement.

After reviewing the official documentation provided by TP-Link — including the Omada 10G L2+ Managed Switch datasheet, CLI guide, firmware release notes, and regulatory documents — I would like to respectfully challenge some of the statements made earlier in this discussion.

There is no mention whatsoever in the official product documentation of:

• A “recommended connection” model limiting the number of active ports.

• Any restriction on using all 16 SFP+ ports simultaneously.

• Warnings regarding overheating when all ports are active.

• Topological limitations or operating conditions that would invalidate full usage of the switch.

Quite the contrary — the SX3016F is explicitly marketed as a 16-Port 10G SFP+ switch, intended for “enterprise, campus, and ISP networks,” which inherently demand full-capacity operation, high availability, and resilience.

If there are known thermal design limitations or architectural constraints that prevent the switch from operating reliably with all ports in use, this should be clearly disclosed in the product’s official datasheet and user manual — not casually mentioned in forum replies or left to be “discovered” by customers through trial and error.

To reiterate, this is not an isolated event, nor an improper third-party module issue. Both of our SX3016F units have shown this behavior, and the only recovery method has been a full reboot — something that should never be necessary for port instability in an enterprise-grade switch.

At this point, we respectfully request:

1. What exactly do you mean by “recommended connection”?

2. A clear and official position from TP-Link:
   Can the SX3016F operate with all 16 ports active simultaneously under full load, as advertised — yes or no?

3. If not, why is this limitation not documented in any of the official materials?

4. Are there any firmware improvements or hardware revisions being developed to address this issue?

Thank you for your attention. We sincerely hope for a transparent response that reflects the level of professionalism TP-Link intends to represent in its enterprise solutions.

Best regards,

Hi @empbilly 

empbilly wrote

  @Clive_A 

 

Thank you again for your responses and engagement.

 

After reviewing the official documentation provided by TP-Link — including the Omada 10G L2+ Managed Switch datasheet, CLI guide, firmware release notes, and regulatory documents — I would like to respectfully challenge some of the statements made earlier in this discussion.

 

There is no mention whatsoever in the official product documentation of:

• A “recommended connection” model limiting the number of active ports.

• Any restriction on using all 16 SFP+ ports simultaneously.

• Warnings regarding overheating when all ports are active.

• Topological limitations or operating conditions that would invalidate full usage of the switch.

 

Quite the contrary — the SX3016F is explicitly marketed as a 16-Port 10G SFP+ switch, intended for “enterprise, campus, and ISP networks,” which inherently demand full-capacity operation, high availability, and resilience.

 

If there are known thermal design limitations or architectural constraints that prevent the switch from operating reliably with all ports in use, this should be clearly disclosed in the product’s official datasheet and user manual — not casually mentioned in forum replies or left to be “discovered” by customers through trial and error.

 

To reiterate, this is not an isolated event, nor an improper third-party module issue. Both of our SX3016F units have shown this behavior, and the only recovery method has been a full reboot — something that should never be necessary for port instability in an enterprise-grade switch.

 

At this point, we respectfully request:

1. What exactly do you mean by “recommended connection”?

2. A clear and official position from TP-Link:
   Can the SX3016F operate with all 16 ports active simultaneously under full load, as advertised — yes or no?

3. If not, why is this limitation not documented in any of the official materials?

4. Are there any firmware improvements or hardware revisions being developed to address this issue?

 

Thank you for your attention. We sincerely hope for a transparent response that reflects the level of professionalism TP-Link intends to represent in its enterprise solutions.

 

Best regards,

As you use our modules, the installation of our modules has this. I have reiterated that I offered you a link. Please read that.

1. The link I gave earlier has the screenshot from the installation guide for a full 10G connection.

2. I am under the impression that you are using the 10G instead of 1G. Yet, you wrote that you tried a 1G 311LM and experienced the same issue. But for the sake of the test, I think you should remove others for testing purposes, as we are troubleshooting. Necessary steps are needed.

3. If you are in the industry, you should know that 10G fiber to fiber, or 10G fiber to RJ45, would face an overheating issue if there is a heavy load. It is inevitable. What you can do is to add fans or cool the ambient temp for performance.

So, removing other modules would be a simple and straightforward way to verify if this is a problem with overheating.

4. 3016F can handle fiber connections 1 and 10G mixed. Or a full 10G as well. No issue reported before. To verify what I wrote, you can research the forum.

But as you described that you run into issues, to narrow down the possible causes, it's fair to ask you to remove the other 10G or any fiber connections.

If you don't want to proceed with this, that'd be fine.

5. You stated that the same module(third-party) works fine on other ports. And the said module on other ports, tested several, which is also what you wrote, experienced the stability problems.

With a proper logic to what you wrote, that indicates that the fiber should be fine, and 1/10G should work okay on this switch. 

Back to the question I asked, did you verify the peer connection of the "issued" fiber lines? What are the logs on the peer switch?

Diagram of the links? With the module number and switch model marked on the diagram.

Except for the fiber thing, any other features you configured on both sides?

You mentioned that you have used two modules from us to test, that is to say that you used two TP modules tested with the same fiber line and on random ports, the problem persists only with this fiber line?
Why not consider swapping the fiber line? This, based on my logic, seems to be a problem with the fiber line as you experience the issue on any ports but this instability does not occur on any ports the fiber lines.

About the warnings or heads-up you think should be written in the docs, no. That's not a practice in the industry.

About the questions, here are the answers:

1. As written above. See the link I provided earlier if this is a full 10G setup to ensure the best performance. You can keep 16 ports with 10G connections, but if there is a problem with the connection or overheating, consider cooling down the ambient temp or adding fans.

2. As written above.

3. As written above in point 3.

4. No. An internal test performed for 2 weeks before we released this product did not pose any problems. We have tested in extreme low temp and high temp for full fiber connections with our modules, and no issues were reported.

There are no firmware or fixes to the "instability" or "compatibility" since it was released in 2023. You can review the release notes for the past years. 

The recommended solution for incompatibility is to consider our modules.

About the "instability", I have not seen reports since its release and in the past two years, as I have been working as a tech support manager and a forum mod. There are indeed problems with the third-party modules and auto-negotiation. But never "instability".

hi  @Clive_A 

Thank you again for your response. I’d like to reinforce a few technical points based on our real-world operating conditions and the tests we've already conducted, as some of the hypotheses raised do not align with what we’re actually observing.

1. Fully climate-controlled data center environment
   Both SX3016F switches are installed in our Data Center, which operates with 24/7 climate control and proper temperature regulation. Therefore, the possibility of overheating is completely ruled out.

2. Optical link with ideal attenuation
   The fiber link where the TP-Link modules are connected shows an attenuation of -4 dBm, which is excellent by fiber optics standards, even for long-range single-mode modules. 
   Additionally, the same issue occurred on other links with different fibers, all of which showed attenuation levels well within recommended thresholds.

3. Tested with multimode and single-mode modules, including TP-Link
   The issue involving port lockup and loss of functionality happened with both multimode and single-mode modules, including two TP-Link TL-SM311LM modules, tested on different ports and over different fiber links.
   So, this is not an isolated case of third-party module incompatibility, nor is it related to a specific link.

4. It’s not viable to test with only one module connected
   The suggestion to test with just one module connected is not feasible in our environment, as these two switches provide connectivity to the entire campus. Disconnecting other links would result in service disruption to critical systems, which is simply not an option.

I would also like to add — respectfully — that we understand TP-Link may be taking a defensive stance to protect its product, which is expected from any manufacturer.
However, I want to emphasize that my goal here is to resolve this problem in a calm, technical, and objective manner.

That said, I would like to reiterate:

• The environment is stable and climate-controlled.

• The fiber links are in excellent condition, with proper attenuation.

• The issue occurred with different module types, brands, and connections.

• Ports are locking up in a way that only a full switch reboot restores operation — which is unacceptable for a product positioned as enterprise-grade.

Continuing to suggest that the issue is due to overheating or bad fiber links does not align with the evidence we've gathered.

Once again, I respectfully request a clear and official position from TP-Link regarding the SX3016F’s ability to fully utilize all 16 SFP+ ports under normal conditions, and whether there are any planned firmware updates or technical revisions to address these occurrences.

I look forward to your response.

Best regards,

@empbilly Have you tried downgrading to older firmware versions? For my SX3008F recent versions introduced SFP instability similar to what you are seeing and only a full restart would bring the port back. Downgrading to 1.20.0 build 20231011 for SX3008F fixed the SFP issues for me and others. We documented the issues here: https://community.tp-link.com/en/business/forum/topic/749964

I suspect there are SFP issues introduced with recent firmware versions that haven't been identified and fixed and it may affect your SX3016F too.

Hi @empbilly 

empbilly wrote

hi  @Clive_A 

 

Thank you again for your response. I’d like to reinforce a few technical points based on our real-world operating conditions and the tests we've already conducted, as some of the hypotheses raised do not align with what we’re actually observing.

 

1. Fully climate-controlled data center environment
   Both SX3016F switches are installed in our Data Center, which operates with 24/7 climate control and proper temperature regulation. Therefore, the possibility of overheating is completely ruled out.

2. Optical link with ideal attenuation
   The fiber link where the TP-Link modules are connected shows an attenuation of -4 dBm, which is excellent by fiber optics standards, even for long-range single-mode modules. 
   Additionally, the same issue occurred on other links with different fibers, all of which showed attenuation levels well within recommended thresholds.

3. Tested with multimode and single-mode modules, including TP-Link
   The issue involving port lockup and loss of functionality happened with both multimode and single-mode modules, including two TP-Link TL-SM311LM modules, tested on different ports and over different fiber links.
   So, this is not an isolated case of third-party module incompatibility, nor is it related to a specific link.

4. It’s not viable to test with only one module connected
   The suggestion to test with just one module connected is not feasible in our environment, as these two switches provide connectivity to the entire campus. Disconnecting other links would result in service disruption to critical systems, which is simply not an option.

I would also like to add — respectfully — that we understand TP-Link may be taking a defensive stance to protect its product, which is expected from any manufacturer.
However, I want to emphasize that my goal here is to resolve this problem in a calm, technical, and objective manner.

 

That said, I would like to reiterate:

• The environment is stable and climate-controlled.

• The fiber links are in excellent condition, with proper attenuation.

• The issue occurred with different module types, brands, and connections.

• Ports are locking up in a way that only a full switch reboot restores operation — which is unacceptable for a product positioned as enterprise-grade.

 

Continuing to suggest that the issue is due to overheating or bad fiber links does not align with the evidence we've gathered.

 

Once again, I respectfully request a clear and official position from TP-Link regarding the SX3016F’s ability to fully utilize all 16 SFP+ ports under normal conditions, and whether there are any planned firmware updates or technical revisions to address these occurrences.

 

I look forward to your response.

 

Best regards,

First, I know that you have a mindset to troubleshoot this. I have mine. If you ask this on the forum, I think we should follow (single) one's instead of keeping each's one track mind and talking about different stuff.  

And this is the forum I am in charge of. I usually require every step to be checked before I further move this case to a private ticket if necessary. I gotta understand the full picture of your network and the tests we should try. 

You may have tried them in a support ticket or not. But that's not my concern. I don't have access to your ticket (as you mentioned, you have another ongoing conversation with you in email), as it is a separate system. I still need a positive answer to the basic question about the issue.

Or you might consider keeping this conversation to the support ticket only instead of repeating yourself.

Second, regarding every question you asked me, I positively answered. If you think that I ignore or did not directly answer your question about the 3016F when being used with 16, then I'll repeat.

In a test environment, based on the reports before releasing this product, hot and cold temp, which you see the operating temp in the specs, this device works okay while 16 ports are used.

In the end, the questions I asked were ignored. That'll be fine. I will not repeat my questions because you seem to already have a conclusion in your heart. What I asked is a dialectic way to verify the issue. 

If you simply want a stand on whether it can work with 16 ports, you have it.
If you want to continue the debugging with me step-by-step, then we can continue by answering the questions I asked in the previous reply.

That'll be fine if you don't want to have downtime. And I understand. But rebooting also creates a short downtime and we are trying to troubleshoot. Some steps are inevitable when this goes deeper.

Asking about the temps and other stuff I discussed with you, and pay-attentions to the fiber connection are the basis. I don't know if the support asked you or not. I have not done training for them since I moved to the forum team. Senior support, which I used to train, no longer processes the tickets/chats.