Edgecore AS5114-48X na dentOS: SFP+ w porcie 18 enumeruje się poprawnie, ale onlpdump wciąż pokazuje RX_LOS

RX_LOS samo w sobie mówi tylko, że odbiornik nie widzi wystarczająco dużo światła, więc zanim obwinisz box: co zgłasza druga strona? Jeśli port peera udostępnia DDM, odczytaj jego moc Tx i potwierdź, że laser faktycznie się pali i port nie jest shut. Warto też wiedzieć, czy obie strony to ten sam typ optyki i ten sam tryb światłowodu - moduł short reach naprzeciw long reach albo zły światłowód wygląda dokładnie tak samo.

I próbowałeś drugiego modułu o innym part number w porcie 18, czy tylko ten jeden przekładany między portami?

Druga strona to port 10G na innym switchu, ta sama optyka short reach po obu stronach. Ten port linkuje bez problemu z innym modułem przez dokładnie ten sam patchcord, więc laser peera żyje, a trasa światłowodowa jest dobra od końca do końca. Port 18 jest admin up, i dostaję identyczny wynik z odwróconym sznurem.

Irytująca część to to, co mogę zaobserwować lokalnie: onlpdump daje mi obecność plus bitmaskę statusu, i to wszystko. Nie mam po stronie dentOS żadnej liczby Rx, żeby porównać ją z drugą stroną, więc utknąłem na "coś nie odbiera" bez wiedzy, po której to jest stronie.

Od symptomu do przyczyny, w kolejności, w jakiej bym to prowadził. Detekcja dowodzi tylko ścieżki I2C/EEPROM i hydrauliki MAC, nic więcej. Linia kernela o inband/10gbase-r to host konfigurujący samego siebie - nie znaczy, że dotarł choć jeden foton. Przy ustawionym RX_LOS zostają trzy podejrzani: ciemny albo skrzyżowany światłowód, druga strona, która nie nadaje, i odbiornik, który nie działa na tej platformie.

Pierwsze dwa już mocno przepchnąłeś, więc przestań zbierać bity i zdobądź liczbę. Wystarczy dowolny switch, który drukuje diagnostykę cyfrową. Na EXOS to show ports <port> transceiver information, co daje temperaturę, napięcie zasilania, prąd polaryzacji lasera, moc Tx i Rx i oznacza każdą wartość poza progami modułu, a debug hal show optic port <port> dorzuca vendora, part number, numer seryjny, złącze i długość fali z EEPROM. Goniłem tak martwy port 10G na X460-G2-24x-10G4 i znalazłem mniej więcej -26,78 dBm na odbiorniku, na co żaden odbiornik 10G short ani long reach się nie zsynchronizuje.

Jeśli druga strona potrafi dać ci odczyt Rx, podczas gdy twój moduł nadaje, przynajmniej dowiesz się, czy jej laser działa. To, co zostaje potem, to platforma nienapędzająca akurat tej części.

Tu ten sam box, a na tej platformie wsparcie modułów jest per część, nie per standard. Na naszym AS5114-48X Avago AFBR-703SDZ-IN2 rev G2.3 wstaje bez żadnego strojenia - platforma zgłasza go jako Intel Corp z numerem seryjnym AA1329A5UTA, co na pierwszy rzut oka myli ludzi.

Dwie części nigdy u nas nie zadziałały w tym samym switchu na tym samym światłowodzie: Intel FTLX8571D3BCV-IT rev A, który masz ty, i OPNEXT TRS5020EN-S301. Obie były wykrywane, obie siedziały dokładnie jak twój port 18. Pożycz sprawdzoną część, zanim spędzisz kolejny wieczór nad instalacją światłowodową.

Warto być precyzyjnym co do tego bitu: RX_LOS to własne wyjście loss-of-signal modułu, zdefiniowane w SFF-8472, a warstwa platformy po prostu wystawia je jako status 0x00000004. Ustawia się poniżej progu LOS odbiornika, więc mówi ci "za mało światła" i nigdy dlaczego. Dlatego też idealnie czysty odczyt EEPROM i martwa ścieżka optyczna współistnieją bez sprzeczności.

Drugi powód, żeby upierać się przy prawdziwej liczbie Rx: tłumienie z poziomu CLI wygląda identycznie jak niekompatybilność. Kolega miał port Zyxela siedzący koło -25,69 dBm, a naprawą był patchcord plus panel krosowy, który ktoś wcześniej sknocił, nie moduł. Jeśli nie możesz odczytać DDM po stronie dentOS, odczytaj to z drugiej strony albo z hosta - sama bitmaska tego nie rozstrzygnie.