EX4200 zgłasza źle zaprogramowany EEPROM SFP+ po aktualizacji Junosa, podczas gdy MX960 nadal pokazuje DOM
Prowadzimy kilka odcinków DWDM na 80 km z EX4200 z optyką innych producentów po obu stronach, bo oryginalne części DWDM producenta nigdy nie mieściły się w budżecie. Przez lata to działało bez problemu. Po przejściu urządzeń EX na Junosa 12.3 optyka nadal siedzi w tych samych portach, a odcinki nadal istnieją, ale switch przestał w ogóle przyznawać, że moduły to optyka.
- EX4200, Junos 12.3 (DOM działało bez zarzutu na 11.4 w tym samym chassis)
- Integra SFPP-C51-80-10GD, DWDM 80 km SFP+
- MX960 na drugim końcu tego samego odcinka, identyczny numer katalogowy, DOM nadal kompletne
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableLog messages wypisuje dokładnie jedną linię przy włożeniu modułu: SFP+ of type 0 EEPROM is Mis Programmed.
Co już wykluczyłem:
- wyjąłem i osadziłem ponownie optykę, przeniosłem ją do innego portu na tym samym chassis, bez zmian;
- wypróbowałem zapasowy EX3300 i QFX5100 w laboratorium, oba zachowują się tak samo, więc to nie jest jedno zepsute urządzenie;
- sprawdziłem jeszcze raz drugi koniec, MX960 daje pełną diagnostykę dla tej samej części z tego samego zamówienia.
Czyli sterownik EX wymusza coś w EEPROM, co starsze wydanie po prostu ignorowało? A jeśli tak, czy da się coś zrobić z samą optyką, czy to jest rozmowa do przeprowadzenia z dostawcą?
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 6
Ta linijka w logu to nie ogólne marudzenie, to sterownik mówiący ci, które sprawdzenie zawiodło.
Bajty od 3 do 10 strony A0 trzymają kody zgodności transceivera opisane w SFF-8472 - bity mówiące 10GBASE-SR, LR, ER, kody SONET, te od Fibre Channel i tak dalej. W tym rodzaju optyki wszystkie osiem bajtów to zera, dlatego komunikat nazywa to type 0. Specyfikacja oczekuje, że w tym polu gdzieś będzie ustawiony przynajmniej jeden bit; pole zgodności samych zer to nieprawidłowy opis modułu. Starszy kod EX nigdy tego nie sprawdzał i szedł prosto do parsowania strony diagnostycznej, nowszy sterownik najpierw waliduje to pole, a potem odmawia potraktowania modułu jako znanej optyki 10G. Stąd unknown cable i brakujące DOM. Linia MX nie uruchamia tego sprawdzenia na tej samej ścieżce, i dlatego dokładnie ta sama część tam nadal działa.
Udowodnij to, zanim zaczniesz się z kimkolwiek spierać: zejdź do powłoki i zrób xcvrpeek strony A0 na tym porcie, a potem spójrz na offsety od 3 do 10. Same zera zamykają sprawę.
Naprawienie tego na miejscu to zwykle ten moment, gdzie wszystko się sypie. Teoretycznie xcvrpoke zapisuje te same bajty z powrotem. W praktyce wielu producentów blokuje stronę A0 i zapis zwraca EIO, i nic z tym nie zrobisz od strony switcha. Co zostaje, to dostawca: albo wysyła optykę zaprogramowaną z prawdziwymi kodami zgodności, albo wysyła ją z odblokowaną A0, żebyś mógł sam ustawić bity. Jeśli nie potrafi zrobić ani jednego, ani drugiego, to jest problem dostawcy przebrany za problem Junosa.
Dwie rzeczy warto ustalić, zanim ktokolwiek zacznie zgadywać.
Po pierwsze, dokładne wydanie na każdym urządzeniu. Mówisz, że EX poszedł na 12.3, ale co działa na MX960? Jeśli to nadal starsza gałąź, to te dwa urządzenia nie są tak naprawdę porównywalne i różnica na razie nic nie mówi.
Po drugie, czy część po stronie MX to dosłownie ten sam SFPP-C51-80-10GD z tej samej partii, czy ten sam model z innego zamówienia? Partie różnią się bardziej, niż ktokolwiek by chciał.
Wklej
show interfaces diagnostics opticsz obu końców, plus wszystko, co messages log wypisuje, kiedy wyjmujesz i wkładasz optykę z powrotem, nie tylko tę jedną linijkę, którą już zacytowałeś.Ta sama część po obu stronach, SFPP-C51-80-10GD, to samo zamówienie, kolejne numery seryjne.
Na MX960
show interfaces diagnostics opticsdaje pełny zestaw: temperaturę, prąd polaryzacji lasera, moc TX, moc RX. Na EX4200 to samo polecenie wypisuje nagłówek interfejsu, a potem linię unknown cable, nic więcej. Ponowne włożenie optyki daje w loguSFP+ of type 0 EEPROM is Mis Programmedi nic ponad to, bez względu na to, którego portu używam.Co mnie niepokoi, to że przed aktualizacją dokładnie ta sama optyka w dokładnie tym samym chassis i porcie zgłaszała DOM bez słowa skargi.
Warto dodać, że połowa tego dotycząca samego odczytu istnieje też po drugiej stronie płotu. Na Cisco
show idprom interface <if> detailzrzuca bajty identyfikacyjne bez żadnej gimnastyki w powłoce, co jest wygodne do sprawdzenia partii na zapasowym switchu, zanim moduły trafią w pobliże urządzenia Juniper.Odczyt jest wszędzie nieszkodliwy. Zapis z hosta to zupełnie inne zwierzę: xcvrpoke to narzędzie wewnętrzne, nie jest wspierane jako sposób naprawy modułów, i jak już wspomniano, blokuje go vendor lock mniej więcej w połowie przypadków. Użyj go, żeby udowodnić, co jest nie tak z EEPROM, a potem przekaż ten dowód temu, kto sprzedał ci optykę.
Ta sama klasa problemu, zupełnie inny objaw, na wypadek gdyby ktoś tu trafił z wyszukiwarki.
Wsadziliśmy bezimienny SFP BiDi WDM 1G do ge-0/0/1 na EX4600 i interfejs po prostu nie istniał. Brakowało go w
show interfaces terse, a każde polecenie wobec niego wracało zerror: device ge-0/0/1 not found. Log mówiłOPTIC State changed for port: 0/0/1, a potemFibre channel transceiver plugged in without Fibre channel configuration!!. EEPROM był zakodowany tak, że Junos klasyfikował moduł jako transceiver Fibre Channel zamiast Gigabit Ethernet, więc żaden interfejs Ethernet nigdy dla niego nie powstał. Żadna ilość konfiguracji tego nie naprawi, poprawnie zakodowany moduł owszem.I to nie dotyczy tylko taniego końca rynku. Była partia SFP+ 10G sygnowanych przez Citrix, przez którą urządzenia NetScaler MPX i SDX logowały przy starcie
*** Unsupported SFP+/SFP type !na własnych częściach producenta. Dobre egzemplarze mają na etykiecie oznaczenie rewizji A2, złe wróciły na RMA. Złe kodowanie zdarza się na każdym poziomie cenowym.Potwierdzam, i dzięki za dokładne offsety.
xcvrpeek na stronie A0 pokazuje offsety od 3 do 10 jako zera na każdym z egzemplarzy SFPP-C51-80-10GD, które sprawdziłem, łącznie z tymi, które nadal są w pudełkach. xcvrpoke od razu wraca z EIO, więc A0 jest zablokowana i po naszej stronie nie ma czego ratować.
Wróciłem do dostawcy z offsetami bajtów i zacytowaną linijką z logu. Przyjęli to i przekodowują partię z prawdziwymi kodami zgodności; te siedzące w MX960 zostają tam, gdzie są, bo na tej platformie nic nie narzeka. Oznaczam powyższe wyjaśnienie jako odpowiedź.