SFP port STOP working on flow control settings change?

[IntL-Daniel]

I have found probably an issue with SPF ports (tested on WS-12-250-AC and WS-10-250-AC and Ubiquiti module UF-RJ45-1G) - whenever I change flow control settings on SFP port, the link goes down (like unpluged cable) and the only way to make it work again is to:

* physicaly unplug / plug SFP module OR
* reboot the switch
(unfotunately even disable / enable SFP port is NOT a solution)


Tested on fw 1.5.5 up to 1.5.12 and the same behaviour, is this expected?

[sirhc]

Not all SFP modules work with all SFP ports and you will find 1 module that does not work and another of same model that does.

I have experienced this across many manufacturers including Cisco routers.

Read the steps I take to test each SFP nodule before deployment in these posts.

viewtopic.php?f=6&t=293&start=190#p36438

viewtopic.php?f=6&t=293#p1239

[IntL-Daniel]

OK, thanks for reply. I bet I bought these Ubiquiti modules bacause of your recommendation in the past. So could you please confirm, that if you change flow control settings on "compatible" module from your list that it still works (not like my case)?

[sirhc]

OK, thanks for reply. I bet I bought these Ubiquiti modules because of your recommendation in the past. So could you please confirm, that if you change flow control settings on "compatible" module from your list that it still works (no like my case)?

I have used and tested UBNT modules to work but as I said there are tolerances so one module may work fine and another does not.

If the SFP module fails the testing method I statited I do before deploying an SFP module I would not use it but it may work fine in another brand of equipment I uses so I use it elsewhere. But regardless of the manufacturer including my CIsco routers I perform the tests I stated.

Changing flow control on an SFP module and many other config changes like speed from AUTO to 1G and so on would be the same as a software reboot as far as the SFP module is concerned because it would drop the link make changes to the SFP module and attempt to reestablish the link.

I am sure that this module would fail switch software reboots, possibly every time sometime or just randomly which is why I state before deploying an SFP module do several software reboots and power cycles. "Chances" are that if it fails this test it will fail in all Netonix switches but yet another identical SFP will pass. Again this is +/- tolerances on timing in communications negotiation. This is why removing the SFP module and re-inserting it will fix it as it uses a totally different initial communications negotiation as the SFP module is powered down and powered back up sort of like rebooting a device / power cycling it.

[IntL-Daniel]

Thank you for all explanations, I really forgot that my reported "issue" could be related to long time known modules compatibility problem. But according to my investigations, 90% of these compatibility lockups could be solved by strictly set SFP port speed to 1G instead of Auto.

[sirhc]

Thank you for all explanations, I really forgot that my reported "issue" could be related to long time known modules compatibility problem. But according to my investigations, 90% of these compatibility lockups could be solved by strictly set SFP port speed to 1G instead of Auto.

No, in this event usually if you look at what we call the christmas tree at the top of the UI the switch graphic does not even show that it sees the SFP module as the grey box is dark. When you pull it [SFP module] and reinsert it the box turns light grey as they are now communicating [SFP module to the board SFP slot].

Again this is usually caused by a timing issues as with standard non MIL SPEC components you can have a +/- 3% variation. And if the switch is all the way one way and the SFP module is all the way the other way then you can see this happen. Which is why as I said if you buy 10 of the same SFP module maybe all 10 work fine or maybe 1 or 2 do not. Again tolerances. Cheaper SFP modules often use cheaper components and you see more of this.

In reality I do not think I have ever seen a Cisco BRand SFP act this way but I rarely pay the money for Cisco SFP modules except at my head end where I connect to my fiber provider.

Also if you are using copper 1G SFP modules you should use AUTO if possible (SFP+ ports do not always offer this option) not hard code speed, I have talked about why in other posts.

Also cheaper copper SFP modules tend to bridge ground current where some more expensive modules run fully isolated circuits providing 1500V isolation but even that isolation breaks down when the ground current exceeds about 400 Hz and ground current sometimes does via harmonics or from lightening strike carried into your service or up through your ground rods if a near ground strike.

[IntL-Daniel]

I would like still add some experience with SFP port and flow control. Currently I am testing other brand SFP Maxlink ML-SFP-RJ45-1G (cisco compatible) and really not sure if THIS is still the SFP compatibility problem. Could you Chris please check on your side these steps:

1/ connect SFP module to switch to port with disabled flowcontrol
2/ connect patch cable to the SFP and connect it to other device (other switch or whatever where you could control the current negotiated state of flow control) - in my case I did connect patch cable to other Netonix switch but to normal RJ45 metalic port with enabled flowcontrol

Now I can see on both sides that flow control is not negotiated, because only one side has it enabled - OK!

3/ now try to enable flow control on SFP port - both sides ports goes down and up a both sides started to show negotiated flowcontrol - OK!
4/ now try to disable flow control on SFP port - both sides ports goes down and up BUT event though SFP port shows no flow control negotiated (because it is disabled) on other side there is still signaled negotiated flowcontrol ! - so in fact it is still enabled on the SFP!

So the result - since one time you enable flowcontrol on SFP (from disabled state), it will stay enabled forever even though you try to disable it in web UI and it shows that it is disabled (but in fact no). The only way to really disable the flow control again is to unplug-plug the SFP module from the switch.

So could you please double check my steps with your 100% compatible SFP module? Or maybe there is really a bug in your fw? Thanks