LibreNMS가 ZTE ZXA10 C300/C320 OLT에서 광 센서를 못 찾고 ONU 인터페이스도 아예 없음
작은 ISP에서 액세스 레이어를 맡고 있는데, GPON OLT 두 대도 다른 장비들처럼 모니터링에 똑같이 나오게 하고 싶습니다. 바라는 건 특별한 게 아닙니다. 섀시 온도, CPU·RAM 부하, 포트별 카운터, 그리고 제가 진짜 신경 쓰는 부분인 광 쪽입니다. 즉 OLT 포트 자체의 Rx/Tx dBm이랑 가입자 ONU별 Rx 수치요.
- ZTE ZXA10 C300, ZXA10 C320, SNMP v2c 읽기 전용 커뮤니티
- LibreNMS 25.8.0-dev, 같은 사이트에 자체 호스팅한 poller
- 양쪽 OLT 다 SFP, SFP+ 업링크
기본 상태에서는 광 관련 정보가 아예 없습니다.
# discovery completes, device is green, but:
# - no transceiver Rx/Tx power sensors are discovered for either OLT
# - ONU interfaces do not exist in IF-MIB, only the OLT's own ports
snmpwalk -v2c -c <community> <olt> IF-MIB::ifDescr이미 해본 것:
- SNMP 자체는 멀쩡한 것 확인, 업링크와 PON 포트의 트래픽 그래프는 제대로 그려짐
- 바꿀 때마다 장비를 다시 discover하고 표준 센서 테이블을 확인했는데 전부 비어 있음
- C320 계열용으로 만들어진 템플릿을 찾아봤는데 GPON 포트나 ONU 광 정보를 다루는 건 하나도 없음
그래서 궁금한 게, 이 장비들이 실제로 그 정보를 어느 트리에 공개하는지입니다. 자기 포트용이랑 ONU별 둘 다요. 그리고 누가 이걸 업그레이드에도 안 깨지는 형태로 LibreNMS에 넣어본 적 있는지도요.
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
짧게 말하면, 이 OLT들의 광 관련 정보는 표준 MIB에는 하나도 없고 전부 ZTE 사설 엔터프라이즈 트리 3902 안에 있습니다.
쉬운 것부터 보면, 섀시 온도는 .1.3.6.1.4.1.3902.1015.2.1.3.2에 있습니다. 65/55/15/5도 임계값을 쓰는 PHP 센서 정의가 돌아다니는데, 그 수치를 그냥 믿지 말고 알림을 걸기 전에 본인 섀시가 실제로 어느 온도에서 도는지부터 대조해보세요.
진짜 일은 ONU 쪽입니다. IF-MIB는 OLT 자체 인터페이스만 기술하고, PON 포트 하나에 ONU가 최대 128개까지 붙을 수 있어서 인터페이스를 걸 자리가 아예 없습니다. 결국 다들 shelf, slot, port, ONU 번호를 정수 하나에 욱여넣어서 인덱스를 만드는 방식으로 갔습니다.
이걸 ONU 트리에 대고 씁니다.
이 트리에 ONU RX 레벨과 Counter64 바이트 카운터가 다 들어 있어서, ONU별 트래픽도 같은 walk에서 나옵니다.
주의할 점이 두 가지 있습니다. 이건 어디까지나 사용자들이 쌓은 패치 더미고 업스트림에 반영된 게 하나도 없으니, 업데이트 후에 다시 적용할 수 있게 사본을 따로 보관하세요. 그리고 ONU가 300개 넘는 OLT는 센서 개수가 대략 10배로 늘어나서 poller가 그걸 티 나게 느려집니다. 이 규모에서는 ONU 데이터를 일반 인터페이스가 아니라 Components 쪽에 넣으세요.
누가 템플릿을 만들어주기 전에 두 가지만 확인할게요.
표준 MIB 밖으로 walk를 돌려본 적 있나요? ZXA10 계열에서는 흥미로운 데이터가 IF-MIB에 없어서, 센서 테이블이 비어 있는 건 버그가 아니라 당연한 결과입니다. 아래 명령 결과를 올려주세요.
여기서 값이 나오면 시작할 수 있고 나머지는 인덱스 계산 문제입니다.
둘째, PON 포트당 ONU가 몇 개고 섀시 전체로는 총 몇 개인가요? 이 숫자에 따라 일반 센서로 갈지 더 가벼운 방식으로 갈지가 갈리고, 조언도 꽤 달라집니다.
그거였습니다. 3902를 손으로 walk하니까 바로 값이 나왔고, 연결해보니 지금은 OLT 포트와 ONU 양쪽 다 온도, CPU, 메모리, 대역폭, 에러 카운터, RX dBm이 다 들어옵니다.
규모 관련 경고도 이론이 아니었습니다. C300에는 ONU가 300개를 훌쩍 넘게 물려 있어서, ONU 하나하나가 전부 센서가 되니까 이 장비의 poller 실행 시간이 눈에 띄게 늘었습니다. 그래서 ONU별 데이터는 Components로 옮기고 OLT 광 정보만 일반 센서로 남겨뒀습니다. 그래도 이건 해결됐다기보다는 절반만 됐다고 해야 할 것 같습니다. 동작은 하는데 어디까지나 제 패치 모음이고, C320용으로 바로 쓸 수 있는 건 하나도 없거든요.
벤더는 다른데 저도 같은 교훈을 얻었습니다. 장비가 숫자를 던져주더라도 그걸로 알림을 쌓기 전에 반대쪽이랑 대조부터 해보세요.
저희는 EX4550과 EX3300 두 대 사이에 non-Juniper SFP+로 20km 링크가 두 개 있었습니다. 둘 다 트래픽은 정상으로 흘렀는데, EX4550에서
show interfaces diagnostics optics를 치면이 나오고, 같은 광케이블의 EX3300 쪽 끝에서는 0.1196 mW / -9.22 dBm으로 나왔습니다. 이건 EX4550의 Junos 스케일링 결함으로 PR1007055고, 12.3R8에서 고쳐졌습니다. 업그레이드하기 전까지는 EX4550 쪽 수치는 그냥 장식으로 치고 반대쪽 값을 썼습니다.
건너 들은 얘기라 가볍게 들으셔도 되는데, ICX 7450이랑 ICX 7550에서는 Ruckus 공급 파트넘버 33211-100과 33210-100에서 광 모니터링이 계속 비어 있고, 같은 섀시의 Brocade 코딩 동급 제품은 정상적으로 나온다고 합니다. FI-264785로 추적 중이고 08.0.95j 빌드쯤에서 고쳐질 예정이라네요. 모듈을 다시 꽂아보기 전에
show optic부터 한번 치는 게 낫습니다.