R630의 Intel X520이 allow_unsupported_sfp=1인데도 comp_codes_10g=0x00인 10GBASE-T 구리 SFP+를 거부합니다
R630 두 대를 10G로 통합하는 중인데 랙 상단까지 배선이 구리라서, 광케이블을 새로 깔기보다 X520 카드에 10GBASE-T SFP+ 모듈을 꽂았습니다. 스위치 쪽은 군말 없이 받아들입니다. 서버 쪽이 거부합니다.
- Dell PowerEdge R630, Intel X520 (82599), 듀얼 포트
- FS SFP-10GM-T-30, Dell 코딩, 서버당 모듈 1개
- DKMS로 빌드한 Intel out-of-tree ixgbe
- 두 포트 모두에 override를 설정한 /etc/modprobe.d/ixgbe.conf
# cat /etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1,1
# dmesg
ixgbe: failed to load because an unsupported SFP+ module type was detected
# 10G compliance codes read back from the module
comp_codes_10g=0x00이미 시도해본 것:
- modprobe.d 항목뿐 아니라 수동으로
modprobe ixgbe allow_unsupported_sfp=1도 실행 - 모듈 리로드가 아니라 initramfs를 다시 빌드하고 콜드부팅까지
- 모듈을 두 번째 포트로, 그다음 두 번째 서버로 옮겨봄, 결과는 동일
흥미로운 부분은 그 compliance 바이트입니다. 모듈이 10G에 대해 아예 아무것도 보고하지 않습니다. 드라이버가 override를 보기도 전에 그걸 먼저 검사하는 걸까요, 그리고 제대로 코딩된 광모듈을 사는 것 말고 달리 할 수 있는 게 있을까요?
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 6
화이트리스트와 싸우는 게 아니라 검사 순서와 싸우고 있는 겁니다.
SFF-8472에는 10GBASE-T용 compliance 비트가 없습니다. 그냥 그런 코드 포인트 자체가 없어서, 정직한 구리 SFP+는 10G compliance 코드를 전부 0으로 보고하는데, 그게 바로 지금 보신
comp_codes_10g=0x00입니다. ixgbe는 그 바이트를 읽고 10G 모듈로 인식할 만한 게 없으면allow_unsupported_sfpoverride 근처에도 가보지 못하고 바로 그 자리에서 포기합니다. 그 플래그가 미검증 광모듈이나 DAC에는 잘 통하면서 구리 모듈에는 전혀 안 통하는 이유가 이겁니다.Intel의 out-of-tree ixgbe를 대상으로 이 compliance 검사 순서를 옮기는 커뮤니티 패치가 있습니다. 관리자가 명시적으로
allow_unsupported_sfp=1을 설정한 경우, 10G compliance 코드가 전부 0인 모듈을 일찌감치 걸러내는 대신 SR로 분류해줍니다. 업스트림에 제출됐지만 아직 머지되지 않았으니, DKMS 소스에 직접 적용해서 빌드에 같이 넣어둬야 합니다. 작성자는 그 후 서버 두 대에서 10Gb/s full duplex로 잘 된다고 밝혔고, 다른 사람도 같은 패치로 HLX-SFPX 구리 모듈이 X520에서 동작한다고 확인해줬습니다.적용하기 전에 주의할 점이 두 가지 있습니다. Intel이 검증하지 않은 광모듈은 Intel의 호환성 보증 밖에 있으니, 이건 이제 그쪽 문제가 아니라 여러분 문제가 됩니다. 그리고 10GBASE-T PHY는 발열이 큰 부품이라, 자체 통풍이 없는 서버 케이지에서는 옆 슬롯의 광모듈보다 훨씬 뜨거워지니 링크가 올라온 뒤에는 모듈 온도를 지켜보세요.
뭐든 패치하러 가기 전에 확실히 짚어둘 게 두 가지 있습니다.
첫째, 모듈 리로드가 아니라 콜드부팅을 거친 장비에서 커널이 실제로 보는 값 그대로
/sys/module/ixgbe/parameters/allow_unsupported_sfp를 출력해보세요. 여기 나오는 값이 conf 파일에 적힌 것과 정확히 같지 않다면, 설정이 반영되기도 전에 뭔가가 드라이버를 로드하고 있는 거고 나머지 디버깅은 다 헛수고입니다.둘째, 어떤 ixgbe가 로드돼 있나요? 드라이버가 끝까지 로드되지 않아서 인터페이스가 아예 없는 상황이면
ethtool -i는 쓸모가 없으니,modinfo ixgbe가 보고하는 내용과 빌드한 DKMS 패키지 버전을 올려주세요.그리고 그
comp_codes_10g=0x00은 어디서 나온 건가요? 드라이버가 알려준 건가요, 아니면 모듈 EEPROM을 직접 덤프한 건가요?파일에는 파라미터가
1,1이고, 콜드부팅 후/sys/module/ixgbe/parameters/allow_unsupported_sfp도1,1로 읽힙니다. 그러니 조용히 무시된 게 아니라 적용은 되고 있습니다. Initramfs는 부팅 전에 다시 빌드했습니다. dmesg 줄은 어느 쪽이든 똑같습니다.compliance 코드는 드라이버가 아니라 제가 직접 SFF-8472 데이터에서 읽어낸 겁니다. 10G compliance 바이트는 0이고, ID 필드의 나머지는 다 정상으로 보입니다. 같은 모듈이 스위치 포트에서는 10G로 링크되니 죽은 모듈은 아닙니다.
실무 쪽으로 하나 덧붙이자면, DKMS는 커널이 업데이트될 때마다 디스크에 있는 소스에서 다시 빌드하니, 패치는 나중에 지워버릴 빌드 디렉터리가 아니라 그 소스 트리 안에 있어야 합니다. 재부팅 창에서야 알게 되지 말고 첫 커널 업데이트 뒤에 포트가 돌아오는지 미리 확인하세요.
이런 부류의 문제에서 더 넓게 얻을 수 있는 교훈은, 모듈 코딩보다 드라이버 버전이 더 큰 영향을 미친다는 겁니다. 패시브 DAC를 쓴 X710에서도 같은 이야기였습니다. 케이블 하나, 포트 하나가 Ubuntu 24.04에서는 멀쩡한데 TrueNAS SCALE에서는
Link detected: no,Speed: Unknown으로 죽어 있었는데, 그 빌드가 6.6.44-production 커널에서 나온 i40e를 달고 있었기 때문입니다. i40e가 6.12.9-production에서 가져온 25.04-BETA.1에서는 트윈액스가 다른 건 아무것도 안 건드렸는데도, 카드가 여전히 펌웨어 9.20인 채로 저절로 올라왔습니다. 그 포트에서 광모듈은 양쪽 시스템 모두 멀쩡했고, 그게 바로 원인을 오래된 드라이버가 패시브 구리를 다루는 방식으로 좁혀준 지점입니다. 비교하는 양쪽에서ethtool -i만 미리 돌려봤어도 케이블을 훨씬 덜 바꿔 끼웠을 겁니다.모듈 종류는 다르지만 드라이버는 같고, 지금 살펴보는 김에 같이 배제해둘 만한 함정입니다. X520 도터카드가 달린 Dell R720에서 Cisco 10G 멀티모드 LC 모듈이 거부됐고, 인터페이스는 그냥 안 보였습니다. 옵션은 modprobe.d에도 있었고 GRUB에도 있었는데 아무것도 안 바뀌었습니다. 호스트가 EFI로 부팅되는데 그 GRUB 커맨드라인이 쓰인 적이 없었기 때문입니다.
EFI로 부팅하는 Proxmox에서는 이 파라미터가
/etc/kernel/cmdline에ixgbe.allow_unsupported_sfp=1로 들어가야 하고, 그다음pve-efiboot-tool refresh를 해야 합니다. 그 케이스에서는 그렇게 해도 안 고쳐져서 결국 Intel 정품 모듈을 사는 걸로 끝났으니, 이건 해결책이라기보다 지워나갈 항목 하나로 보세요.그 사례에서 얻을 또 다른 점은, 양쪽 끝이 각자 독립적으로 그 광모듈에 만족해야 한다는 겁니다. 스위치가 받아들이는 모듈이라도 호스트한테는 거부당할 수 있는데, 지금 딱 그 상황에 계신 겁니다.
DKMS 소스에 패치를 적용하고 다시 빌드했습니다. 두 포트 다 10Gb/s full duplex로 올라왔고, 그 이후로 부하를 줘도 계속 유지되고 있습니다.
되긴 하는데 해결됐다고는 못 하겠습니다. 머지되지 않은 패치라 커널 업데이트마다 계속 들고 다녀야 하고, 드라이버는 그 포트를 SR로 표시해서 제 뒤에 이 장비를 보는 사람은 헷갈릴 겁니다. 모듈도 옆 케이지의 광모듈보다 눈에 띄게 뜨겁게 도는데 그 슬롯은 통풍이랄 게 거의 없습니다. 다음 서버 묶음부터는 그냥 광케이블을 깔고 드라이버와 씨름하는 건 그만두려 합니다.