TL-SG3428X-M2 (V1): gniazdo SFP+ 26 nie daje linku z żadnym TL-SM5310-T, gniazdo 27 migocze przy nim
Zajmuję się małą siecią biurową, jedna szafka ze switchem, a cztery gniazda SFP+ w naszym switchu dostępowym niosą łącza 10G do szafy serwerowej. Działało miesiącami bez żadnej uwagi, a teraz jedno gniazdo po prostu przestało istnieć.
- TP-Link TL-SG3428X-M2 (V1), firmware 1.20.4 Build 20241104 Rel.40746, zaadoptowany w Omada
- cztery moduły TP-Link TL-SM5310-T 10GBASE-T w portach SFP+ 25-28
- patchcordy CAT6A, drugie końce to dwa serwery i NAS
Stan portów w tej chwili:
port 25 up, 10G
port 26 down, no link LED with any module
port 27 up, 10G, but drops for a moment whenever a cable goes into or out of port 26
port 28 up, 10GCo już sprawdziłem:
- przełożyłem moduły przez wszystkie cztery gniazda: moduł z 26 działa bez zarzutu w 25 i 28, a każdy moduł wsadzony do 26 zostaje martwy, więc same moduły są sprawne
- nowe patchcordy, inne porty po drugiej stronie, bez zmian
- restart switcha, wyłączenie i włączenie portu, bez zmian
Czego nie umiem wytłumaczyć, to drganie portu 27, kiedy dotykam wyłącznie portu 26. Czy gniazdo 26 jest martwe i warto zgłaszać RMA, czy jest jeszcze coś do wykluczenia najpierw?
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 6
To regresja firmware w 1.20.4 Build 20241104, nie martwy sprzęt. Wzorzec, który opisujesz - jedno gniazdo SFP+, które nigdy się nie zapala ze sprawdzonymi modułami, plus sąsiad, który migocze, gdy ruszasz to martwe - to właśnie robi ten build z miedzianymi modułami TL-SM5310-T.
Cofnij switcha do poprzedniego wydania i porty wracają. W praktyce:
Ludzie z TP-Link sami przyznali, że w tym wydaniu coś jest nie tak na switchach Omada zaadaptowanych pod kontroler v5.14, powiedzieli, że sprawa jest badana, i doradzili na razie zostać przy starszym firmware. Więc nie marnuj zgłoszenia serwisowego na sprzęt, wykorzystaj je na numer builda.
Jeśli naprawdę nie możesz zrobić downgrade'u, jedynym obejściem jest życie na trzech gniazdach, które wciąż działają, i trzymanie portu 26 pustego. To nie jest naprawa, tylko sposób na utrzymanie ruchu do czasu pojawienia się poprawionego wydania.
Zanim wypełnisz formularz RMA: kiedy to się zaczęło i czy switch odebrał w tym samym czasie aktualizację firmware? 1.20.4 Build 20241104 jest dość świeży, a kontroler chętnie sam wypchnie nowy obraz, jeśli automatyczne aktualizacje zostały włączone.
Warto też ustalić: port 27 drga tylko wtedy, gdy w 26 siedzi moduł, czy też przy pustym 26? Martwe gniazdo zwykle nie sprawia, że sąsiad się gubi. To bardziej pachnie oprogramowaniem stojącym za portami niż pękniętym lutem.
Ten sam switch, ten sam build, więc nie jesteś sam. Port 25 działał bez zarzutu, port 26 nie dawał diody linku z żadnym moim modułem, a 27 i 28 to wracały, to znikały - jeden z nich zasila EAP783, więc każdy spadek był bardzo widoczny. Przeszedłem dokładnie ten sam rytuał przekładania modułów i sam siebie przekonałem, że gniazdo jest martwe.
To nie było gniazdo. Urządzenie dostało aktualizację firmware tuż przed początkiem problemów, a powrót do poprzedniego obrazu przywrócił wszystkie cztery porty SFP+. Sprawdź historię aktualizacji, zanim cokolwiek gdziekolwiek wyślesz.
Potwierdzam, i wstyd powiedzieć, jak blisko byłem wysłania switcha do serwisu. Historia aktualizacji pokazuje, że 1.20.4 Build 20241104 wylądował kilka dni przed tym, jak porty zaczęły dziwaczeć, a ja nigdy nie uruchamiałem tego ręcznie, więc przyszło samo.
Cofnąłem do poprzedniego wydania, zaadoptowałem ponownie i wszystkie cztery gniazda stoją na 10G, łącznie z portem 26. Port 27 już nie drga, kiedy pracuję przy 26. Automatyczne aktualizacje są teraz wyłączone, a stary obraz leży na serwerze plików obok kopii zapasowej konfiguracji.
Do archiwum: ta sama rodzina ma jeszcze jedną pułapkę firmware, o której warto wiedzieć. Na TL-SX3008F (V1) z SM5310-T(UN) zasilającym stację roboczą, firmware 1.20.2 i 1.20.3 zostawiały port SFP+ martwy, gdy tylko PC szedł spać albo był wyłączany. Przeniesienie modułu do wolnego gniazda działało dokładnie raz na gniazdo, a gdy wszystkie gniazda zostały już wykorzystane, tylko restart switcha przywracał porty. Przypięcie portu na sztywno do 1G omijało problem, kosztem prędkości, za którą zapłaciłeś.
Inny właściciel trafił na to samo z modułami RJ45 od 10Gtek (ASF-10G2-T), Wiitek i Xicom za adapterem Iocrest AQC113. Downgrade do 1.20.0 Build 20231011 Rel.42220 rozwiązał sprawę u nas obu. Inny objaw, ta sama lekcja: to właśnie w obsłudze miedzianych SFP+ w tych buildach siedzą błędy.
Miej z tyłu głowy jeszcze jedno przy tej linii switchy: bezczynny moduł może kosztować więcej niż port. Na TL-SX3016F z 1.0.0 Build 20210730 Rel.65115 CPU siedziało na 87-89% bez żadnego ruchu i co trzy minuty wrzucało do logu linię CPU RISING THRESHOLD.
Obciążenie szło w parze z liczbą włożonych modułów - jeden moduł 0-1%, dwa 73-76%, trzy lub więcej 88-90% - a sprowadzało się do modułów Mellanox MFM1T02A-SR z podłączonym światłowodem, przy których po drugiej stronie nic się nie świeciło, więc link stał martwy. Zamiana ich na Ubiquiti UF-MM-10G trzymała CPU nisko niezależnie od tego, co działo się na porcie, a samo wyciągnięcie nieużywanych modułów też leczyło sprawę. Odpowiedź samego TP-Link brzmiała, że moduł siedzący tam z martwym linkiem po prostu dużo kosztuje chipset, i że obciążenie wraca do normy, gdy tylko port dostanie porządny link. To zostawia niewyjaśnioną niewygodną połowę: zmień markę, zostaw moduł równie bezczynny, a CPU siedzi cicho. Więc gdy już wrócisz na starszy firmware, zerknij też na wykres CPU.