SONiC, CMIS 4.0 QSFP-DD를 벤더 필드가 깨진 상태로 디코딩함 - SFF 모듈은 정상 파싱

어느 브랜치를 쓰시나요? show interfaces transceiver eeprom과 sfputil 사이에 202012에서는 알려진 키 이름 불일치가 있었고 202205에서 정리됐으니, 더 깊이 파기 전에 이것부터 배제해볼 만합니다.

같은 포트에 대해 sudo sfputil show eeprom -d 출력을 올려주세요. sfputil도 똑같이 깨진 문자열을 준다면 문제는 공유 디코드 경로에 있는 겁니다. 대신 에러가 난다면 완전히 다른 얘기가 됩니다 - 저희 쪽에는 그냥 Cannot get Module EEPROM data: Invalid argument라고만 답하고 디코딩 근처에도 못 가는 플랫폼이 있습니다.

둘 다 같은 포트에 돌려봤습니다 - sudo sfputil show eeprom -d와 show interfaces transceiver eeprom -d. 깨지는 양상도 똑같고, 필드도 똑같고, 시리얼이 있어야 할 자리에 나오는 쓰레기 값도 똑같습니다. 어디서도 Invalid argument는 안 나오고, 읽기 자체는 아무 불평 없이 잘 됩니다.

그러니까 두 명령이 서로 일치하긴 하는데, 틀린 답에서 일치하는 거네요. 옆의 QSFP28 포트는 둘 다 깨끗하게 나오니, 플랫폼 문제라기보다는 이 CMIS 부품에 국한된 문제로 보입니다.

그 패턴은 자기가 이해 못 하는 메모리 맵에 파서를 그대로 들이댔을 때 나오는 전형적인 신호입니다 - vendor name 필드에 파트넘버가 앉아 있고, 시리얼은 읽을 수 없고, connector와 encoding은 밀려 있죠. 모듈이 고장 났거나 I2C 읽기가 깨졌다면 에러나 0으로 채워진 블록이 나오지, 이렇게 깔끔하게 틀린 문자열이 나오지는 않습니다.

디코드 경로는 sonic_platform_base/sonic_sfp/sfputilbase.py에 있는데, 거기서 세 identity 문자열은 뭐가 꽂혀 있든 상관없이 레거시 SFF 맵을 기준으로 하드코딩된 오프셋에서 그대로 가져옵니다. CMIS 4.0 QSFP-DD는 그 주소에 identity 블록을 두지 않습니다 - CMIS 4.0 스펙 8.3절에 나와 있죠 - 그러니 코드는 제대로 된 모듈에서 진짜 바이트를 읽고 있긴 한데, 자기가 읽고 있다고 믿는 바이트가 아니라 그 범위에 있는 아무 거나 출력하는 겁니다. 그래서 이게 절대 깔끔하게 실패하지도 않는 겁니다 - 어느 단계도 identifier 바이트를 보고 CMIS 레이아웃으로 전환하지를 않으니까요.

실질적인 결론은, CMIS 맵을 이해하는 파서가 아니고서는 이걸 제대로 해낼 방법이 없다는 겁니다. 그게 여러분 브랜치에 들어오기 전까지는 이 부품에 대한 CLI 출력은 재고 관리에 쓸 수준이 못 됩니다. 자산 데이터베이스용으로는 CLI를 긁어오지 말고 페이지를 raw로 읽어서 직접 디코딩하세요.

raw로 읽으려면 optoe 드라이버가 필요한 겁니다 - SFP, QSFP, CMIS EEPROM을 직접 읽고 쓸 수 있게 노출해주니까, 바이트를 뽑아서 여러분 스크립트에서 직접 디코딩할 수 있습니다. 지금으로선 CMIS 부품에 대해 자산 데이터베이스에 넣을 만한 건 그것뿐입니다.

오프셋을 찾아보실 거면 한 가지 주의하세요. 다들 인용하는 표는 SFF용입니다 - A0h의 20-35바이트가 vendor name, 40-59바이트가 PN, rev, SN이죠. 바로 그 오프셋들이 CMIS 모듈에서 쓰레기 값을 만들어내는 범인이니 거기서는 재사용하지 마세요. 벤치용 도구로 Linux 호스트에서 쓸 때도 마찬가지입니다 - 디코딩된 뷰를 보는 ethtool -m과 raw 바이트를 보는 ethtool -e는 SFP 부품에는 괜찮지만, CMIS에 대해 출력하는 필드를 믿기 전에 여러분 빌드가 실제로 뭘 이해하고 있는지부터 확인하세요.

CMIS 처리가 부실한 곳은 EEPROM 디코더 말고도 더 있습니다. InnoLight 800G QSFP-DD 옵틱 한 트레이를 투입했는데, T-DP8CNH-NNO와 T-DP8CNT-NNO였고, 대략 두 번에 한 번꼴로 꽂을 때마다 포트가 죽어버렸습니다. datapath는 DataPathDeactivated로 보고됐고, 로그에는 'ConfigSuccess' 타임아웃이 찍혔고, 그 뒤로는 포트가 영구히 다운됐습니다 - 재시도도 없고, 저절로 돌아오는 것도 없었습니다.

범인은 결국 cmis.py의 decommission_all_datapaths()였습니다. 이 함수는 DEINIT, application ID를 0으로 클리어, 그다음 INIT까지 전체 시퀀스를 순서대로 쭉 돌리는데, 다음 단계로 넘어가기 전에 앞 단계가 실제로 적용됐는지는 한 번도 확인하지 않습니다. 저희 부품은 바로 그 확인을 필요로 해서, datapath가 절반만 설정된 채로 남고 state machine은 그냥 타이머만 다 흘려보냅니다. 진짜 고치려면 비동기로 기다려야 하는데, xcvrd의 인라인 CMIS state machine 안에서는 블로킹을 할 수가 없으니, 제가 마지막으로 확인했을 때까지는 아무도 고친 걸 올리지 못했습니다. 버그는 다른데 주제는 같습니다 - SFF 부품용으로 짠 코드에 CMIS 경로를 그냥 덧붙인 거죠.

얘기가 흘러가는 방향에 하나만 바로잡을게요. 이 두 가지 실패 유형이 계속 뒤섞이거든요. Cannot get Module EEPROM data: Invalid argument가 나오거나, 파워 사이클 후 드라이버가 고쳐질 때까지 QSFP가 sfputil에서 아예 사라지거나, 플랫폼이 get_transceiver_info를 구현조차 안 한 경우 - 이런 건 플랫폼과 드라이버 쪽 공백이고, 디코딩이 시작되기도 전에 막히는 겁니다.

여기서 설명된 건 그 반대입니다 - 읽기는 완전하고 성공적인데, 그걸 잘못된 필드 레이아웃으로 해석하는 거죠. 이걸로 모듈을 바꾸거나 드라이버 버전을 쫓아다닐 필요는 없습니다. 그 모듈 안의 바이트는 멀쩡하고, CMIS로 제대로 디코딩하는 도구라면 라벨에 적힌 시리얼을 그대로 보여줄 겁니다.