Optik SFP+ third-party tetap down di DCS-7150S-24 bekas: file flash enable3px masih jadi opsi?
Saya ambil beberapa switch Arista bekas buat lab dan langsung nabrak optics gate-nya. Modul yang coded Arista link naik, kabel DAC pasif link naik, dan apa pun yang third-party bikin port-nya tetap down.
Sisi lab-nya:
- DCS-7150S-24, dibeli bekas, tidak ada support contract dan tidak ada account team di belakang saya
- macam-macam modul SFP+ third-party
- kabel DAC pasif buat run pendek di dalam rack
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upYang udah saya pahami sejauh ini:
- DAC-nya naik sementara optiknya tidak, itu ngasih tau saya ini coding check, bukan cabling dan bukan cage yang mati
- ada configuration command bentuk
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, yang jelas minta key yang saya tidak punya cara buat dapetin - tulisan lama nyebutin marker file di flash sebagai ganti key, tapi saya tidak bisa mastiin itu berlaku buat generasi yang mana
Dari dua mekanisme itu yang mana yang berlaku buat box seumur ini, dan file flash-nya masih jadi opsi di 7150S, atau key-nya satu-satunya jalan yang tersisa?
Comments 6
Buat generasi itu, jawabannya file, dan itu se-crude yang kedengerannya. Dari EOS CLI:
File kosong, tidak ada isinya sama sekali - keberadaannya doang udah nyalain optik third-party setelah reload. Daftar platform di mana ini jalan itu panjang: DCS-7120T-4S, keluarga DCS-7050, dan seluruh line DCS-7150S di antara yang lain, dan tiap model punya rilis EOS terbaru yang masih menghormati file itu, mulai kira-kira dari 4.13.16M di box paling lama sampai train 4.23 di 7150S. Switch yang lebih baru sama sekali mengabaikan file itu.
Jadi 7150S-24 ada di sisi yang bagus dari garis itu, asal kamu belum pindah ngelewatin apa yang didukung model itu. Coba dulu sebelum kamu deket-deket ke jalur key-nya.
Train EOS apa yang ada di 7150S-24 itu, dan kamu upgrade itu setelah beli? Itu penting, soalnya cut-off-nya per platform, bukan per family. Flag file-nya terdokumentasi jalan di 7048T, 7120T-4S, 7140T-8S, varian SFP+ 7124 dan 7148, seri 7050 dan 7150S, dan line card 7548S-LC, tapi rilis EOS terakhir yang masih menghormati itu beda-beda buat masing-masing.
Kalau kamu udah upgrade EOS di box bekas itu, ada kemungkinan cukup besar kamu udah nge-upgrade diri kamu sendiri keluar dari trik itu, dan fix yang murah itu balik turun satu train ketimbang berburu key.
Belum pernah nyentuh EOS-nya sejak box-nya datang, jadi masih di train mana pun yang ditinggalin seller-nya - yang ternyata beruntung. Udah dikerjain touch, write memory, reload-nya - dan modul SFP+ third-party yang tadinya mati sekarang naik jadi port biasa. Tidak ada key, tidak ada account team, tidak butuh apa-apa lagi. DAC-nya tetap jalan sepanjang waktu, seperti yang diharapkan.
Buat siapa pun yang mendarat di sini dengan box yang lebih baru: file itu beneran diabaikan di situ, dan satu-satunya jalan itu key kriptografis per-customer yang tinggal di running configuration sebagai
Key-nya datang dari account atau sales team, bukan dari support - TAC tidak berwenang ngeluarin unlock key dan bakal ngirim kamu balik ke account management, yang jadi jalan buntu kalau switch-nya berasal dari pasar bekas.
Layak diulang buat lab build: kabel DAC pasif diterima secara default apa pun status unlock-nya. Kalau run-nya cukup pendek, kamu bisa nyamperin seluruh pertanyaan ini dengan cabling pakai DAC dan nyimpen optiknya buat link yang beneran butuh itu.
Koreksi kecil buat "tinggal di running configuration": di kode lama yang pernah saya pakai ada juga varian yang tidak terdokumentasi dari command yang sama, jadi kalau kamu ketemu referensi yang tidak cocok sama syntax di atas, dari situ asalnya, bukan orang yang salah ketik.
Di pengalaman saya, key-nya efektif tanpa reboot juga - kebanyakan optik third-party mulai jalan persis setelah command-nya dimasukin, walau beberapa modul tetap nolak apa pun yang dicoba. Itu udah lama, di hardware yang tidak lagi saya punya, jadi cek di box kamu sendiri sebelum kamu rencanain maintenance window di sekitar itu.
Berhubung perbandingan ini muncul tiap kali topiknya muncul: di Cisco IOS-XE dan IOS XR, yang setara itu dua langkah, bukan satu. Command global-nya sendiri saja tidak cukup, kamu juga butuh yang per-interface di tiap port fisik yang harus nerima modulnya:
Baris per-interface itu yang skip pengecekan product-ID, jadi port-nya minimal bakal nyoba nyalain optiknya - tidak ada jaminan modulnya terus jalan, cuma platform-nya berhenti nolak itu. Saya udah kerjain ini di IOS XR 5.3.3 dan di box IOS-XE.
Caveat-nya sama di kedua vendor, dan itu alasan orang terus berdebat soal ini: kalau satu fault dilacak ke transceiver third-party yang dipasang customer, support di bawah warranty atau contract bisa ditahan. Oke-oke aja buat lab, keputusan yang layak diambil secara sadar di production.