Third-party 32G FC SFP+ in a Brocade G610: is Mod_Inv the end of the conversation
We are adding a G610 to an existing fabric and there is a box of non-Brocade 16G/32G FC SFP+ left over from another build. Before I plan any ports around them I put one into a spare port on the bench to see what the switch makes of it.
- Brocade G610, Gen 6
- third-party 32G FC SFP+, no Brocade markings on the module
- Brocade-branded 16G optics pulled from an older switch, for comparison
- same patch cord in both tests
switchshow
...
8 8 010800 id N32 Mod_InvThere is also an entry in the system error log about an unqualified transceiver every time the module is inserted.
What I tried:
- moved the module to another port and reseated it properly by the pull tab
- swapped the cable and confirmed the port links fine with a branded optic
- went through the Fabric OS documentation looking for anything that lets an unqualified module through
Is there a supported way to run non-qualified optics in a G610, or is Mod_Inv simply the end of the conversation on this platform? I would rather know now than after the optics are on a purchase order.
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Mod_Inv is documented behaviour, not a fault on your bench. The hardware installation guide for the G610 leaves no room for interpretation: a module has to be qualified for Brocade products before the switch will run it, and everything else is parked in Mod_Inv with a line written to the system error log. No override is documented - no knob, no unsupported-optics mode, nothing to enable.
The list you want before anything goes on a purchase order is the Brocade Transceiver Support Matrix, organised per platform with both manufacturing and ordering part numbbers. If a part is not listed for the G610, plan around it rather than hoping.
Since you are handling loose optics anyway: pull them by the tab, they get hot; push until the latch clicks; and mind which way up they go - in the top row of ports the gold contact edge faces down, in the bottom row it faces up. Also do not force a cable meant for another transceiver type into the cage, it will go in far enough to look seated and then behave exactly like a bad module.
Understood on the unbranded ones, they go back in the box.
What I did not expect: one of the Brocade-labelled 16G optics I pulled from the old switch also lands in Mod_Inv on the G610, while the identical-looking one besidde it comes up and links normally.
sfpshowgives me a Brocade vendor name and a part number on both, and both work in the chssis they came out of.So the label on the module clearly is not the whole story. What else does Fabric OS weigh before it decides an optic is qualified?
The label is not the criterion - the combination of part number, serial prefix and Fabric OS release is. The support matrix is per platform and carries a long tail of footnotes, and that is exactly where this kind of surprise lives.
A few of them, so you can see the shape of the rule. Secure optics are the loudest case: in an SX6 blade or a 7810 they will not come up below 8.2.1e or 8.2.2c, while everywhere else the same modules come with no version condition at all. The 2-km 4x32G FC QSFP wants 8.1.0b once it sits in an X6 ICL port. Then it narrows down to the serial number - a JDB prefix pushes you to 9.1.1a or 9.2.0, other parts to 9.2.0c2 or 9.2.1b, a BAB1 prefix to 9.2.0 - and several 64G parts each have a floor of their own: 9.0.1a, 9.1.0, 9.1.1, in one case 10.0.1. A few entries are capped at 32G/16G, and the FC32-64 has its own exclusions.
Practical version for your two modules: take the part number and serial prefix from
sfpshow, the release fromfirmwareshow, then read the matrix row for your platform before declaring anything faulty. One more trap in the same table: XBR-000479 insists on identical optics at both ends.For contrast, the Ethernet-side descendants of these same Brocade families answer the question in a completely different register. SLX, VDX and MLX sit under Extreme now, and their optics portal keeps a per-family approved list - modules, addapters, patch and breakout cables alike. The policy note is blunt: hardware from a third party that is not on that list gets no warranty and no compliance statement; run an optic off that list, or the interface module beside it, and the risk is yours alone - no liability, no service obligation from Extreme. Listed parts carry certification paperwork: CE and CDRH, EN60825-1, GR-468, FCC CFR 21 1040.10, NRTL. What the portal does not say is what a given platform actually does with an unlisted module - so there "unsupported" is a commercial statement, while on your G610 it is enforced in firmware.
On the older FC switches - 300, 6505, 6510, 6520 - the FAQ states that Brocade-branded SFPs are required and explains it with the tighter wavelength and parameter tolerances at 16G, where a module outside spec can fault a port and take applications down with it. That is the vendor's own reasoning as written, not something measured.