Edgecore AS9716-32D: PDDF 환경에서 sfputil이 400G QSFP-DD 모듈을 QSFP28로 디코딩합니다
랩에서 AS9716-32D 두 대를 400G 스파인으로 올리는 중이고, PDDF 플랫폼 레이어가 들어간 커뮤니티 SONiC 이미지를 쓰고 있습니다. 광모듈 자체는 문제가 없고 상대 쪽 링크도 잘 올라오는데, 스위치가 모듈에 대해 말하는 내용이 전부 틀렸습니다.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- 이 플랫폼용 PDDF가 들어간 커뮤니티 SONiC 빌드
- 첫 번째 케이지에 400G QSFP-DD 모듈(NeoPhotonics 제품)
읽기 자체는 성공하고, 모듈도 목록에 뜨고, 케이지는 QSFP28로 보고됩니다.
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonics문제는 바로 그 Identifier 줄입니다. 이건 QSFP-DD 제품이라 아래 바이트들이 CMIS가 아니라 SFF-8636 필드셋 기준으로 디코딩되고 있고, 그 뒤로 이어지는 필드들은 노이즈처럼 읽힙니다.
지금까지 확인한 것:
- 모듈 자체는 멀쩡함. 같은 제품이 다른 플랫폼에서는 제대로 읽히고 반대쪽에서도 빛을 봄
- 재장착하거나 다른 케이지로 옮겨도 달라지지 않음. 400G 포트 전부 동일하게 동작함
- PDDF 디바이스 디스크립션에서 이 케이지들이 QSFP28로 선언되어 optoe1에 바인딩되어 있음
이 마지막 부분이 답의 전부인가요? QSFP-DD 케이지는 그냥 다른 optoe 디바이스가 필요한 건가요? 플랫폼 디스크립션을 고치는 게 정석적인 해결법인가요, 아니면 그 위 어딘가에서도 케이지 타입을 알아야 하나요?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
증상이 바인딩 문제와 정확히 일치하니 광모듈 쪽은 더 볼 필요 없습니다.
AS9716-32D의 PDDF 디바이스 디스크립션은 400G 케이지를 QSFP28로 선언하고 optoe1에 바인딩합니다. optoe1은 QSFP+와 QSFP28이 쓰는 SFF-8636 EEPROM 레이아웃을 노출하기 때문에, CMIS 모듈이 잘못된 맵으로 읽히면서 identifier 뒤로는 전부 노이즈처럼 보이는 겁니다. 화면에 보이는 포트 타입은 감지된 게 아니라 그냥 디스크립션에 적힌 그대로일 뿐입니다.
QSFP-DD는 CMIS를 따르고, CMIS는 optoe3가 담당합니다. 해결책은 그 케이지들의 PDDF 디바이스 디스크립션에서 두 필드를 함께 뒤집는 겁니다. 타입은 QSFP28에서 QSFP-DD로, 드라이버는 optoe1에서 optoe3로. 같은 장비에 400G NeoPhotonics 제품을 꽂아 직접 확인했고, 바꾼 뒤로는
sfputil show eeprom이 모듈을 제대로 디코딩해서 보여줍니다.주의할 점이 두 가지 있습니다. 이건 플랫폼 데이터라서, 빌드하는 이미지 안에 이 수정이 들어가 있지 않으면 이미지 업그레이드가 옛날 디스크립션을 아무렇지 않게 되돌려놓습니다. 그리고 업스트림에서 정확히 이 수정이 승인은 됐지만 이후 변경에 합쳐지면서 풀 리퀘스트 자체는 머지되지 않고 닫혔으니, 여러분 이미지에 이미 들어가 있을 거라고 가정하지 마세요. 먼저 자기 플랫폼의 디바이스 디스크립션을 읽어보면 애초에 쫓을 문제가 있는지 1분 안에 알 수 있습니다.
플랫폼 파일을 손대기 전에 해당 포트에서
sudo sfputil show eeprom -d로 raw 덤프부터 올려주세요. 바이트가 다 들어 있는데 해석만 틀렸다면 이건 모듈 문제가 아니라 바인딩 문제이고, RMA 얘기가 나오기 전에 그 구분에 10분 쓰는 건 아깝지 않습니다.나머지 절반은 이미 스스로 답을 냈습니다. optoe1은 QSFP+와 QSFP28이 쓰는 SFF-8636 방식이라 CMIS 모듈을 그걸로 읽으면 identifier부터 망가진 값이 나오는데, 그게 바로 올려주신 출력입니다. 디스크립션이 QSFP-DD 케이지에 optoe1이라고 적어놓은 이상 모듈 쪽을 의심할 여지는 남지 않습니다.
그러니 그 케이지들 중 하나의 PDDF 디바이스 디스크립션 관련 줄도 같이 올려주세요. 드라이버 필드만 틀렸는지 선언된 케이지 타입까지 틀렸는지 그걸로 알 수 있습니다.
그게 맞았습니다. 케이지 타입을 QSFP-DD로, 드라이버를 optoe3로 바꾸고 reload하니 이제 모듈이 제대로 디코딩되고,
sfputil show eeprom도 더 이상 케이지를 QSFP28이라고 부르지 않습니다. 위에서 나온 업그레이드 문제 때문에 동작 중인 스위치를 패치하는 대신 저희가 빌드하는 이미지 쪽에 수정을 넣었습니다.나중에 이 글을 보는 분들을 위해 솔직히 말하면, 이건 EEPROM을 읽는 방식만 고친 것뿐입니다. 이 플랫폼의 나머지 트랜시버 관련 부분에는 여전히 자잘한 문제들이 남아 있어서, 장비가 완전히 정리됐다고는 못 하겠습니다.
남은 문제들 얘기가 나와서 말인데, 같은 플랫폼에서 기다리고 있는 게 하나 더 있습니다. SONiC master 빌드를 돌리는 저희 AS9716-32D (x86_64-accton_as9716_32d-r0)에서,
sudo sfputil show presence는 꽂힌 포트를 Present로 표시하고 EEPROM도 제대로 읽는데,show interfaces transceiver presence는 모든 포트를 Not present로 보고합니다. Syslog에는 계속 이게 찍힙니다.CLI로 EEPROM을 읽으면 RuntimeError('PddfEeprom is not Programmed')로 실패합니다. 재부팅 후 무작위로 나타나고 근본 원인은 아직 아무도 올린 적이 없어서, 저희 쪽에서 믿는 presence 확인 방법은 sfputil뿐입니다.
관련은 없지만 비슷한 영역 얘기를 하자면, 이 두 명령어가 202012 브랜치에서 키 이름이 서로 다르게 나오는 문제도 알려져 있는데, 이건 202205에서 정리됐습니다. 출력이 내용이 아니라 표현만 다르다면 아마 그게 전부일 겁니다.