LibreNMS discovery na Nokia 7705 wywala się z Column 'channels' cannot be null i nie zbiera DOM
Odpytujemy w LibreNMS kilka routerów agregacyjnych Nokia 7705 i chciałem z nich optyczny DOM z zwykłego powodu - żeby złapać słabnący odcinek, zanim zauważy go klient. Discovery na tych urządzeniach nigdy się nie kończy.
- Nokia 7705 z TiMOS
- LibreNMS 26.3.1
- zwykłe jednokanałowe SFP 1G w portach, różni producenci, część z nich stara
- SNMP poza tym zdrowy: interfejsy, CPU, pamięć i ruch odpytują się bez problemu
Discovery zatrzymuje się za każdym razem tutaj:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be nulla wynikiem jest brak wpisów transceiverów i brak czujników optycznych dla całego routera - nie jeden zły port przy reszcie działającej, całe urządzenie wraca puste.
Co już sprawdziłem:
- ponownie uruchomiłem discovery dla samego tego urządzenia, ten sam błąd w tym samym miejscu
- usunąłem i dodałem urządzenie na nowo: tworzy się, a potem discovery wywala się w tym samym miejscu
- inni producenci w tej samej instalacji odkrywają transceivery i DOM normalnie, więc nie wygląda to na zepsutą bazę po mojej stronie
Czy to znany problem discovery z TiMOS i czy da się coś z tym zrobić, poza wyłączeniem discovery transceiverów dla tych routerów?
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 3
Znany, i to nie twoja baza.
Kod discovery TiMOS pobiera liczbę kanałów z TIMETRA-PORT-MIB::tmnxPortSFPNumLanes i wrzuca to, co dostanie, prosto do kolumny
channels, która nie przyjmuje NULL. Zwykli winowajcy to starsze jednokanałowe optyki: agent nigdy nie wypełnia dla nich tego obiektu, więc port oddaje do insertu null, insert się wywala, a awaria ściąga za sobą całe discovery transceiverów tego urządzenia. Dlatego tracisz każdy port, a nie tylko ten z nietypowym modułem.Dwa wyjścia. Najczystsze to przejść na nowszy LibreNMS - zaakceptowana upstream zmiana zabezpiecza tę wartość w LibreNMS/OS/Timos.php, tak że brakująca lub pusta liczba kanałów jest czytana jako jeden kanał, a wszystko inne wymuszane na integer. Jeśli tkwisz na obecnym release, wstaw to samo zabezpieczenie do tego pliku ręcznie; to kilka linii, choć zniknie przy następnej aktualizacji, jeśli o nim zapomnisz.
Zanim cokolwiek załatasz, przejdź po TIMETRA-PORT-MIB::tmnxPortSFPNumLanes na routerze. Porty, które odpowiadają pustką, to te zabijające insert, i warto wiedzieć, jakie optyki w nich siedzą.
Potwierdzone w obu punktach, dzięki.
Przechodząc po tym OID: porty z najstarszymi optykami 1G nie zwracają w ogóle nic dla liczby kanałów, wszystko nowsze odpowiada 1. Więc null bierze się z modułów, które odziedziczyłem, dokładnie jak opisano.
Po przejściu na build z tym zabezpieczeniem discovery przechodzi do końca na wszystkich 7705, transceivery pojawiają się z jednym kanałem każdy, a czujniki optyczne są rysowane na wykresach. Żadnych zmian po stronie routera, żaden port nie jest wykluczony.
Dwie rzeczy, których można się spodziewać teraz, gdy discovery się kończy.
DDM na sprzęcie Nokii jest bramkowany flagą capability w EEPROM modułu. To podejście firmowe w całej rodzinie sprzętu i najjaśniej opisane jest w 7210 SAS interface guide: platforma bez problemu wypisze diagnostykę dla modułu, który nigdy nie ustawia tej flagi, mówiąc w tym samym akapicie, że nie zweryfikowała ani nie sprawdziła tych liczb. Inne urządzenie niż twoje, ta sama logika - wiarygodnie wyglądające liczby RX/TX z optyka trzeciej firmy to nie dowód, że kalibracja jest poprawna.
Druga połowa to sam moduł. GLC-SX-MM nie ma strony A2h, więc nie ma czego odczytać żadnemu pollerowi; GLC-SX-MMD ma, a D to właśnie diagnostyka. Jeden wykres na stałe płaski i pusty, sprawdź to, zanim zaczniesz podejrzewać pollera.