LibreNMS-Discovery an einem Nokia 7705 stirbt mit Column 'channels' cannot be null und sammelt kein DOM
Wir pollen eine Handvoll Nokia-7705-Aggregationsrouter in LibreNMS, und ich wollte optisches DOM von ihnen aus dem üblichen Grund: eine Strecke erwischen, die weich wird, bevor der Kunde es merkt. Discovery wird bei diesen Geräten nie fertig.
- Nokia 7705 mit TiMOS
- LibreNMS 26.3.1
- gewöhnliche Single-Lane-1G-SFPs in den Ports, gemischte Hersteller, manche davon alt
- SNMP sonst gesund: Interfaces, CPU, Speicher und Traffic pollen alle sauber
Discovery bleibt jedes Mal hier stehen:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be null
und das Ergebnis ist: keine Transceiver-Einträge und keine optischen Sensoren für den ganzen Router, nicht ein schlechter Port bei sonst funktionierenden, das ganze Gerät kommt leer zurück.
Was ich versucht habe:
- Discovery für das einzelne Gerät allein neu laufen lassen, derselbe Fehler an derselben Stelle
- Gerät gelöscht und neu angelegt: Es wird erstellt, dann stirbt Discovery an derselben Stelle
- andere Hersteller in derselben Installation discovern Transceiver und DOM normal, das sieht also nicht nach einer kaputten Datenbank auf meiner Seite aus
Ist das ein bekanntes TiMOS-Discovery-Problem, und gibt es etwas dagegen zu tun, außer Transceiver-Discovery für diese Router komplett abzuschalten?
Comments 3
Bekannter Fall, und es liegt nicht an deiner Datenbank.
Der TiMOS-Discovery-Code zieht die Lane-Anzahl aus TIMETRA-PORT-MIB::tmnxPortSFPNumLanes und wirft, was dabei rauskommt, direkt in die Spalte
channels, die kein NULL akzeptiert. Ältere Single-Lane-Optik ist meist der Übeltäter: Der Agent befüllt dieses Objekt für sie nie, der Port gibt dem Insert also ein Null mit, der Insert crasht, und der Fehler reißt die gesamte Transceiver-Discovery des Geräts mit sich. Deshalb verlierst du jeden Port statt nur den mit dem ungewöhnlichen Modul.Zwei Wege raus. Am saubersten ist, LibreNMS vorwärtszubewegen: Die upstream akzeptierte Änderung sichert den Wert in LibreNMS/OS/Timos.php ab, sodass eine fehlende oder leere Lane-Anzahl als ein einzelner Kanal gelesen wird und alles andere zu einem Integer gezwungen wird. Wer auf dem aktuellen Release feststeckt, baut dieselbe Absicherung von Hand in diese Datei ein; das sind ein paar Zeilen, verschwindet aber beim nächsten Update wieder, wenn man nicht dran denkt.
Bevor irgendwas gepatcht wird: TIMETRA-PORT-MIB::tmnxPortSFPNumLanes am Router durchgehen. Welche Ports mit nichts antworten, sind die, die den Insert killen, und es lohnt sich zu wissen, welche Optik darin steckt.
Beides bestätigt, danke.
Beim Durchgehen dieser OID: Die Ports mit der ältesten 1G-Optik liefern für die Lane-Anzahl überhaupt nichts zurück, alles Neuere antwortet mit 1. Das Null kommt also von den geerbten Modulen, genau wie beschrieben.
Nach dem Wechsel auf einen Build mit dem Check läuft Discovery an allen 7705 bis zum Ende durch, die Transceiver erscheinen mit je einem Kanal, und die optischen Sensoren werden gegraphed. Keine Änderungen auf der Router-Seite, keine Ports ausgeschlossen.
Zwei Dinge, die jetzt zu erwarten sind, wo Discovery durchläuft.
DDM bei Nokia-Geräten wird über ein Capability-Flag im EEPROM des Moduls freigeschaltet. Das ist der hausinterne Ansatz über die ganzen Familien hinweg, am deutlichsten steht es im 7210-SAS-Interface-Guide: Die Plattform druckt bereitwillig Diagnosewerte für ein Modul, das das Flag nie setzt, und sagt im selben Absatz, dass sie diese Zahlen nicht validiert oder verifiziert hat. Andere Box als deine, dieselbe Logik: Plausible RX/TX-Werte von einer Third-Party-Optik sind kein Beweis, dass die Kalibrierung stimmt.
Die andere Hälfte ist das Modul selbst. GLC-SX-MM hat keine A2h-Seite, es gibt für keinen Poller etwas zu lesen; GLC-SX-MMD schon, das D steht für Diagnostics. Ein Graph dauerhaft flach und leer: Das zuerst prüfen, bevor der Poller verdächtigt wird.