LibreNMS findet keine optischen Sensoren an ZTE-ZXA10-C300/C320-OLTs und überhaupt keine ONU-Interfaces
Ich betreue die Access-Layer bei einem kleinen ISP und will, dass unsere zwei GPON-OLTs im Monitoring genauso auftauchen wie alles andere. Die Wunschliste ist nicht exotisch: wie heiß das Chassis läuft, CPU- und RAM-Last, Zähler pro Port, und der Teil, der mich eigentlich interessiert, die optische Seite. Das heißt Rx/Tx in dBm für die OLT-Ports selbst und ein Rx-Wert pro Teilnehmer-ONU.
- ZTE ZXA10 C300 und ZXA10 C320, SNMP v2c Read-only Community
- LibreNMS 25.8.0-dev, selbst gehosteter Poller am selben Standort
- SFP- und SFP+-Uplinks an beiden OLTs
Von Haus aus bekomme ich überhaupt nichts Optisches:
# 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::ifDescrWas ich schon gemacht habe:
- geprüft, dass SNMP selbst gesund ist, Traffic-Graphen an den Uplinks und den PON-Ports werden korrekt gezeichnet
- die Geräte nach jeder Änderung neu discovered und die Standard-Sensortabellen geprüft, alle leer
- nach einem fertigen Template für die C320-Familie gesucht und nichts gefunden, was GPON-Port- oder ONU-Optik abdeckt
Also, in welchem Baum veröffentlichen diese Boxen das überhaupt, sowohl für die eigenen Ports als auch pro ONU, und hat das schon mal jemand so in LibreNMS bekommen, dass es ein Upgrade übersteht?
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
Kurzfassung: Nichts Optisches auf diesen OLTs steckt in einer Standard-MIB, alles liegt im privaten ZTE-Enterprise-Baum 3902.
Erst mal das Einfache, Chassis-Temperatur unter .1.3.6.1.4.1.3902.1015.2.1.3.2. Dafür kursiert eine PHP-Sensordefinition mit Schwellen bei 65/55/15/5 Grad. Die nicht blind übernehmen, sondern gegen das prüfen, was das eigene Chassis tatsächlich fährt, bevor Alerting darauf verdrahtet wird.
Die ONU-Seite ist die eigentliche Arbeit. IF-MIB beschreibt nur die OLT-Interfaces, und ein einzelner PON-Port kann bis zu 128 ONUs tragen, es gibt also nichts, woran man ein Interface aufhängen könnte. Am Ende haben Leute den Index aus Shelf, Slot, Port und ONU-Nummer gebaut, gepackt in eine einzige Ganzzahl:
und ihn gegen den ONU-Baum verwendet:
Dieser Baum trägt die ONU-RX-Pegel und Counter64-Byte-Zähler, Traffic pro ONU kommt also aus demselben Walk.
Zwei Warnungen. Das ist ein Haufen Nutzer-Patches, nichts, was upstream gelandet ist, die eigenen Kopien also irgendwo aufheben, um sie nach einem Update erneut anwenden zu können. Und ein OLT mit über 300 ONUs multipliziert die Sensorzahl um etwa das Zehnfache, was der Poller merkt. In dieser Größenordnung die ONU-Daten in Components packen statt in gewöhnliche Interfaces.
Zwei Fragen, bevor dir jemand ein Template schreibt.
Hast du schon etwas außerhalb der Standard-MIBs gewalkt? Bei der ZXA10-Familie stecken die interessanten Daten nicht in IF-MIB, eine leere Sensortabelle ist also das erwartete Ergebnis, kein Bug. Poste, was zurückkommt von
Kommt da ein Wert zurück, bist du im Geschäft, und der Rest ist Index-Arithmetik.
Zweitens: Wie viele ONUs pro PON-Port, und wie viele insgesamt pro Chassis? Diese Zahl entscheidet, ob gewöhnliche Sensoren reichen oder etwas Leichteres gebraucht wird, und sie ändert den Rat ziemlich stark.
Das war's. 3902 von Hand gewalkt lieferte sofort Werte, und nach dem Verdrahten habe ich jetzt Temperatur, CPU, Speicher, Bandbreite, Fehlerzähler und RX-dBm für sowohl die OLT-Ports als auch die ONUs.
Die Warnung wegen der Größenordnung war auch nicht theoretisch. Der C300 trägt weit über 300 ONUs, und der Poller-Lauf für dieses Gerät wurde spürbar länger, sobald jede ONU zu Sensoren wurde, die ONU-Daten wandern deshalb nach Components, und nur die OLT-Optik bleibt als normale Sensoren. Ich würde das trotzdem eher als teilweise gelöst bezeichnen als als fertig: Es funktioniert, aber es ist mein eigener Patch-Satz, und für den C320 gibt es nichts von der Stange.
Anderer Hersteller, gleiche Lektion von meiner Seite: Sobald eine Box tatsächlich Zahlen liefert, sie gegen die Gegenseite prüfen, bevor darauf Alerting gebaut wird.
Wir hatten zwei 20-km-Links mit Nicht-Juniper-SFP+ zwischen einem EX4550 und einem Paar EX3300. Beide Links führten Traffic, aber am EX4550 gab
show interfaces diagnostics opticsaus:während das EX3300-Ende derselben Faser 0,1196 mW / -9,22 dBm meldete. Das ist ein Junos-Skalierungsfehler am EX4550, PR1007055, behoben in 12.3R8. Bis zum Upgrade haben wir den EX4550-Wert als Dekoration behandelt und die Gegenseite benutzt.
Aus zweiter Hand, also mit Vorsicht zu genießen: Am ICX 7450 und ICX 7550 soll die optische Überwachung für die von Ruckus gelieferten Teilenummern 33211-100 und 33210-100 leer bleiben, während Brocade-codierte Äquivalente im selben Chassis normal melden, geführt als FI-264785, mit einem Fix etwa ab einem 08.0.95j-Build erwartet. Vor jedem Neustecken von Modulen lohnt sich ein
show optic.