Optyka SFP+ third-party stoi down na używanym DCS-7150S-24: czy plik enable3px na flash to nadal opcja
Wziąłem parę używanych switchy Arista do labu i od razu wpadłem na bramkę optyki. Moduły kodowane przez Aristę łączą się, pasywne kable DAC łączą się, a wszystko third-party zostawia port na down.
Strona labu:
- DCS-7150S-24, kupiony używany, bez kontraktu wsparcia i bez zespołu account za mną
- różne moduły SFP+ third-party
- pasywne kable DAC do krótkich odcinków wewnątrz szafy
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upCo do tej pory ustaliłem:
- to, że DAC wstaje, a optyka nie, mówi mi, że to sprawdzanie kodowania, nie okablowanie i nie martwe gniazdo
- jest komenda konfiguracyjna postaci
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, która oczywiście chce klucza, którego nie mam skąd wziąć - starsze opracowania wspominają o pliku-znaczniku na flash zamiast klucza, ale nie umiem stwierdzić, której generacji to dotyczy
Który z tych dwóch mechanizmów jest tym dla skrzynki w tym wieku, i czy plik na flash to wciąż opcja na 7150S, czy klucz to jedyna droga, jaka została?
Comments 6
W tej generacji to plik, i jest tak prymitywny, jak brzmi. Z CLI EOS:
Pusty plik, nic w środku - sama jego obecność włącza optykę third-party po reloadzie. Lista platform, na których to działa, jest długa: DCS-7120T-4S, cała rodzina DCS-7050 i cała linia DCS-7150S między innymi, a każdy model ma najnowsze wydanie EOS, które jeszcze honoruje ten plik, w przedziale od mniej więcej 4.13.16M na najstarszych skrzynkach po train 4.23 na 7150S. Nowsze switche całkowicie ignorują ten plik.
Więc 7150S-24 jest po dobrej stronie tej granicy, o ile nie przeszedłeś dalej, niż model wspiera. Wypróbuj to, zanim zbliżysz się do drogi przez klucz.
Jaki train EOS jest na tym 7150S-24, i czy zaktualizowałeś go po zakupie? To ma znaczenie, bo granica jest per platforma, nie per rodzina. Plik-flaga jest udokumentowany jako działający na 7048T, 7120T-4S, 7140T-8S, wariantach SFP+ 7124 i 7148, seriach 7050 i 7150S oraz kartach liniowych 7548S-LC, ale ostatnie wydanie EOS, które go jeszcze honoruje, różni się dla każdego z nich.
Jeśli już zaktualizowałeś EOS na używanej skrzynce, jest spora szansa, że sam się wyaktualizowałeś poza tę sztuczkę, i wtedy tanią naprawą jest zejście o train w dół, zamiast polowania na klucz.
Nigdy nie ruszałem EOS, odkąd skrzynka przyjechała, więc wciąż stoi na tym train, jaki zostawił sprzedawca - co okazało się szczęściem. Zrobiłem touch, write memory, reload - i moduły SFP+ third-party, które wcześniej były martwe, teraz wstają jako zwykłe porty. Bez klucza, bez zespołu account, nic więcej nie potrzeba. DAC-i działały przez cały czas bez zmian, jak należało się spodziewać.
Dla każdego, kto tu trafia z nowszą skrzynką: ten plik jest tam po prostu ignorowany, a jedyną drogą jest kryptograficzny klucz per klient, który żyje w konfiguracji running jako
Klucz pochodzi z zespołu account albo sprzedaży, nie z supportu - TAC nie ma uprawnień do wydawania kluczy odblokowujących i odeśle cię do account management, co jest ślepym zaułkiem, kiedy switch pochodzi z rynku wtórnego.
Warto powtórzyć dla budów laboratoryjnych: pasywne kable DAC są akceptowane domyślnie niezależnie od stanu odblokowania. Jeśli odcinki są dość krótkie, możesz ominąć całe to pytanie, okablowując DAC-iem i zostawiając optykę dla linków, które faktycznie jej potrzebują.
Mała poprawka do „żyje w konfiguracji running": na starszym kodzie, na jakim pracowałem, był też nieudokumentowany wariant tej samej komendy, więc jeśli trafisz na odniesienie, które nie zgadza się ze składnią powyżej, to stamtąd się bierze, a nie z czyjejś literówki.
Z mojego doświadczenia klucz działał też bez restartu - większość optyki third-party zaczynała działać zaraz po wpisaniu komendy, choć kilka modułów i tak odmawiało bez względu na wszystko. To było dawno temu, na sprzęcie, którego już nie mam, więc sprawdź to na swojej skrzynce, zanim zaplanujesz wokół tego okno serwisowe.
Skoro to porównanie wraca za każdym razem, gdy wraca ten temat: na Cisco IOS-XE i IOS XR odpowiednik to dwa kroki, nie jeden. Sama globalna komenda nie wystarczy, potrzebujesz jeszcze tej per-interfejs na każdym fizycznym porcie, który ma przyjąć moduł:
To linia per-interfejs pomija sprawdzanie product ID, więc port przynajmniej spróbuje zaświecić optykę - bez obietnicy, że moduł potem zadziała, tylko że platforma przestaje go odrzucać. Robiłem to na IOS XR 5.3.3 i na skrzynkach IOS-XE.
Zastrzeżenie jest takie samo u obu producentów, i to dlatego ludzie ciągle się o to spierają: jeśli usterkę wyśledzi się do transceivera third-party zainstalowanego przez klienta, wsparcie w ramach gwarancji albo kontraktu może zostać wstrzymane. W porządku dla labu, decyzja warta świadomego podjęcia na produkcji.