Possible to use 3rd party optics with HPE FlexFabric 5700 40XG 2QSFP+ Switch JG896A

[msinelnikov]

Hello,

Possible to use 3rd party optics with HPE FlexFabric 5700 40XG 2QSFP+ Switch JG896A?

Command  allow-unsupported-transceiver work for this model?

[Ivan_B]

Hello!

There is no such command as "allow-unsupported-transceiver", even in Comware 5. That command is called "transceiver phony-alarm-disable" and all what it does - disables warnings about incompatible transceivers in the logbuffer , but it is not implemented in 5700 which runs on Comware 7 platform.

In general you can use 3rd party transceivers that aren't listed as officially compatible, it is not forbidden and unlike ProCurve switches in Comware-based ones there is no allowed list of supported transceivers. But, you need to know that there will be no support for such transceivers and no support for any issues with link instability, performance issues etc. if our Support recognizes that incompatible transceivers are in use.

[Ivan_B]

UPDATE: The 'transceiver phony-alarm-disable' command has been implemented in 5700 since version F2417. 

http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-a00005966en_us-1.pdf , Page 242, section "New feature: Transceiver module alarm suppression":

Usage guidelines
The device regularly checks transceiver modules for their vendor names. If a transceiver module does not have a vendor name or the vendor name is not HPE, the device repeatedly outputs traps and log messages. Disable transceiver module source alarm if the transceiver modules were manufactured or sold by HPE

[parnassus]

Hi! Great update.. Provided that latest HPE FlexFabric 5700 software release is the R2432P06 we can say for sure that that feature is pretty much historical (OTOH the F2417 is quite old, probably earlier than 2016, and AFAIK never officially published).

I don't understand the statement: "Disable transceiver module source alarm if the transceiver modules were manufactured or sold by HPE" ...shouldn't be the contrary? I mean...if the Transceivers are HP/HPE certified/supported then no alarm should be emitted by the switch OS...with this design...disabling that alarming mechanism could be just a reasonable way to suppress useful (but annoying) warnings about Transceivers that are not HP/HPE certified/supported as it is desired they should be...I don't see the reason to disable an alarming mechanism that should not start in presence of supported Transceivers.

[Ivan_B]

Hi Parnassus!

That really depends on your point of view HPE's statement should be considered as "some of transceivers that were manufactured or sold by HPE may not be properly recognized, so if you are totally sure you have obtained the transceiver from legitimate source, then just disable the alarm, because it is false positive."
And to be honest I've seen it many times how 100% legit and reliable transceivers due to certain reasons (software bug in particular release or incorrectly set registers in the transceiver by OEM) were reported as 3rd party ones and thus "incompatible". But if we are 100% sure about quality and compatibility of those transceivers we recommend to apply that command to get rid of those annoying log messages. 

Lools like it was initial intent about applicability and scope of that command and that's why the statement looks strange at first sight, taking into account how and when many people use it   But at the same time HPE can't be responsible if a customer decides to use 3rd party transceiver that has not been tested and then applies that command to get rid of alarming log messages, especially taking into account potential impact on network stability and production services. Perhaps that's why using of 3rd party transceivers is not even mentioned in the doc  

[parnassus]

Hi Ivan!

Yep very strange warning approach...but your explanation is quite reasonable.

With my limited experience (I haven't seen many hundreds or thousands of transceivers, just many dozens) it's not that hard to believe about the issues your reported causing troubles also on on legitimate supported and HP/HPE branded Transceivers (OEM Firmware bugs or Switch firmware bugs) so it's totally possible that's the reason behind the whole point.

---

@Ivan_B wrote: But at the same time HPE can't be responsible if a customer decides to use 3rd party transceiver that has not been tested and then applies that command to get rid of alarming log messages, especially taking into account potential impact on network stability and production services. Perhaps that's why using of 3rd party transceivers is not even mentioned in the doc  

---

I agree 100%.

What I learnt is that if it's 3rd party and it eventually works (being not switch vendor's original, not certified and not supported as per vendor documentation)...it doesn't necessarily mean that it is supported by HP/HPE/Aruba (in any case) and it also doesn't mean it can't cause issues...on the contrary! that's no matter if Comware 5/7 based switch series were always more tolerant about 3rd party transcerivers if compared to others switch series of the very same vendor (it's enough to compare what HP/HPE/Aruba permits - more or less strictly - on its other switch lines, such as ArubaOS-Switch based or fresh new ArubaOS-CX based switch series).

[Ivan_B]

Hi @msinelnikov!

Did you have time to try the solution proposed? Did it resolve the problem?

Thank you in advance!