I have a problem with two Cisco branded SFP's that keep reporting sfpVendorNotSupported in the Device Manager.
Re-seating the modules, swapping them into other ports and enabling/disabling the ports.
Anyone have any other ideas I can try?
Sorry, I should have posted the part number.
Contacted our support guy. Will post what we come up with.
where did you buy those and what is the output from "sho int fc 1/x transceiver"?
a lot of fake cisco products are in the market...
output from "show int fc 1/x transceiver":
part number is
serial number is
fc-transmitter type is unknown
fc-transmitter supports unknown link length
media type is unknown
Supported speed is unknown
Nominal bit rate is 0 MBits/sec
Failed to get runtime SFP state info.
Digital diagnostics feature not supported in SFP
They were originally working, I had moved them out of existing ports because in the 9134 I was told that in a block of 4 there is one chip controlling the 4 ports. We only have 24 licensed SFP's. I did make sure the licenses were activated on the ports I had moved them from. I've already had been able to get another couple GBICs working like this (moving from one set of 4 ports to another).
Suggestion from the vendor was to replace the GBICs. So I'm logging a support call to have them replaced. Still, I'm assuming they still work, but for some reason they've thrown this error. Fairly frustrating!
oh, sorry forgot to write that the vendor supporting the switches is HDS, and our initial vendor is probably someone I wouldn't suspect of delivering fake GBICs.
HDS contact said they have come across this problem before.
It was suggested to just log a support call to replace them.
Suggested that the data on the GBIC is corrupted, and that it can be reset in the factory.
Hi I got the same problem in our Blades what would be your suggestion ?
show int fc 2/1
fc2/1 is down (Error disabled - SFP vendor not supported)
Port description is ISL houicsw188 fc2/1
Hardware is Fibre Channel, SFP is short wave laser w/o OFC (SN)
Port WWN is 20:41:00:0d:ec:5a:de:40
Admin port mode is auto, trunk mode is on
snmp link state traps are enabled
Port vsan is isolated vsan
Receive data field Size is 2112
Beacon is turned off
5 minutes input rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
5 minutes output rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
1 frames input, 212 bytes
0 discards, 0 errors
0 CRC, 0 unknown class
0 too long, 0 too short
1 frames output, 212 bytes
0 discards, 0 errors
0 input OLS, 0 LRR, 0 NOS, 0 loop inits
0 output OLS, 0 LRR, 0 NOS, 0 loop inits
Unfortunately it is still unresolved for us. Our contracted hardware support from HDS is suggesting a firmware upgrade, but we haven't had one scheduled at this time.
Which SAN-OS version are you running ?
Over here (> 8000 ports) we've also a couple of them, usually malfunction hardware, just replace them. Optionally, eliminate the porthole by inserting the SFP in another hole.
Support guy confirmed that we have to do a whole switch replacement. Apparently he's been talking with Cisco and they have said that there is a glitch somewhere in the backplane and not being able to access some addressable memory which prevents some SFP's being recognised. Not sure the validity of the claim, but anyway.
Just wanted to post a follow-up.
The replacement switch was put in, and all was working fine.
The problem presented itself again today. Although this time the response from our support guys was to ask to restart the switch to see if it came good. The problem that originally presented itself as sfpVendorNotSupported went away after a reboot. Now, it looks like our support guys will be doing an IOS upgrade for us to see if that resolves any future problems.