LibreNMS discovery on a Nokia 7705 dies with Column 'channels' cannot be null and collects no DOM
We poll a handful of Nokia 7705 aggregation routers in LibreNMS and I wanted optical DOM off them for the usual reason - catching a span going soft before the customer notices. Discovery never finishes on those devices.
- Nokia 7705 running TiMOS
- LibreNMS 26.3.1
- Ordinary single-lane 1G SFPs in the ports, mixed vendors, some of them old
- SNMP otherwise healthy: interfaces, CPU, memory and traffic all poll fine
Discovery stops here every time:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be nulland the result is no transceiver entries and no optical sensors for the whole router - not one bad port with the rest working, the entire device comes back empty.
What I have tried:
- Re-ran discovery for the single device on its own, same error at the same point
- Deleted and re-added the device: it is created, then discovery dies in the same place
- Other vendors in the same installation discover transceivers and DOM normally, so it does not look like a broken database on my side
Is this a known TiMOS discovery problem, and is there anything to do about it short of turning transceiver discovery off for these routers?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Known one, and it is not your database.
The TiMOS discovery code pulls the lane count out of TIMETRA-PORT-MIB::tmnxPortSFPNumLanes and drops whatever it gets straight into the
channelscolumn, which does not accept NULL. Older single-lane optics are the usual offenders: the agent never populates that object for them, so the port hands the insert a null, the insert blows up, and the failure takes the whole device's transceiver discovery down with it. That is why you lose every port rather than the one with the odd module.Two ways out. Cleanest is to move LibreNMS forward - the change accepted upstream guards the value in LibreNMS/OS/Timos.php, so that an absent or empty lane count is read as a single channel and anything else is forced to an integer. Stuck on your current release, put the same guard into that file by hand; it is a couple of lines, though it will disappear under the next update if you forget it is there.
Before you patch anything, walk TIMETRA-PORT-MIB::tmnxPortSFPNumLanes on the router. Whichever ports answer with nothing are the ones killing the insert, and it is worth knowing which optics are sitting in them.
Confirmed on both counts, thanks.
Walking that OID: the ports with the oldest 1G optics return nothing at all for the lane count, everything newer answers with 1. So the null is coming from the modules I inherited, exactly as described.
After moving to a build that has the check, discovery runs to the end on all of the 7705s, the transceivers appear with a single channel each, and the optical sensors are being graphed. No changes on the router side, no ports excluded.
Two things to expect now that discovery finishes.
DDM on Nokia gear is gated by a capability flag in the module EEPROM. That is the house approach across the families, and it is spelled out most plainly in the 7210 SAS interface guide: the platform will happily print diagnostics for a module that never sets the flag, while saying in the same paragraph that it has not validated or verified those numbers. Different box to yours, same logic - plausible RX/TX numbers off a third-party optic are not proof the calibration is right.
Other half is the module itself. GLC-SX-MM has no A2h page, so there is nothing for any poller to read; GLC-SX-MMD does, the D being the diagnostics. One graph permanently flat and empty, check that before the poller.