IBM Flex System EN4093 zrzuca porty trunku SFP+ w ERRDISABLE przy boocie i podczas pracy
Dwie obudowy Flex System, każda z EN4093R 10Gb Scalable Switch (opcja 49Y4270) jako modułem sieciowym. Porty wracają jako error-disabled po zdarzeniu zasilania chassis, i rzadziej wpadają w ten sam stan, kiedy wszystko już działa. To nie zawsze te same porty, co czyni to tak męczącym do wytropienia.
Setup:
- IBM Flex System EN4093 10Gb Scalable Switch, opcja 49Y4270
- trunk uplinku z czterech portów do rdzenia, optyka IBM plus jeden DAC dodany później
- port QSFP+ rozbity w stronę drugiej obudowy
- MSTP działające po naszej stronie, rdzeń jest od innego dostawcy
Co pokazuje lista portów po boocie:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesWypróbowane:
- shutdown / no shutdown na dotkniętych portach przywraca większość z nich do następnego zdarzenia
- wyczyszczono i osadzono ponownie każdy światłowód w trunku, bez zmiany wzorca
- porównano konfigurację portu na drugim końcu, prędkości zgadzają się na papierze
Co dokładnie wpycha te porty w errdisable, i czy jest sposób, żeby to zatrzymać przy każdym boocie zamiast czyścić to ręcznie za każdym razem?
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 5
Ten switch ma siedem udokumentowanych stanów, które wyłączają port, i mają one bardzo mało wspólnego ze sobą:
Twój przypadek to ten czwarty, i to ten, na który trafia większość ludzi, bo to ten, który budujesz sobie sam: zmieszaj prędkości albo typy modułów wewnątrz jednego trunku i switch się sprzeciwia. Wystarczy jeden DAC siedzący obok trzech modułów optycznych. Wyciągnij stamtąd DAC i wypełnij slot modułem pasującym do pozostałych trzech.
Dla portu na detektorze flapów, odbicie go wciąż jest udokumentowanym sposobem odzyskania:
Potem odczytaj z powrotem konfigurację spanning tree na tym łączu i przejrzyj ręcznie miedź i światłowód. Po każdej zmianie konfiguracji zrób reload, bo inaczej stan roboczy po cichu przestaje pasować do tego, co myślisz, że ustawiłeś.
Dwie rzeczy, których nie oczekuj. Dwa z tych siedmiu stanów trzymają port w dole po wygaśnięciu timeoutu i chcą ręki na porcie. I żadne wydanie firmware tego nie naprawia - linia producenta jest taka, że konfigurujesz się dookoła tego, więc identyczne moduły na każdym członku trunku plus czysty światłowód to wszystko, co da się zrobić w ramach prewencji.
Zacząłbym od dwóch różnych powodów w tym samym wklejeniu. Czy dany port zawsze wraca wyłączony z tego samego powodu, czy ten, który padł na capabilities przy tym boocie, przy następnym uruchamia detektor flapów? Powód, który trzyma się portu, i powód, który wędruje, to dwa osobne śledztwa, i tylko jedno z nich kończy się kupowaniem sprzętu.
Druga rzecz warta ustalenia to co rdzeń uruchamia dla spanning tree. Jesteście na MSTP; jeśli druga strona wrzuca na te uplinki BPDU w stylu Cisco PVST, ten switch ma mechanizm ochrony, który reaguje dokładnie na to i zrzuca port, a z zewnątrz wygląda to jak usterka, którą już tropicie. Widzisz, czy któryś ze spadków pokrywa się ze zmianą topologii na rdzeniu, a nie z waszymi własnymi bootami?
Per port jest spójnie, w skali całego urządzenia nie. Członkowie trunku, którzy padają, zawsze wracają z mismatched link capabilities, a port dostępowy na 5 zawsze uruchamia tylko detektor flapów, w interwale, w którym nie potrafię znaleźć wzorca. Więc to faktycznie wygląda jak dwie usterki w tej samej marynarce.
Na spanning tree po drugiej stronie nie potrafię jeszcze odpowiedzieć - rdzeń należy do innego zespołu i zapytałem ich, co faktycznie emitują na tych uplinkach. Nic w naszym logu jak dotąd nie wiąże spadku ze zmianą topologii tam, ale czytałem go pod kątem zdarzeń linku, a nie pod tym kątem, więc nie nazwałbym tego wykluczonym.
Inny producent, ten sam kształt. Mieliśmy FortiGate 201F wiszący na FortiSwitch 548D na SFP+ z własnym DAC Fortinetu między nimi, i link 10Gbps po prostu nie chciał zostać up - padał, cokolwiek zrobiliśmy ze speed i duplex, a cofnięcie obu końców z FortiOS 7.4 do 7.2.5 nic nie zmieniło.
To, co w końcu utrzymało, to krótszy DAC Fortinetu z wyłączonym STP na tym jednym łączu, i stoi od tamtej pory. Część warta zapamiętania to rozumowanie, które przyszło potem: im dłuższy pasywny przebieg miedzi, tym bardziej sygnał degraduje się, zanim dotrze, więc przy 10G każdy długi albo graniczny DAC należy do listy podejrzanych, bez względu na to, jaka etykieta jest na nim wydrukowana. Z trzema modułami optycznymi i jednym DAC w trunku errdisable, mocno przyjrzałbym się temu nietypowemu.
Jedna rzecz do zrobienia, zanim dotkniesz jakiegokolwiek sprzętu: zapisz dokładny rytm flapów na tle znaczników czasu w logu.
Na zupełnie niezwiązanym switchu, TL-SG3452X, każdy zapełniony port SFP+ padał i wstawał co dziesięć do piętnastu minut, z komunikatami STP w logu przy każdym flapie, i oczywistym wnioskiem była zła optyka - dopóki firmowy DAC TL-SM5220-1M nie zaflapował w dokładnie tym samym rytmie. To zabiło teorię optyki w jednym teście i wskazało zamiast tego na regresję firmware; jedyną działającą odpowiedzią było zostanie na starszym buildzie.
Regularny interwał znaczy, że coś ma timeout według harmonogramu. Losowy znaczy, że coś jest fizyczne. Tani test, i oszczędza ci kupowania modułów, których nie potrzebujesz. Opłaca się też trzymać poprzedni obraz firmware pod ręką, żeby downgrade zostawał na stole.