Catalyst 3850 wrzuca port w err-disable, gdy ThinkSystem SR650 używa optyki Lenovo 46C3447 SR
Nowy host ESXi wchodzi do szafy podpiętej pod kampusowy 3850. Zarządzanie po miedzi wstało bez dramatu, uplinki 10G nie: gdy tylko serwer się uruchamia, port switcha spada w err-disable, a host nie widzi nic na tym vmnic.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, z adapterem Emulex VFA5.2 2x10GbE SFP+
- moduły Lenovo 10GBASE-SR, 46C3447, w adapterze
- Cisco WS-C3850-24XS-S z Cisco SFP-10G-SR po stronie switcha
- patchcord OM3 LC-LC między nimi
Te1/0/7: goes err-disabled within seconds of the server powering on
ESXi: the uplink shows DISCONNECTED
Same patch cord, Cisco SFP-10G-SR at both ends switch to switch: link up and stableJuż próbowałem:
- przełożyłem serwer na inny port tego samego switcha, to samo zachowanie
- zamieniłem 46C3447 na jego bliźniaka z drugiego portu adaptera
- nowy patchcord, oba końce wyczyszczone i osadzone ponownie
Światłowód i optyka po stronie switcha są wyraźnie w porządku, więc coś protestuje przeciwko modułowi Lenovo. Która strona tu protestuje, serwer czy switch, i czy jest sposób, żeby 3850 się z tym pogodził?
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
Ten log rozstrzyga sprawę.
gbic-invalidto switch odmawiający tego, co odczytuje jako nieautoryzowany moduł, a sprawdzenie, które to wyzwala, siedzi po stronie Cisco, nie na SR650 i nie w ESXi. Protestuje przeciwko optyce SR zakodowanej przez Lenovo na tym łączu i zabija port, zanim link w ogóle zostanie oceniony, dlatego też przekładanie portów i zamiana przewodów nic u ciebie nie zmieniły.Dwie linijki w konfiguracji globalnej:
Pierwsza mówi switchowi, żeby działał dalej z modułem, którego nie rozpoznaje, druga zatrzymuje err-disable przed zastrzeleniem portu, gdy to sprawdzenie CRC zawiedzie. Żadna z nich nie działa wstecz, więc odbij port po zmianie i osadź światłowód ponownie, gdy jest wyłączony:
Zapisz konfigurację, gdy już wstanie. Jeśli zostanie tylko w running config, po następnym reloadzie port wróci w err-disable i będziesz debugować to jeszcze raz, w znacznie gorszym momencie.
Dwa zastrzeżenia. Wychodzisz teraz poza wspieraną konfigurację Cisco: traktują optykę stron trzecich jako nieprzetestowaną, a TAC może odmówić sprawy interoperacyjności, która taką obejmuje, co ma znaczenie, jeśli to łącze siedzi pod kontraktem. I
service unsupported-transceivernie jest uniwersalną naprawą. Ten sam komunikat bad crc przetrwa ją, gdy przeszkodą jest sam port, na przykład slot SFP tylko-1G z wciśniętym modułem 10G, więc jeśli port zostaje down po odbiciu, sprawdź, na jakiej prędkości faktycznie pracuje każdy koniec, zanim znowu obwinisz optykę.Zanim ktokolwiek zacznie zgadywać: co switch faktycznie loguje, gdy port pada? Err-disable zawsze nazywa swoją przyczynę, a przyczyna zmienia odpowiedź całkowicie. Skarga bezpieczeństwa albo CRC na moduł to inny problem niż flap czy potknięcie protokołu, i lekarstwo na jedno nic nie da na drugie.
Wyciągnij
show loggingz okolic momentu, gdy serwer się uruchamia, i wklej linijki dla tego portu. Potwierdź też, co fizycznie siedzi w Te1/0/7 - mówisz Cisco SFP-10G-SR, więc czy 46C3447 to jedyna część spoza Cisco na całej tej ścieżce?Log z momentu, gdy pada, dwie linijki dla tego portu:
Czyli to wyzwala się sprawdzenie bezpieczeństwa, nie flap. I tak, koniec po stronie switcha to prawdziwy Cisco SFP-10G-SR z pudełka Cisco, 46C3447 w serwerze to jedyna część zakodowana przez Lenovo na całej ścieżce. Co właśnie mnie zmyliło, bo komunikat nazywa port na switchu, a nie cokolwiek po stronie serwera.