SONiC QSFP28 케이지의 QSA 어댑터: 10G 옵틱은 링크되는데 DDM이 안 나옴
SONiC를 올린 화이트박스 스위치에서 쌓여 있는 10G 옵틱을 재활용하는 중이라, QSFP28 케이지 몇 개에 QSA 스타일 어댑터(10GTek QSA-100A)를 끼우고 일반 10G SFP+ 모듈을 꽂아 쓰고 있습니다. 기계적으로도 전기적으로도 문제없습니다. 무너지는 건 관리 쪽입니다.
- 스위치: 1U 화이트박스, 해당 플랫폼용으로 빌드된 SONiC
- 어댑터: 10GTek QSA-100A, QSFP28 케이지를 SFP+로
- 옵틱: 폐기된 액세스 스위치에서 뽑아온 10G SFP+ 모듈
- 같은 옵틱이 다른 장비의 네이티브 SFP+ 케이지에서는 정상적으로 읽힘
어댑터를 낀 포트에서 보이는 것:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the port지금까지 해본 것:
- 두 번째 어댑터와 두 번째 옵틱으로 교체 - 동일한 증상;
- 페어를 다른 QSFP28 케이지로 옮김 - 결과 동일;
- 다른 곳의 네이티브 SFP+ 포트에서는 옵틱이 전체 진단 정보를 보고하는 것을 확인.
빠진 진단 데이터라는 게 패시브 어댑터가 애초에 실어 나를 수 없는 것인가요, 아니면 스위치 소프트웨어 쪽 문제인가요? 소프트웨어 쪽이라면 수정이 플랫폼 레이어에 들어가야 하나요, 아니면 범용 트랜시버 코드 쪽인가요?
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 7
플랫폼 코드를 파고들기 전에, 이걸 반으로 갈라주는 질문 하나만요. 같은 케이지에 네이티브 QSFP28 모듈을 꽂아보세요 - 거기서는 진단 정보가 나오나요, 아니면 뭘 꽂든 그 포트에서 DDM이 죽어 있나요?
네이티브 부품이 정상으로 읽힌다면 케이지와 I2C 경로는 멀쩡한 거고, 문제는 온전히 포트 드라이버가 어댑터를 거쳐 들어온 것을 어떻게 해석하는지로 귀결됩니다. 네이티브 부품도 똑같이 빈 값이 나온다면 이 스레드는 더 읽을 필요 없습니다 - 어댑터와는 무관한 다른 장애를 갖고 계신 겁니다.
잘 알려져 있고 꽤 재미없는 관리 인터페이스 차이인데, 여기서 어댑터는 범인이 아닙니다.
SFP 쪽에서는 I2C 주소 두 개가 관여합니다 - identification 데이터는 0x50에, 진단 맵은 0x51에 있죠. QSFP 부품은 전부 0x50 아래 두고 페이지를 전환해서 나머지에 접근합니다. 그러니 케이지가 QSFP라고 전달받은 드라이버는 단일 주소에서 페이지를 뒤지고 0x51에는 아무것도 안 물어봅니다. identification은 포트가 올라올 만큼은 그럴듯하게 나오지만, 진단 정보는 아예 풀리지 않죠 - 정확히 올리신 것과 같은 모양입니다.
수정은 옵틱도 어댑터도 아니라 플랫폼 레이어에 들어가야 합니다. 모든 플랫폼이 자기만의 SfpUtil 구현체를 갖고 있는데, 그쪽에서는 그 포트를 QSFP가 아니라 SFP 케이지로 선언해줘야 합니다. 누군가 그렇게 고치기 전까지는 어댑터를 낀 포트의 DDM/DOM은 계속 비어 있습니다. 고치고 나면 모듈이 네이티브 SFP+ 케이지에서와 같은 방식으로 읽힙니다.
링크는 살아 있는데 진단 정보는 아무것도 없는 게 바로 이 포트들에서 소프트웨어가 잘못됐을 때 나오는 모습입니다. 옵틱 상태가 애매할 때 나오는 모습이 아닙니다.
표준 이름을 짚어두면 구분이 명확해집니다. SFP 쪽은 SFF-8472고, 진단 정보는 두 번째 주소로 접근하는 별도 메모리 맵에 있습니다. QSFP와 QSFP28은 SFF-8636을 따르고, 더 신형 부품은 CMIS를 따르는데, 여기서는 모든 게 페이지 선택 뒤에 있는 단일 주소에 걸려 있습니다.
어댑터는 그 둘을 이어줄 수가 없습니다. 기계적, 전기적으로 순수 패시브 부품이라 관리용 배선이 그냥 그대로 관통할 뿐이고 도중에 아무것도 변환해주지 않습니다. 그러니 호스트는 바이트를 한 개라도 읽기 전에 두 메모리 모델 중 어느 쪽이 적용되는지 미리 전달받아야 하는데, 어댑터에는 그걸 알려줄 방법이 없습니다.
대조해보자면, Dell ONIE 하드웨어에서는 같은 부류의 문제가 더 세게 뭅니다. 407-BBRO QSA 안에 407-BBOU 10GBASE-SR SFP+(SFP-10GSR-85)를 넣고, S4048-ON의 40G 포트와 S6010-ON의 아무 포트에나 꽂았는데, 둘 다 OpenSwitch OPX 3.1 dev2를 돌리고 있었습니다:
opx-ethtool은 media를 정확히 식별하고, 트랜시버를 enabled와 qualified로 표시하고, admin state는 up, 지원 속도는 1000, 10000, 40000 Mbps로 나오는데, 포트는 속도, duplex, autoneg를 뭘로 설정하든 - 기본값을 포함해서 - 절대 올라오지 않습니다. 누군가 OPX platform-config 저장소에 개선 요청으로 이 QSA가 여기서 동작하게 해달라고 이슈를 올렸는데, 아무도 답하지 않았습니다. 지금도 열린 채로 남아 있습니다.
벤더 락도 아니고 옵틱 불량도 아닙니다. 그 케이지는 네트워크 OS가 애초에 어댑터 모드로 넣어주지를 않는 거고, 인터페이스 설정을 아무리 조합해도 그걸 대신해주지 않습니다.
관련은 있지만 두 사례를 하나로 묶지는 마세요. 원글의 상황은 링크는 살아 있는데 진단 정보만 빠진 겁니다 - 데이터 경로는 멀쩡하고 관리용 읽기만 잘못됐으니 플랫폼 SfpUtil을 고치면 해결됩니다. Dell 사례는 그 케이지용 포트 프로파일이 애초에 적용되지 않아서 포트가 아예 안 올라오는 겁니다. 이건 한 단계 더 아래의 문제고 따로 고쳐야 합니다.
급하게 증상만 맞춰보는 사람이라면, 완전히 무관한 이유로 포트가 다운돼 있는 동안 트랜시버 코드를 다시 쓰느라 하루를 날릴 수도 있습니다.
"어댑터는 기계적 기능이 아니라 소프트웨어 기능이다"의 또 다른 버전입니다. OS10 10.5.2.7을 쓰는 Z9264F-ON에서 10G SFP+ 미디어용으로 QSA28 어댑터를 쓴다는 건 4x10G breakout 케이블이 쓰는 것과 같은 port-group 프로파일에 그 포트를 넣는다는 뜻입니다:
그 플랫폼에서 port-group 프로파일은 QSFP28 포트 페어 단위로 작동하기 때문에, 이걸 적용하면 페어마다 파트너 포트가 비활성화됩니다. QSA28은 인터페이스 하나인데도 breakout과 똑같은 대가를 치르게 됩니다 - 사용 가능한 포트 64개가 32개가 되는 거죠. OS10 사용자 가이드에도 Dell 옵틱 스펙시트에도 싱글 포트 QSA 모드는 문서화돼 있지 않습니다.
그 장비에서 네이티브 10G가 많이 필요하다면 처음부터 2:1 손실을 감안해서 설계하거나 랙에 별도 10G 스위치를 두세요.
이런 걸 한 트레이 주문하기 전에 저라면 체크리스트에 두 가지를 넣겠습니다. 네트워크 OS가 정확히 그 플랫폼에 대해 QSA 지원을 선언하고 있는지, 그리고 선언한다면 그걸 켜는 대가로 뭘 치러야 하는지 - 포트든, 진단 정보든, 옆 케이지까지 끌고 내려가는 프로파일이든요. 물리적으로 맞는지는 전혀 문제가 안 됩니다. 이런 어댑터들은 하나같이 케이지에 아무 불만 없이 들어갑니다.
이 스레드에 나온 사례들은 소프트웨어가 어디까지 가느냐에서만 갈립니다. SONiC에서는 직접 고칠 수 있는 문제라서, 포트를 SFP로 선언하면 진단 정보가 돌아옵니다. 위의 Dell 플랫폼들에서는 남의 플랫폼 코드를 기다리는 처지라, 어댑터나 옵틱을 바꿔봐야 전혀 움직이지 않습니다.