v1.5.22 Bug Reports and Comments

[sirhc]

Providing the code would not help you. Stephen could better explain why but it has to do with semaphore locking of the I2C bus when addressing the SFP control module.

Our switches ONLY support SFPs with a particular "copper" PHY (Marvel 88E1111) which is the same PHY Cisco uses, optical PHY are different. The issue comes from the control module in the SFP which is where off brands cheat and don't follow spec.


Some examples of where they cheat:
Their inrush exceeds spec and can draw down the 3.3V power supply and force reboot loops
When you disable the SFP port the module does not actually shut down the PHY which it should.
And there is more.

[mayheart]

Another switch upgraded to 1.5.22 that's has IGMP going through it for some legacy TV applications, coming in and out of a fiber SFP port here without any issues.

Both SFPs are bidi FS.COM Cisco branded.

[KeesH]

I noticed two issues.
Some switches - not all - lost the ability to connect to our NTP server. The switch had no problems pinging the NTP server.
Found issue on both WS-6 mini and WS-12-250-DC "Time not set"

When downgrading the WS-12-250-DC's it did not keep the ports powered. All of them went through a power cycle.

Warning for those that have WS-6 Minis attached to the WS-12-250-DC and plan on downgrading them at the same time....

[jorge]

Hi.

VLANs stopped working after upgrade to v1.5.22. I have about 100 VLANs, all of them stopped working. I use 1528 MTU on the ethernet and 1524 MTU on the VLAN. Downgrade to v1.5.16 made them work again.


Thanks for your work.

[Stephen]

Flo, when you get a chance.


On a switch that has 1.5.22 running and is exhibiting issue's with the SFP and PPPoE discovery.

Please try running this command:

Code: Select all

 from console in UI or SSH or console cable
cmd [ENTER] (drops you to linux)
/etc/init.d/vtss_appl restart
 

Please let us know if performing this action on a switch that is fully booted with the PPPoE issue changes it's behavior at all.

I think sirhc mentioned this before but most (well basically all) of the work done on SFP module's specifically had to do with copper module's. However, there is one exception but it's nature doesn't render an obvious solution at the moment.


It would also be helpful to know what SFP module's you are using, and if you could send me a config it could also help (you can PM me or post here if you are OK with that).

[sirhc]

Hi.

VLANs stopped working after upgrade to v1.5.22. I have about 100 VLANs, all of them stopped working. I use 1528 MTU on the ethernet and 1524 MTU on the VLAN. Downgrade to v1.5.16 made them work again.


Thanks for your work.

What do you mean 1524 MTU on the VLAN?
The switch only allows you to set the MTU via port?

[oeyre]

If your asking about getting stats from an SFP control module or the SFP PHY then no, that is not available in any device that I know of?

The specific information I mean would be:

Vendor
Product/Model
Serial
Temperature
Optical Tx/RX levels

I thought it would be helpful in 2 ways, first of all if people are having SFP issues they can dump out all the tech stuff for analysis.

Secondly it would be nice to know your optical signal level :)

Edit: Third if I start getting port errors I can easily check if its a dodgy FS unit that needs swapping ;)

[sirhc]

If your asking about getting stats from an SFP control module or the SFP PHY then no, that is not available in any device that I know of?

The specific information I mean would be:

Vendor
Product/Model
Serial
Temperature
Optical Tx/RX levels

I thought it would be helpful in 2 ways, first of all if people are having SFP issues they can dump out all the tech stuff for analysis.

Secondly it would be nice to know your optical signal level :)

Edit: Third if I start getting port errors I can easily check if its a dodgy FS unit that needs swapping ;)

We do report what the SFP module reports as the vendor, simply mouse over the SFP port and a box pops up and we provide everything the control module reports.

I think we could query "optical" SFP modules for that info (some as not all report properly / follow spec). I will suggest doing that in the WS3 line then possibly back port it to the WS line.

And when I say some, we have several 10G SFP modules that report incorrect info, even as far as fiber reporting as copper and copper reporting as fiber. Cisco "always" follows spec and you pay dearly for it. $$$$

When you buy based on $$$ it's a crap roll.

[Dawizman]

I didn't notice if it's known in my quick read through. Upgraded one switch at a new tower site in order to test before going network wide. WS-12-250-DC. It's been running for a few days no issues. This morning we moved customers over to it, and the SNMP interface traffic counters seem to have stopped working shortly after, despite SNMP still responding, and other OIDs working just fine such as power and thermal related sensors, and uptime.

How can I help diag?

[oeyre]

We do report what the SFP module reports

Well there you go! Never stop learning, kids.

I will suggest doing that in the WS3 line then possibly back port it to the WS line.

That would be great. Consider adding support for, and populating the relevant data into ENTITY-MIB and ENTITY-SENSOR-MIB in your SNMP implementation. Certain NMS like observium for example will then pick up and automatically start tracking/graphing all your levels, serials etc.

Plus a web/CLI page just to look at all the EEPROM/optical data.

Cisco "always" follows spec and you pay dearly for it. $$$$

We use Prolabs/FS for $$$ reasons instead of Cisco/Finisar and have been pretty lucky when it comes to compatibility in our Cisco/Juniper/MikroTik. We don't have many SFP in use on our Netonix and I'm not imformed enough to comment on compatibility, other than its been working without major incident on 1.5.8 and 1.5.16 releases. Will advise if we have any dramas this week upgrading to 1.5.22