08-01-2012 08:20 AM - edited 03-07-2019 08:06 AM
I got a pair of new C3560X-24T-S switches with C3KX-NM-10G modules, and am trying to get a long distance 10G link up using 3rd party SFP-10G-ER SFPs (XGIGA with Cisco coded IDPROMs)
I've enabled use of unsupported transcievers with the following commands:
service unsupported-transceiver
no errdisable detect cause gbic-invalid
After that the switches accepts the SFPs but I get no light (sh int trans shows Tx -40), but if I insert a supported SFP first and then switches to my ER SFPs I get them to start transmitting, however I still don't LINK on the interface.
I've tried with both 12.2(55)SE3 (that the switches came with) and 15.0(1)SE3 with same results.
I know SFP-10G-ER SFPs are not supported on these switches, but are scheduled for the 15.0(2) release, but I was under the impression that they should already work using the above commands to enable the use of unsupported SFPs.
So my question is basically: Is the new code in 15.0(2) really needed to make ER SFPs work, so I should just wait for that release, or are my 3rd party SFP simply broken/un-compatible with these switches?
Also, could reprogramming them to look like SFP-10G-LR SFPs, which are supported, make any difference, or should it already have worked now with service unsupported-transceiver enabled if they were compatible?
Cheers // Mathias
Solved! Go to Solution.
08-01-2012 02:59 PM
I know SFP-10G-ER SFPs are not supported on these switches, but are scheduled for the 15.0(2) release, but I was under the impression that they should already work using the above commands to enable the use of unsupported SFPs.
If you can talk to the vendor of the SFP+ and have them reflash the SFP+ to come up as "LR" then it'll work. Someone has done it before (but different SFP manufacturer).
So my question is basically: Is the new code in 15.0(2) really needed to make ER SFPs work, so I should just wait for that release, or are my 3rd party SFP simply broken/un-compatible with these switches?
I have been waiting for this "promise" since 2010. I too have an "ER" issue with a 3750E.
08-01-2012 02:59 PM
I know SFP-10G-ER SFPs are not supported on these switches, but are scheduled for the 15.0(2) release, but I was under the impression that they should already work using the above commands to enable the use of unsupported SFPs.
If you can talk to the vendor of the SFP+ and have them reflash the SFP+ to come up as "LR" then it'll work. Someone has done it before (but different SFP manufacturer).
So my question is basically: Is the new code in 15.0(2) really needed to make ER SFPs work, so I should just wait for that release, or are my 3rd party SFP simply broken/un-compatible with these switches?
I have been waiting for this "promise" since 2010. I too have an "ER" issue with a 3750E.
08-02-2012 12:41 AM
leolaohoo wrote:
I know SFP-10G-ER SFPs are not supported on these switches, but are scheduled for the 15.0(2) release, but I was under the impression that they should already work using the above commands to enable the use of unsupported SFPs.If you can talk to the vendor of the SFP+ and have them reflash the SFP+ to come up as "LR" then it'll work. Someone has done it before (but different SFP manufacturer).
Yeah, I saw that post, so I'm waiting for a new delivery now with SFP+ coded as LR. It just surprises me that they don't work with "service unsupported-transceiver" enabled. I thought that command should surpress all the checks of the SFP type. But perhaps it just surpresses the check of the vendor name, but still checks for supported "models".
Anyway, thanks for the response. I'll update when I get the re-coded SFP's.
08-02-2012 03:25 PM
It just surprises me that they don't work with "service unsupported-transceiver" enabled.
It's got nothing to do with this command.
Without this command, the Cisco appliance will interrogate the SFP/SFP+ module and verify some funky algorithm inside. Cisco has their own code and if that code (from the SFP/SFP+) matches then the appliance will say something like "Oh good, you're a Cisco-approved part, proceed".
If that algorithm doesn't match then the appliance will put the interface into error-disable.
Using the command above, this will "override" this feature and prevent the interface from going into error-disable because the algorithm doesn't match.
There are a few lines in the existing IOS that will only support -SR and -LR SFP+ and this is the bit where it's preventing any SFP+ from operating. This is the line that Cisco has longed promise (since 2010) to fix by putting -ER in the code.
08-08-2012 05:06 AM
Got the reprogrammed SFP+' s today showing up as SFP-10GBase-LR and working fine!
08-08-2012 05:15 AM
LOL!
Thanks for the ratings.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide