LibreNMS nie znajduje żadnych czujników optycznych na OLT ZTE ZXA10 C300/C320 i w ogóle żadnych interfejsów ONU
Zajmuję się warstwą dostępową w małym ISP i chcę, żeby nasze dwa GPON OLT pojawiały się w monitoringu tak samo jak wszystko inne. Lista życzeń nie jest egzotyczna: jak gorące jest chassis, obciążenie CPU i RAM, liczniki na port, i część, na której naprawdę mi zależy, strona optyczna. Czyli Rx/Tx w dBm dla samych portów OLT i wartość Rx per abonencki ONU.
- ZTE ZXA10 C300 i ZXA10 C320, SNMP v2c community tylko do odczytu
- LibreNMS 25.8.0-dev, self-hosted poller na tej samej lokalizacji
- uplinki SFP i SFP+ na obu OLT
Od razu po instalacji nie dostaję nic optycznego w ogóle:
# 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::ifDescrCo już zrobiłem:
- potwierdziłem, że samo SNMP jest zdrowe, wykresy ruchu na uplinkach i portach PON rysują się poprawnie
- odkrywałem urządzenia ponownie po każdej zmianie i sprawdziłem standardowe tabele sensorów, wszystkie puste
- szukałem gotowego template dla rodziny C320 i nie znalazłem niczego pokrywającego port GPON ani optykę ONU
Więc w którym drzewie te urządzenia faktycznie publikują te dane, zarówno dla własnych portów, jak i per ONU, i czy ktoś wciągnął to do LibreNMS w formie, która przeżywa upgrade?
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
Krótka wersja: nic optycznego na tych OLT nie siedzi w standardowym MIB, wszystko jest w prywatnym drzewie enterprise ZTE 3902.
Zacznij od tego łatwego, temperatura chassis pod .1.3.6.1.4.1.3902.1015.2.1.3.2. Krąży do tego definicja sensora w PHP z progami 65/55/15/5 stopni. Nie bierz ich na wiarę, sprawdź je względem tego, na czym faktycznie działa twoje chassis, zanim podepniesz do nich alerting.
Strona ONU to prawdziwa robota. IF-MIB opisuje tylko interfejsy OLT, a jeden port PON może nieść do 128 ONU, więc nie ma na czym zawiesić interfejsu. To, na czym ludzie w końcu wylądowali, to budowanie indeksu z shelf, slot, port i numeru ONU spakowanych w jedną liczbę całkowitą:
i używanie go względem drzewa ONU:
To drzewo niesie poziomy RX ONU i liczniki bajtów Counter64, więc ruch per ONU wychodzi z tego samego walk.
Dwa ostrzeżenia. To stos łatek od użytkowników, nic, co trafiło upstream, więc trzymaj swoje kopie gdzieś, skąd dasz radę nałożyć je ponownie po aktualizacji. A OLT z ponad 300 ONU mnoży liczbę twoich sensorów jakieś dziesięć razy, co poller zauważy. W takiej skali wsadź dane ONU do Components zamiast do zwykłych interfejsów.
Dwa pytania, zanim ktokolwiek napisze ci template.
Robiłeś walk czegoś poza standardowymi MIB-ami? W rodzinie ZXA10 ciekawe dane nie siedzą w IF-MIB, więc pusta tabela sensorów to oczekiwany wynik, a nie bug. Wklej, co dostajesz z
Jeśli to zwraca wartość, jesteś w grze, a reszta to arytmetyka indeksów.
Drugie: ile ONU na port PON, i ile na chassis w sumie? Ta liczba decyduje, czy chcesz zwykłych sensorów, czy czegoś lżejszego, i mocno zmienia poradę.
To było to. Ręczny walk po 3902 od razu zwrócił wartości, i po podpięciu tego mam teraz temperaturę, CPU, pamięć, przepustowość, liczniki błędów i RX w dBm zarówno dla portów OLT, jak i dla ONU.
Ostrzeżenie o skali też nie było teoretyczne. C300 niesie dobrze ponad 300 ONU, i przebieg pollera dla tego urządzenia zauważalnie się wydłużył, gdy każdy ONU zmienił się w sensory, więc dane per ONU przenoszę do Components, a optyka OLT zostaje jako zwykłe sensory. Wciąż nazwałbym to częściowym rozwiązaniem, a nie pełnym: działa, ale to mój własny zestaw łatek, i dla C320 nic nie przychodzi gotowe.
Inny vendor, ta sama lekcja z mojej strony: gdy urządzenie w końcu daje ci liczby, sprawdź je względem drugiego końca, zanim zbudujesz na nich alerting.
Mieliśmy dwa linki 20 km z SFP+ spoza Junipera między EX4550 a parą EX3300. Oba linki przenosiły ruch, ale na EX4550
show interfaces diagnostics opticsdrukowałopodczas gdy koniec tego samego włókna na EX3300 zgłaszał 0,1196 mW / -9,22 dBm. To defekt skalowania w Junosie na EX4550, PR1007055, poprawiony w 12.3R8. Do czasu upgrade'u traktowaliśmy odczyt z EX4550 jako dekorację i używaliśmy dalekiego końca.
Z drugiej ręki, więc bierz to z przymrużeniem oka: na ICX 7450 i ICX 7550 monitoring optyczny podobno zostaje pusty dla numerów części od Ruckusa 33211-100 i 33210-100, podczas gdy odpowiedniki zakodowane pod Brocade w tym samym chassis raportują normalnie, tropione jako FI-264785 z poprawką spodziewaną gdzieś koło builda 08.0.95j. Warto rzucić
show optic, zanim ktokolwiek zacznie przekładać moduły.