DWDM SFP+ firmy trzeciej nie wstaje na Aristcie 7050T z EOS 4.10.6 - czy jest coś poza łataniem image'u

Zanim ktoś skieruje cię w stronę image'u, dwie rzeczy.

Do jakiej gałęzi EOS jesteś w ogóle przywiązany na tym 7050T? Jeśli musi zostać na 4.10.6, to hack pod konkretny build jest przynajmniej spójny sam ze sobą. Jeśli możesz go przenieść, miej na uwadze, że obsługa transceiverów została przeorganizowana w późniejszych wydaniach i żaden przepis napisany pod 4.10.6 się nie przenosi.

A co ten dostawca w ogóle potrafi w nie wgrać? Warto zapytać, czy ich programator w ogóle ma profil Aristy, czy tylko kodowanie Cisco per platforma, które większość z nich trzyma - części ASR9K na przykład potrzebują własnego profilu, a dostawcy optyki taki utrzymują. Przekodowanie partii wychodzi dużo taniej niż życie na zmodyfikowanym image'ie. Osobno: pytałeś już swój account team o klucz unsupported-transceiver, czy to jest poza stołem z powodów komercyjnych?

Łatka image'u faktycznie działa na tym dokładnie buildzie i to niewiele roboty - ale rób to na labie albo zapasowym boxie, nigdy na czymś, co niesie ruch.

Kształt tego: rozpakuj EOS-4.10.6.swi i zachowaj składniki, którymi są boot0, initrd-i386, linux-i386, rootfs-i386.sqsh i version. Rozpakuj system plików root jako root, zedytuj agenta, spakuj z powrotem:

unsquashfs rootfs-i386.sqsh
mksquashfs squashfs-root/ rootfs-i386.sqsh
zip -Z store EOS-4.10.6a.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

Sama edycja jest w squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: zakomentuj cztery linie koło linii 172, które sprawdzają stan obecności, a potem uruchamiają autoryzację transceivera. -Z store przy zip nie jest opcjonalne, swi musi zostać nieskompresowany, inaczej box tego nie zbootuje.

Potem porty wstają z czymkolwiek, co wsadzisz, bo nic już nie waliduje. Dwie ceny: nie masz wsparcia producenta na zmodyfikowanym image'ie, a łatka jest przywiązana do tego buildu, więc trzymaj oryginalny .swi na flash, żeby zbootować z powrotem, gdy coś pójdzie nie tak.

Odpowiadając na pytania powyżej: box jest zapasowy, bez kontraktu wsparcia, a dostawca w ogóle nie ma profilu Aristy w swoim programatorze - kodują pod platformy Cisco i na tym kończy się lista, więc przekodowanie tej partii nie wchodzi w grę. Droga przez account team nie jest zamknięta, tylko nie pomaga mi w tym tygodniu.

Przebudowałem 4.10.6 tak jak opisano, zbootowałem załatany image i oba porty DWDM wstały za pierwszym razem. Oryginalny image wciąż siedzi na flash. Link trzyma się stabilnie od tamtej pory, a druga strona nie widzi niczego niezwykłego.

Cieszę się, że zadziałało, ale bądź ze sobą szczery co do żywotności tej łatki, bo wątek powyżej brzmi, jakby było to bardziej uniwersalne, niż jest naprawdę.

To jest napisane pod 4.10.6 i nic więcej. Ludzie pytali, jak powtórzyć to na 4.14.5F, 4.14.7M i 4.23.8M, i nikt nigdy nie wrzucił działającej odpowiedzi, bo menedżer transceiverów został przeorganizowany w późniejszych wydaniach i tych czterech linii tam już na ciebie nie czeka. Każdy upgrade wymienia też image, więc łatka znika, a porty padają przy najbliższej rutynowej konserwacji.

Drogi, które przeżywają upgrade, to klucz service unsupported-transceiver wydawany przez account team dla konkretnego klienta, a na starszych platformach plik znacznikowy enable3px. Używaj łatanego image'u, żeby utrzymać przy życiu stary box, nie jako standardu dla sieci.

Ta sama walka po stronie Cisco, z detalem wartym zapamiętania. DWDM SFP+ firmy trzeciej na 80 km (Pro10Optix, oznaczony SFP-10G-DWDM-192) chodził w switchach Catalyst 6500 bez żadnych zastrzeżeń. Przełożony do wbudowanych portów SFP+ ASR 9001 na IOS XR 5.3.3 dawał:

%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR: SFP Module is not supported
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED: Not supported Product ID

Czerwona dioda portu, interfejs down, stan zgłaszany jako utrata linku albo za słabe światło bez loopbacku, długość fali odczytywana jako 0 nm, a laser nigdy się nie odpala. transceiver permit pid all na interfejsie samo z siebie nic nie zmieniało, a globalne service unsupported-transceiver do tego też nie ratowało tej partii. Platforma oczekuje part number w kształcie DWDM-SFP10G-xx.yy z własnej macierzy optyki, a ogólny PID nie mapuje się na żadną wspieraną optykę, więc nie ma czego rozluźniać przez override.

Ktoś inny na tym samym wydaniu miał moduły Skylane SPDTU080100D139 na 80 km działające na 9001 - ale tylko z obiema komendami skonfigurowanymi, inaczej interfejs nie wracał do siebie po odbiciu linku. Wadliwa partia została ostatecznie wymieniona na poprawnie zakodowane moduły.

Dorzucam jedną rzecz, dzięki której unikniesz kolejnego okrążenia z dostawcą: proś, żeby kodowali pod platformę, nie pod markę. Spora część tych wątków to moduły, które przedstawiają się jako właściwy vendor, ale niosą part number, o którym macierz platformy nigdy nie słyszała, a override'y typu permit rozluźniają sprawdzenie tylko dla modułów, które poza tym wyglądają dla boxa poprawnie.

Póki moduły są jeszcze na stole, każ im potwierdzić, że EEPROM jest ściśle zgodny z SFF-8472. Niechlujne dane A2h odczytują się jako bzdury - wspomniana wyżej długość fali 0 nm to dokładnie ten smaczek - a gdy odczyt jest już czysty, a platforma nadal odrzuca część, masz coś konkretnego dla wsparcia producenta zamiast ogólnej dyskusji o optyce firm trzecich.