Catalyst 3850 nge-err-disable port pas ThinkSystem SR650 pakai optik SR Lenovo 46C3447
Host ESXi baru masuk ke rack yang nyambung ke 3850 campus. Management di copper naik tanpa drama, uplink 10G-nya nggak: begitu server boot, port switch-nya langsung jatuh ke err-disable dan host-nya nggak lihat apa-apa di vmnic itu.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, dengan adapter Emulex VFA5.2 2x10GbE SFP+
- modul Lenovo 10GBASE-SR, 46C3447, di adapternya
- Cisco WS-C3850-24XS-S dengan Cisco SFP-10G-SR di sisi switch
- patch OM3 LC-LC di antara keduanya
Te1/0/7: goes err-disabled within seconds of the server powering on
ESXi: the uplink shows DISCONNECTED
Same patch cord, Cisco SFP-10G-SR at both ends switch to switch: link up and stableYang sudah dicoba:
- pindahin server ke port lain di switch yang sama, hasilnya sama
- tukar 46C3447 dengan kembarannya dari port adapter satunya
- patch cord baru, dibersihin dan dipasang ulang di kedua ujung
Fiber dan optik di sisi switch jelas-jelas nggak masalah, jadi ada sesuatu yang nolak modul Lenovo-nya. Yang nolak ini sebenarnya sisi mana, server atau switch, dan ada cara nggak biar si 3850 bisa hidup berdampingan sama modul ini?
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 3
Log itu yang mastiin.
gbic-invaliditu switch-nya nolak apa yang dia baca sebagai modul nggak sah, dan pengecekan yang jalan ada di sisi Cisco, bukan di SR650 dan bukan di ESXi. Dia nolak optik SR ber-kode Lenovo di link itu dan matiin port-nya sebelum link-nya sempat dievaluasi, makanya pindah port dan tukar kabel nggak ngubah apa-apa buat kamu.Dua baris di global configuration:
Baris pertama nyuruh switch-nya tetep jalan sama modul yang dia nggak kenal, baris kedua nyetop err-disable nembak port-nya waktu pengecekan CRC itu gagal. Dua-duanya nggak retroaktif, jadi bounce port-nya abis itu dan pasang ulang fiber-nya selagi down:
Simpan configuration-nya begitu udah up. Kalau cuma ada di running config, port-nya bakal balik err-disabled abis reload berikutnya dan kamu bakal debug ini lagi di momen yang jauh lebih buruk.
Dua catatan. Kamu sekarang di luar configuration yang didukung Cisco: mereka anggap optik pihak ketiga itu untested dan TAC bisa nolak kasus interoperability yang melibatkan itu, yang penting kalau link ini ada di bawah kontrak. Dan
service unsupported-transceiverbukan solusi universal. Pesan bad crc yang sama tetap muncul kalau port-nya sendiri yang jadi penghalang, misalnya slot SFP 1G-only yang dipaksain modul 10G, jadi kalau port-nya tetap down abis di-bounce, cek dulu speed yang beneran jalan di tiap ujung sebelum nyalahin optiknya lagi.Sebelum ada yang nebak-nebak: switch-nya sebenarnya nyatet apa waktu port-nya down? Err-disable selalu nyebutin penyebabnya, dan penyebabnya itu yang ngubah jawabannya total. Keluhan security atau CRC soal modul itu masalah yang beda dari flap atau protocol trip, dan obat buat satu nggak ngaruh buat yang lain.
Ambil
show loggingdari sekitar momen server-nya nyala dan post baris-barisnya buat port itu. Terus konfirmasi juga apa yang beneran nangkring di Te1/0/7, kamu bilang Cisco SFP-10G-SR, jadi apa 46C3447 itu satu-satunya part non-Cisco di sepanjang path itu?Log dari momen dia drop, dua baris buat port itu:
Jadi ini pengecekan security yang jalan, bukan flap. Dan iya, ujung switch-nya beneran Cisco SFP-10G-SR asli dari box Cisco, 46C3447 di server itu satu-satunya part ber-kode Lenovo di sepanjang path-nya. Itu yang bikin saya bingung, soalnya pesannya nyebutin port di switch-nya, bukan apa pun di sisi server.