Catalyst 3850, bir ThinkSystem SR650 Lenovo 46C3447 SR optik kullanınca portu err-disable yapıyor
Bir kampüs 3850'sine bağlı bir rafa giren yeni bir ESXi host. Bakır üzerindeki yönetim dramasız geldi, 10G uplink'ler gelmedi: sunucu açılır açılmaz switch portu err-disable'a düşüyor ve host o vmnic'te hiçbir şey görmüyor.
- Emulex VFA5.2 2x10GbE SFP+ adaptörlü Lenovo ThinkSystem SR650, 7X06CTO1WW
- adaptördeki Lenovo 10GBASE-SR modülleri, 46C3447
- switch tarafında Cisco SFP-10G-SR'li Cisco WS-C3850-24XS-S
- aralarında OM3 LC-LC patch
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 stableŞimdiye kadar denenenler:
- sunucuyu aynı switch'te farklı bir porta taşıdım, aynı davranış
- 46C3447'yi diğer adaptör portundaki ikiziyle değiştirdim
- taze patch kordon, her iki uç temizlendi ve yeniden oturtuldu
Fiber ve switch tarafındaki optik açıkça sağlam, yani bir şey Lenovo modülüne itiraz ediyor. Burada itiraz eden taraf hangisi, sunucu mu switch mi, ve 3850'yi bununla yaşatmanın bir yolu var mı?
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
O log meseleyi çözüyor.
gbic-invalid, switch'in yetkisiz bir modül olarak okuduğu şeyi reddetmesi, ve ateşlenen kontrol Cisco tarafında yaşıyor, SR650'de değil, ESXi'de hiç değil. O linkteki Lenovo kodlu SR optiğe itiraz ediyor ve link hiç değerlendirilmeden portu öldürüyor, ki portları taşımanın ve kordonları değiştirmenin sizin için hiçbir şeyi değiştirmemesinin nedeni de bu.Global konfigürasyonda iki satır:
Birincisi switch'e tanımadığı bir modülle devam etmesini söylüyor, ikincisi o CRC kontrolü başarısız olduğunda err-disable'ın portu vurmasını durduruyor. İkisi de geriye dönük işlemiyor, yani sonrasında portu sıçratın ve o düşükken fiberi yeniden oturtun:
Yukarı kalktığında konfigürasyonu kaydedin. Sadece running config'te yaşıyorsa, port bir sonraki reload'dan sonra yine err-disabled olarak geri gelir ve bunu çok daha kötü bir anda tekrar debug edersiniz.
İki uyarı. Artık Cisco'nun desteklediği konfigürasyonun dışındasınız: üçüncü parti optikleri test edilmemiş sayıyorlar ve TAC bunu içeren bir birlikte çalışabilirlik vakasını reddedebilir, bu link bir sözleşme altındaysa önemli olan bu. Ve
service unsupported-transceiverevrensel bir çözüm değil. Aynı bad crc mesajı, engel portun kendisi olduğunda hayatta kalıyor, örneğin sadece 1G'lik bir SFP yuvasına itilmiş bir 10G modülü, yani sıçratmadan sonra port düşük kalırsa, optiği tekrar suçlamadan önce her ucun gerçekte hangi hızda çalıştığını kontrol edin.Kimse tahmin etmeden önce: port düştüğünde switch gerçekte neyi loglıyor? Err-disable her zaman nedenini adlandırır, ve neden cevabı tamamen değiştirir. Bir modül hakkında güvenlik ya da CRC şikayeti, bir flap ya da protokol takılmasından farklı bir sorun, ve birinin çözümü diğeri için hiçbir işe yaramaz.
Sunucunun açıldığı andan itibaren
show loggingçekin ve o port için satırları paylaşın. Ayrıca Te1/0/7'de fiziksel olarak ne olduğunu doğrulayın, Cisco SFP-10G-SR diyorsunuz, yani 46C3447 o yoldaki tek Cisco olmayan parça mı?Düştüğü andan log, o port için iki satır:
Yani ateşlenen bir flap değil güvenlik kontrolü. Ve evet, switch ucu bir Cisco kutusundan çıkma gerçek bir Cisco SFP-10G-SR, sunucudaki 46C3447 yoldaki tek Lenovo kodlu parça. Beni şaşırtan da buydu, çünkü mesaj sunucu tarafındaki herhangi bir şey yerine switch'teki portu adlandırıyor.