Are you paying too much for SFP+ transceivers?

Are you paying too much for SFP+ transceivers?

The fiber transceiver industry

When you buy transceivers for your switch, it is standard practice to order them from your network equipment manufacturer. However the switch vendor doesn’t actually manufacture these transceivers. There are a number of fiber interface transceiver manufacturers in the world, such as Finisar, Avago, JDSU, MRV, AOI, Delta and Wavesplitter.
These vendors will supply a variant of their standard transceiver to the switch vendor for resale. The switch vendor will perform testing of that transceiver against their switch, create a compatibility matrix and SKU for that transceiver and start selling the transceiver.

The switch vendor will request that the transceiver vendor flash the transceivers EEPROM with a vendor specific identifier. The switch operating system will use the I2C bus to query the transceiver EEPROM data, and verify that the transceiver has the correct identifier.  If the identifier doesn’t match, then the OS will not power up the laser.
The idea is that the switch vendor doesn’t want you to put anything into your router which hasn’t been approved by them. The cynical mind would ask just how much testing is actually required. As long as the transceiver complies with the required IEEE and MSA standards all it would take is a quick compatibility test and for the vendor could publish a list of all supported transceivers. But why would your friendly switch vendor kill the golden goose if customers are happy to pay top dollar for a re-badged transceiver?

Hidden Commands

Let’s look at a Cisco switch for our example.   There is a hidden command on Cisco IOS and NX-OS, called “service unsupported-transceiver”.   There is also a JunOS equivalent of “allow-other-transceivers”.
3750e-sw1(config)#service unsupported-transceiver [1]
Warning: When Cisco determines that a fault or defect can be traced to
the use of third-party transceivers installed by a customer or reseller,
then, at Cisco’s discretion, Cisco may withhold support under warranty or
a Cisco support program. In the course of providing support for a Cisco
networking product Cisco may require that the end user install Cisco
transceivers if Cisco determines that removing third-party parts will
assist Cisco in diagnosing the cause of a support issue.
Well that sounds ominious!! But hold-on. What Cisco is saying that it can’t provide support for a transceiver that it hasn’t certified, and that seems pretty fair to me.  It’s not easy to self-source transceivers though. If you bought a 3rd party transceiver, you would have the additional hassle of sourcing the transceiver from someone other than your channel partner. Also you’d have to have some Cisco-blessed transceiver on hand if TAC wanted to isolate a router problem, and rule our your non-blessed transceiver. Lastly you’d have the logistical challenge of having another support agreement with your transceiver vendor to handle defective transceivers.

Well why use 3rd Party Transceivers then?

Assuming you get an identical transceiver from Finisar and Cisco, the major difference is cost. The list price for an SR SFP+ transceiver from Cisco is ~ $1,500 USD, but I saw SR SFP+ Finisar transceivers listed at an average price of $150 USD on the internet. Even at a 30% discount for the Cisco transceiver, that’s still $1034 against $150, a sizable markup.
As high-density merchant-silicon based switches become mainstream, the per-port cost of the switch is dropping dramatically. The transceiver costs now become a very large part of the total system cost and, for a 48-port switch the transceiver costs could easily exceed the base cost of the switch.

Judgement call

There’s no silver bullet here. The cost-savings could be large, but there are supply-chain complexities as outlined above. Its up to you and your execs to decide on the appropriate path to take. At the very least you should be making an informed pricing decision when procuring your next batch of transceivers.
What’s your view on this? Post a comment below with your thoughts.

[1] Please don’t execute these commands on production devices unless you’re very confident. On certain platforms this command could reset ALL active interfaces.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.