ZXA10-OLTs in LibreNMS: keine Transceiver-dBm auf den Port-Seiten, und die Lüfter- und Netzteil-Sensoren sind verschwunden
Wir pollen eine gemischte Flotte von ZTE-ZXA10-OLTs aus LibreNMS, und zwei Dinge stimmen nicht. Ich vermute, sie hängen nicht zusammen, bin mir aber nicht sicher.
- ZTE ZXA10 C300 auf V2.1.0, noch im Einsatz in einem alten POP
- ZTE ZXA10 C620 auf V2.0.30, dazu ein C650 und ein C650E
- ein ZTE ZXA10 C320, der sich früher brav verhalten hat
- SFP- und SFP+-Uplinks, darunter GPON-Karten
Erstes Problem: Die Port-Seiten haben überhaupt keine Transceiver-Sensoren. Keine Empfangs- oder Sendeleistung in dBm, keine Modultemperatur, keine Versorgungsspannung, kein Laser-Biasstrom. Genau diese Werte will ich, um einen schmutzigen Steckverbinder zu erwischen, bevor die Teilnehmer anfangen anzurufen.
Zweites Problem: Die Statussensoren, die am C320 funktioniert haben, Lüfter, Netzteile und Kartenstatus, sind nach einer Neuerkennung still verschwunden. Kein Fehler im Log, nichts schlug fehl, sie stehen einfach nicht mehr auf dem Gerät.
Wenn ich die Boxen von Hand abklappere, stecken die optischen Daten eindeutig irgendwo in der MIB, aber eine OID, die auf einer Plattform antwortet, liefert auf einer anderen nichts zurück:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Bisher versucht:
- Neuerkennung und vollständiger Poll auf jedem Gerät
- verglichen, was ein C650 auf derselben OID antwortet gegenüber dem, was der C300 antwortet
- geprüft, ob leere Käfige der Grund sind, warum die Erkennung aufgibt
Wo liegen die optischen Werte bei der ZXA10-Familie eigentlich, und was lässt einen Statussensor bei der Erkennung verschwinden, ohne irgendetwas zu loggen?
Comments 5
Beide sind bekannt, und wie du vermutet hast, hängen sie nicht zusammen.
Welche optische Tabelle du bekommst, hängt von der Plattform ab, und die beiden koexistieren nie auf einer Box. Der ältere C300, hier gegen V2.1.0 getestet, liefert zxAnOpticalModuleMonTable:
C620 auf V2.0.30, C650 und C650E liefern stattdessen zxAnOpticalModuleInfoTable:
Beide Tabellen liefern dieselben vier Werte: RX- und TX-Leistung in dBm, Modultemperatur, Versorgungsspannung, Laser-Biasstrom. Die Rohwerte brauchen den Faktor 0,001. Zwei Sentinel-Werte müssen auch rausgefiltert werden, sonst alarmiert jeder leere Käfig im Chassis: Ein nicht unterstützter Port oder ein unbestückter Käfig antwortet mit 2147483647, ein dunkler Port mit -80000. Kartenpräsenz gehört überhaupt nicht ins optische Polling, das ist ein eigener Betriebsstatus-Sensor, der unbestückte Slots überspringt.
Eure verschwundenen Lüfter, Netzteile und der Kartenstatus sind ein anderer Bug. Bei den State-Einträgen im Plattform-YAML fehlte der Schlüssel value:, und ohne ihn liest die Erkennung am Ende den Tabellennamen, als wäre er eine Spalte, findet nichts Brauchbares und wirft den Sensor still raus, nirgendwo ein Fehler, weshalb ihr es nur als Abwesenheit bemerkt habt. Den Schlüssel zurückzusetzen hat hier am C320-Testaufbau sechs Sensoren wiederhergestellt.
Fairerweise vorgewarnt, bevor du damit planst: Das reitet auf einem Change, der noch offen ist und nicht gemerged, und im Review wurde die Ethernet-Fehlerüberwachung schon als out of scope herausgekürzt. Behandle es als Patch, den du selbst mitführst, nicht als Fix, auf den man wartet.
Zeig uns die sysDescr, die jede dieser Boxen meldet. C300, C320, C620, C650 und C650E sind, was die optische MIB angeht, keine eine Familie, eine OID, die bei einigen antwortet und bei den restlichen schweigt, ist also zu erwarten und kein Fehler.
Poste das Ende eines Walks von den beiden, die sich am meisten unterscheiden, dem C300 und einem der C650, auf der OID, die du schon probiert hast. Wenn einer antwortet und der andere leer bleibt, ist das die ganze Geschichte, und die Lösung ist pro Plattform.
Und haltet eure zwei Probleme auseinander. Die fehlenden Lüfter- und Netzteil-Sensoren sind ein Problem der Discovery-Definition und haben nichts damit zu tun, welche optische Tabelle das OLT implementiert.
Bestätige die Lücke von der anderen Seite. Ich habe zu derselben Familie auf 25.8.0-dev gefragt: ein C320-GPON-OLT, und wonach ich eigentlich suchte, war grafische Darstellung an den GPON-Ports auf beiden Seiten, am OLT und an den ONUs - RX- und TX-Leistungspegel, wie lang jeder Link ausmisst, Auslastung pro Port - plus ob es irgendwo schon eine Vorlage für die Familie gibt.
Es wurde geschlossen, ohne dass jemand OIDs, einen Walk oder eine Methode gepostet hätte, es dokumentiert also nur, dass die Abdeckung für die C320-Familie von Haus aus lückenhaft ist. Im Nachhinein hätte ich der Anfrage einen Walk beilegen sollen. Wenn du das ohnehin baust: ONU-Optikpegel sind der Teil, den noch niemand gemacht hat, und einige von uns würden ihn nutzen.
Das passt zu dem, was die Flotte macht. Der C300 antwortet auf .1.3.6.1.4.1.3902.1015.3.1.13.1 und liefert auf der anderen OID nichts, C620 und C650 sind umgekehrt, und der C650E verhält sich wie der C650.
Die Werte kommen als Integer zurück und brauchen den Faktor 0,001, genau wie beschrieben. Die, die zuerst wie Datenmüll aussahen, ergeben jetzt Sinn: 2147483647 an den Käfigen, die wir nie bestückt haben, und -80000 an zwei Ports, wo das Gegenende ausgeschaltet ist. Beide Sentinel-Werte sind hier real, wer also Schwellenwerte gegen die Rohwerte schreibt, bekommt eine sehr geräuschvolle Alarmliste.
Habe auch das Plattform-YAML geprüft, der Schlüssel value: fehlt bei uns ebenfalls. Werde das lokal mitführen, solange der Change noch offen ist. Die beiden Probleme zu trennen war der Teil, den ich von Anfang an falsch hatte.
Eins, das man beim Bauen im Hinterkopf behalten sollte: DOM-Daten sind überall nur eine Teilmenge, nicht nur bei ZTE.
In SONiC lässt sich bei einem CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28 das EEPROM problemlos auslesen, und TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR plus TRANSCEIVER_STATUS füllen sich alle mit Identität plus Temperatur, Spannung, Bias und Leistung pro Lane, aber die Control-und-Status-Gruppe fehlt einfach: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode und get_power_override liefern in der Datenbankansicht nichts zurück, wer diese Bits braucht, muss sie sich selbst bei der Plattform-API holen.
Dieselbe Lehre von der Firewall-Seite. Bei PAN-OS druckt show transceiver-detail all den Diagnoseblock, und das erste Feld, das man liest, ist diagnostic-monitor. Steht dort No, implementiert das Modul kein digitales optisches Monitoring, und jeder Wert kommt als N/A zurück. Da ist nichts kaputt, es gibt nur nichts zu lesen. Es lohnt sich, diese Unterscheidung im eigenen Alerting zu kodieren, damit ein Modul ohne DOM nicht genauso aussieht wie ein toter Port.