Brocade G720 keeps every 64G SFP-DD port in Module_Invalid with the DD PoD licence applied
We inherited a pair of Connectrix DS-7720B (Brocade G720) for a new fabric, and I haven't got anywhere near zoning yet, because not one of the double density ports will come up. Every single one of them says the same thing in switchshow:
Index Port Address Media Speed State Proto
====================================================
48 48 031800 dd -- Module_Invalid (Speed Mismatch / Incompatible SFP)
49 49 031900 dd -- Module_Invalid (Speed Mismatch / Incompatible SFP)What is in the rack:
- Connectrix DS-7720B / Brocade G720, Fabric OS still on the 9.0.x line it was delivered with
- Double Density Ports on Demand licence installed and showing as applied
- Brocade branded 64G FC SFP-DD transceivers, part 57-1000505-01
- factory patch cords out of the same box as the optics
Before anyone suggests the obvious: I've reseated every module and moved two of them between ports, and the fault stays with the ports rather than travelling with the modules. The Double Density Ports on Demand licence really is applied and not merely ordered, I checked that twice. Patch cords swaapped, ends cleaned, no difference. Ordinary ports on the same chassis carry traffic quite happily, so this isn't a dead switch.
Did we get handed a bad batch of double density optics, or is the switch writing them off before it has properly looked at what is in the cage?
Comments 6
Your optics are fine. Your firmware is the problem.
64G FC SFP-DD on a G720 is supported from Fabric OS 9.1.0 onwards. On 9.0.x the firmware has no notion of that form factor at all, so it cannot identify what is sitting in the cage and falls back to declaring it incompatible - which is precisely the Module_Invalid with Speed Mismatch / Incompatible SFP you see on evry double density port. Your bench work says the same thing from the other direction: an ordinary optic lights up in the very port that refuses a dd module, and the second chassis behaves identically because it is running identical firmware.
The part you have, 57-1000505-01, is listed in the Brocade Transceiver Support Matrix, and the matrix is where the minimum firmware per platform is written down. For the G720 that entry begins at 9.1.0. Go to 9.1.0 or later and those ports come up with the optics already in them.
That blade in the box is the same story. Every Gen 7 platform carries its own floor in the matrix - the G730 (DS-7730B), the 7850 (MP-7850B) and the FC64-64 among them - so look each one up before you move double density optics onto it, or you will lose this afternoon a second time on the next box.
Whatever else you do, do not send the modules back.
Hold off on the RMA paperwork, because a whole batch of dead optics isn't what this looks like from here. Module_Invalid with dd already sitting in the media column means the switch got something out of the cage and didn't like what it read. A genuinely dead module usually doesn't get that far - you'd be looking at a no-module state instead.
Three things would narrow it down and none of them cost you anything:
And keep the licence out of your thinking for now. Ports on Demand unlocks ports; it doesn't teach the firmware about a form factor it has never met.
Good clal on the borrowed optic. I pulled a working Brocade module out of one of the normal ports, dropped it into port 48, and it came online straight away as an F-Port. Put a 64G SFP-DD back into that same port and it's Module_Invalid again within a second or two. So the cage is alive, the licence is doing its job and the port itself is fine - it's only the double density modules the switch won't have.
Both switches, yes. The second DS-7720B is mostly still in its crate, but I put two of the dd modules into it on the bench and got the identical line back, so it isn't one chassis with a fault.
Gen 7 elsewhere: nothing in production yet, but there's an FC64-64 blade in a box waiting for a director slot, and it was bought to take exactly these optics. If it's going to bite there as well, I'd rather know now than during the migration window.
Different vendor, same shape of trap. Posting it in case it saves somebody else an afternoon of pulling modules out of cages.
Dell S5248F-ON, SONiC master build. Not one SFP28 port worked. Every port LED solid, and show interface transceiver presence listed no transceivers whatsoever, with perfectly healthy optics in the cages.
None of it was optical. The platform monitor container was down: pmon wasn't running, and neither were pcied, xcvrd and psud. xcvrd is the process that tlaks I2C to the modules, so with it dead nobody was reading an EEPROM at all, and the CLI was honestly reporting what it knew, which was nothing. docker ps and show system-health detail told me the whole story in about a minute - after I'd already spent half a day swapping modules around.
Same family of thing on a Z9264F, where the platform plugin's Sfp constructor fell over with AttributeError: 'Sfp' object has no attribute 'port_type' and took determine-reboot-cause.service down with it at boot. When a whole class of ports misbehaves in exactly the same way, the optic is nearly never the thing to suspet first.
The other half of this is unglamorous, and it is where the time actually goes. A Fabric OS jump on a switch with nothing behind it yet is still a change window rather than something you do between two meetings, so work out first what else in the fabric has to move with it and book the outage properly.
Since that FC64-64 is still in its box: put it on 9.1.0 or later before it ever sees a double density optic. Otherwise you reproduce this thread in a director rather than an edge switch, with an audience.
One more practical thing. Get to your supplier before they log the RMA. Those modules identify themselves perfectly well, the host simply has no table entry for them yet. If the supplier accepts them back as faulty you will wait three weeks for a replacement batch that behaves in precisely the same way, and then still have to do the upgrade.
Confirmed, and it was the firmware.
Both switches went to 9.1.0 in the window at the weekend, and on the reboot every double density port came out of Module_Invalid and went online at 64G with the same 57-1000505-01 optics that had been sitting in them the whole time. Nothing reseated, nothing replaced, nothing recabled.
The licence turned out to be the red herring I'd been chasing - applied correctly from the start, it just couldn't do anything useful on 9.0.x. The blade goes to 9.1.0 before it goes anywhere near a director slot, and I've written that on the box it is sitting in. Saved us an RMA and a fairly awkward conversation wtih the supplier.