FortiGate 101F: wspólne porty RJ45/SFP 17-20 gasną po aktualizacji FortiOS
Mamy parę FortiGate 101F dla biura na 40 osób, nic egzotycznego. port17 niesie uplink SFP do switcha rdzeniowego, port19 to odcinek RJ45 do serwerowni, oba w obrębie wspólnego bloku RJ45/SFP (porty 17-20). W oknie serwisowym w zeszłym miesiącu podnieśliśmy parę do FortiOS 7.4.4, i od tego czasu ten blok jest martwy.
- FortiGate 101F, i FortiGate 100F w drugiej lokalizacji zachowujący się tak samo
- port17: moduł SFP 1G do stackowanego switcha dostępowego
- port19: RJ45 do portu switcha 1G
- FortiOS 7.4.4, zaktualizowany z builda 7.2
Porty 1-16 są w porządku, padły tylko te wspólne. Co rzuciło mi się w oczy, to że opcje prędkości w GUI już nie wyglądają tak jak przed aktualizacją, a działająca konfiguracja ma teraz to:
config system interface
edit "port17"
set speed 1000full
next
endNikt tu tego nie wpisał. Każdy port na tym pudełku był na auto przed aktualizacją.
Sprawdzone do tej pory:
- wyjąłem i włożyłem SFP z powrotem, zamieniłem na sprawdzony egzemplarz, bez zmian
- przełożyłem drugi koniec na inny port switcha
- zimny restart firewalla, konfiguracja przetrwała jak wyżej
Czy wspólny blok RJ45/SFP na 100F/101F ma tracić auto podczas aktualizacji, czy nasza konfiguracja gdzieś się posypała? I jaki jest właściwy sposób, żeby to przywrócić?
Comments 5
Twojej konfiguracji nikt w biurze nie napsuł, zrobiła to aktualizacja. Na 100F i 101F aktualizacja po cichu wbija sztywne 1000full na wspólne porty RJ45/SFP, tam gdzie wcześniej było auto, nie pytając, czy druga strona przeżyje tę prędkość. Zależnie od drugiego końca dostajesz wtedy port, który łapie link na złej prędkości, albo taki, który w ogóle nigdy nie złapie linku, i dokładnie dlatego 17-20 są martwe, a dedykowane porty nietknięte. Fortinet ma to w rejestrze jako znany problem 989629, opisany w release notes do 7.2.9; dotknięte gałęzie to v7.2.8 i nowsze, v7.4.2 i nowsze, oraz v7.6.0 i nowsze.
Przywróć prędkość ręcznie, port po porcie:
Na v7.2.8 oraz od v7.4.2 do v7.4.4 zwykłe auto nie jest dostępne na liście, i właśnie dlatego GUI wygląda u ciebie inaczej, więc użyj tam 1000auto. Na v7.2.9, v7.4.5, v7.6.0 i nowszych normalna opcja wróciła i chcesz:
Powtórz dla port18 do port20, jeśli są używane. A na następne okno: sprawdź najpierw, czy twoja ścieżka zarządzania nie ląduje na portach 17-20, bo inaczej pudełko wróci z twoim portem dostępowym wymuszonym na 1000full i pojedziesz na miejsce, żeby naprawić to z konsoli.
Z jakiego builda faktycznie startowałeś? „build 7.2" to szeroki zakres, a to, co trzeba wpisać, żeby to naprawić, różni się między gałęziami. Druga rzecz warta ustalenia to czy drugie końce oferują autonegocjację, czy same są przypięte na sztywno: peer, który tylko i wyłącznie autonegocjuje, będzie stał bezczynnie naprzeciw portu trzymanego na stałej prędkości.
Jedno do ustalenia, zanim cokolwiek zmienisz: czy twoja ścieżka zarządzania przechodzi przez którykolwiek z portów 17-20? Jeśli tak, zrób następną zmianę z konsoli, a nie przez sieć.
Warto dodać ogólną uwagę dla każdego, kto trafi tu ze wspólnym portem, który się źle zachowuje: na większości urządzeń ta para naprawdę się wyklucza. NETGEAR nazywa to dual personality na GS716T-200, gdzie każde z dwóch gniazd SFP jest sparowane z jednym z ostatnich portów miedzianych, i tylko jedna połowa tej pary może być aktywna naraz, więc wsadzenie modułu po cichu wyłącza pasujący RJ-45 z użytku. Każdy port na tym modelu i tak jest gigabitowy, więc uplink optyczny kupuje ci trasę kablową, nie przepustowość.
Ta sama zasada na bloku FortiGate, więc potwierdź, którą połowę port17 właściwie oglądasz. Moduł w gnieździe plus patchcord w miedzianej połowie tego samego portu to klasyczny samobój, i z CLI wygląda bardzo podobnie do problemu z prędkością.
Inny producent, ten sam smak bólu. EX4200 z modułem uplink EX-UM-2X4SFP: xe-0/1/0 chodził na 10G bez zarzutu, xe-0/1/1 nie dawało się nawet dodać do VLAN-u i nie przepuszczało żadnego ruchu. Oba porty działały na 1G, SFP+ było w pełni widoczne w show chassis hardware, zamieniałem moduły, próbowałem zapasowego EX-UM-2X4SFP i zrobiłem factory reset, zanim ktoś mi powiedział, czym ten moduł naprawdę jest.
Nic nie było wadliwe. Ten moduł przyjmuje SFP+ tylko w dwóch ze swoich gniazd, tych numerowanych sprzętowo jako 0 i 2; druga para przyjmie optykę 1G i nic szybszego. Więc interfejsy 10G, na które można liczyć, to xe-0/1/0 plus xe-0/1/2, a xe-0/1/1, z którym się siłowałem, nigdy nie miało ruszyć na 10G, cokolwiek bym w nie wsadził. Przełożyłem optykę o jedno gniazdo dalej, skonfigurowałem xe-0/1/2, gotowe. Przy gniazdach mixed-mode przeczytaj, co obsługuje dany blok, zanim zrobisz RMA czegokolwiek.
Uwaga z tym kątem wykluczania się combo, on nie wyjaśnia tego przypadku. Porty działały przed aktualizacją, padł dopiero blok wspólny, i w konfiguracji jest linijka z prędkością, której nikt nie wpisał. To jest przepisanie configu, nie priorytet gniazda.
Odwrotny błąd też potrafi kogoś spalić, notabene. Kiedyś spędziłem tydzień na switchach D-Link DES-1210-52 podpiętych światłowodem do OSNOVO NS-SW-8GX2G: wskazanie linku na portach optycznych, zero LAN-u, zero internetu, podczas gdy te same switche działały dobrze spięte łańcuchowo po miedzi, a aktualizacja firmware nic nie zmieniła. Port combo był głównym podejrzanym przez wiele dni. Prawdziwa usterka była po drugiej stronie: porty OSNOVO niosące te moduły SFP były wewnętrznie martwe, spalone, a siedząca w nich optyka była całkowicie zdrowa.
Więc kiedy lokalna konfiguracja już jest w porządku, wsadź sprawdzony moduł w sprawdzony port po drugiej stronie, zanim wyciągniesz jakiekolwiek wnioski o swoim własnym pudełku.