Edgecore AS9716-32D: sfputil decodes a 400G QSFP-DD module as QSFP28 under PDDF
We are bringing up a pair of AS9716-32D as a 400G spine in the lab, on a community SONiC image with the PDDF platform layer. The optics are not the problem, the peer links fine, but everything the switch says about them is wrong.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- community SONiC build with PDDF for this platform
- 400G QSFP-DD module (NeoPhotonics part) in the first cage
The read itself succeeds, the module is listed, and the cage is reported as QSFP28:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsThat identifier line is where it falls apart. This is a QSFP-DD part, so the bytes below are being decoded against the SFF-8636 field set rather than the CMIS one, and the fields that follow read like noise.
Checked so far:
- the module itself is fine, the same part reads correctly on another platform and the far end sees light;
- reseating it and moving it to another cage changes nothing, all 400G ports behave identically;
- in the PDDF device description these cages are declared as QSFP28 and bound to optoe1.
Is that last point the whole answer, do QSFP-DD cages simply need a different optoe device, and is editing the platform description the accepted way to fix it, or does something above it need to learn the cage type as well?
Comments 4
Your symptom matches the binidng exactly, so no need to look further at the optics.
The PDDF device description for the AS9716-32D declares the 400G cages as QSFP28 and binds them to optoe1. optoe1 exposes the SFF-8636 EEPROM layout that QSFP+ and QSFP28 use, so a CMIS module is read through the wrong map and everything past the identifier looks like noise. The port type you see is not detected at all, it is simply what the description says.
QSFP-DD follows CMIS, and CMIS is served by optoe3. The fix is to flip both fields in the PDDF device description for those cages: the type from QSFP28 to QSFP-DD, and the driver from optoe1 to optoe3. I verified that on the same box with a 400G NeoPhotonics part, and after the change
sfputil show eepromreturns the module properly decoded.Two caveats. It is platform data, so an image upgrade will happily put the old description back unless the change is in the image you build. And upstream this exact change was approved but the pull request was closed without being merged, the work having been folded into a later change, so do not assume your image already carries it. Read the device description for your platform first and you will know in a minute whether you are chasing anything at all.
Before you touch any platform file, post the raw dump:
sudo sfputil show eeprom -don that port. If all the bytes are there and only the interpretation is off, this is a binding problem and not a module problem, and that distinction is worth ten minutes before anyone starts talking about an RMA.The other half you have already answered yourself. optoe1 is the SFF-8636 flavour used for QSFP+ and QSFP28, so a CMIS module read through it comes out mangled from the identifier onwards, which is exactly the output you pasted. Once the description names optoe1 for a QSFP-DD cage there is nothing left to suspect on the module side.
So paste the relevant lines of the PDDF device description for one of those cages too. That tells us whether only the driver field is wrong or the declared cage type as well.
That was it. Cage type to QSFP-DD, driver to optoe3, reload, and the module decodes properly now, with
sfputil show eepromno longer calling the cage QSFP28. I put the change into the image we build rather than patching the running switch, precisely because of the upgrade point above.One honest note for anyone finding this later: it fixes how the EEPROM is read, nothing more. The rest of the transceiver plumbing on this platform still has its own quirks and I would not call the box fully sorted.
Since you mention the remaining quirks, here is the one waiting for you on the same platform. On our AS9716-32D (x86_64-accton_as9716_32d-r0) running a SONiC master build,
sudo sfputil show presencelists the populated ports as Present and reads their EEPROM fine, whileshow interfaces transceiver presencereports every port as Not present. Syslog repeats:and reading the EEPROM through the CLI fails with RuntimeError('PddfEeprom is not Programmed'). It appears randomly after a reboot and no root cause was ever posted, so sfputil stays the only presence check I trust there.
Unrelated but in the same area: the two commands are also known to disagree on key names in the 202012 branch, which was cleaned up in 202205. If your outputs differ in wording rather than in content, that is probably all it is.