Adapter QSA w klatce QSFP28 SONiC: optyka 10G linkuje, ale nie zgłasza DDM
Ponownie wykorzystujemy stertę optyki 10G na switchu whitebox z SONiC, więc kilka klatek QSFP28 jest wyposażonych w adaptery w stylu QSA (10GTek QSA-100A) niosące zwykłe moduły 10G SFP+. Mechanicznie i elektrycznie jest w porządku. Strona zarządzania to miejsce, gdzie się rozpada.
- switch: 1U whitebox, SONiC zbudowany pod tę platformę
- adaptery: 10GTek QSA-100A, klatka QSFP28 na SFP+
- optyka: moduły 10G SFP+ wyjęte z wycofanego switcha dostępowego
- ta sama optyka czyta się normalnie w natywnej klatce SFP+ na innym boxie
Co widzę na zaadaptowanych portach:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portCo już próbowałem:
- wymieniłem na drugi adapter i drugą optykę, identyczne zachowanie;
- przełożyłem parę do innej klatki QSFP28, ten sam wynik;
- potwierdziłem, że ta optyka zgłasza pełną diagnostykę w natywnym porcie SFP+ gdzie indziej.
Czy brakujące dane diagnostyczne to coś, czego pasywny adapter po prostu nie może przenieść, czy to leży po stronie software'u switcha? A jeśli to software, to gdzie należy poprawka: warstwa platformy czy generyczny kod transceivera?
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 7
Zanim ktokolwiek zacznie kopać w kodzie platformy, jedno pytanie, które dzieli to na pół. Wsadź natywny moduł QSFP28 do tej samej klatki: dostajesz z niego diagnostykę, czy DDM jest martwe na tym porcie bez względu na to, co wsadzisz?
Jeśli natywna część czyta się dobrze, klatka i ścieżka I2C są zdrowe, a cała sprawa sprowadza się do tego, jak sterownik portu interpretuje to, co przychodzi przez adapter. Jeśli natywna część też wraca pusta, przestań czytać resztę wątku, masz inną usterkę i nie ma ona nic wspólnego z adapterami.
Dobrze znana i dość nudna różnica w interfejsie zarządzania, i to nie adapter jest tu winowajcą.
Po stronie SFP w grze są dwa adresy I2C: dane identyfikacyjne mieszkają pod 0x50, mapa diagnostyki pod 0x51. Część QSFP trzyma to wszystko pod 0x50 i sięga po resztę, przełączając strony. Więc sterownik, któremu powiedziano, że klatka to QSFP, poluje na strony pod jednym adresem i nigdy o nic nie pyta 0x51. Identyfikacja wraca wystarczająco wiarygodna, żeby port wstał, diagnostyka po prostu nigdy się nie rozstrzyga, co dokładnie odpowiada kształtowi tego, co wkleiłeś.
Poprawka należy do warstwy platformy, nie do optyki i nie do adaptera. Każda platforma wysyła własną implementację SfpUtil; w twojej ten port musi zostać zadeklarowany jako klatka SFP zamiast QSFP. Dopóki ktoś tego nie zrobi, DDM/DOM na zaadaptowanych portach zostaje puste. Potem moduł jest czytany tak, jak byłby w natywnej klatce SFP+.
Żywy link z niczym za nim w diagnostyce to właśnie tak wygląda złe oprogramowanie na tych portach. To nie tak wygląda słaba optyka.
Warto nazwać standardy, bo wtedy podział jest oczywisty. Strona SFP to SFF-8472, gdzie diagnostyka mieszka we własnej mapie pamięci, osiąganej pod drugim adresem. QSFP i QSFP28 idą za SFF-8636, a nowsze części za CMIS, gdzie wszystko wisi pod jednym adresem za wyborem strony.
Adapter nie może tego pomostować. To pasywna część mechaniczna i elektryczna, przewody zarządzania biegną przez nią na wprost i nic ich po drodze nie tłumaczy. Więc host musi zostać poinformowany, który z dwóch modeli pamięci obowiązuje, zanim przeczyta choć jeden bajt, a adapter nie ma jak mu to powiedzieć.
Dla kontrastu, ta sama klasa problemu na sprzęcie Dell ONIE gryzie mocniej. QSA 407-BBRO z SFP+ 10GBASE-SR 407-BBOU w środku (SFP-10GSR-85), w portach 40G S4048-ON i w dowolnym porcie S6010-ON, oba na OpenSwitch OPX 3.1 dev2:
opx-ethtool poprawnie identyfikuje medium, oznacza transceiver jako enabled i qualified, admin state up, wspierane prędkości 1000, 10000 i 40000 Mbps, a port i tak nigdy nie wstaje, niezależnie od tego, jaka prędkość, duplex czy autoneg są skonfigurowane, domyślne wartości włącznie. Ktoś otworzył to w repozytorium OPX platform-config jako enhancement request, sprawcie żeby QSA tu działało, i nikt nigdy nie odpowiedział. Wciąż tam siedzi otwarte.
To nie blokada producenta i nie zła optyka. Ta klatka po prostu nigdy nie zostaje przełączona w tryb adaptera przez system sieciowy, i żadna kombinacja ustawień interfejsu tego za ciebie nie zrobi.
Pokrewne, ale proszę nie zlewać tych dwóch przypadków w jedno. To, co jest w oryginalnym poście, to działający link z brakującą diagnostyką: ścieżka danych jest w porządku, tylko odczyt zarządzania jest zły, a załatanie platformowego SfpUtil to naprawia. Przypadek Dell to port, który w ogóle nigdy nie wstaje, bo profil portu dla tej klatki nigdy nie jest w pierwszej kolejności zaaplikowany. To siedzi jedną warstwę niżej i potrzebuje własnej poprawki.
Ktoś dopasowujący objawy w pośpiechu mógłby spalić dzień na przepisywaniu kodu transceivera, podczas gdy jego port jest down z zupełnie niezwiązanego powodu.
Kolejny wariant "adapter to funkcja software'owa", a nie mechaniczna. Na Z9264F-ON pod OS10 10.5.2.7 użycie adapterów QSA28 dla medium 10G SFP+ oznacza wstawienie portu do tego samego profilu port-group, którego używa kabel breakout 4x10G:
Profile port-group na tej platformie działają na parach portów QSFP28, więc zaaplikowanie go wyłącza port partnerski każdej pary. QSA28 to pojedynczy interfejs, a mimo to płacisz cenę w kształcie breakout: 64 użyteczne porty stają się 32. Ani przewodniki użytkownika OS10, ani karta specyfikacji optyki Dell nie dokumentują trybu QSA na pojedynczym porcie.
Jeśli potrzebujesz dużo natywnego 10G na tym boxie, zaplanuj z góry stratę 2:1 albo wstaw do szafy osobny switch 10G.
Zanim ktokolwiek zamówi tacę tych rzeczy, dodałbym dwa sprawdzenia do listy. Czy system sieciowy w ogóle deklaruje wsparcie QSA dla dokładnie tej platformy, a jeśli tak, ile kosztuje jego włączenie: porty, diagnostykę, czy profil, który ciągnie w dół sąsiednią klatkę razem ze sobą. Dopasowanie fizyczne nigdy nie jest problemem, każdy z tych adapterów wchodzi w klatkę bez sprzeciwu.
Przypadki w tym wątku różnią się tylko tym, jak daleko idzie software. Na SONiC dostajesz coś, co możesz naprawić sam, zadeklarować port jako SFP, i diagnostyka wraca. Na platformach Dell powyżej czekasz na cudzy kod platformy, a wymiana adapterów czy optyki w ogóle tego nie ruszy.