

- #FORTINET SUPPORT OF THIRD PARTY TRANCIEVERS INSTALL#
- #FORTINET SUPPORT OF THIRD PARTY TRANCIEVERS SERIAL#
- #FORTINET SUPPORT OF THIRD PARTY TRANCIEVERS FULL#
When you enter the first command, you get the Ominous Warning Message of Doom: These commands are both hidden, so you can’t ? them. Once you start getting the console spam from above, just enter these commands: service unsupported-transceiver While not horribly expensive, it did add a non-trivial cost to my project, not to mention all the extra hours of troubleshooting and banging my head against a wall.Ĭisco has an undocumented and totally unsupported solution to this problem. I ended up putting the old switches back in place as glorified fiber media converters until I figured out that new SFPs were needed.

The fiber ports locked up solid and would not come alive for anything. The above scenario happened to me when I traded out a couple of HP 2848 swtiches for some newer 2610s. They bore the information from Finisar, an electroics OEM. Their old series A SFP modules (HP calls them mini-GBICs) didn’t even have an HP logo. HP is the most curious case that I’ve run into. I don’t have the answer, but I can tell you that Cisco, HP, Dell, and many others do this all the time. Still others say that it’s because the manufacturing tolerances on the vendor SFPs is much better than the third party offerings, even from the same OEM. Others claim it’s to help TAC troubleshoot the switch better in case of a failure. You are stuck ordering your modules from the vendor at an inflated cost instead of buying them from a different source. Why do vendors do this? Some claim it’s vendor lock in. The fiber connection won’t come up and you’ll find yourself screaming at terminal window at 3:30 in the morning. If any of this info doens’t match the database on the switch, the OS will mark the SFP as not supported and disable the port.
#FORTINET SUPPORT OF THIRD PARTY TRANCIEVERS SERIAL#
While Cisco (and many others) OEM their SFP transceivers from different companies, they all have a burned-in chip that contains info such as serial number, vendor ID, and security info like a Cyclic Redundancy Check (CRC). You will see this error message if you have a third party SFP inserted into the Catalyst switch.
#FORTINET SUPPORT OF THIRD PARTY TRANCIEVERS INSTALL#
Huh?!? Why aren’t my fiber connections coming up? Am I going to have to roll the install back? What is going on here?!? %PM-4-ERR_DISABLE: gbic-invalid error detected on Gi1/0/50, putting Gi1/0/50 in err-disable state As you watch the console spam scroll up on your screen, you catch sight of something that makes your blood run cold: %GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port 65586 has bad crc You turn on your switches and wait for the interminably long ASIC and port tests to complete. Thankfully, the last network guy had the foresight to connect the fiber backbone at gigabit speeds.

You couldn’t buy everything new, so you’re reusing as much of your old infrastructure as possible. You had to cut some corners here and there.
#FORTINET SUPPORT OF THIRD PARTY TRANCIEVERS FULL#
You’ve been fighting for months to get the funding to get these switches so your servers can run at full gigabit speed.

You’ve just finished installing your new Catalyst switches into the rack and you’re ready to turn them up and complete your cutover.
