[Sesse__]

> Often Cisco/etc will refuse support cases if you aren't using their optics, if the switches/routers even work with them in the first case, which isn't a given as often they'll refuse to work with non branded optics.

As others here have pointed out, Cisco reserves the right to do this but doesn't do it in practice. They don't even have a realistic chance to _detect_ a Cisco-programmed FS SFP, since it simply identifies the same as a genuine Cisco module.

If your case was directly related to the SFP (“I can't get a link on this fiber port”), then yes, they could probably refuse it. But if your case is about basically anything else on the switch, they won't care.

[bnjms]

> If your case was directly related to the SFP (“I can't get a link on this fiber port”), then yes, they could probably refuse it.

I have zero doubt they will. But also you prove nothing and are doing yourself and the vendor a disservice if you fake it. There’s no telling what your 3rd party transceiver is doing incorrectly. Better to get one single supported sfp and get that fixed which will probably fix your other issue too.

FS is so big they’re probably fine. Another option is to get one supported sfp, find if it’s encoded to an oem part, then buy and install the oem part directly. Easy to twist the arm of your var to do this.

[Sesse__]

> But also you prove nothing and are doing yourself and the vendor a disservice if you fake it. There’s no telling what your 3rd party transceiver is doing incorrectly.

If I report an IS-IS problem and the root cause is an OEM SFP on a completely unrelated port, then the design of the switch is pretty awful. :-)

[bnjms]

Oh! I’m in complete agreement.

I’ve never heard of a vendor being so difficult. My comment applies only to interface errors. (Up/down status, rx/tx errors, fec issue, etc) Any vendor without an override for 3rd party sfp should be rejected after RFP.