Open tooling for transceiver EEPROMs beyond ethtool -m: sfppi, sfpdoctor, py-sfp-eeprom, oom
A good half of my work is putting one company's optics into another company's switch, so I spend a lot of time asking a module what it thinks it is. My toolbox for that is currently one command deep, and I would like to know what else is worth putting on the bench machine.
- Linux boxes with SFP+ and QSFP28 ports for bench work, plus a Raspberry Pi doing nothing useful
- a lab switch running SONiC, and whatever vendor CLI the customer kit happens to have
- a drawer of modules from SFP through QSFP-DD, most of them coded for somebody else
What I use today:
ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom
On the vendor side it is whatever the box offers - show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor. All of that reads. None of it writes, and none of it tells me whether a checksum is actually wrong or just unusual.
What I have found but not yet used in anger:
- sfppi, an I2C programmer for the Raspberry Pi that also fixes checksums
- sfpdoctor and py-sfp-eeprom for reading and modelling SFF-8472 pages
- OCP oom, the open optical monitoring library aimed at switches, and the optoe driver that sfputil sits on
The commercial coder boxes are a separate decision and not the one I am asking about. What I want first is which of the open tools people actually keep on a bench: what reads a page reliably across form factors, what is safe to write with, and where the boundary sits between the SFF-8472 parts and the CMIS ones in the same drawer.
Has anyone built a working routine out of these, or is it still one tool per task?
Comments 0
No comments yet.