ethtool -m 너머의 트랜시버 EEPROM 오픈 툴: sfppi, sfpdoctor, py-sfp-eeprom, oom

제 업무의 절반 가까이는 한 회사의 옵틱을 다른 회사의 스위치에 꽂는 일이라, 모듈한테 스스로 뭐라고 생각하는지 물어보는 데 시간을 꽤 씁니다. 지금 이 작업을 위한 도구함은 명령어 하나짜리라, 벤치 머신에 더 올려둘 만한 게 뭐가 있는지 알고 싶습니다.

• 벤치 작업용 SFP+, QSFP28 포트가 있는 리눅스 장비, 그리고 딱히 쓸모없는 일만 하는 Raspberry Pi
• SONiC를 돌리는 랩 스위치, 그리고 고객 장비에 붙어 있는 아무 벤더 CLI
• SFP부터 QSFP-DD까지 모듈이 가득한 서랍, 대부분 다른 누군가용으로 코딩됨

지금 쓰고 있는 것:

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

벤더 쪽으로는 그 장비가 제공하는 대로 씁니다. show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor요. 이건 전부 읽기만 됩니다. 쓰기는 하나도 안 되고, 체크섬이 진짜로 틀린 건지 그냥 특이한 건지도 알려주지 않습니다.

찾아는 놨지만 아직 실전에 써본 적은 없는 것:

• sfppi, Raspberry Pi용 I2C 프로그래머, 체크섬도 고쳐줌
• SFF-8472 페이지를 읽고 모델링하는 sfpdoctor와 py-sfp-eeprom
• 스위치 대상 오픈 광 모니터링 라이브러리인 OCP oom, 그리고 sfputil이 올라가 있는 optoe 드라이버

상용 코더 박스는 별개의 결정이고 지금 묻는 건 그게 아닙니다. 먼저 알고 싶은 건 사람들이 실제로 벤치에 두고 쓰는 오픈 툴이 뭔지입니다. 폼팩터를 넘나들며 페이지를 안정적으로 읽는 게 뭔지, 쓰기에 안전한 게 뭔지, 그리고 같은 서랍 안에서 SFF-8472 부품과 CMIS 부품 사이 경계가 어디쯤인지요.

이런 도구들로 돌아가는 루틴을 만들어본 분 계신지, 아니면 여전히 작업마다 도구 하나씩 따로 쓰는지 궁금합니다.