ZXA10 OLT w LibreNMS: brak dBm transceivera na stronach portów, zniknęły czujniki wentylatora i zasilacza
Odpytujemy z LibreNMS mieszaną flotę OLT-ów ZTE ZXA10 i coś jest nie tak w dwóch miejscach. Podejrzewam, że nie są ze sobą powiązane, ale nie jestem pewien.
- ZTE ZXA10 C300 na V2.1.0, wciąż w eksploatacji w starym POP-ie
- ZTE ZXA10 C620 na V2.0.30, plus C650 i C650E
- jeden ZTE ZXA10 C320, który wcześniej działał normalnie
- uplinki SFP i SFP+, pod nimi karty GPON
Pierwszy problem: strony portów w ogóle nie mają czujników transceivera. Żadnej mocy odbioru czy nadawania w dBm, żadnej temperatury modułu, napięcia zasilania, prądu polaryzacji lasera. To są liczby, które chcę widzieć, żeby wyłapać brudne złącze, zanim zaczną dzwonić abonenci.
Drugi problem: czujniki stanu, które na C320 działały, wentylatory, zasilacze i stan kart, po ponownym wykryciu po cichu zniknęły. Żadnego błędu w logu, nic nie padło, po prostu ich już nie ma na urządzeniu.
Przechodząc po urządzeniach ręcznie widać, że dane optyczne gdzieś w MIB-ie na pewno są, ale OID, który odpowiada na jednej platformie, na innej milczy:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Co już sprawdziłem:
- ponowne wykrycie i pełny odpyt na każdym urządzeniu
- porównanie odpowiedzi C650 i C300 na ten sam OID
- czy przyczyną poddania się przy wykrywaniu są puste klatki
Gdzie właściwie mieszkają odczyty optyczne w rodzinie ZXA10 i co sprawia, że czujnik stanu znika przy wykrywaniu bez żadnego zapisu w logu?
Comments 5
Obie sprawy są znane i, jak podejrzewasz, nie są ze sobą powiązane.
To, którą tabelę optyczną dostaniesz, zależy od platformy, i te dwie nigdy nie współistnieją na jednym urządzeniu. Starszy C300, sprawdzony tutaj na V2.1.0, udostępnia zxAnOpticalModuleMonTable:
C620 na V2.0.30, C650 i C650E zamiast tego udostępniają zxAnOpticalModuleInfoTable:
Obie tabele dają te same cztery odczyty: moc rx i tx w dBm, temperaturę modułu, napięcie zasilania, prąd polaryzacji lasera. Surowe wartości trzeba przeskalować przez 0,001. Trzeba też odfiltrować dwie wartości wartownicze, inaczej każda pusta klatka w obudowie będzie alarmować: nieobsługiwany port albo niezapełniona klatka odpowiada 2147483647, a martwy port odpowiada -80000. Obecność karty w ogóle nie należy do odpytywania optycznego, to osobny czujnik stanu operacyjnego, który pomija niezapełnione sloty.
Twoje zniknięte wentylatory, zasilacze i stan kart to inny błąd. We wpisach stanu w YAML-u platformy brakowało klucza value:, a bez niego wykrywanie w końcu czyta nazwę tabeli tak, jakby to była kolumna, nie znajduje nic sensownego i po cichu porzuca czujnik, bez żadnego błędu, dlatego zauważyłeś to tylko jako brak. Przywrócenie klucza przywróciło tutaj sześć czujników na testowym C320.
Uczciwe ostrzeżenie, zanim na tym coś zaplanujesz: to jedzie w zmianie, która wciąż jest otwarta, a nie scalona, i przegląd już wyciął z niej monitorowanie błędów ethernet jako coś poza zakresem. Traktuj to jako łatkę, którą sam utrzymujesz, a nie jako poprawkę, na którą można czekać.
Pokaż sysDescr, jaki zgłasza każde z tych urządzeń. C300, C320, C620, C650 i C650E to nie jedna rodzina, jeśli chodzi o MIB optyczny, więc to, że OID odpowiada na części z nich, a na reszcie milczy, jest raczej normą niż usterką.
Wklej koniec walk z dwóch najbardziej różniących się urządzeń, C300 i jednego z C650, na OID-zie, który już sprawdzałeś. Jeśli jeden odpowiada, a drugi jest pusty, to cała historia i poprawka jest per platforma.
I trzymaj swoje dwa problemy osobno. Brakujące czujniki wentylatora i zasilacza to kwestia definicji wykrywania i nie mają nic wspólnego z tym, którą tabelę optyczną implementuje OLT.
Potwierdzam tę samą lukę z drugiej strony. Pytałem o tę samą rodzinę na 25.8.0-dev: GPON OLT C320, i chodziło mi o wykresy na portach GPON po obu stronach, na OLT i na ONU - poziomy mocy rx i tx, jak długo mierzy się każdy link, wykorzystanie na port - plus czy gdzieś już istnieje szablon dla tej rodziny.
Zamknięto to bez żadnych OID-ów, walk czy metody, więc jedyne, co to dokumentuje, to że pokrycie C320 od razu po instalacji jest częściowe. Po fakcie powinienem był dołączyć walk do zgłoszenia. Jeśli i tak to budujesz, poziomy optyczne ONU to część, której nikt jeszcze nie zrobił, a wielu z nas by z tego skorzystało.
To zgadza się z tym, co robi nasza flota. C300 odpowiada na .1.3.6.1.4.1.3902.1015.3.1.13.1 i nic nie zwraca na drugim OID-zie, C620 i C650 są odwrotnie, a C650E zachowuje się jak C650.
Wartości wracają jako liczby całkowite wymagające przeskalowania przez 0,001, dokładnie jak opisano. To, co na pierwszy rzut oka wyglądało na śmieci, teraz ma sens: 2147483647 na klatkach, których nigdy nie zapełniliśmy, i -80000 na dwóch portach, gdzie drugi koniec jest wyłączony. Obie wartości wartownicze są tu prawdziwe, więc każdy, kto napisze progi na surowych liczbach, dostanie bardzo hałaśliwą listę alertów.
Sprawdziłem też YAML platformy i u nas też brakuje klucza value:. Będę to utrzymywać lokalnie, skoro zmiana wciąż jest otwarta. To rozdzielenie dwóch problemów było tym, co miałem źle od samego początku.
Jedna rzecz, o której warto pamiętać przy budowaniu tego: dane DOM to wszędzie podzbiór, nie tylko na ZTE.
W SONiC EEPROM CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28 odczytuje się bez problemu, i TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR oraz TRANSCEIVER_STATUS wypełniają się identyfikacją plus temperaturą, napięciem, polaryzacją i mocą na lane, ale grupa sterowania i stanu po prostu nie istnieje: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode i get_power_override w widoku bazy danych nic nie zwracają, więc jeśli potrzebujesz tych bitów, musisz sam zapytać o nie API platformy.
Ta sama lekcja od strony firewalli. W PAN-OS show transceiver-detail all wypisuje blok diagnostyczny, a pierwsze pole do sprawdzenia to diagnostic-monitor. Jeśli mówi No, moduł nie implementuje cyfrowego monitoringu optycznego i każda wartość wraca jako N/A. Nic tam nie jest zepsute, po prostu nie ma czego czytać. Warto zakodować to rozróżnienie w swoim alertowaniu, żeby moduł bez DOM nie wyglądał tak samo jak martwy port.