Oryginalny SFP+ 160-9103-900 wstaje jako UCTF na Ciena 3930 - gdzie jest lista certyfikowanych modułów
Uruchamiam przekazanie 10G dla klienta na 3930, które już było na miejscu. Moduł jest własny Ciena, wzięty z naszego magazynu, i port faktycznie wstaje - ale stan operacyjny to UCTF zamiast Ena, i alarm niecertyfikowanego transceivera siedzi tam na stałe. Test odbiorczy wymaga czystej listy alarmów, więc nie mogę tego przekazać w takim stanie.
- Ciena 3930, oprogramowanie w takiej wersji, w jakiej dostarczono na miejsce
- Ciena 160-9103-900 SFP+ 10G
- para jednomodowa do NTU klienta, krótki dystans
> port xcvr show
Port 1 ... Oper State: UCTFCo wypróbowałem:
- wyjąłem i włożyłem ponownie moduł, przełożyłem go na inny port, ten sam wynik
- założyłem drugi 160-9103-900 z tego samego magazynu, identyczny UCTF
- potwierdziłem, że link przekazuje ruch, więc to nie jest problem optyczny
Spodziewałem się, że moduł oznaczony marką Ciena w switchu Ciena będzie tą jedną kombinacją, która nigdy nie sprawia problemów. Jak mam sprawdzić, które modele transceiverów faktycznie certyfikuje działające oprogramowanie, i co sprawia, że stan niecertyfikowany znika?
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 4
Dokładnie o to chodzi, i to łapie ludzi, bo każdy zakłada, że sprawdzenie dotyczy producenta. Nie dotyczy. Switch porównuje kodowanie, jakie niesie moduł, z listą modeli, które certyfikuje jego własne wydanie oprogramowania. Moduł zbudowany przez Cienę, którego modelu nie ma na tej liście, wstaje jako UCTF, a moduł od vendora kompatybilnej optyki, którego kodowanie pasuje do wpisu na liście, wstaje czysto.
Więc procedura jest taka:
Weź wpis z pierwszego polecenia, który pasuje do szybkości i zasięgu, jakich potrzebujesz, i zdobądź moduły zakodowane pod niego. Mieliśmy ten sam UCTF na 3930 i wstawiliśmy ModuleTek 10G LR SFP+ zakodowany jako XCVR-S10V31, który jest na liście wspieranych - port wstał ze stanem operacyjnym Ena i bez żadnego wskazania niecertyfikowania, a nic innego na switchu nie zostało ruszone.
Zastrzeżenia warte wspomnienia przed przekazaniem klientowi: to jest dopasowanie kodowania, nie oświadczenie vendora o wsparciu, więc jeśli urządzenie jest objęte kontraktem, sprawdź, co umowa mówi o optyce spoza Cieny, zanim to zaprojektujesz. Druga droga to wydanie oprogramowania, które faktycznie wymienia 160-9103-900, ale przy żywej usłudze klienta upgrade zwykle jest tym droższym z dwóch rozwiązań.
Uruchom
port xcvr show supportedi poszukaj swojego modelu w wyniku. Wypisuje modele i szybkości liniowe, które wydanie na urządzeniu jest gotowe certyfikować, i to ta lista się liczy - nie to, co jest wybite na klatce.Wklej, co wróci, albo przynajmniej napisz, czy 160-9103-900 się w tym pojawia. Jeśli nie, masz już odpowiedź, i to, że moduł jest oryginalną Cieną, nie ma tu żadnego znaczenia. Warto też podać, na jakim wydaniu SAOS jest 3930 - lista jest per wydanie, a urządzenie, które siedzi na miejscu od jakiegoś czasu, spokojnie może być starsze niż numer partu, który wymienia dopiero późniejsze oprogramowanie.
Uruchomiłem. Lista jest długa, ale 160-9103-900 nie ma w niej - przejrzałem ją dwa razy. Oprogramowanie jest takie, z jakim urządzenie przyjechało, nikt nie ruszał wydania od czasu instalacji, a
port xcvr showwciąż stawia port na UCTF.Czyli oryginalna sztuka Ciena jest niecertyfikowana na switchu Ciena, bo to wydanie jej nie wymienia. Nie ta odpowiedź, której się spodziewałem, ale wyjaśnia, czemu drugi moduł z tego samego magazynu zachował się identycznie.
Warto dodać scenariusz awarii, gdzie kodowanie nie jest problemem, bo gonienie za kodowaniem jest kosztowne. Na ME3600X z 15.3(1)S miałem
%PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not supportedi err-disable gbic-invalid na modułach 10G.service unsupported-transceiverino errdisable detect cause gbic-invalidniczego nie zmieniły, moduły nigdy nie pojawiły się wshow inventory,show interfacew ogóle nie wypisywał typu nośnika, a miernik optyczny nie widział z nich żadnego światła. Był to martwy zestaw - moduły wzięte z innego ME3600 już działającego w produkcji zadziałały od razu. Brak typu nośnika plus brak światła Tx znaczy sprzęt, i żadna komenda odblokowania tego nie uratuje.Drugi kraniec skali to kodowanie, które jest złe konkretnie dla tej platformy: DWDM SFP+ 80 km firm trzecich w ASR 9001 zostawały w dole z generycznym PID, a
transceiver permit pid allich nie ratował, bo IOS XR chciał PID w kształcie DWDM-SFP10G-xx.yy z macierzy optyki tej platformy. Dostawca przekodował partię i wstały. Twój przypadek leży pomiędzy: kodowanie jest ważne, po prostu nie ma go na liście tego wydania.