SFP+ DWDM pihak ketiga tetap down di Arista 7050T dengan EOS 4.10.6 - ada cara lain selain patch image?

Sebelum ada yang nunjuk kamu ke image, dua hal dulu.

Kamu sebenarnya terikat ke EOS train yang mana di 7050T itu? Kalau harus tetap di 4.10.6, hack yang spesifik ke satu build itu paling tidak konsisten sama dirinya sendiri. Kalau bisa pindah, paham dulu bahwa penanganan transceiver-nya dirombak di release belakangan dan tidak ada resep yang ditulis buat 4.10.6 yang bisa dipindahin.

Dan supplier itu sebenarnya bisa nge-burn apa ke modulnya? Layak ditanya apakah programmer mereka bawa profile Arista sama sekali, atau cuma coding Cisco per-platform yang kebanyakan mereka simpan - part ASR9K, misalnya, butuh profile sendiri dan vendor optiknya memang menjaga satu. Nyoding ulang batch-nya jauh lebih murah daripada hidup dengan image yang dimodifikasi. Terpisah: kamu udah nanya account team kamu soal unsupported-transceiver key belum, atau itu memang tidak mungkin karena alasan komersial?

Patch image-nya memang bekerja di build yang persis itu, dan tidak terlalu ribet - tapi kerjain di lab atau box cadangan, jangan pernah di apa pun yang bawa traffic.

Bentuknya begini: unzip EOS-4.10.6.swi dan simpan member-nya, yaitu boot0, initrd-i386, linux-i386, rootfs-i386.sqsh, dan version. Unpack root filesystem-nya sebagai root, edit agent-nya, repack:

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

Edit-nya sendiri ada di squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: comment out empat baris dekat line 172 yang assert state presence-nya lalu jalanin authentication transceiver-nya. -Z store di zip-nya itu tidak opsional, swi-nya harus tetap uncompressed atau box-nya tidak akan bisa boot itu.

Setelah itu port-nya naik dengan apa pun yang kamu colok, karena tidak ada lagi yang divalidasi. Dua harganya: kamu tidak punya vendor support di image yang dimodifikasi, dan patch-nya terikat ke build ini, jadi simpan .swi stock-nya di flash buat boot balik ke situ kalau ada yang meleset.

Buat jawab pertanyaan di atas: box-nya cadangan tanpa support contract, dan supplier-nya sama sekali tidak punya profile Arista di programmer mereka - mereka nge-coding buat platform Cisco dan itu akhir dari list-nya, jadi nge-coding ulang batch ini tidak ditawarkan. Jalur account team bukannya tidak mungkin, cuma tidak membantu saya minggu ini.

Saya rebuild 4.10.6 seperti yang dijelaskan, boot image yang di-patch, dan kedua port DWDM-nya naik di percobaan pertama. Image stock-nya masih nongkrong di flash. Link-nya stabil sejak itu, dan sisi seberang tidak lihat apa pun yang aneh.

Senang itu berhasil, tapi jujur aja sama diri sendiri soal umur patch itu, karena thread di atas bikin kedengarannya lebih general dari yang sebenarnya.

Itu ditulis buat 4.10.6 dan tidak lebih. Orang udah nanya cara ngulang ini di 4.14.5F, 4.14.7M, dan 4.23.8M dan tidak ada yang pernah post jawaban yang beneran jalan, karena transceiver manager-nya dirombak di release belakangan dan empat baris itu tidak lagi nongkrong nunggu kamu di situ. Tiap upgrade juga ngeganti image-nya, jadi patch-nya hilang dan port-nya drop di maintenance rutin berikutnya.

Jalur yang selamat lewat upgrade itu key service unsupported-transceiver yang customer-specific dan dikeluarkan account team, dan di platform yang lebih lama, marker file enable3px. Pakai image yang di-patch buat bikin box lama tetap berguna, bukan sebagai standar buat network-nya.

Pertarungan yang sama di sisi Cisco, dengan satu detail yang layak dibawa ke sini. SFP+ DWDM 80 km pihak ketiga (Pro10Optix, berlabel SFP-10G-DWDM-192) sudah jalan di switch Catalyst 6500 tanpa komplain. Dipindah ke port SFP+ built-in di ASR 9001 dengan IOS XR 5.3.3, mereka kasih:

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

LED port merah, interface down, state-nya dilaporkan link loss atau low light tanpa loopback, panjang gelombangnya kebaca 0 nm dan laser-nya tidak pernah nyala. transceiver permit pid all di interface-nya tidak mengubah apa-apa dengan sendirinya, dan service unsupported-transceiver global di atasnya juga tidak menyelamatkan batch itu. Platform-nya mengharapkan part number berbentuk DWDM-SFP10G-xx.yy dari matrix optiknya sendiri, dan PID generic tidak mapping ke optik yang didukung sama sekali, jadi tidak ada apa pun buat override-nya longgarkan.

Ada orang lain di release yang sama yang berhasil jalanin modul Skylane SPDTU080100D139 80 km di 9001 - tapi cuma dengan kedua command-nya dikonfigurasi, kalau tidak interface-nya tidak akan recover setelah link bounce. Batch yang gagal itu akhirnya ditukar dengan modul yang ber-coding benar.

Nambahin satu hal yang hemat satu putaran waktu kamu balik ke supplier: minta mereka coding buat platform-nya, bukan buat brand-nya. Sebagian besar thread kayak gini itu modul yang identify sebagai vendor yang benar tapi bawa part number yang matrix platform-nya belum pernah denger, dan override gaya permit itu cuma melonggarkan pengecekan buat modul yang kalau tidak begitu udah kelihatan benar di mata box-nya.

Selagi modulnya ada di meja mereka, minta mereka konfirmasi EEPROM-nya beneran conform ke SFF-8472. Data A2h yang berantakan kebaca jadi omong kosong - wavelength 0 nm yang disebut di atas itu persis contohnya - dan begitu readout-nya bersih dan platform-nya tetap menolak part-nya, kamu punya sesuatu yang konkret buat vendor support, bukan cuma argumen umum soal optik pihak ketiga.