Supermicro E300-9A na pfSense Plus 22.05: ix2 i ix3 wiszą na no carrier z DAC-iem, który normalnie łapie link na USW-Aggregation
Mój firewall to Supermicro E300-9A na pfSense Plus 22.05, i oba porty 10G SFP+ odmawiają wstania. Ani ix2, ani ix3 nigdy nie pokazuje carrier, cokolwiek wsadzę do gniazda.
Sprzęt:
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M i pasywny kabel twinax 10Gtek
- moduły światłowodowe Supermicro AXS85-192-M3 jako alternatywa
- Ubiquiti USW-Aggregation po stronie switcha
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 wygląda tak samo.
Sprawdzone do tej pory:
- oba kable działają na USW-Aggregation między innymi urządzeniami, więc nie są martwe
- zamieniłem miedź na moduły światłowodowe AXS85-192-M3, to samo no carrier na obu portach
- restartowałem urządzenie kilka razy, w tym wkładałem moduł, gdy działało
Czy jest w tym pudełku coś, co trzeba kopnąć, zanim gniazda zaczną działać, czy patrzę na dwa martwe porty?
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
Ciepłe restarty donikąd cię nie zaprowadzą - te porty zapamiętują stan medium i nigdy nie sondują go od nowa przy restarcie. Wyłącz urządzenie porządnie, wyciągnij zasilacz na parę minut, potem uruchom je ponownie z modułem już włożonym. To przywróciło oba porty u mnie, a ktoś inny opisał identyczne zachowanie na porcie Intel X552, dlatego uważam, że to zastały stan medium, a nie problem pfSense.
Jeśli wkładasz moduł, gdy system już działa, zrób szybki down/up na interfejsie zamiast restartować:
To sprawia, że sterownik patrzy na gniazdo od nowa. To nie jest trwała naprawa niczego, ale oszczędza restart, gdy zamieniasz moduły na stole. Sprawdź wynik przez
ifconfig -a, a nie przez panel przedni.Najpierw zrób pełne odcięcie zasilania i potwierdź oba gniazda kablem DAC, zanim dotkniesz strony switcha. Debugowanie jednej rzeczy na raz ma tu znaczenie, bo „no carrier przy każdym module" i „link wstaje na złej prędkości" to zwykle dwie osobne usterki, które akurat trafiły na ten sam odcinek kabla.
Pełne odcięcie zasilania załatwiło sprawę. Wyłączenie, zasilacz wyjęty, odczekanie paru minut, włączenie z powrotem - oba porty wstały. Spiąłem DAC między ix2 i ix3 i dostałem czysty link 10G, a para AXS85-192-M3 też daje 10G między tymi dwoma portami, więc gniazda i moduły są w porządku.
Strona switcha to inna historia. W stronę USW-Aggregation link negocjuje wyłącznie na 1G, a jeśli wymuszę 10G na którymkolwiek końcu, pada i zostaje padnięty. Więc połowa problemu zniknęła, a ta irytująca połowa wciąż tu jest.
Ta połowa z opadaniem do 1G wygląda bardzo znajomo. Ścigałem ten sam objaw na TL-SG3428X i TL-SX3008F: restart serwera wiszącego na jednym z tych portów SFP+ i wracał wynegocjowany na 1G, bez względu na to, jak skonfigurowany był port switcha. Adaptery Intel X520-DA2, Mellanox i HP, optyka Intel E10GSFPSR i 10GTek, aktualizacje firmware, kilka wersji sterowników na Linuksie i Windowsie, profile portów - nic z tego niczego nie zmieniało. Restart switcha albo przełączenie prędkości portu z 10G i z powrotem przywracało link 10G aż do kolejnego resetu hosta.
To, co faktycznie to naprawiło, to zmiana optyki, a nie cokolwiek po stronie hosta: moduły TP-Link SM5110-SR na końcu switcha i link wracał na 10G za każdym razem. Ktoś inny potwierdził to samo na SG3428XMPP. Wniosek był taki, że switch źle negocjuje z niektórymi modułami innych producentów po resecie linku po stronie hosta.
Inny producent po twojej stronie, ale kształt pasuje. Zanim kupisz komplet czegokolwiek, pożycz jeden moduł marki Ubiquiti i przetestuj jeden port na switchu agregacyjnym.
Co do wymuszania 10G: robienie tego tylko na jednym końcu pogarsza sprawę, a nie poprawia. Druga strona wciąż próbuje negocjować, a stałe ustawienie nie daje jej niczego, z czym mogłaby negocjować, więc link po prostu zostaje w dole - dokładnie to zachowanie, które opisujesz. Ustaw prędkość i dupleks na sztywno na obu końcach, albo na żadnym.
Dwa pokrewne przypadki ze świata MikroTika, gdyby coś zabrzmiało znajomo. Na RB4011 wykryto Finisar FTLF8524P2BNV-BR z sfp-rx-loss i sfp-tx-fault pokazującymi oba no, a interfejs mimo to mówił no-link, bo SFP 1G w gnieździe SFP+ trzeba przypiąć na sztywno, a nie negocjować:
i znowu, na obu końcach. Drugi przypadek to CCR1072, gdzie auto-negotiation zostawało na DONE po utracie linku i sterownik nigdy go nie restartował; wyłączenie autoneg i sztywne ustawienie prędkości przywróciło link, kosztem prawidłowego wykrywania link-down.