LibreNMS'te ZXA10 OLT'ler: port sayfalarında transceiver dBm yok, fan ve PSU sensörleri de kayboldu
LibreNMS'ten karışık bir ZTE ZXA10 OLT filosunu polluyoruz ve iki şey yanlış gidiyor. Birbiriyle ilgisiz olduklarını düşünüyorum ama emin değilim.
- V2.1.0'da bir ZTE ZXA10 C300, hâlâ eski bir POP'ta hizmette
- V2.0.30'da bir ZTE ZXA10 C620, artı bir C650 ve bir C650E
- eskiden düzgün davranan bir ZTE ZXA10 C320
- SFP ve SFP+ uplink'ler, altlarında GPON kartları
Birinci sorun: port sayfalarında hiç transceiver sensörü yok. dBm cinsinden alış ya da gönderim gücü yok, modül sıcaklığı yok, besleme voltajı yok, lazer bias akımı yok. Abonelerden telefon gelmeye başlamadan kirli bir konnektörü yakalamak için istediğim rakamlar tam olarak bunlar.
İkinci sorun: C320'de çalışan state sensörleri, fanlar, güç kaynakları ve kart durumu, bir yeniden keşiften sonra sessizce ortadan kayboldu. Logda hata yok, hiçbir şey başarısız olmadı, sadece artık cihazda değiller.
Kutuları elle gezince optik veri belli ki MIB'in bir yerinde duruyor, ama bir platformda cevap veren bir OID diğerinde hiçbir şey döndürmüyor:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Şimdiye kadar denenenler:
- her cihazda yeniden keşif ve tam bir poll
- bir C650'nin aynı OID'de verdiği cevabı bir C300'ünkiyle karşılaştırmak
- boş kafeslerin discovery'nin pes etmesinin sebebi olup olmadığını kontrol etmek
ZXA10 ailesinde optik okumalar gerçekte nerede duruyor, ve bir state sensörünü hiçbir şey loglamadan discovery'de kaybolmaya iten ne?
Comments 5
İkisi de bilinen sorunlar, ve tahmin ettiğiniz gibi birbirleriyle ilgisizler.
Hangi optik tabloyu aldığınız platforma bağlı, ikisi de aynı kutuda hiç bir arada bulunmaz. Burada V2.1.0'a karşı test edilen daha eski C300, zxAnOpticalModuleMonTable'ı gösteriyor:
V2.0.30'daki C620, C650 ve C650E ise bunun yerine zxAnOpticalModuleInfoTable'ı gösteriyor:
İki tablo da size aynı dört okumayı verir: dBm cinsinden rx ve tx gücü, modülün sıcaklığı, besleme voltajı, lazer bias akımı. Ham değerler 0.001 ölçeklemesi ister. İki sentinel değerin de filtrelenmesi gerekir, yoksa şasideki her boş kafes size alarm verir: desteklenmeyen bir port ya da doldurulmamış bir kafes 2147483647 cevabı verir, karanlık bir port da -80000 cevabı verir. Kart varlığı optik polling'e hiç ait değil, bu doldurulmamış slotları atlayan ayrı bir operational-status state sensörü.
Kaybolan fanlarınız, PSU'larınız ve kart durumunuz farklı bir bug. Platform YAML'ındaki state girdilerinde value: anahtarı eksikti, o olmadan discovery tablo adını sanki bir sütunmuş gibi okumaya kalkıyor, kullanılabilir bir şey bulamıyor ve sensörü sessizce düşürüyor, hiçbir yerde hata yok, sadece bir yokluk olarak fark etmenizin sebebi de bu. Anahtarı geri koymak buradaki C320 test düzeneğinde altı sensörü geri getirdi.
Buna göre plan yapmadan önce dürüstçe uyarayım: bu, merge edilmiş değil hâlâ açık duran bir değişikliğe biniyor, review de ethernet hata izlemeyi kapsam dışı diye ondan zaten kırpmış durumda. Bunu beklenecek bir düzeltme değil, kendi taşıdığınız bir yama olarak görün.
O kutuların her birinin raporladığı sysDescr'ı bize gösterin. Optik MIB açısından C300, C320, C620, C650 ve C650E tek bir aile değil, yani bazılarında cevap veren bazılarında sessiz kalan bir OID bir arıza değil, beklenen bir şey.
Zaten denediğiniz OID'de en çok farklılaşan ikisinden, C300 ile C650'lerden birinden bir walk'un kuyruğunu paylaşın. Biri cevap verip diğeri boşsa, bütün hikaye bu ve düzeltme platform bazında olur.
Ayrıca iki sorununuzu birbirinden ayrı tutun. Kayıp fan ve PSU sensörleri bir discovery tanım sorunu, OLT'nin hangi optik tabloyu uyguladığıyla hiçbir ilgisi yok.
Boşluğu diğer taraftan doğrulayayım. 25.8.0-dev'de aynı aile hakkında sormuştum: bir C320 GPON OLT, peşinde olduğum şey de her iki uçta, hem OLT'de hem ONU'larda GPON portlarının grafiğiydi - rx ve tx güç seviyeleri, her linkin ne kadar ölçtüğü, port başına kullanım - artı aile için bir şablonun zaten bir yerde var olup olmadığı.
Kimse OID, walk ya da yöntem paylaşmadan kapatıldı, yani belgelediği tek şey C320 ailesi için kutudan çıktığı haliyle kapsamın kısmi olduğu. Geriye dönüp bakınca isteğe bir walk eklemeliydim. Bunu zaten inşa ediyorsanız, ONU optik seviyeleri kimsenin yapmadığı ve çoğumuzun kullanacağı kısım.
Bu, filonun yaptığıyla eşleşiyor. C300, .1.3.6.1.4.1.3902.1015.3.1.13.1'de cevap veriyor ve diğer OID'de hiçbir şey döndürmüyor, C620 ile C650 tam tersi, C650E de C650 gibi davranıyor.
Değerler tam olarak tarif edildiği gibi 0.001 ölçeklemesi isteyen tamsayılar olarak geliyor. İlk başta anlamsız görünenler şimdi anlam kazanıyor: hiç doldurmadığımız kafeslerde 2147483647, karşı ucu kapalı olan iki portta da -80000. Her iki sentinel de burada gerçek, yani eşikleri ham sayılara göre yazan herkes çok gürültülü bir alarm listesi alır.
Platform YAML'ını da kontrol ettim, bizim tarafımızda da value: anahtarı eksik. Değişiklik hâlâ açık olduğu için bunu yerel olarak taşıyacağım. Baştan yanlış yaptığım kısım iki sorunu ayırmakmış.
Bunu inşa ederken aklınızda tutmanız gereken bir şey: DOM verisi sadece ZTE'de değil her yerde bir alt küme.
SONiC'te bir CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28'in EEPROM'u sorunsuz okunuyor, TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR ve TRANSCEIVER_STATUS da identity artı sıcaklık, voltaj, lane başına bias ve güçle doluyor, ama control ve status grubu basitçe yok: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode ve get_power_override veritabanı görünümünde hiçbir şey döndürmüyor, yani o bitlere ihtiyacınız varsa gidip platform API'sine kendiniz sormanız gerekiyor.
Firewall tarafından da aynı ders. PAN-OS'ta show transceiver-detail all diagnostik bloğunu yazdırıyor, okunacak ilk alan da diagnostic-monitor. No diyorsa, modül dijital optik izlemeyi uygulamıyor demektir ve her değer N/A olarak geliyor. Orada bozuk bir şey yok, okunacak bir şey yok sadece. Bu ayrımı alerting'inize kodlamakta fayda var, böylece DOM'suz bir modül ölü bir port gibi görünmez.