Hoe haal ik op een ZXA10 C320 de gegevens van de uplinkmodule en de ONU-niveaus op - via CLI of via SNMP
Ik heb op een node een ZTE ZXA10 C320 draaien, uplink 10G. Niveaus en status bekijk ik handmatig vanaf de console, maar ik wil dit graag in monitoring krijgen, zodat ik niet bij elke klacht van een abonnee de CLI in hoef.
- OLT: ZTE ZXA10 C320
- uplink: SFP+ in xgei_1/21/1
- abonnees op gpon-onu_1/1/1:1 en verder over de takken
Over de uplinkmodule heb ik al iets gevonden, dit commando geeft de output:
show int optical-module-info xgei_1/21/1Daarna loop ik tegen drie dingen aan:
- met welk commando haal ik het niveau van een specifieke ONU op, in plaats van de output van de hele tak te moeten uitpluizen
- is er een SNMP-object met datzelfde ontvangstvermogen, zodat ik niet met een script de CLI hoef te parsen; een kant-en-klaar template voor de C320 in monitoring heb ik niet gevonden
- in hoeverre is het ontvangstniveau eigenlijk te vertrouwen: op één uplink is het cijfer keurig, maar CRC op de interface loopt ondertussen langzaam op
Wie haalt deze gegevens standaard van een C320 - waar zijn jullie op uitgekomen, CLI of SNMP, en welke OID's?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 4
Verduidelijk even wat je precies in de monitoring nodig hebt. De inventaris van de module (vendor, partnummer, serienummer) en het vermogen in de tijd zijn twee verschillende verhalen: het eerste is genoeg om eens per dag op te halen en als feit te bewaren, het tweede heeft pas zin als je het regelmatig uitleest en in een grafiek zet.
En de tweede vraag, belangrijker: heb je CRC op de uplink al gericht bekeken, of viel het je terloops op? Als de teller echt oploopt, dan is het ontvangstniveau niet de hoofdverdachte, en moet je niet beginnen met grafieken bouwen, maar met deze interface.
Voor de uplink geeft precies het commando dat je al gevonden had alles wat je nodig hebt:
In de output staan meteen de vendornaam, het partnummer, het serienummer, het moduletype (bijvoorbeeld 10GBASE-LR), de golflengte van 1310 nm, Rx en Tx in dBm, biasstroom, lasersnelheid en temperatuur. Plus daar staan ook de alarmdrempels voor vermogen, stroom, spanning en temperatuur - je hoeft niet apart voor de inventaris ergens anders te kijken.
Kijk voor de abonnees naar de demping per specifieke ONU:
Voor monitoring staat het ontvangstvermogen op de OLT op .1.3.6.1.4.1.3902.1015.1010.11.2.1.2:
De ruwe waarde moet je altijd door 1000 delen, anders krijg je in plaats van dBm onbegrijpelijke duizendtallen. Daar struikelt bijna iedereen over die voor het eerst een grafiek op dit OID bouwt.
En over je derde punt: voordat je conclusies trekt op basis van het niveau, kijk naar de CRC-tellers op de uplink. Een normale Rx sluit op zichzelf geen vieze connector en geen beschadigd traject uit.
Delen door 1000 was precies wat ontbrak. Bij mij stonden er op de grafiek duizendtallen in plaats van dBm, en ik dacht al die tijd dat ik het verkeerde object had gepakt.
Voor de uplink klopte het beeld: module 10GBASE-LR, 1310 nm, ontvangstniveau normaal, terwijl CRC ondertussen opliep. Ik ben het kruis langsgegaan - de connector bleek vies, na het schoonmaken bleef de teller stilstaan. Dus het advies om eerst naar CRC te kijken en dan pas naar het niveau, bleek terecht.
Niveaus per specifieke ONU zijn met het commando op te halen, ik zet er polling op.
Over monitoring: wacht maar niet op een kant-en-klaar template. De dekking van de C320 is out of the box gedeeltelijk - GPON-poorten, ONU-optiek en lijnlengte verschijnen niet vanzelf. In LibreNMS (build 25.8.0-dev) is nooit fatsoenlijke ondersteuning voor deze familie gekomen: niemand heeft kant-en-klare OID's of een beschreven methode gepubliceerd. Er is dus maar één weg - eigen objecten en een eigen template, en daar ben je al mee bezig.
Houd er meteen rekening mee dat dit op verschillende hardware anders heet. Op een Cisco ISR 4451 bestaat het gebruikelijke commando vanaf de interface niet, DOM komt daar via
show hw-module subslot 0/0 transceiver 0 status, op een FortiGate is datget system interface transceiver. Bouw je één opvrager voor een park met verschillende vendoren, dan is het simpeler om overal via SNMP te trekken en de CLI te bewaren voor het uitpluizen van een specifieke klacht.