EX4200 melaporkan EEPROM SFP+ mis-programmed setelah upgrade Junos, sementara MX960 masih menampilkan DOM
Kami menjalankan beberapa span DWDM 80 km dari EX4200 dengan optik pihak ketiga di kedua ujung, karena part DWDM bermerek vendor tidak akan pernah masuk budget. Itu baik-baik saja selama bertahun-tahun. Setelah box EX-nya dipindah ke Junos 12.3, optiknya masih duduk di port yang sama dan span-nya masih ada, tapi switch-nya berhenti mengakui kalau modul-modul itu optik sama sekali.
- EX4200, Junos 12.3 (DOM bekerja normal di 11.4 pada chassis yang sama)
- Integra SFPP-C51-80-10GD, SFP+ DWDM 80 km
- MX960 di ujung jauh dari span yang sama, part number identik, DOM masih lengkap
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableLog messages mencetak persis satu baris waktu modulnya dipasang: SFP+ of type 0 EEPROM is Mis Programmed.
Yang sudah saya singkirkan dari daftar kemungkinan:
- pasang ulang optiknya dan pindahkan ke port lain di chassis yang sama, tidak ada perubahan;
- coba EX3300 cadangan dan QFX5100 di lab, keduanya berperilaku sama, jadi ini bukan satu box yang rusak;
- cek lagi ujung jauhnya, MX960 memberikan diagnostik lengkap untuk part yang sama dari order yang sama.
Jadi apa driver EX ini memberlakukan sesuatu di EEPROM yang cuma diabaikan begitu saja oleh rilis lama? Dan kalau memang begitu, apa ada yang bisa dilakukan ke optiknya sendiri, atau ini obrolan yang harus dibawa ke supplier?
Comments 6
Baris log itu bukan gerutuan generik, itu driver-nya bilang persis cek mana yang gagal.
Byte 3 sampai 10 di halaman A0 menyimpan compliance code transceiver yang dijelaskan di SFF-8472 - bit-bit yang bilang 10GBASE-SR, LR, ER, kode SONET, kode Fibre Channel, dan seterusnya. Di optik jenis ini kedelapan byte-nya nol semua, makanya pesannya menyebutnya type 0. Spesifikasinya mengharapkan setidaknya satu bit di suatu tempat di field itu yang di-set; field compliance yang semuanya nol bukan deskripsi modul yang valid. Kode EX yang lama tidak pernah mengecek itu dan langsung parsing halaman diagnostik, driver yang lebih baru memvalidasi field itu dulu baru menolak memperlakukan modulnya sebagai optik 10G yang dikenal. Makanya muncul unknown cable dan DOM yang hilang. Lini MX tidak menjalankan cek itu di jalur yang sama, dan itu persis kenapa part yang identik masih bekerja di sana.
Buktikan dulu sebelum berdebat dengan siapa pun: masuk ke shell dan xcvrpeek page A0 di port itu, lalu lihat offset 3 sampai 10. Kalau semuanya nol, kasusnya selesai.
Memperbaikinya langsung di tempat, ini biasanya yang berantakan. Secara teori xcvrpoke bisa menulis balik byte-byte yang sama itu. Pada praktiknya banyak vendor mengunci halaman A0 dan penulisannya balik dengan EIO, dan tidak ada yang bisa kamu lakukan soal itu dari sisi switch. Yang tersisa adalah supplier-nya: entah mereka mengirim optik yang sudah diprogram dengan compliance code yang benar, atau mengirimnya dengan A0 yang tidak terkunci supaya kamu bisa set bit-nya sendiri. Kalau mereka tidak bisa melakukan keduanya, itu masalah supplier yang menyamar jadi masalah Junos.
Dua hal yang perlu dipastikan dulu sebelum ada yang mulai menebak-nebak.
Pertama, rilis persis di masing-masing box. Kamu bilang EX-nya naik ke 12.3, tapi MX960-nya jalan di apa? Kalau itu masih di train yang lebih lama, kedua box ini sebenarnya tidak benar-benar sebanding dan perbedaannya belum memberi tahu apa-apa.
Kedua, apakah part di sisi MX itu benar-benar SFPP-C51-80-10GD yang sama dari batch yang sama, atau model yang sama dari order yang berbeda? Batch bisa beda-beda lebih dari yang diinginkan siapa pun.
Posting
show interfaces diagnostics opticsdari kedua ujung, plus semua yang dicetak log messages waktu kamu cabut dan pasang ulang optiknya, jangan cuma satu baris yang sudah kamu kutip.Part yang sama di kedua ujung, SFPP-C51-80-10GD, order yang sama, serial yang berurutan.
Di MX960
show interfaces diagnostics opticsmemberikan set lengkap: temperature, laser bias current, TX power, RX power. Di EX4200 command yang sama cuma mencetak header interface lalu baris unknown cable, tidak ada yang lain. Memasang ulang optiknya menghasilkanSFP+ of type 0 EEPROM is Mis Programmeddi log dan tidak ada lagi, di port mana pun yang saya coba.Yang bikin saya terganggu, sebelum upgrade optik yang persis sama ini, di chassis dan port yang persis sama ini, melaporkan DOM tanpa keluhan sepatah kata pun.
Perlu ditambahkan, separuh sisi read-only ini juga ada di seberang pagar. Di Cisco,
show idprom interface <if> detailmem-dump byte identifikasi tanpa akrobat shell sama sekali, yang berguna untuk mengecek satu batch di switch cadangan sebelum modulnya mendekati box Juniper mana pun.Membaca itu tidak berbahaya di mana pun. Menulis dari sisi host itu hewan yang berbeda: xcvrpoke itu tool internal, tidak didukung sebagai cara untuk memperbaiki modul, dan seperti sudah disebutkan, itu diblokir oleh vendor lock kira-kira separuh waktu. Pakai itu untuk membuktikan apa yang salah dengan EEPROM-nya, lalu serahkan buktinya ke siapa pun yang menjual optik itu ke kamu.
Kelas masalah yang sama, gejala yang sama sekali berbeda, siapa tahu ada yang nyasar ke sini dari hasil pencarian.
Kami pasang SFP WDM BiDi 1G tanpa merek ke ge-0/0/1 sebuah EX4600 dan interface-nya sama sekali tidak ada. Hilang dari
show interfaces terse, dan command apa pun ke situ balik denganerror: device ge-0/0/1 not found. Log-nya bilangOPTIC State changed for port: 0/0/1laluFibre channel transceiver plugged in without Fibre channel configuration!!. EEPROM-nya di-coding sedemikian rupa sehingga Junos mengklasifikasikan modul itu sebagai transceiver Fibre Channel, bukan Gigabit Ethernet, jadi tidak ada interface Ethernet yang pernah dibuat untuknya. Tidak ada konfigurasi sebanyak apa pun yang bisa memperbaiki itu; modul yang coding-nya benar yang bisa.Dan ini bukan cuma soal ujung murah pasar. Ada satu batch SFP+ 10G bermerek Citrix yang bikin appliance NetScaler MPX dan SDX mencatat
*** Unsupported SFP+/SFP type !saat boot, padahal itu part resmi vendornya sendiri. Unit yang bagus membawa tanda revisi A2 di labelnya, yang jelek dikembalikan lewat RMA. Coding yang buruk terjadi di semua level harga.Terkonfirmasi, dan terima kasih untuk offset yang presisi itu.
xcvrpeek di halaman A0 menunjukkan offset 3 sampai 10 nol semua di setiap unit SFPP-C51-80-10GD yang saya cek, termasuk yang masih di dalam box. xcvrpoke langsung balik dengan EIO, jadi A0-nya terkunci dan tidak ada yang bisa diselamatkan dari sisi kami.
Sudah kembali ke supplier dengan offset byte dan baris log yang dikutip. Mereka menerimanya dan sedang me-recode batch itu dengan compliance code yang sebenarnya; yang terpasang di MX960 tetap di tempatnya, karena tidak ada yang mengeluh di platform itu. Menandai penjelasan di atas sebagai jawabannya.