For those outside the IT/networking realms, SFP use uniform connectors for both the networking device and the fiber cable, but the major vendors (Cisco and friends) have used firmware flags and settings to provide vendor lock-in for at least the last 15 years.
It used to be that in the event of a major outage or hardware failure you would need to issue additional debug commands to the effect of "I know this isn't your approved SFP but please just try it," if you were trying to replace a first party SFP with a third party one. TAC would more or less laugh at you and hang up if you sought support.
I'm not sure if this product will _actually_ change any of that, but here's hoping.
> TAC would more or less laugh at you and hang up if you sought support.
This is common belief and even a dire warning when filing TAC tickets. However, unless the third-party SFP is the prime suspect, I have never experienced a TAC from any major networking vendor[1] refuse support, let alone "laugh and hang up," even metaphorically.
It's good SOP to keep at least a couple SFPs for each networking manufacturer on the shelf, but third-party SFPs are normally in the ballpark of 10% of the cost of OEM and tend to be manufactured better[2].
1. Mostly Cisco, Juniper, HPE, Fortinet
2. I've had a far greater failure rate on OEM SFPs than SFPs from third-parties like Fs.com and USCritical. That and they feel much less flimsy than OEM.
Before I comment, a disclaimer about my small scale. I am running probably three hundred SFP+s running and less than five years of experience with optics. I don't have stock tracking for the individual manufacturers, and the failure rate comments here are based on gut-feel only. (there will be other people here used to far larger scales)
I bucket it into there being three options: genuine, clone, and good-clone.
We had a bad run with fs.com QSFP+s. Their SFP+s have been better to me, but reckon I have had a couple fail.
Atgbics SFP+s have been a reliable clone supplier for us. I don't think I have had any of those fail, and they have been my main vendor for a while now. You can order them programmed with personalities for Cisco, etc.
Part of the edge of fs.com is that it is so easy to place an order and get fast delivery. My main site is in another country to where I live, and I do a few trips a year. Several times they have made low-notice projects possible.
We accidentally ordered a load of “Generic brand” 100G QSFP from FS. Everything worked and appeared fine from the perspective of the switch and cards, reported OK status for everything, _except_ the lasers never turned on. Switching to an Extreme switch made the switch end work fine, but not the server.
Turns out Mellanox/NVIDIA hardware are _really_ picky about their cards. We bought a box from FS that reprogrammed the compatibility firmware and they worked instantly (FS also offered to return and reprogram but we needed it fast).
This was a big shock after dealing with nothing but CAT5/6/RJ45 that has been stable and common for decades (?).
> Atgbics SFP+s have been a reliable clone supplier for us.
With the caveat that I'm a USian and my scale is even lower than yours (10 10gbit SFP+ modules in my apartment combination home, office, and lab, running trouble-free for the past three years) I've found 10Gtek to be a reliable supplier. You can order 10gbit SFP+ modules straight from them for 14USD per per module. Though, shipping costs straight from them is currently pretty terrible: $35 if you're spending less than $800.
Stores like Newegg will often meet or beat that per-module price and offer free shipping if you buy a bundle of four or more... but modules with the personality you want may not be in stock.
Don't think I ever had a case there TAC said anything about my sfps. Most of the time if it's the SFP you replace it, code it correctly with a device like the one linked, or it's the wrong kind of SFP anyway.
Longer than that - in 2005 I was at a network hardware startup and we had vendor-locked (ahem, _qualified_) SFPs back then. Probably started back in 2001 when they were introduced.
I have installed 100s of SFP connections and I've never had an issue with compatibility. I've never even heard of this. Is it just for some ultra high end products or something?
It's more for enterprise gear than anything. For example, enterprise Cisco gear will absolutely reject non-cisco optics, but datacenter gear won't. As an example, the Nexus 9000 line accepts non-cisco optics by default. Granted, those are 10k+ boxes so somewhat high-end but nowhere near the ASR line.
The nexus line being more modern in spirit also helps. Catalysts still reject non-cisco optics without a configuration line afaik.
A good rule of thumb is whether the equipment tries to vendor-lock you in.
Another example that comes to mind is at least one generation of Intel NICs (don't remember if it's the 5xx or the 7xx), where even the open-source mainline (!) driver will reject the optic without a driver argument passed to it when modprobe'ing it.
It's more common the more expensive the SFP host equipment, yes. This "compatibility" stuff is generally euphemism for "ridiculously primitive DRM" - lots of higher end network equipment checks the SFP Vendor ID and Serial Number and will reject it if it doesn't match an allow-list of "qualified" hardware. Programmers like these let you clone the VID/Serial from a "qualified" SFP onto a random SFP.
The two X520s that I have will refuse to work with non-Intel transceivers unless either you're running Linux and have set the 'allow_unsupported_sfp' option, or have edited the card's EEPROM to unset the "shut down unless the transceiver is a Genuine Intel part" bit. It's my understanding that very many Intel NICs are like this.
I remember [0] the Juniper switches that I used to have (before I switched to Mikrotik) refusing to work with anything other than Official Juniper transceivers.
That might be a misremember - I've been using Juniper for nearly 20 years now and only ever saw a "software bug" in 18.x that broke OEM optics, but that was quickly addressed with a patch shortly after release.
Is there anything here from Ubiquiti that can allow me to plug an AT&T Fiber directly into my Unifi switch and get rid of the BGW620 crap? One would think AT&T Fiber is so common in Ubiquiti's target market that they should make an official SFP module for this already.
I know there are these XPS-GROUPON with "8311 firmware" SFP modules or something to bypass it but they cost $130+ and just wondering if there's something for <$50 before I pull the trigger.
Also
> 1000% lower pricing
What the hell does that mean? If some other vendor sells it for $1000, you sell it for -$9000?
If it's a PON then it's not Ethernet media. You would then be looking for an ONT SFP but those are far from ordinary SFPs. They are not just dumb devices, there is a lot going on inside them since they crammed a whole ONT into the SFP, and it communicates SFI back to the host equipment as if it would have been Ethernet.
Consider that AT&T fiber device to be a literal component of their network in a way that is: adopted into the network management system, configured with appropriate settings for the particular network and network segment, maybe the device is named in a particular way for their billing/CRM solution, there may need to be e911 info configured in the device if they often do VoIP service, etc.
In short, a gpon network is not quite the same as rolling to Walmart or whatever and just grabbing a replacement cable/dsl modem.
Ehhhhh... I'm not sure the market opportunity there is large enough for them to pursue.
They're strapped with SKU as is. Ubiquiti seems very focused on two main segments right now, which is growing enterprise switching and wifi, and their outdoor wireless gear, where (if memory serves from quarterly earnings reports) is now mostly concentrated outside the US.
>I'm not sure if this product will _actually_ change any of that, but here's hoping.
SFP programmers have been around forever and work great. This will solve the issue. The only really unique thing here is the form factor and price. I think the last time I looked at a programmer 8 years ago I seem to recall it was about 10x this price. I’m guessing cheaper ones have popped up out of China since then.
I like the pricing of this and especially the health check part.
But the programming an SFP module part has been a thing forever. In Europe at least.
Flexoptics for example have their own boxes to program optics.
Logitech held out on moving some of their more niche products to USB-C until they were forced by the EU. I'm sure when the author _started_ their journey they had not released the Ergo S yet, looks like it came out September '24.
I also gave up on waiting for the Ergo S and grabbed a Kensington TB550. The name is awful, but the trackball is excellent.
I was an active and fairly early Reddit user for many years, but the brutal changes to satisfy financial goals drove me away as well.
I think it’s interesting to see a flagging platform with a user base that will consistently post and upvote “fuck spez” celebrated here as a success, but I suppose the only thing that matters at this level of discussion is the almighty dollar.
Reddit has always had a ton of stupid irrelevant side projects. Remember "creddits"/ReddCoin, the "social cryptocurrency" they were developing? Hard to believe that was a decade ago. Harder to believe that in retrospect, they should have just done it, been ready when the crypto hype wave came and exited/IPO'd as billionaires.
In my experience 8BitDo makes nice products, but given the audience I have to ask... did anyone else's hands preemptively cramp just looking at this thing?
A couple thoughts on what it's primary use-case might be:
1) The thing is so small that it can fit in your pocket and you have it with you "all the time" to use with your phone/tablet/Switch console, whenever the mood strikes, even if you're away from home.
2) You have a cheap, perishable controller that you don't mind lending to visiting family/friends with small children who want to play your Switch console, but you're afraid they will break your $70 Switch Pro controller.
Ultimately users will go where the package maintainers are. There are more people out there willing and able to write Ruby today than Perl (Fink) or TCL (MacPorts).
I'm sure someone will start a macOS package manager based on python and yum to signal the waning days of those technologies.
MacPorts has 36k active ports. Estimates I see online for the number of Homebrew formulae are less than 5k. TCL isn’t difficult to write and most Portfiles are just a bunch of whitespace-aligned key-value pairs.
I'm secretly hoping for a makepkg / pacman-based replacement to homebrew, to have the same set of commands and package naming conventions across mac / win / linux
It used to be that in the event of a major outage or hardware failure you would need to issue additional debug commands to the effect of "I know this isn't your approved SFP but please just try it," if you were trying to replace a first party SFP with a third party one. TAC would more or less laugh at you and hang up if you sought support.
I'm not sure if this product will _actually_ change any of that, but here's hoping.