Aruba 2530-48G 두 대, 새로 깐 200m OM4 구간: J4858C 모듈 자체 테스트는 정상인데 포트 51은 Down
얼마 전에 두 건물 사이에 200m OM4 백본을 깔았는데, 이미 갖고 있는 장비로 그걸 살려보려는 중이에요. 양쪽 다 2530이고 모듈도 둘 다 HPE 정품인데, 링크가 도무지 안 올라와요.
- Aruba 2530-48G 2대
- J4858C 1000SX 2개, 양쪽 다 포트 51
- 새로 깐 OM4 약 200m, 시공업체가 정상이라고 인증함
- 패치 패널에서 스위치까지 Digitus DK-2533-01 OM2 LC 점퍼
그 포트에 대해 show tech transceivers가 이렇게 나와요:
Port 51 Down Auto 1000FDx 1000SX multi이미 한 것:
- 양쪽 스위치에서 모듈 자체 테스트를 돌렸고 둘 다 통과
- 양쪽에
interface 51 enable, 변화 없음, 포트는 계속 Down - 두 모듈을 스위치끼리 서로 바꿔봄, 어느 쪽으로 해도 결과는 같음
- 패널이랑 스위치 양쪽에서 점퍼를 다시 꽂아봄
두 가지 가설 사이에서 막혔어요. 두 모듈 다 처음부터 불량이거나, 아니면 OM4 트렁크에 물린 OM2 점퍼가 이걸 죽이고 있거나요. 어느 쪽이 더 그럴듯할까요, 그리고 둘 중 하나를 실제로 증명하려면 다음에 뭘 테스트해봐야 할까요?
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
더 이론 세우기 전에 링크부터 짧게 만들어보세요. 스위치 하나를 다른 쪽으로 가져가서 J4858C 두 개를 다 꽂고 패치코드 하나로만 이어보세요. 점퍼 하나, 패널도 없고 깔린 광케이블도 없이요. 그렇게 해서 포트 51이 Up으로 뜨면 모듈 두 개랑 스위치 포트 두 개를 한 번에 다 지운 거고, 남는 건 선로의 나머지 부분이에요. 깔린 광케이블, 패널, 커플러, 종단이요.
제가 맡았던 케이스가 딱 그렇게 흘러갔어요. 똑같은 2530-48G 한 쌍, 똑같은 J4858C, 깔린 구간에서는 포트 51이 Down이었는데 모듈 두 개를 케이블 하나로 직결하자마자 Up이 됐어요. 그 증거로 보면 저라면 광모듈 의심은 접을 것 같아요. 다만 이 테스트가 뭘 증명해주는지는 분명히 해야 해요. 구간을 하나 골라내주는 것뿐이지 그 이상은 아니에요. 트레이스의 어느 부분이 나쁜지, 패널인지 스플라이스인지 커넥터인지 아니면 그냥 엉뚱한 페어에 패치된 건지는 누가 미터기나 OTDR을 대보기 전까지는 계속 미지수예요.
하는 김에 OM2 가설은 접어두는 게 좋을 것 같아요. 200m 거리의 1000SX라면 점퍼 등급이 발목을 잡는 게 아니고, 어차피 OM3랑 OM4는 서로 호환돼요. 등급을 섞는 건 지저분하고 저라면 새 배선을 그렇게 깔지는 않겠지만, 지금 쫓고 있는 문제의 원인은 아니에요.
직결 테스트가 통과하면, 광케이블 깐 업체한테 다시 가서 광케이블별로 손실이랑 길이가 적힌 인증 결과를 문서로 요청하세요. 자기네 테스트로는 링크가 정상이라고 선언해놓은 거니까, 뭔가 대충 넘어갔거나 지금 패치돼 있는 것과 다른 페어를 측정한 거예요. 다시 와서 재작업하라고 말할 근거가 바로 그거고요.
우선, Down으로 똑같이 찍히는 두 가지 다른 결함을 구분해야 해요. administratively down이거나 설정이 잘못된 포트랑, enable은 돼 있는데 수신부에 빛이 전혀 없는 포트는 완전히 다른 문제예요. 이미
interface 51 enable을 돌렸는데도 여전히 Down으로 나온다고 하셨으니 설정은 제외하고 레이어1 문제인 거예요.범위를 좁힐 만한 게 두 가지 있어요. 두 스위치 사이에 물리적으로 뭐가 있어요? 패치 패널은 몇 개고, 스플라이스 트레이는 있는지, 거리를 맞추려고 누가 커플러를 추가했는지요. 그리고 광케이블별 실제 손실 수치가 적힌 시공업체 인증 리포트가 있어요, 아니면 그냥 말로 '테스트는 정상이었다' 정도인가요?
그리고 듀플렉스 점퍼가 양쪽 패널에서 똑같은 방식으로 배선돼 있지 않은지도 확인하세요. 양쪽 다 스트레이트로 가면 TX가 TX로 물리는 상황이 되는데, 그게 지금 설명하신 것과 정확히 똑같아 보여요.
두 스위치를 같은 방에 못 모을 때 쓸 수 있는 같은 테스트의 변형이 있어요: 모듈을 자기 자신한테 루프백시키는 거예요. 같은 듀플렉스 모듈의 TX에서 RX로 패치코드를 연결하고, 고출력 부품이면 수신부가 타버리지 않게 중간에 감쇠기를 넣으세요. 포트가 올라오면 호스트 포트랑 모듈은 전기적으로도 광학적으로도 멀쩡한 거고, 문제는 반대편이거나 광케이블이거나 페어링이에요.
MES3324F에 스위치 대 스위치로 링크가 안 되던 FIBO SFP+를 꽂고 정확히 이걸 해봤는데, 루프는 바로 올라왔고 그래서 찾는 범위가 모듈에서 구간 쪽으로 옮겨갔어요. 한 가지 주의할 점은, BiDi 모듈에서는 셀프 루프가 무의미해요, TX랑 RX가 서로 다른 파장이라서요. 그럴 때는 대신 매칭되는 한 쌍을 서로 맞대서 루프하세요.
다음 배치는 벽 근처에 가기 전에 모듈부터 테스트하세요. EEPROM이랑 DDM(vendor, part number, 온도, TX/RX 파워)을 읽고, 미터기로 TX 파워를 재고, 감쇠기로 수신 감도를 확인하고, 위에서 설명한 대로 루프백을 해보고, 그다음 목표 속도로 실제 트래픽을 흘리면서 에러 카운터를 지켜보세요. 손 닿는 곳에 호스트가 있으면 마지막 두 가지는
ethtool -m이랑iperf3로 커버돼요. 정말 신경 쓰는 링크라면 NRZ 기준 1e-12 미만을 확인할 수 있을 만큼 충분히 긴 PRBS-31 BER 테스트가 모듈을 증명해주는 방법이고요. 계측기 하나로는 전부 검증이 안 돼요.WISP 쪽에서 빌려온 습관 하나가 저를 두 번 살렸는데요: 서비스에 넣기 전에 모든 모듈에 웜 리부트, 콜드 리부트, 재장착을 다 시켜보세요. 어떤 부품은 꽂았을 땐 링크가 되는데 전원을 껐다 켜면 죽은 채로 돌아와요 - GLC-T-OEM이 전형적인 예로, 재장착을 해야만 올라와요 - 그리고 다른 것들은 실제로는 아닌 링크 상태를 보고하기도 해요. 그걸 옥상에서 찾는 것보다 작업대에서 찾는 게 훨씬 싸게 먹혀요.