LibreNMS, ZTE ZXA10 C300/C320 OLT'lerde optik sensör bulmuyor, ONU arayüzü de hiç yok
Küçük bir ISS'te erişim katmanına bakıyorum ve iki GPON OLT'imizin diğer her şey gibi monitoring'de görünmesini istiyorum. İstek listesi sıra dışı değil: şasi ne kadar ısınıyor, CPU ve RAM yükü, port başına sayaçlar ve asıl önem verdiğim kısım, optik taraf. Yani OLT portlarının kendisi için Rx/Tx dBm ve abone başına ONU için bir Rx değeri.
- ZTE ZXA10 C300 ve ZXA10 C320, SNMP v2c read-only community
- LibreNMS 25.8.0-dev, aynı site üzerinde self-hosted poller
- her iki OLT'de de SFP ve SFP+ uplink'ler
Kutudan çıktığı haliyle optik tarafta hiçbir şey almıyorum:
# 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::ifDescrŞimdiye kadar yaptıklarım:
- SNMP'nin kendisinin sağlıklı olduğunu doğruladım, uplink'lerdeki ve PON portlarındaki trafik grafikleri doğru çiziliyor
- her değişiklikten sonra cihazları yeniden keşfettim ve standart sensör tablolarını kontrol ettim, hepsi boş
- C320 ailesi için hazır bir template aradım ve GPON portu ya da ONU optiğini kapsayan hiçbir şey bulamadım
Peki bu cihazlar bunu gerçekte hangi ağaçta yayınlıyor, hem kendi portları hem de ONU başına, ve birileri bunu upgrade'den sağ çıkacak bir şekilde LibreNMS'e sokabildi mi?
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
Kısa cevap: bu OLT'lerde optikle ilgili hiçbir şey standart bir MIB'de yaşamıyor, hepsi ZTE'nin özel enterprise ağacı 3902'de.
Kolay olandan başla, şasi sıcaklığı .1.3.6.1.4.1.3902.1015.2.1.3.2 adresinde. Bunun için ortalıkta 65/55/15/5 derecelik eşiklere sahip bir PHP sensör tanımı dolaşıyor. Bunlara körü körüne güvenme, alarm bağlamadan önce şasinin gerçekte hangi sıcaklıkta çalıştığıyla karşılaştır.
Asıl iş ONU tarafında. IF-MIB sadece OLT arayüzlerini tanımlıyor ve tek bir PON portu 128'e kadar ONU taşıyabiliyor, yani üzerine asacak bir arayüz yok. İnsanların sonunda yaptığı şey, shelf, slot, port ve ONU numarasından tek bir tam sayıya paketlenmiş bir index kurmak oldu:
ve bunu ONU ağacına karşı kullanmak:
O ağaç ONU RX seviyelerini ve Counter64 byte sayaçlarını taşıyor, yani ONU başına trafik de aynı walk'tan çıkıyor.
İki uyarı. Bu bir yığın kullanıcı yaması, upstream'e ulaşmış hiçbir şey yok, yani kopyalarını bir update'ten sonra tekrar uygulayabileceğin bir yerde tut. Ayrıca 300'den fazla ONU'lu bir OLT sensör sayını kabaca on katına çıkarıyor, ki bunu poller fark edecektir. Bu ölçekte ONU verisini sıradan arayüzler yerine Components'e koy.
Biri sana template yazmadan önce iki soru.
Standart MIB'lerin dışında herhangi bir şey walk ettin mi? ZXA10 ailesinde ilginç veri IF-MIB'de değil, yani boş bir sensör tablosu bug değil, beklenen bir sonuç. Şuradan ne döndüğünü paylaş:
Bu bir değer döndürürse iş tamamdır, gerisi index aritmetiği.
İkincisi: PON portu başına kaç ONU var ve toplamda şasi başına kaç tane? Bu sayı sıradan sensör mü yoksa daha hafif bir şey mi istediğini belirliyor ve tavsiyeyi epey değiştiriyor.
İşte buydu. 3902'yi elle walk etmek hemen değer döndürdü ve bağladıktan sonra artık hem OLT portları hem de ONU'lar için sıcaklık, CPU, bellek, bant genişliği, hata sayaçları ve RX dBm var.
Ölçek konusundaki uyarı da teorik değilmiş. C300'de 300'ün epey üzerinde ONU var ve her ONU sensöre dönüşünce o cihaz için poller çalışması gözle görülür şekilde uzadı, yani ONU başına veri Components'e taşınıyor ve sadece OLT optiği normal sensör olarak kalıyor. Buna yine de çözüldü değil kısmen çözüldü derim: çalışıyor ama bu benim kendi yama setim ve C320 için hazır hiçbir şey yok.
Farklı vendor, ama benim tarafımdan aynı ders: bir cihaz sana rakam verdiğinde, üzerine alarm kurmadan önce onları karşı uçla karşılaştır.
EX4550 ile bir çift EX3300 arasında Juniper olmayan SFP+'lı iki tane 20 km'lik linkimiz vardı. Her iki link de trafik geçiriyordu, ama EX4550'de
show interfaces diagnostics opticsşunu bastı:aynı fiberin EX3300 ucu ise 0,1196 mW / -9,22 dBm bildiriyordu. Bu, EX4550'deki bir Junos ölçeklendirme hatası, PR1007055, 12.3R8'de düzeltildi. Upgrade edene kadar EX4550 okumasını dekor olarak görüp karşı ucu kullandık.
İkinci elden bilgi, o yüzden hafif al: ICX 7450 ve ICX 7550'de optik izleme, Ruckus tedarikli 33211-100 ve 33210-100 parça numaraları için boş kalıyormuş, aynı şasideki Brocade kodlu eşdeğerleri ise normal rapor veriyormuş; FI-264785 olarak takip ediliyor, düzeltmenin 08.0.95j civarı bir build'de gelmesi bekleniyor. Kimse modülleri yeniden oturtmaya başlamadan önce bir
show opticdenemeye değer.