dentOS의 Edgecore AS5114-48X: 포트 18 SFP+는 정상 인식되는데 onlpdump는 계속 RX_LOS

RX_LOS 자체는 그냥 수신기가 빛을 충분히 못 받고 있다는 것만 말해주니까, 장비 탓하기 전에: 반대편은 뭐라고 하나요? 반대쪽 포트가 DDM을 노출한다면 그 Tx 파워를 읽어서 레이저가 실제로 켜져 있고 포트가 shut 상태가 아닌지 확인해보세요. 양쪽이 같은 광모듈 타입에 같은 광 모드인지도 알아둘 만해요 - 단거리 모듈이 장거리 모듈을 마주보고 있거나 광섬유가 잘못됐을 때도 딱 이렇게 보이거든요.

그리고 포트 18에 다른 부품번호의 모듈을 하나 더 꽂아보셨나요, 아니면 이 모듈 하나만 포트 사이로 옮겨보신 건가요?

반대편은 다른 스위치의 10G 포트고, 양쪽 다 같은 단거리 광모듈이에요. 그 포트는 바로 이 패치코드로 다른 모듈을 꽂으면 잘 링크되니까, 상대쪽 레이저는 살아있고 광 경로도 끝까지 멀쩡해요. 포트 18은 admin up이고, 코드를 뒤집어도 결과는 똑같아요.

짜증나는 부분은 제가 로컬에서 볼 수 있는 게: onlpdump가 presence랑 상태 비트마스크만 주고 끝이라는 거예요. dentOS 쪽에는 반대편이랑 비교할 Rx 수치가 없어서, 어느 쪽인지도 모른 채 "뭔가 수신이 안 되고 있다"에서 멈춰 있어요.

증상에서 원인으로, 제가 작업하는 순서대로 가면요. 인식이 증명하는 건 I2C/EEPROM 경로랑 MAC 배선뿐, 그 이상은 아니에요. inband/10gbase-r 관련 커널 로그 줄은 호스트 쪽이 스스로 설정하는 거지 - 광자 하나라도 도착했다는 뜻은 아니에요. RX_LOS가 뜬 상태에서 남는 용의자는 세 가지예요: 광섬유가 단선됐거나 교차됐거나, 반대편이 송신을 안 하거나, 이 플랫폼에서 수신기가 안 먹히는 경우요.

앞의 두 가지는 이미 세게 밀어붙이셨으니, 비트 그만 모으고 숫자를 확보하세요. 디지털 진단을 찍어주는 스위치면 뭐든 돼요. EXOS에서는 show ports <port> transceiver information인데, 온도, 공급 전압, 레이저 바이어스, Tx/Rx 파워를 주고 모듈 임계값 밖의 값은 전부 플래그로 표시해줘요. debug hal show optic port <port>는 여기에 EEPROM에서 벤더, 파트넘버, 시리얼, 커넥터, 파장을 더해줘요. 저는 이런 식으로 X460-G2-24x-10G4의 죽은 10G 포트를 쫓아가서 수신 쪽에서 대략 -26.78dBm을 찾아냈는데, 이건 10G 단거리든 장거리든 어떤 수신기도 락을 걸 수 없는 값이에요.

반대편에서 본인 모듈이 송신하는 동안 Rx 수치를 줄 수 있다면, 적어도 그쪽 레이저가 동작하는지는 알게 돼요. 그러고 나서 남는 건 플랫폼이 이 특정 부품을 못 돌린다는 것뿐이에요.

저희도 같은 장비인데, 이 플랫폼에서는 모듈 지원이 표준 단위가 아니라 부품 단위예요. 저희 AS5114-48X에서는 Avago AFBR-703SDZ-IN2 rev G2.3이 아무 손질 없이 바로 올라와요 - 플랫폼은 이걸 시리얼 AA1329A5UTA의 Intel Corp로 보고하는데, 처음 보면 다들 헷갈려해요.

같은 스위치, 같은 광섬유에서 저희한테 전혀 안 됐던 부품이 두 개 있어요: 지금 갖고 계신 것과 같은 Intel FTLX8571D3BCV-IT rev A, 그리고 OPNEXT TRS5020EN-S301이요. 둘 다 인식은 됐고, 둘 다 포트 18이랑 정확히 똑같은 상태였어요. 광케이블 배선에 저녁 시간 더 쓰기 전에 정상 작동이 확인된 부품을 하나 빌려보세요.

그 비트에 대해 정확히 짚자면: RX_LOS는 SFF-8472에서 정의된 모듈 자체의 loss-of-signal 출력이고, 플랫폼 레이어는 그걸 그냥 상태 0x00000004로 노출할 뿐이에요. 수신기의 LOS 임계값 아래에서 뜨는 거라, "빛이 부족하다"는 것만 말해주지 왜인지는 절대 말 안 해줘요. 그래서 EEPROM은 완벽하게 깨끗하게 읽히는데 광 경로는 죽어 있는 상황이 모순 없이 같이 존재할 수 있는 거예요.

진짜 Rx 수치를 고집해야 하는 또 다른 이유는: CLI에서 보면 감쇠랑 비호환성이 똑같아 보인다는 거예요. 동료 하나는 Zyxel 포트가 -25.69dBm 근처에 앉아 있었는데, 해결책은 모듈이 아니라 패치코드랑 누군가 손댔던 패치 패널이었어요. dentOS 쪽에서 DDM을 못 읽으면, 반대편이나 호스트에서 읽으세요 - 비트마스크 하나로는 이게 안 풀려요.