IBM Flex System EN4093 menjatuhkan port trunk SFP+ ke ERRDISABLE saat boot dan saat operasi
Dua enclosure Flex System, masing-masing dengan EN4093R 10Gb Scalable Switch (option 49Y4270) sebagai network module. Port kembali error-disabled setelah chassis mengalami power event, dan lebih jarang jatuh ke state yang sama waktu semuanya sedang berjalan normal. Tidak selalu port yang sama, itu yang bikin ini melelahkan untuk dikejar.
Setup:
- IBM Flex System EN4093 10Gb Scalable Switch, option 49Y4270
- uplink trunk empat port ke core, optik IBM plus satu DAC yang ditambahkan belakangan
- port QSFP+ di-breakout ke arah enclosure kedua
- MSTP jalan di sisi kami, core-nya vendor lain
Yang ditampilkan port list setelah boot:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesSudah dicoba:
- shutdown / no shutdown di port yang terdampak mengembalikan sebagian besar sampai event berikutnya
- bersihkan dan pasang ulang semua fiber di trunk, tidak ada perubahan pada polanya
- bandingkan konfigurasi port di ujung satunya, speed cocok di atas kertas
Apa sebenarnya yang mendorong port-port ini ke errdisable, dan apakah ada cara menghentikannya terjadi di setiap boot, dibanding membersihkannya manual setiap kali?
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 5
Switch ini punya tujuh state terdokumentasi yang bisa mendisable port, dan hubungan di antara satu dengan yang lain sangat sedikit:
Milikmu itu yang keempat, dan itu yang paling sering ditemui orang, karena itu yang kamu bangun sendiri: campur speed atau tipe modul dalam satu trunk dan switch-nya keberatan. Satu DAC yang duduk di sebelah tiga modul optik saja sudah cukup. Keluarkan DAC itu dari situ dan isi slotnya dengan modul yang cocok dengan tiga lainnya.
Untuk port yang kena flap detector, membouncing-nya masih jadi recovery yang terdokumentasi:
Setelah itu, baca ulang konfigurasi spanning tree di link itu dan periksa copper dan fiber-nya secara manual. Ikuti setiap perubahan konfigurasi dengan reload, atau running state-nya diam-diam berhenti cocok dengan apa yang kamu kira sudah kamu set.
Dua hal yang jangan diharapkan. Dua dari tujuh state itu membuat port tetap down setelah timeout habis dan minta tangan manual di port-nya. Dan tidak ada rilis firmware yang memperbaiki ini - kata vendor, kamu yang harus mengonfigurasi jalan memutarnya, jadi modul yang identik di semua anggota trunk plus fiber yang bersih adalah batas pencegahan yang bisa dilakukan.
Dua alasan berbeda dalam paste yang sama, itu tempat saya akan mulai. Apakah port tertentu selalu kembali disabled dengan alasan yang sama, atau yang jatuh karena capabilities di boot ini bisa memicu flap detector di boot berikutnya? Alasan yang tetap per port dan alasan yang berpindah-pindah itu dua investigasi terpisah, dan cuma salah satunya yang berakhir dengan kamu beli hardware.
Hal kedua yang perlu dipastikan adalah apa yang dijalankan core untuk spanning tree. Kamu pakai MSTP; kalau sisi seberang mengirim BPDU rasa Cisco PVST ke uplink itu, switch ini punya mekanisme proteksi yang bereaksi persis terhadap itu dan menjatuhkan port-nya, dan dari luar itu terlihat seperti kegagalan yang sedang kamu kejar. Bisa kamu lihat apakah ada drop yang sejalan dengan topology change di core, bukan dengan boot kamu sendiri?
Per port konsisten, tapi lintas box tidak. Anggota trunk yang jatuh selalu kembali dengan mismatched link capabilities, dan access port di 5 cuma pernah memicu flap detector, tanpa interval yang bisa saya temukan polanya. Jadi ini memang terlihat seperti dua fault yang pakai jaket sama.
Spanning tree di sisi seberang belum bisa saya jawab - core-nya milik tim lain dan saya sudah tanya mereka apa sebenarnya yang dipancarkan ke uplink itu. Sejauh ini tidak ada di log kami yang mengaitkan drop dengan topology change di sana, tapi saya bacanya untuk link event, bukan untuk itu, jadi saya tidak akan bilang itu sudah tersingkirkan.
Vendor beda, bentuk sama. Kami punya FortiGate 201F yang nyantol ke FortiSwitch 548D lewat SFP+ dengan DAC Fortinet sendiri di antara keduanya, dan link 10Gbps-nya benar-benar tidak mau tetap up - dia drop apa pun yang kami lakukan ke speed dan duplex, dan mengembalikan kedua ujung dari FortiOS 7.4 ke 7.2.5 tidak mengubah apa pun.
Yang akhirnya bertahan adalah DAC Fortinet yang lebih pendek dengan STP dimatikan di link itu saja, dan sejak itu tetap up. Bagian yang layak dibawa adalah alasan yang muncul belakangan: semakin panjang jalur copper pasif, semakin sinyalnya sudah degradasi begitu sampai, jadi di 10G, DAC panjang atau yang marginal mana pun masuk daftar curiga apa pun label yang tercetak di situ. Dengan tiga optik dan satu DAC di trunk yang errdisable, saya akan curiga keras ke yang beda sendiri itu.
Satu hal yang perlu dilakukan sebelum menyentuh hardware apa pun: catat cadence persis dari flap-nya dibanding timestamp log.
Di switch yang sama sekali tidak berhubungan, TL-SG3452X, setiap port SFP+ yang terisi turun dan naik lagi setiap sepuluh sampai lima belas menit dengan pesan STP di log tiap kali flap, dan kesimpulan yang jelas adalah optik rusak - sampai DAC first-party TL-SM5220-1M ikut flap dengan ritme yang persis sama. Itu langsung mematikan teori optik dalam satu test dan malah menunjuk ke regresi firmware; satu-satunya jawaban yang berhasil di situ adalah tetap di build yang lebih lama.
Interval yang teratur berarti ada sesuatu yang timeout sesuai jadwal. Yang acak berarti ada sesuatu yang fisik. Test yang murah, dan itu menghemat kamu dari beli modul yang tidak kamu butuhkan. Ada baiknya juga simpan image firmware sebelumnya supaya downgrade tetap jadi opsi.