Lenovo RackSwitch G8124E odrzuca generyczny SFP+ 10G SR z komunikatem UNAPPROVED - SR SFP+ is DISABLED
Wyciągnęliśmy parę G8124E z wycofanej z eksploatacji szafy i odbudowuję je jako warstwę agregacji dla wewnętrznego środowiska testowego. Budżet na markową optykę wynosi zero, więc wszystko idzie z generycznymi modułami 10G SR tego typu, który już mamy gdzie indziej.
- Lenovo RackSwitch G8124E, chassis z dawnym oznaczeniem IBM
- generyczny SFP+ 10G SR, duplex LC, ta sama partia co te działające w naszym produkcyjnym top-of-rack
- patchcord OM3 do karty sieciowej serwera, która linkuje na 10G z dokładnie tym samym typem modułu
Port ożywa na chwilę, a potem switch go wyłącza:
UNAPPROVED - SR SFP+ is DISABLEDPo tym link nigdy się nie nawiązuje, a port zostaje w stanie down.
Co już próbowałem:
- przełożyłem moduł przez cztery różne klatki, identyczny komunikat za każdym razem
- wstawiłem drugi moduł z tej samej partii i trzeci od innego dostawcy
- przejrzałem konfigurację interfejsu w poszukiwaniu czegoś w rodzaju przełącznika allow-unsupported i nic nie znalazłem
Czy jest jakiś sposób, żeby to urządzenie zaakceptowało optykę stron trzecich, czy sprawdzenie zatwierdzenia da się zadowolić tylko modułami zakodowanymi przez Lenovo?
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
Zanim ktoś poda ci komendę: co zgłasza
show version? W tej rodzinie lekarstwo to nie jedna komenda, dzieli się według gałęzi kodu: co robisz na obrazie 7.x, nie jest tym, co robisz na 8.x, więc najpierw trzeba ustalić wersję.Powiedz też, czy moduły są całkiem generyczne, czy niosą rozpoznawalny ciąg vendora w EEPROM. Firmware ocenia każdy moduł po tym ciągu, a ludzie z SFP+ zakodowanym przez Intela w dokładnie tym samym switchu też dostają ostrzeżenie o niezatwierdzonym transceiverze, więc sam komunikat niewiele mówi o samej optyce.
show versionpokazuje obraz 7.x, czyli starszą gałąź, nie bieżącą.Moduły są całkiem generyczne, bez żadnego kodowania Intela czy Cisco, identyfikują się jako OEM, który je zbudował. Trzeci moduł wsadziłem też do stojącego obok IBM RackSwitch G8124 i dostałem tam to samo zachowanie, więc to nie jedna zła klatka ani jedna zła sztuka optyki.
Na starszych strumieniach jest zmienna boot loadera, która wyłącza sprawdzanie zatwierdzenia. Jest opisana dla 5.x, 6.x, 7.x i 8.3.x lub niżej, więc urządzenie na 7.x się łapie.
Potrzebujesz do tego konsoli szeregowej, portu mini-USB RS232, nie sieci. Zrób reload switcha i trzymaj Shift+M przez test pamięci, aż boot loader da ci prompt
=>, potem:Wartość rozróżnia wielkość liter,
Overridez wielkiej litery O. Uruchomprintenvprzedboot, żeby faktycznie zobaczyć, że zmienna się zapisała. Gdy switch skończy bootować, przestaje wyłączać niezatwierdzone moduły SFP+ i porty po prostu wstają.Dwa zastrzeżenia. To środek laboratoryjny i awaryjny, Lenovo nie wspiera optyki stron trzecich i nic tutaj nie jest oficjalne. I trzymaj się z daleka od optyki dual-rate na tych starszych urządzeniach, sprawia kłopoty nawet po wyłączeniu sprawdzenia.
To ta sama historia w całej linii switchy Lenovo, nie tylko w G8124E. Mam tu G8272, który ocenia Cisco-Finisar
SFP-10G-LR-Sjako Unapproved, pokazuje port jako Disabled i zostawia link down. Prawdziwa optyka Cisco, po prostu nie ma jej na liście Lenovo.Po stronie ThinkSystem, NE1032 i NE1032T, to CNOS, a nie ENOS, i tam wejściem jest komenda platformy pozwalająca na niewspierane transceivery zamiast sztuczki z boot loaderem. Sam tego nie uruchamiałem, więc zweryfikuj składnię na swoim urządzeniu, zanim zaplanujesz wokół tego okno. Wzorzec pod spodem się nie zmienia: firmware porównuje ciąg vendora z EEPROM z listą i wyłącza to, czego nie rozpoznaje.
Jedna rzecz do dopisania: override niekoniecznie przetrwa aktualizację firmware'u. Jeśli wgrasz nowy obraz i porty znowu padną, wróć na konsolę szeregową i sprawdź
printenv, zanim zaczniesz wyciągać moduły - zmienna może po prostu zniknąć.I nie traktuj przełączników odblokowujących vendora jako ogólnie niezawodnych. Na Catalyst 9200 z IOS-XE 16.9.x
service unsupported-transceivernie ma żadnego efektu przez CSCvk03296, a to, czego ludzie używali zamiast tego, tono errdisable recovery cause gbic-invalidw konfiguracji globalnej, co trzymało porty z dala od err-disable i pozwalało działać modułom FS i Cables and Kits. Inny producent, ta sama lekcja: udokumentowany przełącznik i przełącznik, który faktycznie działa, to nie zawsze to samo.