Fortinet 25G DAC łączy identyczne FortiSwitche, ale nie FS2048 z FS648
Konsolidujemy dwa rzędy agregacji na FortiSwitchach i ostatni element to połączenie 25G między FS2048 a FS648 w sąsiednich szafach. Wszystko inne w projekcie wstało za pierwszym razem, tylko ten jeden link się opiera.
- FortiSwitch 2048, port 25G na przednim panelu
- FortiSwitch 648, port 25G na przednim panelu
- Fortinet FN-CABLE-SFP28-5, pasywny DAC, kabel producenta, nie zamiennik
- oba porty nietknięte poza konfiguracją VLAN
Co widzę:
FS2048 port: down, no rx/tx counters moving
FS648 port: down, no rx/tx counters moving
same FN-CABLE-SFP28-5 between two FS648 units: up at 25G, stableCo już zrobiłem:
- podmieniłem na drugi FN-CABLE-SFP28-5 z tej samej paczki, bez zmian
- przeniosłem oba końce na inne porty 25G na każdym z chassis, bez zmian
- sprawdziłem, że kabel jest sprawny, łącząc go między dwoma identycznymi FS648, gdzie wstaje od razu
Czyli kabel jest dobry i porty są dobre, tylko kombinacja nie działa. Czy na portach 25G jest coś, co musi się zgadzać między tymi dwoma modelami, zanim link się wytrenuje?
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
Dokładnie to. Oba chassis są zbudowane na różnych generacjach ASIC i PHY, i korekcja błędów, na jakiej każdy z nich sam się ustawia przy 25G, nie jest taka sama po obu stronach, więc link nigdy nie kończy treningu. Zostaje czyste down/down i nic w logach, czego można by się uchwycić.
Ustaw ręcznie ten sam tryb FEC na obu portach:
Zrób to na FS2048 i na FS648, używając nazwy portu właściwej dla każdej strony. CL91 to wariant Reed-Solomon i czyści zdecydowanie więcej niż opcja CL74 firecode, ale to, który z dwóch wybierzesz, ma dużo mniejsze znaczenie niż wybranie tego samego po obu stronach: oba PHY muszą kodować i dekodować identycznym schematem, inaczej trening nigdy się nie zakończy, a "auto" na dwóch różnych rodzinach PHY to nie jest identyczny schemat.
Port powinien wstać, jak tylko druga strona zostanie zatwierdzona. Jeśli później dołożysz do tego trzeci model, ustaw to jawnie i tam, zamiast zakładać, że domyślna wartość się przeniosła.
Kabel, który łączy identyczne jednostki, a między różnymi modelami umiera, to warstwa fizyczna, która nie może się w czymś dogadać, a przy 25G po miedzi to prawie zawsze FEC.
Zanim cokolwiek innego, podaj, jaki fec-state jest teraz skonfigurowany na obu portach. Wartość domyślna różni się między generacjami FortiSwitch, a te dwa modele, które łączysz, to nie ta sama rodzina ASIC/PHY, więc "fabryczne ustawienia po obu stronach" nie znaczy "to samo ustawienie po obu stronach".
Jeśli te dwa porty pokażą różne wartości, masz odpowiedź, zanim ruszysz cokolwiek innego.
Nic nie było ruszane po żadnej ze stron, więc oba porty działają na tym, co obraz ustawia domyślnie. Strona FS2048 jest pusta:
Tak samo na FS648. Prędkość i auto-negocjacja też nietknięte, wrzuciłem porty tylko do właściwego VLAN-u. Jeśli wartości domyślne różnią się między modelami, to by tłumaczyło, czemu ten sam kabel jest w pełni zadowolony między dwoma identycznymi urządzeniami.
Ta sama klasa problemu, tylko zupełnie poza Fortinetem, gdyby się przydało. Miałem pasywny DAC 25G SFP28, który bez problemu łączył się między UniFi USW-Pro-Aggregation a serwerem z kartą Intel SFP28, i dawał zupełnie nic na sfp28-2 w MikroTiku CCR2004-1G-12S+2XS - żadnego błędu po żadnej stronie, po prostu brak linku. Próbowałem Ubiquiti UACC-DAC-SFP28-3M i Lenovo 7Z57A03558, ten sam efekt. W pewnym momencie port nawet wstał i po jakichś dwóch sekundach znowu spadł, co było wskazówką, że coś nie kończy treningu, a nie że kabel jest martwy.
Znowu FEC: strona Ubiquiti trzyma FEC włączony bez wspieranego sposobu na zmianę, a RouterOS w 6.49 przestawił domyślną wartość z fec91 na brak FEC. To, co tutaj zadziałało, to przejście na RouterOS 7.4, gdzie opcje FEC są odsłonięte, uruchomienie
a potem ustawienie portu na fec74 z wyłączoną auto-negocjacją, wyłączoną kontrolą przepływu w obu kierunkach, 25 Gbps pełny dupleks, plus nadpisanie profilu portu po stronie UniFi wymuszające 25G FDX. To jest mój sprzęt i mój firmware, więc traktuj ten dokładny przepis jako punkt wyjścia i zweryfikuj na swoim.
Warto dodać, że to samo pokrętło nazywa się inaczej zależnie od tego, w czyim CLI akurat stoisz, i to właśnie sprawia ból, gdy w szafie jest więcej niż jeden producent. Na linkach 25G Cisco między stackiem Catalyst 9300 a parą Catalyst 9500 to fec cl108 po obu stronach postawiło je do góry; na 100G między tą parą 9500 a Nexusem 9000 zadziałało fec off po obu stronach. Ta sama decyzja, inne słowa kluczowe.
I FEC nie zawsze trzeba włączać. Na Nexusie 93180YC-EX z SFP-H25GB-SR wpiętym w adapter Cavium 25G port switcha stał na FEC auto i oczekiwał FEC z powodu optyki, podczas gdy karta sieciowa w ogóle nie zgłaszała obsługi FEC, więc strony nigdy się nie dogadały i interfejsy zostawały down przy rozpoznanych modułach. Tam fec off na interfejsie switcha było rozwiązaniem, a show interface potwierdza przejście trybu z Auto na Off.
Czyli zasada brzmi nie "używaj cl91", tylko "zdecyduj o trybie, a potem ustaw go jawnie po obu stronach".
Potwierdzam. set fec-state cl91 na porcie FS2048 samo z siebie nic nie zmieniło, potem to samo na porcie FS648 i link wstał w ciągu kilku sekund. Liczniki ruszyły po obu stronach i przetrwało to restart każdego z chassis.
Od teraz to ustawienie zostaje jawne na każdym porcie 25G w tej parze, zamiast ufać wartości domyślnej. Dwa wieczory podmieniania zupełnie sprawnych kabli za jedną linijkę konfiguracji.