IBM Power FC adapters: is the SFP its own FRU, and will IBM swap optics we did not buy from them
We run a couple of IBM Power boxes next to a small SAN, and I am trying to write down a sane spares policy before the next hardware maintenance renewal. The part I cannot pin down is the transceiver itself: on some adapters it looks like a field-replaceable part in its own right, on others a service call ends with the whole adapter being swapped and the optic going out of the door with it.
- IBM Power Systems, Fibre Channel adapters at 32Gb and 64Gb
- Ethernet and RoCE adapters in the same chassis, SFP28 and QSFP28 cages
- optics mostly supplied by IBM, plus a handful of third-party SFP28 on the Ethernet side
What I have managed to dig out of the adapter documentation so far:
64Gb FC: EN2N/EN2P (CCIN 2F05), EN1N/EN1P (CCIN 2CFD) - transceiver FRU 78P7722
32Gb FC: EN2L/EN2M (CCIN 2F06), EN1L/EN1M (CCIN 2CFC) - transceiver FRU 02CL041
What I have tried:
- opened a service call on a port that wnet quiet, and the outcome was an adapter FRU replacement rather than an optic
- asked whether we can simply order the transceiver FRU and keep a spare on the shelf, and got no straight answer
- walked the Ethernet adapter features to see whether the same logic applies there at all
So two questions. On which features is the transceiver genuinely a separate FRU, and what is the actual service position when the module sitting in the cage was not bought from IBM?
Comments 3
Your reading of the FC side is right, and those two FRUs are the whole story there: 78P7722 for the 64Gb features and 02CL041 for the 32Gb ones. The list is published per feature code rather than per adapter family, so look yours up instead of assuming the neighbour slot behaves the same.
On Ethernet and RoCE the features that carry separately replaceable optics include EC85/EC86, EC75/EC76, EC66/EC67, EC2R/EC2S, EC2T/EC2U, EC3L/EC3M, EC3A/EC3B, EN24/EN26 and EC71/EC72. The counter-case is the copper adapters: those never become optical ports because you found a module that fits, they are simply not in that game.
The service part is blunt and it is the bit that decides your spares policy. The only optics IBM will put a hand to are ones you bought from IBM that are still inside warranty or sitting under a hardware maintenance contract. Everything else falls outside the service agreement, even where the cage is mechanically open and the port links perfectly well. The same documentation also says not to swap a module before working through normal troubleshooting, which is very likely how your call ended up as an adapter replacement.
That lines up with what we have in the racks. Our 32Gb ports are the EN1L/EN1M pair, so 02CL041 is the number to keep on the shelf, and I will stop pretending the third-party SFP28 in the Ethernet adapters are covered by anything at all. Those stay on the lab side of the estate.
On the troubleshooting order, point taken. We now record port errors and the module readings before anyone is allowed to pull an optic, so a call cannot be closed with an adapter swap just because someone disturbed the module first.
Worth separating two things that constantly get mixed up in SAN work: protocol interop and per-port coding checks. We ran an IBM SAN24B-5 in front of an HPE MSA 2040 ES LFF whose ports had HPE 8 Gb shortwave FC SFP+ (C8R23A) in them, and the brand mix bothered nobody, because each module only has to be accepted by the cage it sits in. Leave the array-vendor optics in the array, put switch-vendor optics in the switch, and you sidestep both the vendor check and the support argument.
The other trap is migration. Old 8G long-wave SFP+, part 57-1000027-02, out of a SAN48B-5 does not carry over to a SAN64B-7 (8960-P64, a G720 under the covers) - they are not on the qualified list for the Gen7 box. Check each part number against the Brocade transceiver support matrix before you budget the move, and run sfpshow on the old switch first so you know exactly what you are holding.