GPON 스틱 DFP-34X-2C2가 dmesg에 수십 초 뒤에야 나타나고 그다음엔 1G로 링크됨
우리 WAN을 종단하는 Linux 박스에서 통신사 ONT를 SFP GPON 스틱으로 교체하는 중인데, 이 스틱은 트랜시버답게 행동하는 게 전혀 없습니다. 꽂으면 케이지가 30초 넘게 조용해서, 두 번이나 모듈이 죽은 줄 알았을 정도이고, 커널이 마침내 인식하고 나면 링크는 기가비트 속도로 자리를 잡아버려서 이 작업을 하는 의미가 없어집니다.
장비 구성:
- Linux 라우터 박스, 커널 SFP 레이어가 구동하는 SFP 케이지, mainline 커널
- ODI DFP-34X-2C2 GPON 스틱
- 두 번째 샘플로 Huawei MA5671a 스틱
- 같은 케이지에서 즉시 나타나는 평범한 1G 파이버 모듈, 그러니 케이지 자체는 멀쩡함
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control off지금까지 해본 것:
- 스틱을 다시 꽂고 인터페이스를 건드리기 전에 몇 분간 그대로 둬봄, 대기 시간은 처음 꽂을 때뿐 아니라 매번 나타남
- 감지된 뒤에 인터페이스를 껐다 켜봄, 협상된 모드는 전혀 바뀌지 않음
- MA5671a도 똑같이 느리게 나타남, 그러니 샘플 하나만의 불량은 아님
이게 그냥 Linux 호스트에서 GPON 스틱이 원래 이렇게 동작하는 건가요, 아니면 제 쪽에서 뭔가 잘못하고 있는 건가요? 꽂은 시점과 감지되는 시점 사이에 실제로 무슨 일이 벌어지고 있는 건가요?
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
추측을 시작하기 전에 확실히 짚어둘 게 두 가지 있습니다. 첫째, 두 줄짜리 grep 말고 꽂은 시점부터 잘라내지 않은 dmesg 전체를 올려주세요. 케이지가 커널 SFP 레이어 뒤에 있다는 말은 의심할 이유가 없지만, 걸러내신 줄들이야말로 모듈이 몇 번이나 probe됐는지, 중간에 뭐가 포기했는지, 각 시도가 얼마나 걸렸는지를 보여주는 부분입니다.
둘째, 스틱이 마침내 올라온 뒤에 인터페이스 자체는 뭘 할 수 있다고 주장하나요, 그리고 알려진 모드 목록 어딘가에 2500baseX가 나타나나요? 그리고 PON 쪽에서 ISP가 주는 속도는 얼마인가요, 그게 기가비트 요금제라면 지금 받고 있는 링크가 맞는 것이고 고칠 게 없는 셈이니까요.
안타깝지만 예상된 동작이고, 당신 호스트 문제가 아닙니다.
GPON 스틱은 EEPROM 칩이 든 트랜시버가 아닙니다. 자체 SoC를 얹은 작은 Linux 컴퓨터를 SFP 껍데기에 욱여넣은 것이고, 호스트가 I2C로 읽는 EEPROM은 그 시스템이 에뮬레이션하는 겁니다. 스틱 자체 펌웨어가 그 페이지들을 서빙할 수 있을 만큼 부팅을 마치기 전까지는 버스에서 아무것도 응답하지 않는데, 그래서 일반 모듈은 즉시 응답하는 동안 당신은 수십 초를 그냥 앉아 기다리게 되는 겁니다. 모듈 줄이 뜨기 전의 그 침묵이 바로 부팅 시간입니다.
문제의 나머지 절반은 에뮬레이션된 페이지가 광고하는 내용이 자주 그냥 틀리다는 겁니다. 이런 스틱들의 호스트 쪽 인터페이스는 2500BASE-X인데 EEPROM은 다른 걸 말하고 있어서, SFP 레이어는 그걸 곧이곧대로 받아들여 기가비트 모드로 자리 잡습니다. 두 문제 모두 설정으로 손댈 수 있는 게 아니라 커널의 모듈별 quirk로 처리되고, OEM DFP-34X-2C2는 바로 이런 이유로 그 quirk 중 하나를 물려받았습니다.
당신 샘플이 그 quirk에 걸리는지는 그게 보고하는 벤더·파트 문자열에 달려 있고, 이건 리배지 제품마다 달라지니, 당신이 커버된다고 가정하기 전에 dmesg 줄에 찍히는 내용과 quirk가 매칭하는 조건을 비교해보세요.
quirk 방식이 애초에 왜 필요한지 강조하자면: SFF-8472는 평범한 I2C 타이밍 안에 응답하는 수동 메모리 장치를 전제로 합니다. 말을 걸 수 있게 되기까지 30초씩 부팅이 필요한 장치는 전혀 고려 대상이 아니라서, 표준을 따르는 호스트가 모듈을 포기하거나 결국 읽어낸 모드 비트를 그대로 믿는 건 당연한 권리입니다.
위에서 나온 리배지 얘기가 실제 함정입니다. 매칭은 벤더·파트 문자열 기준이라서, 다른 이름으로 팔리는 같은 물리적 스틱은 quirk를 완전히 빗나가고 당신은 별다른 이유 없이 다시 기가비트 링크로 돌아가게 됩니다. 그리고 부팅 직후에 모듈이 바로 있을 거라는 전제로 뭔가를 만들지 마세요, 여기서 그 경합은 절대 이길 수 없습니다.
스틱 벤더들이 EEPROM 내용을 고쳐주길 바라는 것도 낙관적인 생각입니다. 이 문제가 제기됐을 때 대형 ISP조차 그들에게서 돌아온 건 거의 없었습니다.
같은 부류의 문제가 소비자용 라우터에서도 나타나니, 적어도 혼자는 아닙니다. Archer BE800, BE900, GE800의 10G SFP+ 콤보 포트에 스틱을 꽂은 사람들은 돈 주고 산 2.5G 대신 1 Gbit/s를 받고 있고, 그 포트에서 동작한다고 보고된 TP-Link 자체 목록에 있는 스틱은 ODI DFP-34X-2C2, Huawei MA5671A, Nokia G-010SA로, 결국 모두가 도달하는 그 짧은 부품 목록과 같습니다.
거기서 1차 조언은 펌웨어와 재장착이었는데, 재장착 얘기가 헛소리는 아닙니다. 끝까지 딸깍 소리가 나게 꽂히지 않은 모듈은 실제로 속도가 떨어집니다. 베타 빌드는 결국 모델별로 하나씩 포트 설정을 노출했습니다:
이 중 하나가 박스에 올라가면 SFP 포트 모드를 telnet으로 설정할 수 있게 되는데, 먼저 인터페이스를 내리고
ip link set eth1 down같은 식으로 진행합니다.그래도 이건 고침이 아니라 우회일 뿐입니다. 1년쯤 지나서 같은 불만이 다시 들어왔는데, 스틱만의 얘기도 아니었습니다. 한 사람은 그 포트에 JT-COM의 JT-AOC-SFP-15 AOC를 꽂았고, 다른 사람은 Ampcom의 패시브 10G SFP+ DAC를 꽂았는데, 둘 다 1 Gbit/s에 머물렀습니다.
누가 스틱을 NIC 쪽으로 옮기라고 제안하기 전에 알아둘 만한 또 다른 실패 모드가 있습니다. Intel X520과 kmod-ixgbe를 쓰는 x86 위의 OpenWrt 19.07에서는 MA5671a가 미지원 SFP로 그냥 거부됩니다. 평소처럼 모듈 설정 파일을 통해 allow_unsupported_sfp를 설정해도 거기서는 아무 효과가 없고, 이 파라미터는 모듈을 로드할 때 줘야 합니다:
그리고 그렇게 해도 드라이버는 여전히 거부하는데, 애초에 스틱의 EEPROM이 정상적인 트랜시버를 기술하지 않기 때문이고 이 플래그로는 그걸 가릴 수 없습니다. 정말 NIC로 가게 된다면 먼저 평범한 1000BASE-T, LX, SX 모듈로 포트부터 검증하세요, 안 그러면 카드와 스틱을 동시에 디버깅하게 됩니다.
다만 그 둘을 섞지 않게 조심하세요. allow_unsupported_sfp는 ixgbe 안에 있고 그 드라이버가 특정 옵틱을 아예 구동할 의향이 있는지를 결정하는데, 이건 여기서 다루는 것과는 다른 결정입니다. 긴 대기 시간과 잘못된 모드는 범용 SFP 레이어가 에뮬레이션된 페이지를 읽어서 그 결과를 phylink로 넘기는 데서 나오고, 모듈별 quirk는 바로 거기에 있습니다.
제대로 된 SFP 케이지가 달린 보드에서는 ixgbe 플래그 자체가 존재하지 않고 답도 아니며, X520에서는 quirk 목록도 구해주지 못합니다. 겉으로는 같은 증상이지만 아래 계층이 다르고, 이 둘을 섞어버리면 결국 아무 소용없이 드라이버를 다시 빌드하게 되는 겁니다.
하는 김에 하나 더 선을 그어두자면: 호스트가 스틱을 보게 만드는 것과 OLT가 그걸 받아들이게 만드는 건 별개의 문제이고, 후자가 훨씬 더 나쁠 수 있습니다.
setmac과 OMCI 쿼리로 ZTE ZXHN F601에서 복사한 정체성, 즉 GPON 시리얼, PLOAM 비밀번호, LOID, 하드웨어 시리얼, 펌웨어 문자열까지 전부 넣은 Xicom DFP-34X-2C2 사례가 잘 문서화되어 있습니다. 스틱은 O5 상태까지 ranging된 다음 그냥 거기 멈춰서, ONU ID도 할당되지 않고 트래픽도 없습니다. O5에 도달했다는 건 ranging이 됐다는 뜻일 뿐이고, MIB 업로드는 여전히 OLT가 기대하는 ONT 프로필과 맞아야 하기 때문입니다. 그 스레드에서 아무도 해결책을 내놓지 못했습니다.
그러니 로컬에서 2500BASE-X까지 얻었다 해도 어려운 부분이 끝났다고 가정하지 마세요. 운영자가 서비스 프로필을 특정 ONT 모델 하나에 묶어둔 경우라면, 서드파티 스틱을 받아들이게 만들 복사 가능한 필드 조합 자체가 없을 수도 있습니다.