LibreNMS vindt geen optische sensoren op ZTE ZXA10 C300/C320 OLT's en helemaal geen ONU-interfaces
Ik beheer de accesslaag bij een kleine ISP en ik wil dat onze twee GPON OLT's in de monitoring verschijnen op dezelfde manier als al het andere. Het wensenlijstje is niet exotisch: hoe heet het chassis draait, CPU- en RAM-belasting, tellers per poort, en het deel waar het me eigenlijk om gaat, de optische kant. Dat betekent Rx/Tx dBm voor de OLT-poorten zelf en een Rx-waarde per abonnee-ONU.
- ZTE ZXA10 C300 en ZXA10 C320, SNMP v2c read-only community
- LibreNMS 25.8.0-dev, self-hosted poller op dezelfde locatie
- SFP- en SFP+-uplinks op beide OLT's
Out of the box krijg ik helemaal niets optisch:
# 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::ifDescrWat ik al gedaan heb:
- geverifieerd dat SNMP zelf gezond is, trafiekgrafieken op de uplinks en de PON-poorten worden correct getekend
- de apparaten na elke wijziging opnieuw laten discoveren en de standaard sensortabellen gecontroleerd, allemaal leeg
- gezocht naar een kant-en-klaar template voor de C320-familie en niets gevonden dat GPON-poort- of ONU-optiek dekt
Dus in welke boom publiceren deze apparaten dat eigenlijk, zowel voor hun eigen poorten als per ONU, en heeft iemand dit al in een vorm in LibreNMS gekregen die een upgrade overleeft?
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
Korte versie: er zit niets optisch van deze OLT's in een standaard-MIB, het zit allemaal in de private enterprise-tree 3902 van ZTE.
Begin met het makkelijkste, de chassistemperatuur op .1.3.6.1.4.1.3902.1015.2.1.3.2. Daar circuleert een PHP-sensordefinitie voor met drempels van 65/55/15/5 graden. Neem die niet zomaar aan, controleer ze tegen wat jouw chassis daadwerkelijk draait voordat je er alerting op aansluit.
De ONU-kant is het echte werk. IF-MIB beschrijft alleen de OLT-interfaces, en één PON-poort kan tot 128 ONU's dragen, dus is er niets om een interface aan op te hangen. Wat mensen uiteindelijk deden, is de index opbouwen uit shelf, slot, poort en ONU-nummer, samengepakt in één integer:
en die gebruiken tegen de ONU-tree:
Die tree bevat de ONU RX-niveaus en Counter64-bytetellers, dus verkeer per ONU komt uit dezelfde walk.
Twee waarschuwingen. Dit is een stapel user-patches, niets dat upstream terecht is gekomen, dus bewaar je eigen kopieën ergens waar je ze na een update opnieuw kunt toepassen. En een OLT met ruim 300 ONU's vermenigvuldigt je sensoraantal met ruwweg tien, en dat merkt de poller. Zet op die schaal de ONU-data in Components in plaats van in gewone interfaces.
Twee vragen voordat iemand een template voor je schrijft.
Heb je iets buiten de standaard-MIB's gewalkt? Bij de ZXA10-familie zit de interessante data niet in IF-MIB, dus een lege sensortabel is het verwachte resultaat en geen bug. Post wat je terugkrijgt van
Als dat een waarde teruggeeft, zit je goed en is de rest indexrekenwerk.
Ten tweede: hoeveel ONU's per PON-poort, en hoeveel per chassis in totaal? Dat aantal bepaalt of je gewone sensoren wilt of iets lichters, en het verandert het advies behoorlijk.
Dat was het. Handmatig 3902 walken gaf meteen waarden terug, en nadat ik het had aangesloten heb ik nu temperatuur, CPU, geheugen, bandbreedte, foutentellers en RX dBm voor zowel de OLT-poorten als de ONU's.
De waarschuwing over schaal was ook niet theoretisch. De C300 heeft ruim meer dan 300 ONU's, en de pollerrun voor dat apparaat werd merkbaar langer zodra elke ONU sensoren opleverde, dus verhuist de per-ONU-data naar Components en blijven alleen de OLT-optieken als gewone sensoren staan. Ik zou dit nog steeds gedeeltelijk noemen in plaats van opgelost: het werkt, maar het is mijn eigen patchset, en voor de C320 is er niets kant-en-klaars.
Andere leverancier, zelfde les van mijn kant: zodra een apparaat je wel cijfers geeft, controleer ze tegen de andere kant voordat je er alerting op bouwt.
We hadden twee links van 20 km met non-Juniper SFP+ tussen een EX4550 en een paar EX3300's. Beide links gaven verkeer door, maar op de EX4550 printte
show interfaces diagnostics opticsterwijl het EX3300-uiteinde van dezelfde vezel 0,1196 mW / -9,22 dBm rapporteerde. Dat is een Junos-schaaldefect op de EX4550, PR1007055, gecorrigeerd in 12.3R8. Tot we upgraded, behandelden we de EX4550-uitlezing als decoratie en gebruikten we de andere kant.
Uit de tweede hand, dus neem het met een korrel zout: op ICX 7450 en ICX 7550 blijft optische monitoring naar verluidt leeg voor de door Ruckus geleverde onderdeelnummers 33211-100 en 33210-100, terwijl Brocade-gecodeerde equivalenten in hetzelfde chassis normaal rapporteren, getrackt als FI-264785 met een fix verwacht rond een 08.0.95j-build. Een
show opticwaard voordat iemand modules opnieuw gaat insteken.