Self-coding SFP+ optics on a FlexBox V3 versus pre-coded at a quarter of the price
We are a small regional ISP rebuilding the optics budget for next year. Every 10G spare on our shelf is coded for exactly one platform, so the spares pool is roughly three times larger than our failure rate justifies. The idea on the table is to buy re-codable modules and code them ourselves as they leave the shelf.
What is in the field:
- Cisco and Juniper on the aggregation side, several generations mixed
- 10GBASE-LR SFP+ on the metro links, that is where the money actually goes
- vendor-original modules only on the handful of ports covered by a support contract
The per-module numbers I have collected so far, same class of 10GBASE-LR SFP+:
Fiberstore, pre-coded 34.00 USD
Flexoptix, self-codable 136.80 USD
Flexoptix FlexBox V3 one-off cost of the programmer
Solid Optics multi-fiber tool no public price at all
Four times the price of a module for the ability to code it, plus whatever the box itself costs. That is a hard sell to the person who signs the invoices.
Two questions for people who actually run this. Do self-coded modules stay accepted by Cisco and Juniper gear once they are in service, and at what spares volume does the premium start paying for itself?
Comments 4
We have been coding our own optics on a FlexBox V3 for a good while, so on the technical half of your question: nothing has been rejected. Cisco and Juniper boxes take them, no warnings in the log, no ports held down, no arguments during a maintenance window. Whatever you are afraid of on that side has not happened here.
The money half is a different argument and I would not sell it upstairs as a per-module saving, because it is not one. You are not paying 136.80 instead of 34 for a better laser. You are paying it so the shelf holds one SKU instead of five. Count the modules you wrote off last year because they were coded for a platform you had already retired, and add the hours somebody spent driving a correctly coded spare to a site at night. That is the number the premium has to beat, not the price on the invoice.
That is roughly how I framed it internally, only without numbers behind it. Our write-off pile is mostly 1G parts coded for kit we decommissioned, so the argument is real but smaller than I would like.
For scale at the other end of the range: on the ports where we do keep originals, the cheapest single-mode 10G part we can get quoted from Cisco is an SFP-10G-LRM, at around a thousand dollars. Next to that, 136.80 for something I can recode and move between platforms stops looking expensive. It only looks expensive next to the 34 dollar pre-coded module, and that one has to be bought again every time the far end changes vendor.
Different corner of the same problem, in case it shifts your baseline. Ubiquiti sells its own coding tool now, the UACC-SFP-WIZARD, at 49 USD against roughly 369 USD for the established programmers, and their promotional module prices were 12 USD for 10G SR, 29 USD for 25G SR and 39 USD for 100G SR4, quoted as 10 to 70 percent under the competition.
Before anyone gets excited: the wizard codes Ubiquiti modules only. It is not a general purpose programmer and it will not touch the stock you already own, so it does not replace the box you are pricing. If your estate is Cisco and Juniper it buys you nothing at all. It is still worth knowing, because 369 USD for a programmer is going to get harder to defend.
One thing to keep in the model when you decide which ports keep originals.
Take the Dell 10Gb iSCSI SFP+ optical adapter kit, part 540-BBKJ. Optically it is a plain 10GBASE-SR: 850 nm, duplex LC, about 300 m on OM3. There is no iSCSI-specific optical layer and no separate standard for it. What that part number buys is the vendor string in the module EEPROM, so the storage controller reports a qualified module, plus the support entitlement on that path.
Which is exactly the calculation you are doing, except the answer flips depending on the port role. On a plain Ethernet switch a generically coded module usually just passes traffic and nobody notices. On a storage controller a module the box refuses to qualify becomes a storage incident, and the support conversation after it goes badly. So code your own for transport ports, and keep originals where the support case is the thing you are really buying.