ZXA10 OLT's in LibreNMS: geen transceiver-dBm op de poortpagina's, en de fan- en PSU-sensoren zijn verdwenen
We pollen een gemengde vloot ZTE ZXA10-OLT's vanuit LibreNMS en er zijn twee dingen mis. Ik vermoed dat ze niets met elkaar te maken hebben, maar zeker weet ik het niet.
- ZTE ZXA10 C300 op V2.1.0, nog in dienst in een oude POP
- ZTE ZXA10 C620 op V2.0.30, plus een C650 en een C650E
- één ZTE ZXA10 C320 die vroeger wel deed wat hij moest doen
- SFP- en SFP+-uplinks, GPON-kaarten eronder
Eerste probleem: de poortpagina's hebben helemaal geen transceiversensoren. Geen ontvangst- of zendvermogen in dBm, geen moduletemperatuur, geen voedingsspanning, geen laser-bias-stroom. Dat zijn precies de getallen waarmee ik een vuile connector wil opvangen voordat abonnees gaan bellen.
Tweede probleem: de statussensoren die op de C320 wel werkten, fans, voedingen en kaartstatus, zijn na een herontdekking stilletjes verdwenen. Geen fout in het log, niets ging kapot, ze staan gewoon niet meer op het apparaat.
Als ik de dozen met de hand langsloop, zit de optische data duidelijk ergens in de MIB, maar een OID die op het ene platform antwoordt geeft op het andere niets terug:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Tot nu toe geprobeerd:
- herontdekking en een volledige poll op elk apparaat
- vergeleken wat een C650 antwoordt tegenover wat de C300 antwoordt op dezelfde OID
- gecontroleerd of lege cages de reden zijn waarom discovery het opgeeft
Waar leven de optische uitlezingen daadwerkelijk bij de ZXA10-familie, en waardoor verdwijnt een statussensor bij discovery zonder dat er iets gelogd wordt?
Comments 5
Allebei bekend, en zoals je al vermoedde staan ze los van elkaar.
Welke optische tabel je krijgt hangt af van het platform, en de twee bestaan nooit samen op één doos. De oudere C300, hier getest tegen V2.1.0, exposeert zxAnOpticalModuleMonTable:
C620 op V2.0.30, C650 en C650E exposeren in plaats daarvan zxAnOpticalModuleInfoTable:
Beide tabellen geven je dezelfde vier uitlezingen: rx- en tx-vermogen in dBm, temperatuur van de module, voedingsspanning, laser-bias-stroom. Ruwe waarden hebben de 0,001-schaling nodig. Er moeten ook twee sentinelwaarden gefilterd worden, anders slaat elke lege cage in het chassis bij je alarm: een niet-ondersteunde poort of een onbezette cage antwoordt 2147483647, en een donkere poort antwoordt -80000. Kaartaanwezigheid hoort helemaal niet thuis in de optische polling, dat is een aparte operationele-status-sensor die onbezette slots overslaat.
Jouw verdwenen fans, PSU's en kaartstatus zijn een andere bug. Bij de state-items in de platform-YAML ontbrak de sleutel value:, en zonder die sleutel eindigt discovery ermee de tabelnaam als kolom te lezen, vindt niets bruikbaars en laat de sensor stilzwijgend vallen, nergens een fout, en dat is waarom je het alleen als afwezigheid opmerkte. De sleutel terugzetten herstelde hier zes sensoren op de C320-testopstelling.
Eerlijke waarschuwing voordat je erop plant: dit zit in een wijziging die nog open staat en niet gemerged is, en review heeft ethernet-foutmonitoring er al als buiten scope uitgehaald. Behandel het als een patch die je zelf meedraagt, niet als een fix om op te wachten.
Laat de sysDescr zien die elk van die dozen rapporteert. C300, C320, C620, C650 en C650E zijn wat de optische MIB betreft geen ene familie, dus een OID die op sommige antwoordt en bij de rest stil blijft is te verwachten en geen storing.
Post de staart van een walk van de twee die het meest verschillen, de C300 en een van de C650's, op de OID die je al geprobeerd hebt. Antwoordt de ene en is de andere leeg, dan is dat het hele verhaal en is de fix per platform.
Houd ook je twee problemen uit elkaar. De ontbrekende fan- en PSU-sensoren zijn een discovery-definitiekwestie en hebben niets te maken met welke optische tabel de OLT implementeert.
Bevestig de leemte van de andere kant. Ik heb over dezelfde familie gevraagd op 25.8.0-dev: een C320 GPON-OLT, en waar ik naar op zoek was is grafieken op de GPON-poorten aan beide kanten, op de OLT en op de ONU's: rx- en tx-vermogensniveaus, hoe lang elke link meet, benutting per poort, plus of er ergens al een template voor de familie bestond.
Het werd gesloten zonder dat iemand OID's, een walk of een methode postte, dus het enige wat het documenteert is dat de dekking out-of-the-box voor de C320-familie gedeeltelijk is. Achteraf gezien had ik een walk bij het verzoek moeten voegen. Als je dit toch aan het bouwen bent: ONU-optische-niveaus is het deel dat niemand gedaan heeft en heel wat van ons zouden het gebruiken.
Dat komt overeen met wat onze vloot doet. De C300 antwoordt op .1.3.6.1.4.1.3902.1015.3.1.13.1 en geeft niets terug op de andere OID, bij de C620 en C650 is het andersom, en de C650E gedraagt zich als de C650.
Waarden komen terug als integers die de 0,001-schaling nodig hebben, precies zoals beschreven. Wat eerst als rommel oogde is nu logisch: 2147483647 op de cages die we nooit bezet hebben, en -80000 op twee poorten waar de andere kant uitstaat. Beide sentinelwaarden zijn hier echt, dus wie drempels schrijft tegen de ruwe getallen krijgt een heel ruizige alertlijst.
Ook de platform-YAML gecontroleerd en de sleutel value: ontbreekt bij ons ook. Dat draag ik lokaal mee zolang de wijziging nog open staat. De twee problemen uit elkaar houden was het deel dat ik vanaf het begin verkeerd had.
Eén ding om in gedachten te houden terwijl je dit bouwt: DOM-data is overal een deelverzameling, niet alleen bij ZTE.
In SONiC wordt de EEPROM van een CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28 probleemloos gelezen, en TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR plus TRANSCEIVER_STATUS vullen zich allemaal met identiteit plus temperatuur, spanning, bias en vermogen per lane, maar de control- en statusgroep ontbreekt gewoon: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode en get_power_override geven niets terug in de databaseweergave, dus als je die bits nodig hebt vraag je ze zelf bij de platform-API op.
Zelfde les vanaf de firewallkant. Op PAN-OS print show transceiver-detail all het diagnostiekblok, en het eerste veld om te lezen is diagnostic-monitor. Staat daar No, dan implementeert de module geen digitale optische monitoring en komt elke waarde terug als N/A. Er is daar niets stuk, er valt gewoon niets te lezen. Het is de moeite waard om dat onderscheid in je alerting vast te leggen zodat een module zonder DOM er niet hetzelfde uitziet als een dode poort.