Penguncian vendor dan “unsupported transceiver” · Masalah umum dan solusi · Transceiver optik dan kabel · Dokumentasi · CodingBox
CodingBox Dokumentasi

Penguncian vendor dan “unsupported transceiver”

Masalah transceiver paling umum yang ada. Vendor switch dan NIC — Cisco, Intel, HPE/Aruba, Juniper, Mellanox, dan lain-lain — memeriksa string identifikasi yang dilaporkan sebuah modul dari EEPROM-nya, lalu menolak atau menandai modul yang tidak mereka kenali.

Hal utama yang dipelajari engineer dengan cara yang sulit: “tidak didukung” tidak berarti “tidak akan berfungsi”. Pada sebagian besar platform, status ini bersifat informasional saja dan port tetap bisa dibuat up.

Gejala

PlatformApa yang Anda lihat
Cisco IOSPort notconnect — unsupported; log %C4K_TRANSCEIVERMAN-3-INCOMPATIBLE
Cisco IOS setelah upgradePort berpindah ke errdisable, alasan gbic-invalid
MellanoxEEPROM terbaca tetapi tidak ada link: speed and type: Not supported
Intel X520 / ixgbeno carrier dengan SFP non-Intel

Yang berhasil

Cisco. Dua perintah ini rutin ditanamkan ke dalam konfigurasi dasar untuk mengizinkan modul pihak ketiga pada semua port:

service unsupported-transceiver
no errdisable detect cause gbic-invalid

Keunikan platform: pada sebagian build Catalyst 9200, perintah pertama mengembalikan % Ambiguous command — ketik perintahnya secara lengkap; pada Nexus 9000 ini adalah perintah tersembunyi tanpa tab-completion, tetapi tetap diterima.

Intel X520 (Linux). Muat driver dengan opsi yang mengizinkan modul non-Intel:

modprobe ixgbe allow_unsupported_sfp=1

Ada varian persisten yang membalik satu bit di EEPROM milik NIC itu sendiri dan didokumentasikan di sumber-sumber di bawah — perlakukan dengan hati-hati, karena penulisan yang salah ke EEPROM NIC tidak dapat dipulihkan di lapangan.

Seri ASR 9000. Modul yang dipasang ke port yang sudah up mungkin tidak terdeteksi: shut port tersebut, pasang modulnya, lalu no shut.

Perbaikan radikal — kodekan ulang modulnya. Tulis ulang vendor ID dan nomor part modul tersebut sehingga modul menampilkan dirinya sebagai modul native. Inilah yang dilakukan CodingBox di EEPROM editor, dengan CC_BASE/CC_EXT dihitung ulang dan backup diambil terlebih dahulu. Lihat Pengodean ulang EEPROM untuk mekanismenya.

Saran yang diulang semua orang

Simpan satu modul OEM asli dari setiap jenis di rak. Pasang modul tersebut sebelum membuka tiket dukungan, sehingga vendor tidak bisa menyalahkan optik pihak ketiga atas masalah itu.

Memverifikasi pada switch

Setelah melakukan salah satu di atas, konfirmasikan modul terlihat dan terbaca: lihat Memverifikasi optik pada switch untuk perintah per-NOS, dan bandingkan dengan data identifikasi yang dibaca CodingBox di meja kerja.

Apa persisnya yang dibandingkan host — nama, PN, OUI, pola serial, signature vendor — dan pada langkah bring-up yang mana penolakan terjadi: Bidang vendor, Apa yang dilakukan host.

Perilaku validasi dan override per-vendor dalam satu tabel: Bagaimana setiap NOS memvalidasi modul; string PN persis yang diharapkan platform: Penomoran part OEM; sintaks perintah per NOS: Resep konfigurasi port.


Jika Anda menemukan ketidakakuratan atau kesalahan dalam artikel ini, pilih bagian teks yang bersangkutan lalu tekan Ctrl+Enter untuk .