Uplink 100GE z Huawei CE6800 do Profitap XX-3200G nigdy nie wstaje na optyce SR4
Wymieniam klientowi dotychczasową parę agregacyjną na sprzęt CloudEngine, i jedyny link, który nie chce wstać, to feed 100GE do ich packet brokera. Wszystko inne na switchu weszło bez dramatów.
- Huawei CloudEngine 6800, port 100GE
- moduły QSFP28 100GBASE-SR4, oryginalne Huawei, po jednym na każdym końcu
- packet broker Profitap XX-3200G po drugiej stronie
Oba końce widzą swój moduł. W logu switcha nie ma nic poza wpisami o wpięciu i wyjęciu transceivera z czasu, gdy przekładałem sprzęt, żadnych alarmów, a interfejs po prostu stoi na down:
<CE6800> display interface 100GE1/0/1
...
FEC : RS-FECCo już sprawdziłem:
- podmieniłem oba moduły na zapasowe i wyczyściłem końcówki MPO, bez zmian;
- przeniosłem link na inny port 100GE na switchu;
- sprawdziłem stronę brokera, wykrywa swój moduł i nie zgłasza nic złego.
Czyli optyka jest rozpoznana po obu stronach, nic nie narzeka, a linku nie ma. Co jeszcze musi się zgadzać między portem 100GE CloudEngine a urządzeniem innego producenta, żeby link się wytrenował?
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 niezgodność FEC. CloudEngine domyślnie włącza RS-FEC na portach 100GE z optyką SR4, broker nie ma ustawienia FEC i przez to działa bez niego, a dwa końce, które nie zgadzają się co do FEC, nigdy nie kończą treningu. Nic nie jest zepsute, więc nic nie jest logowane, dlatego w logu są tylko twoje komunikaty o wpięciu i wyjęciu.
Wyłącz to na switchu, w widoku interfejsu:
undo fec moderobi to samo. Druga linia jest tą, która ma znaczenie. CE to konfiguracja dwuetapowa, i niezatwierdzonyfec mode nonewygląda całkowicie poprawnie, gdy odczytujesz konfigurację z powrotem, podczas gdy port stoi dokładnie tak samo na down jak wcześniej. Widziałem, jak zgłoszenie klienta ciągnęło się o dzień dłużej z tego właśnie powodu, bo wszyscy byli przekonani, że FEC jest już wyłączony.Po commit,
display interfacepowinno pokazać FEC: NONE, a port powinien się wytrenować.Jeśli drugi koniec kiedyś dostanie ustawienie FEC, lepszą poprawką jest włączyć tam RS-FEC i zostawić switch na jego domyślnym ustawieniu, bo na 100G korekcja naprawdę się przydaje. Między dwoma różnymi vendorami ustawiałbym FEC jawnie po obu stronach, zamiast liczyć na to, że coś to wynegocjuje.
Co broker mówi o FEC po swojej stronie, jeśli w ogóle coś mówi? Ciekawszą połowę już sam podałeś: port switcha działa na RS-FEC. Huawei wprost mówi, że oba końce linku 100GE muszą używać tego samego trybu FEC, inaczej interfejsy nigdy nie wstają, a taka awaria wygląda dokładnie jak twoja: oba moduły zdrowe, brak alarmu, brak logu, port down.
Większość packet brokerów i tapów, z jakimi miałem do czynienia, w ogóle nie wystawia przełącznika FEC, co znaczy, że działają bez niego, i to switch musi ustąpić. Najpierw to potwierdź, a potem zmień jedną rzecz.
Warto dodać, że domyślne ustawienie CloudEngine to nie jedna wartość, zależy od modułu. QSFP28-100G-LR4 i QSFP28-100G-LR1 działają z FEC wyłączonym zgodnie z IEEE 802.3, podczas gdy wszystkie inne typy QSFP28 mają domyślnie FEC włączony. Więc rada, żeby po prostu go wyłączyć, jest błędna na linku LR4, gdzie switch już jest wyłączony, a niezgodność siedzi po drugiej stronie.
Jeszcze dwie zasady z tego samego rozdziału, które mnie kiedyś złapały:
Więc sprawdź, co faktycznie trzymasz w ręku, komendą
display transceiver interface 100GE1/0/1 verbose, zanim zdecydujesz, w którą stronę pchnąć FEC, i pamiętaj o commit tak czy inaczej.