LibreNMS-discovery op een Nokia 7705 crasht met Column 'channels' cannot be null en verzamelt geen DOM
We pollen een handvol Nokia 7705 aggregatierouters in LibreNMS en ik wilde er optische DOM van, om de gebruikelijke reden: een verslechterende span opvangen voor de klant het merkt. Discovery raakt bij die apparaten nooit klaar.
- Nokia 7705 met TiMOS
- LibreNMS 26.3.1
- gewone single-lane 1G SFP's in de poorten, gemengde vendors, sommige oud
- SNMP verder gezond: interfaces, CPU, geheugen en verkeer pollen allemaal prima
Discovery stopt hier elke keer:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be nullen het resultaat is geen transceiver-items en geen optische sensoren voor de hele router - niet één slechte poort met de rest werkend, het hele apparaat komt leeg terug.
Wat ik geprobeerd heb:
- Discovery opnieuw gedraaid voor het ene apparaat apart, zelfde fout op hetzelfde punt
- Apparaat verwijderd en opnieuw toegevoegd: het wordt aangemaakt, dan crasht discovery op dezelfde plek
- Andere vendors in dezelfde installatie discoveren transceivers en DOM gewoon normaal, dus het lijkt niet op een kapotte database aan mijn kant
Is dit een bekend TiMOS-discoveryprobleem, en is er iets aan te doen buiten transceiver-discovery voor deze routers helemaal uitschakelen?
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 3
Bekend geval, en het ligt niet aan jouw database.
De TiMOS-discoverycode haalt het aantal lanes uit TIMETRA-PORT-MIB::tmnxPortSFPNumLanes en stopt wat het krijgt rechtstreeks in de kolom
channels, die geen NULL accepteert. Oudere single-lane optiek is meestal de boosdoener: de agent vult dat object er nooit voor in, dus geeft de poort de insert een null mee, loopt de insert vast, en trekt de fout de hele transceiver-discovery van het apparaat mee onderuit. Daarom verlies je elke poort in plaats van alleen die met de vreemde module.Twee uitwegen. Het schoonst is LibreNMS bij te werken - de wijziging die upstream is geaccepteerd, beschermt de waarde in LibreNMS/OS/Timos.php, zodat een afwezig of leeg lane-aantal als één kanaal gelezen wordt en al het andere naar een integer geforceerd wordt. Zit je vast op je huidige release, zet dezelfde bescherming dan zelf in dat bestand; het is een paar regels, al verdwijnt het bij de volgende update als je vergeet dat het er staat.
Voor je iets patcht, loop TIMETRA-PORT-MIB::tmnxPortSFPNumLanes af op de router. Welke poorten ook maar niets teruggeven zijn degene die de insert om zeep helpen, en het is de moeite waard om te weten welke optiek daarin zit.
Op beide punten bevestigd, bedankt.
Die OID afgelopen: de poorten met de oudste 1G-optiek geven helemaal niets terug voor het lane-aantal, alles nieuwers antwoordt met 1. Dus de null komt van de modules die ik geërfd heb, precies zoals beschreven.
Na het overstappen naar een build met de check, loopt discovery op alle 7705's tot het einde door, verschijnen de transceivers elk met één kanaal, en worden de optische sensoren gegrafiekt. Geen wijzigingen aan de routerkant, geen poorten uitgesloten.
Twee dingen om te verwachten nu discovery klaarkomt.
DDM op Nokia-apparatuur wordt bepaald door een capability-vlag in de module-EEPROM. Dat is de huisstijl door alle families heen, en het staat het duidelijkst beschreven in de 7210 SAS interface guide: het platform print gewoon diagnostiek voor een module die de vlag nooit zet, terwijl het in dezelfde alinea zegt die cijfers niet gevalideerd of geverifieerd te hebben. Andere doos dan die van jou, zelfde logica: plausibele RX/TX-cijfers van een third-party optiek zijn geen bewijs dat de kalibratie klopt.
De andere helft is de module zelf. GLC-SX-MM heeft geen A2h-pagina, dus er is niets voor een poller om te lezen; GLC-SX-MMD wel, de D staat voor diagnostics. Eén grafiek permanent vlak en leeg, controleer dat voor je de poller de schuld geeft.