IBM Flex System EN4093, boot sırasında ve çalışma sırasında SFP+ trunk portlarını ERRDISABLE'a düşürüyor
İki Flex System enclosure, her birinde ağ modülü olarak bir EN4093R 10Gb Scalable Switch (option 49Y4270). Bir chassis güç olayından sonra portlar error-disabled olarak geri geliyor, ve daha az sıklıkla her şey çalışırken aynı duruma düşüyor. Her zaman aynı portlar değil, bu da işi kovalamayı bu kadar yorucu yapan şey.
Kurulum:
- IBM Flex System EN4093 10Gb Scalable Switch, option 49Y4270
- core'a dört portluk uplink trunk, IBM optikler artı sonradan eklenen bir DAC
- ikinci enclosure'a doğru breakout edilmiş QSFP+ portu
- bizim tarafımızda MSTP çalışıyor, core farklı bir vendor
Bir boot'tan sonra port listesinin gösterdiği:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesDenenenler:
- etkilenen portlarda shutdown / no shutdown, bir sonraki olaya kadar çoğunu geri getiriyor
- trunk'taki her fiberi temizledim ve yeniden oturttum, kalıpta değişiklik yok
- karşı uç port yapılandırmasını karşılaştırdım, hızlar kağıt üzerinde eşleşiyor
Bu portları gerçekte errdisable'a iten ne, ve her seferinde elle temizlemek yerine bunu her boot'ta olmaktan alıkoymanı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 5
Bu switch'te bir portu devre dışı bırakacak yedi belgelenmiş durum var, ve birbirleriyle pek az ilgileri var:
Sizinki dördüncüsü, ve çoğu insanın karşılaştığı da bu, çünkü bu kendi kendinize inşa ettiğiniz bir durum: tek bir trunk içinde modül hızlarını ya da tiplerini karıştırın, switch itiraz eder. Üç optik modülün yanında oturan bir DAC yeterli. DAC'ı oradan çıkarın ve slotu diğer üçle eşleşen bir modülle doldurun.
Flap detector'a takılan port için, onu sıçratmak hâlâ belgelenen kurtarma yöntemi:
Bundan sonra, o linkteki spanning tree yapılandırmasını geri okuyun ve bakırı ve fiberi elle gözden geçirin. Her yapılandırma değişikliğinin ardından bir reload yapın, yoksa running state, ayarladığınızı düşündüğünüz şeyle sessizce eşleşmemeye başlar.
Beklenmemesi gereken iki şey. Bu yedi durumdan ikisi, timeout süresi dolduktan sonra da portu down tutuyor ve porta elle müdahale istiyor. Ve hiçbir firmware sürümü bunu düzeltmiyor - vendor'ın söylediği, bunun etrafından yapılandırmayla dolaşmanız gerektiği, yani her trunk üyesinde aynı modüller artı temiz fiber, önlemenin gidebileceği en uç nokta.
Başlayacağım yer aynı paste içindeki iki farklı sebep. Belirli bir port her zaman aynı sebeple mi disabled geri geliyor, yoksa bu boot'ta capabilities yüzünden düşen bir sonrakinde flap detector'ı mı tetikliyor? Port başına sabit kalan bir sebep ile gezinen bir sebep iki ayrı soruşturma, ve sadece biri sizi donanım satın almaya götürüyor.
Sabitlenmeye değer ikinci şey, core'un spanning tree için ne çalıştırdığı. Siz MSTP'desiniz; karşı taraf o uplink'lere Cisco tarzı PVST BPDU'ları koyuyorsa, bu switch'te tam olarak buna tepki verip portu düşüren bir koruma mekanizması var, ve dışarıdan bakınca zaten kovaladığınız arıza gibi görünüyor. Düşüşlerden herhangi birinin kendi boot'larınızla değil core'daki bir topoloji değişikliğiyle hizalanıp hizalanmadığını söyleyebilir misiniz?
Port başına tutarlı, kutu genelinde değil. Düşen trunk üyeleri her zaman mismatched link capabilities ile geri geliyor, ve 5'teki access portu sadece flap detector'ı tetikliyor, içinde bir kalıp bulamadığım bir aralıkta. Yani gerçekten aynı ceketi giyen iki ayrı arıza gibi görünüyor.
Karşı taraftaki spanning tree'yi henüz cevaplayamam - core başka bir takıma ait ve o uplink'lerde gerçekte ne yaydıklarını sordum. Bizim logumuzda şimdiye kadar bir düşüşü oradaki bir topoloji değişikliğine bağlayan hiçbir şey yok, ama onu bunun için değil link olayları için okuyordum, yani elendi demezdim.
Farklı vendor, aynı şekil. Aralarında Fortinet'in kendi DAC'ı olan, bir FortiSwitch 548D'ye SFP+ üzerinden asılı bir FortiGate 201F'imiz vardı, ve 10Gbps link bir türlü up kalmıyordu - hıza ve duplex'e ne yaparsak yapalım düşüyordu, ve her iki ucu FortiOS 7.4'ten 7.2.5'e geri almak hiçbir şeyi değiştirmedi.
Sonunda tutan şey, o tek linkte STP kapatılmış daha kısa bir Fortinet DAC oldu, ve o zamandan beri up. Taşımaya değer kısım, sonrasında gelen mantık: pasif bakır hat ne kadar uzunsa, sinyal vardığında o kadar bozulmuş oluyor, yani 10G'de üzerinde ne yazıyor olursa olsun herhangi bir uzun ya da sınırda DAC şüpheli listesine giriyor. Bir errdisable trunk'ta üç optik ve bir DAC varken, aykırı olana sıkı sıkı bakardım.
Herhangi bir donanıma dokunmadan önce yapılacak bir şey: flap'lerin tam ritmini log zaman damgalarına karşı not edin.
Tamamen ilgisiz bir switch'te, bir TL-SG3452X'te, dolu her SFP+ portu her on-on beş dakikada bir düşüp geri geliyordu, her flap'te logda STP mesajlarıyla birlikte, ve bariz sonuç kötü optiklerdi - ta ki birinci parti bir TL-SM5220-1M DAC tam olarak aynı ritimde flap yapana kadar. Bu, tek bir testte optik teorisini öldürdü ve bunun yerine bir firmware regresyonunu işaret etti; oradaki tek işe yarayan cevap daha eski build'de kalmaktı.
Düzenli bir aralık, bir şeyin bir programda timeout olduğu anlamına gelir. Rastgele bir aralık ise fiziksel bir şey anlamına gelir. Ucuz bir test, ve ihtiyacınız olmayan modülleri satın almaktan kurtarır. Önceki firmware image'ını elde tutmak da işe yarar, böylece bir downgrade masada kalır.