LibreNMS 在 ZTE ZXA10 C300/C320 OLT 上找不到光功率传感器,也完全没有 ONU 接口
我负责一家小型 ISP 的接入层,想让我们的两台 GPON OLT 也能像其他设备一样出现在监控里。要的东西并不稀奇:机箱温度、CPU 和内存负载、每个端口的计数器,以及我真正关心的部分,光功率这一块。也就是 OLT 端口本身的 Rx/Tx dBm,以及每个用户 ONU 的 Rx 数值。
- ZTE ZXA10 C300 和 ZXA10 C320,SNMP v2c 只读团体字
- LibreNMS 25.8.0-dev,轮询器就自建在同一个站点
- 两台 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 端口的流量图都画得出来
- 每次改动之后都重新发现设备,检查了标准的传感器表,全是空的
- 找过针对 C320 系列的现成模板,没找到任何涵盖 GPON 端口或 ONU 光功率的
那么这些设备到底把这些数据发布在哪棵 MIB 树下,不管是它们自己端口的,还是每个 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。网上流传着一份针对它的 PHP 传感器定义,阈值是 65/55/15/5 度。不要直接信这些数字,先跟你机箱实际运行的温度对一下,再拿去接告警。
ONU 这一侧才是真正麻烦的地方。IF-MIB 只描述 OLT 自己的接口,而一个 PON 端口最多能挂 128 个 ONU,所以根本没有接口可以挂上去。大家最后的做法是把架号、槽位、端口和 ONU 编号打包进一个整数,构造出索引:
然后拿这个索引去查 ONU 树:
这棵树上带着 ONU 的接收光功率和 Counter64 字节计数器,所以每个 ONU 的流量也是从同一次 walk 里拿出来的。
两点提醒。这些都是一堆用户自己打的补丁,没有一个进了上游,所以把你自己的副本存好,升级之后能重新打上。另外,一台带 300 多个 ONU 的 OLT,会让你的传感器数量差不多乘以十,轮询器会明显感觉到。到这个规模,建议把 ONU 数据放进 Components,而不是当成普通接口处理。
在有人给你写模板之前,先问两个问题。
你有没有走过标准 MIB 之外的东西?在 ZXA10 系列上,真正有用的数据不在 IF-MIB 里,所以传感器表是空的其实是预期结果,不是 bug。贴一下这条命令返回的内容:
如果这个能返回数值,那就有戏了,剩下的就是索引的算术问题。
第二个问题:每个 PON 端口有多少个 ONU,整个机箱一共有多少个?这个数字决定了你是该用普通传感器,还是该用更轻量的方案,对建议影响很大。
就是这个。手动 walk 3902 立刻就返回了数值,接好之后现在 OLT 端口和 ONU 都有了温度、CPU、内存、带宽、错误计数器和接收 dBm。
关于规模的提醒也不是空谈。C300 上挂了 300 多个 ONU,一旦每个 ONU 都变成传感器,这台设备的轮询时间明显变长了,所以 ONU 级别的数据正在迁移到 Components,只有 OLT 自己的光功率保留为普通传感器。我还是把这个算作部分解决,而不是彻底解决:它能用,但这是我自己的一套补丁,C320 那边没有任何现成的东西。
厂商不一样,但道理是一样的,来自我这边的教训:一旦设备给了你数字,先跟对端核对一下,再拿去搭告警。
我们有两条 20 公里的链路,用的是非 Juniper 的 SFP+,接在一台 EX4550 和两台 EX3300 之间。两条链路都能正常传流量,但在 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会比较稳妥。