NAPALM get_optics na nxos_ssh zwraca tylko DOM lane 1 dla modułów QSFP-100G-CWDM4
Podłączam telemetrię optyczną per port do monitoringu dla pary fabrics Nexus 9000. Zbieranie idzie przez NAPALM, a getterem, na którym się opieram, jest get_optics().
- pary leaf i spine Nexus 9000
- moduły QSFP-100G-CWDM4 na linkach fabric
- NAPALM ze sterownikiem nxos_ssh, transport SSH, NX-API jeszcze nie włączone
Na module 100G z czterema lane getter oddaje dokładnie jeden kanał:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}Sam switch wyraźnie ma te dane - show interface transceiver details wypisuje Rx power, Tx power i bias current dla wszystkich czterech lane - więc to wygląda na parser, nie na platformę.
Co sprawdziłem:
- ten sam wynik na każdym porcie QSFP-100G-CWDM4, jaki odpytuję, więc to nie jeden dziwny moduł
- porty SFP+ wracają poprawnie, co ma sens, gdy jest tylko jeden lane do zaraportowania
- przeczytałem parsowanie optyki w sterowniku i wygląda na to, że zawsze łapany jest tylko pierwszy blok DOM
Czy ktoś faktycznie zbiera DOM per lane przez NAPALM na NX-OS, czy wszyscy kończą na własnoręcznym zeskrobywaniu wyjścia ze switcha?
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
Która dokładnie wersja NAPALM, i na jakim train NX-OS stoją te leafy? Kod optyki w nxos_ssh był przerabiany więcej niż raz, a wyjście transceivera na switchu też nie jest sformatowane identycznie między train'ami, więc obie połówki mają znaczenie, zanim ktokolwiek nazwie to bugiem.
Jedna rzecz warta zrobienia, zanim usiądziesz do pisania własnego parsera: wywołaj get_optics() na jednym z portów SFP+ i zestaw tę strukturę obok CWDM4. Jeśli obie wracają z tym samym szkieletem i różnią się tylko wartości, sterownik dobrze przechodzi przez tekst i po prostu poddaje się po pierwszym pasującym bloku. Jeśli są ukształtowane inaczej, w ogóle nigdy nie dociera do sekcji per lane na portach QSFP. To dwie różne naprawy, a wyjście SFP+ to najtańszy sposób, żeby je rozróżnić.
Aktualne wydanie z PyPI na obu kolektorach, a leafy i spine'y stoją na tym samym train NX-OS, więc dostaję to samo, gdziekolwiek to skieruję - nie jedna dziwna skrzynka.
Zrobiłem porównanie SFP+, o które prosiłeś. Ten sam szkielet w obu przypadkach: physical_channels.channel z pojedynczym elementem przy index 0, wszystkie trzy wartości wypełnione. Dobra odpowiedź dla modułu jednolane'owego, zła dla CWDM4. Więc parser nie zawodzi w znajdowaniu części per lane wyjścia, on dopasowuje blok, wypełnia go i na tym się zatrzymuje. Dokładnie tak to wyglądało, kiedy przeczytałem kod, chciałem tylko, żeby ktoś potwierdził, że dobrze to czytam.
To luka w sterowniku, a nie coś po twojej stronie. Jest otwarty pull request do nxos_ssh, który przepisuje parsowanie optyki: każdy lane wraca jako własny element pod physical_channels.channel zamiast zatrzymywania się na index 0, a każdy element niesie własny poziom Rx, poziom Tx i laser bias current. Fixtures dołączone do niego są zbudowane na czterolane'owym QSFP-100G-CWDM4, więc było to pisane pod dokładnie twój moduł. Uruchamiałem to tylko na skrzynce laboratoryjnej, więc traktuj to jako coś do wypróbowania, a nie rekomendację dla kolektora produkcyjnego.
Dopóki to nie wyląduje w wydaniu, które można zainstalować, pragmatyczną drogą jest pominąć getter dla portów 100G i samodzielnie sparsować
show interface transceiver details, a potem wepchnąć każdy lane do monitoringu jako własną serię. Trochę więcej kodu na głowie, ale przestajesz wyrzucać trzy czwarte sygnału.Niezależnie od tego, którą drogą pójdziesz, alarmuj per lane. Jeden zdegradowany lane na CWDM4 pociągnie w dół cały link, nigdy się nie pokazując, jeśli patrzysz wyłącznie na lane 1.
Widoczność per lane ma na Nexusie większe znaczenie, niż ludzie się spodziewają.
Trafiliśmy na defekt Cloud Scale na Nexus 9000 z QSFP-100G-SR4-S rozbitym na 4x25G. Potrzebny był tylko jeden z czterech portów 25G, pozostałe trzy zostały zamknięte, a ten, na którym nam zależało, nigdy się nie łączył. Wyciągnęło nas z tego postawienie najpierw całej grupy -
no shutdownna każdym z czterech subinterfejsów - pozwolenie, żeby lane 1 się ustabilizował, a potem ponowne zamknięcie trzech zapasowych. Trzymaj też identyczny FEC w całej grupie, kiedy już tam jesteś; dziwne ustawienie na jednym lane nie zostaje grzecznie tylko na tym lane.Chodzi o to, że mając w dashboardach tylko lane 1, jesteś ślepy na większość tego, co robi port 100G. Dodatkowe parsowanie warto mieć na swojej głowie.