LibreNMS里的ZXA10 OLT:端口页面没有光模块dBm数据,风扇和电源传感器也消失了
我们用LibreNMS轮询一批混合型号的ZTE ZXA10 OLT,有两个地方不对。我怀疑这两个问题不相关,但不确定。
- ZTE ZXA10 C300,V2.1.0,还在老POP点服役
- ZTE ZXA10 C620,V2.0.30,还有一台C650和一台C650E
- 一台ZTE ZXA10 C320,以前是正常的
- SFP和SFP+上联,下面挂GPON板卡
第一个问题:端口页面完全没有光模块传感器数据。没有dBm的收发功率,没有模块温度,没有供电电压,没有激光器偏置电流。这些数字正是我想用来在用户打电话投诉之前发现接头脏了的手段。
第二个问题:C320上原本能用的状态传感器,风扇、电源和板卡状态,在一次重新发现之后悄悄消失了。日志里没有任何错误,没有任何失败,它们只是不再出现在设备上了。
手动一台台排查,光学数据显然存在于MIB里的某处,但同一个OID在一个平台上有响应,在另一个平台上却什么都不返回:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1已经试过:
- 对每台设备做重新发现和完整轮询
- 对比同一个OID上C650和C300各自的响应
- 检查是不是空笼子导致发现放弃继续
ZXA10系列的光学读数到底存在哪里,又是什么原因会让一个状态传感器在发现阶段消失却不留下任何日志?
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 5
两个问题都是已知的,正如你猜的那样,它们互不相关。
你能拿到哪张光学表取决于平台,而且这两张表在同一台设备上从不共存。较老的C300,我们在V2.1.0上测试过,暴露的是zxAnOpticalModuleMonTable:
V2.0.30上的C620、以及C650和C650E,暴露的则是zxAnOpticalModuleInfoTable:
不管哪张表,给你的都是同样四个读数:dBm单位的收发功率、模块温度、供电电压、激光器偏置电流。原始值需要乘以0.001做换算。还有两个哨兵值也要过滤掉,不然机箱里每个空笼子都会给你报警:不支持的端口或空笼子会返回2147483647,没有信号的端口会返回-80000。板卡是否在位根本不属于光学轮询的范畴,那是一个单独的运行状态传感器,会自动跳过空槽位。
你那消失的风扇、电源和板卡状态是另一个bug。平台YAML里的状态条目缺了value:这个键,没有它,发现流程就会把表名当成一个列名去读,结果什么可用的东西都读不到,于是悄悄丢掉这个传感器,不留任何错误,这就是为什么你只是发现它"不见了"。把这个键补回去,在这里的C320测试环境里恢复了六个传感器。
提前打个预防针:这是挂在一个还没合并、仍处于open状态的改动里的,而且评审已经把以太网错误监控从这个改动里砍掉,视为超出范围。把它当成你自己维护的一个补丁,而不是等着它被合并进正式版。
把每台设备报告的sysDescr贴出来看看。就光学MIB而言,C300、C320、C620、C650和C650E根本不是同一个家族,所以某个OID在一部分设备上有响应、在另一部分上完全沉默,是意料之中的事,不是故障。
贴一下差异最大的两台设备的walk结果尾部,C300和某台C650,用你已经试过的那个OID。如果一台有响应另一台是空的,那就是全部真相,修法也得按平台分别处理。
另外把你这两个问题分开看待。风扇和电源传感器缺失是发现定义的问题,和OLT实现了哪张光学表毫无关系。
从另一个角度印证了这个差距。我在25.8.0-dev上问过同一个家族的问题:一台C320 GPON OLT,我想要的是在OLT和ONU两端的GPON端口上都做图——收发功率电平、每条链路的距离测量、每端口利用率——外加想知道这个家族是不是已经有现成的模板了。
那个请求最后被关掉了,也没人贴出OID、walk结果或方法,所以它记录下来的唯一事实就是:C320家族的开箱即用覆盖是不完整的。现在回头看,我当时应该附上一份walk结果。如果你反正要做这个,ONU端的光学读数是目前谁都没做过的部分,我们不少人都会用得上。
这和我们这批设备的情况一致。C300在.1.3.6.1.4.1.3902.1015.3.1.13.1上有响应,另一个OID上什么都不返回;C620和C650正好反过来;C650E的表现和C650一样。
返回的数值是需要乘0.001换算的整数,和描述的完全一致。一开始看起来像乱码的那些现在也说得通了:我们没插模块的笼子返回2147483647,两个对端断电的端口返回-80000。这两个哨兵值在我们这边都是真实存在的,所以谁要是直接拿原始数字设阈值,得到的会是一份非常嘈杂的告警列表。
也查了平台YAML,我们这边同样缺那个value:键。既然这个改动还没合并,我们会先在本地自己维护这个补丁。把这两个问题分开看待,是我一开始就搞错的地方。
在做这个的时候有一点要记住:DOM数据在任何平台上都只是一个子集,不止ZTE是这样。
在SONiC里,一个CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28的EEPROM能顺利读出来,TRANSCEIVER_INFO、TRANSCEIVER_DOM_SENSOR加上TRANSCEIVER_STATUS都会填上身份信息以及温度、电压、每通道偏置电流和功率,但控制与状态那一组字段是彻底缺失的:get_rx_los、get_tx_fault、get_tx_disable、get_lpmode和get_power_override在数据库视图里什么都不返回,所以如果你需要这些数据,得自己去问平台API要。
防火墙这边也是同样的教训。在PAN-OS上,show transceiver-detail all会打印诊断信息块,第一个要看的字段是diagnostic-monitor。如果它显示No,说明这个模块没有实现数字光学监测,所有数值都会是N/A。这不是什么故障,只是根本没有数据可读。建议把这个区别编码进你的告警逻辑,免得一个没有DOM功能的模块看起来和一个死掉的端口一样。