Edgecore AS9716-32D: sfputil odczytuje moduł 400G QSFP-DD jako QSFP28 pod PDDF
Stawiamy w laborce parę AS9716-32D jako 400G spine, na community'owym obrazie SONiC z warstwą platformową PDDF. Optyka nie jest problemem, druga strona linkuje bez zarzutu, ale wszystko, co switch o niej mówi, jest błędne.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- community'owy build SONiC z PDDF dla tej platformy
- moduł 400G QSFP-DD (część NeoPhotonics) w pierwszym gnieździe
Sam odczyt się udaje, moduł jest widoczny na liście, a gniazdo zgłaszane jest jako QSFP28:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsTa linia z identyfikatorem to miejsce, gdzie wszystko się sypie. To jest część QSFP-DD, więc bajty poniżej są odczytywane według zestawu pól SFF-8636 zamiast CMIS, a pola, które następują, wyglądają jak szum.
Sprawdzone do tej pory:
- sam moduł jest sprawny, ta sama część czyta się poprawnie na innej platformie, a druga strona widzi światło;
- wyjęcie i włożenie ponownie oraz przełożenie do innego gniazda nic nie zmienia, wszystkie porty 400G zachowują się identycznie;
- w opisie urządzenia PDDF te gniazda są zadeklarowane jako QSFP28 i powiązane z optoe1.
Czy to ostatnie to cała odpowiedź, czy gniazda QSFP-DD po prostu potrzebują innego urządzenia optoe, i czy edycja opisu platformy to przyjęty sposób naprawy, czy coś wyżej też musi się nauczyć typu gniazda?
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
Twój objaw pasuje dokładnie do powiązania (binding), więc nie ma co dalej szukać w optyce.
Opis urządzenia PDDF dla AS9716-32D deklaruje gniazda 400G jako QSFP28 i wiąże je z optoe1. optoe1 udostępnia układ EEPROM SFF-8636, którego używają QSFP+ i QSFP28, więc moduł CMIS jest czytany przez złą mapę i wszystko za identyfikatorem wygląda jak szum. Typ portu, który widzisz, wcale nie jest wykrywany, to po prostu to, co mówi opis.
QSFP-DD trzyma się CMIS, a CMIS jest obsługiwany przez optoe3. Naprawa to zmiana obu pól w opisie urządzenia PDDF dla tych gniazd: typu z QSFP28 na QSFP-DD i sterownika z optoe1 na optoe3. Zweryfikowałem to na tym samym urządzeniu z częścią 400G NeoPhotonics i po zmianie
sfputil show eepromzwraca moduł poprawnie zdekodowany.Dwa zastrzeżenia. To dane platformowe, więc aktualizacja obrazu chętnie przywróci stary opis, jeśli zmiana nie siedzi w obrazie, który budujesz. I upstream dokładnie ta zmiana została zaakceptowana, ale pull request zamknięto bez mergowania, bo pracę wchłonęła późniejsza zmiana, więc nie zakładaj, że twój obraz już to ma. Najpierw przeczytaj opis urządzenia dla swojej platformy, a w minutę będziesz wiedział, czy w ogóle masz czego szukać.
Zanim dotkniesz jakiegokolwiek pliku platformy, wklej surowy zrzut:
sudo sfputil show eeprom -dna tym porcie. Jeśli wszystkie bajty są na miejscu i tylko interpretacja szwankuje, to problem powiązania, nie modułu, i to rozróżnienie warte jest dziesięciu minut, zanim ktokolwiek zacznie mówić o RMA.Drugą połowę już sam sobie odpowiedziałeś. optoe1 to odmiana SFF-8636 używana przez QSFP+ i QSFP28, więc moduł CMIS czytany przez nią wychodzi pokiereszowany od identyfikatora w dół, co dokładnie widać w wklejonym przez ciebie wyniku. Skoro opis nazywa optoe1 dla gniazda QSFP-DD, po stronie modułu nie ma już czego podejrzewać.
Wklej więc też odpowiednie linie opisu urządzenia PDDF dla jednego z tych gniazd. To pokaże, czy błędne jest tylko pole sterownika, czy też zadeklarowany typ gniazda.
To było to. Typ gniazda na QSFP-DD, sterownik na optoe3, reload i moduł dekoduje się teraz poprawnie,
sfputil show eepromjuż nie nazywa gniazda QSFP28. Zmianę umieściłem w obrazie, który budujemy, a nie łatając działający switch, właśnie z powodu tej kwestii z aktualizacją wyżej.Jedna szczera uwaga dla każdego, kto to znajdzie później: to naprawia sposób odczytu EEPROM, nic więcej. Reszta hydrauliki transceiverów na tej platformie wciąż ma swoje dziwactwa i nie nazwałbym tego urządzenia w pełni ogarniętym.
Skoro wspominasz o pozostałych dziwactwach, oto to, które czeka na ciebie na tej samej platformie. Na naszym AS9716-32D (x86_64-accton_as9716_32d-r0) na buildzie master SONiC,
sudo sfputil show presencepokazuje zajęte porty jako Present i bez problemu czyta ich EEPROM, podczas gdyshow interfaces transceiver presencezgłasza każdy port jako Not present. Syslog powtarza:a odczyt EEPROM przez CLI kończy się RuntimeError('PddfEeprom is not Programmed'). Pojawia się losowo po restarcie i nikt nigdy nie opublikował przyczyny źródłowej, więc sfputil zostaje tam jedynym sprawdzeniem obecności, któremu ufam.
Bez związku, ale w tym samym obszarze: te dwie komendy są też znane z tego, że nie zgadzają się co do nazw kluczy w gałęzi 202012, co zostało posprzątane w 202205. Jeśli twoje wyniki różnią się słownictwem, a nie treścią, to prawdopodobnie tylko tyle.