Wie liest man am ZXA10 C320 die Daten des Uplink-Moduls und die ONU-Pegel aus: über CLI oder per SNMP
Ich betreibe an einem Standort einen ZTE ZXA10 C320, Uplink 10G. Pegel und Status schaue ich mir manuell in der Konsole an, aber ich würde das gerne komplett ins Monitoring holen, um nicht bei jeder Abonnentenbeschwerde in die CLI zu müssen.
- OLT: ZTE ZXA10 C320
- Uplink: SFP+ in xgei_1/21/1
- Teilnehmer auf gpon-onu_1/1/1:1 und weiter über die Zweige
Zum Uplink-Modul habe ich schon etwas gefunden, die Ausgabe liefert dieser Befehl:
show int optical-module-info xgei_1/21/1
Weiter komme ich an drei Dingen nicht vorbei:
- mit welchem Befehl liest man den Pegel für eine konkrete ONU aus, statt die Ausgabe über den ganzen Zweig zu durchforsten
- gibt es ein SNMP-Objekt mit derselben Empfangsleistung, damit ich die CLI nicht per Skript parsen muss; eine fertige Vorlage für den C320 im Monitoring habe ich nicht gefunden
- wie sehr kann man dem Empfangspegel überhaupt trauen: an einem Uplink ist die Zahl anständig, und trotzdem läuft CRC am Interface langsam hoch
Wer diese Daten dauerhaft vom C320 abgreift - wobei seid ihr gelandet, CLI oder SNMP, und welche OIDs?
Comments 4
Präzisiere, was genau du im Monitoring brauchst. Das Modulinventar (Hersteller, Teilenummer, Seriennummer) und die Leistung im Zeitverlauf sind zwei verschiedene Geschichten: das eine reicht, einmal täglich abzugreifen und als Fakt zu speichern, das andere lohnt sich, regelmäßig abzufragen und als Grafik darzustellen.
Und die zweite, wichtigere Frage: hast du CRC am Uplink schon gezielt angeschaut, oder nur nebenbei bemerkt? Wenn der Zähler wirklich wächst, ist der Empfangspegel hier nicht der Hauptverdächtige, und man sollte nicht mit dem Bau von Grafiken anfangen, sondern mit diesem Interface.
Beim Uplink liefert dir genau der Befehl, den du gefunden hast, schon alles Nötige:
In der Ausgabe stehen gleich Herstellername, Teilenummer, Seriennummer, Modultyp (zum Beispiel 10GBASE-LR), Wellenlänge 1310 nm, Rx und Tx in dBm, Bias-Strom, Laser-Geschwindigkeit und Temperatur. Dazu gleich die Alarmschwellen für Leistung, Strom, Spannung und Temperatur - fürs Inventar musst du nirgendwo anders hin.
Bei den Teilnehmern schau dir die Dämpfung pro konkreter ONU an:
Fürs Monitoring liegt die Empfangsleistung am OLT unter .1.3.6.1.4.1.3902.1015.1010.11.2.1.2:
Den Rohwert unbedingt durch 1000 teilen, sonst bekommst du statt dBm unverständliche Tausenderwerte. Daran stolpern fast alle, die zum ersten Mal einen Graphen über diese OID zeichnen.
Und zu deinem dritten Punkt: bevor du Schlüsse aus dem Pegel ziehst, schau dir die CRC-Zähler am Uplink an. Ein normaler Rx-Wert schließt weder einen schmutzigen Steckverbinder noch eine beschädigte Trasse aus.
Die Division durch 1000 war genau das, was gefehlt hat. Bei mir standen im Graphen Tausender statt dBm, und ich dachte die ganze Zeit, ich hätte das falsche Objekt erwischt.
Beim Uplink ist das Bild aufgegangen: Modul 10GBASE-LR, 1310 nm, Empfangspegel normal, und CRC läuft trotzdem hoch. Ich bin den Verteiler durchgegangen - der Steckverbinder war schmutzig, nach der Reinigung stand der Zähler still. Der Rat, CRC vor dem Pegel anzusehen, war also treffend.
Die Pegel pro konkreter ONU lassen sich per Befehl auslesen, ich richte eine Überwachung dafür ein.
Zum Monitoring: auf eine fertige Vorlage kannst du nicht warten. Die C320-Abdeckung ab Werk ist lückenhaft - GPON-Ports, ONU-Optik und Leitungslänge erscheinen nicht von selbst. In LibreNMS (Build 25.8.0-dev) ist eine vernünftige Unterstützung für diese Familie nie gekommen: weder fertige OIDs noch eine beschriebene Methode hat je jemand veröffentlicht. Es gibt also nur einen Weg: eigene Objekte und eine eigene Vorlage, da bist du schon auf dem Weg.
Und denk daran, dass das auf unterschiedlicher Hardware unterschiedlich heißt. Auf dem Cisco ISR 4451 gibt es den gewohnten Befehl am Interface nicht, DOM kommt über
show hw-module subslot 0/0 transceiver 0 status, bei FortiGate ist esget system interface transceiver. Wenn du einen einheitlichen Abfrager für einen Park aus unterschiedlichen Herstellern baust, ist es einfacher, überall per SNMP zu ziehen und die CLI für die Analyse einer konkreten Beschwerde vorzuhalten.