ConnectX-4 MCX456A-ECAT nie łączy się z Cisco NCS na 100GBASE-LR4, mimo że loopback przechodzi po obu stronach
Prowadzimy parę szaf, które oddają ruch do Cisco NCS zwróconego w stronę operatora, i jeden ze 100G uplinków serwerowych nigdy nie wstał od czasu budowy. Ten sam wynik po przeniesieniu serwera do innej szafy z innym panelem krosowym, więc przestałem traktować to jako jednorazowy przypadek.
- serwer Supermicro, NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT, oba porty wolne
- generyczny QSFP28 100GBASE-LR4, single mode, zasięg 10 km, po jednym na każdym końcu
- Cisco NCS po drugiej stronie, ciemne włókno między dwoma pomieszczeniami
Część, przez którą utknąłem: każdy moduł przechodzi loopback na swoim własnym urządzeniu. Gdy włókno jest spięte z powrotem prosto w ten sam QSFP28, karta sieciowa zgłasza czysty link 100G, i NCS robi to samo po swojej stronie. Wstaw prawdziwy odcinek między nimi i nie ma nic.
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: noCo już sprawdziliśmy:
- podmieniliśmy oba moduły na zapasowe z tej samej partii, bez zmian
- przenieśliśmy serwer i przepięliśmy przez inny panel
- otworzyliśmy zgłoszenie u producenta karty sieciowej, a odpowiedzią było wskazanie na listę zwalidowanych transceiverów w release notes firmware, co nie tłumaczy, czemu loopback działa
Czy jest coś w LR4 na ConnectX-4, co pozwoliłoby mu łączyć się lokalnie, ale nigdy przez prawdziwy odcinek, czy gonię nie ten koniec sprawy?
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
To brzmi jak zabrudzona trasa, nie problem z kompatybilnością.
Wszystko, co dotąd wymieniłeś, siedzi po stronie, która już testowała się dobrze, dlatego nic się nie zmieniło - sam odcinek to jedyna rzecz wciąż nietknięta. Więc zajmij się trasą:
Lista zwalidowanych transceiverów, na którą cię skierowano, warta jest rzutu okiem, ale moduł, który czysto wstaje w loopback, jest już poprawnie sterowany przez kartę sieciową. Listy kompatybilności tłumaczą moduły, które są odrzucane od razu, nie moduły, które łączą się lokalnie, a umierają na odcinku.
Jeśli czyszczenie nie pomoże, następny krok to źródło światła i miernik mocy na ciemnym włóknie, albo OTDR, jeśli uda się jakiś pożyczyć, zanim kupisz kolejną kartę sieciową albo kolejną parę optyki.
Loopback dowodzi tylko, że jeden port słyszy sam siebie - laser, odbiornik, ustawienia prędkości. Nic nie mówi o szkle między waszymi dwoma pomieszczeniami, a to jedyny element, którego jeszcze nie przetestowałeś. Więc zanim znowu obwinisz kartę sieciową, zbierz liczby z obu końców z wpiętym prawdziwym odcinkiem: jaka jest moc Rx na porcie NCS, a jaka na karcie? Rx poniżej progu Low Warn ze wstawionym odcinkiem to klasyczna wskazówka wskazująca na daleki koniec albo trasę, a nie na lokalny port. Po stronie Linuksa
ethtool -mpowinno dać ten sam odczyt, a jeśli zwróciCannot get module EEPROM information: Input/output error, nie czytaj tego jako martwy moduł - na mlx5 to zwykle dostęp do modułu po stronie firmware, amst start,mst cable add, a potemmlxcablesi tak dadzą ci te wartości.Czyszczenie było odpowiedzią. Przyłożyliśmy skop do czół złączy i oba moduły plus oba patchcordy były zabrudzone; kabel przechodzący przez panel międzypokojowy był gorszy z tych dwóch. Wyczyściliśmy wszystko na trasie, osadziliśmy ponownie, i link 100G do NCS wstał za pierwszym razem i trzyma się od tamtej pory.
Trochę zły na siebie, że spędziłem tyle czasu na wątku kompatybilności, skoro wynik loopback przez cały czas mówił mi, że moduły są w porządku, a trasa nie. Dla każdego, kto trafi tu później: loopback dowodzi portu, nie włókna.