Catalyst 3850 err-disables the port when a ThinkSystem SR650 uses Lenovo 46C3447 SR optics
New ESXi host going into a rack that hangs off a campus 3850. Management on copper came up without drama, the 10G uplinks did not: as soon as the server boots, the switch port drops into err-disable and the host sees nothing on that vmnic.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, with an Emulex VFA5.2 2x10GbE SFP+ adapter
- Lenovo 10GBASE-SR modules, 46C3447, in the adapter
- Cisco WS-C3850-24XS-S with Cisco SFP-10G-SR on the switch side
- OM3 LC-LC patch between them
Te1/0/7: goes err-disabled within seconds of the server powering on
ESXi: the uplink shows DISCONNECTED
Same patch cord, Cisco SFP-10G-SR at both ends switch to switch: link up and stableAlready tried:
- moved the server to a different port on the same switch, same behaviour
- swapped the 46C3447 for its twin from the other adapter port
- fresh patch cord, cleaned and reseated both ends
The fibre and the switch-side optic are clearly fine, so something is objecting to the Lenovo module. Which side is doing the objecting here, the server or the switch, and is there a way to make the 3850 live with it?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
That log settles it.
gbic-invalidis the switch refusing what it reads as an unauthorised module, and the check that fires lives on the Cisco side, not on the SR650 and not in ESXi. It objects to the Lenovo-coded SR optic in that link and kills the port before the link is ever evaluated, which is also why moving ports and swapping cords changed nothing for you.Two lines in global configuration:
The first tells the switch to carry on with a module it does not recognise, the second stops err-disable from shooting the port when that CRC check fails. Neither is retroactive, so bounce the port afterwards and reseat the fibre while it is down:
Save the configuration once it is up. If it only lives in the running config, the port comes back err-disabled after the next reload and you get to debug this again at a much worse moment.
Two caveats. You are now outside Cisco's supported configuration: they consider third-party optics untested and TAC can decline an interoperability case that involves one, which matters if this link sits under a contract. And
service unsupported-transceiveris not a universal fix. The same bad crc message survives it when the port itself is the obstacle, for instance a 1G-only SFP slot with a 10G module pushed into it, so if the port stays down after the bounce, check what speed each end is actually running before blaming the optic again.Before anyone guesses: what does the switch actually log when the port goes down? Err-disable always names its cause, and the cause changes the answer completely. A security or CRC complaint about a module is a different problem from a flap or a protocol trip, and the remedy for one does nothing for the other.
Pull
show loggingfrom around the moment the server powers on and post the lines for that port. Also confirm what is physically sitting in Te1/0/7, you say Cisco SFP-10G-SR, so is the 46C3447 the only non-Cisco part anywhere in that paht?Log from the moment it drops, two lines for that port:
So it is the security check firing, not a flap. And yes, the switch end is a genuine Cisco SFP-10G-SR out of a Cisco box, the 46C3447 in the server is the only Lenovo-coded part in the path. Which is what confused me, because the message names the port on the switch rather than anything on the server side.