IBM Flex System EN4093 बूट के समय और ऑपरेशन के दौरान SFP+ ट्रंक पोर्ट्स को ERRDISABLE में डाल देता है
दो Flex System enclosures हैं, हर एक में network module के तौर पर EN4093R 10Gb Scalable Switch (option 49Y4270) लगा है। chassis पर power event के बाद ports वापस error-disabled हो जाते हैं, और कभी-कभी सब कुछ चलते हुए भी उसी state में चले जाते हैं। हर बार same ports नहीं होते, इसी वजह से इसे chase करना इतना थकाने वाला है।
Setup:
- IBM Flex System EN4093 10Gb Scalable Switch, option 49Y4270
- core की तरफ चार ports का uplink trunk, IBM optics plus एक DAC जो बाद में add किया गया
- दूसरे enclosure की तरफ break out किया हुआ QSFP+ port
- हमारी तरफ MSTP चल रहा है, core किसी दूसरे vendor का है
boot के बाद port list में यह दिखता है:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesTry किया:
- affected ports पर shutdown / no shutdown करने से ज्यादातर वापस आ जाते हैं, अगले event तक
- trunk की हर fibre साफ करके reseat की, pattern में कोई फर्क नहीं
- far-end port की configuration compare की, speeds कागज़ पर match करती हैं
असल में इन ports को errdisable में क्या धकेल रहा है, और क्या कोई तरीका है जिससे हर boot पर यह होना रुक जाए, बजाय इसके कि हर बार हाथ से clear करना पड़े?
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 में सात documented states हैं जो किसी port को disable कर सकती हैं, और इनका आपस में लेना-देना लगभग नहीं है:
आपका मामला चौथा वाला है, और यही वह है जिससे ज्यादातर लोग टकराते हैं, क्योंकि यह खुद अपने हाथों बनाई हुई problem है: एक ही trunk के अंदर module speeds या types मिला दो और switch को ऐतराज़ हो जाता है। तीन optical modules के साथ एक DAC होना ही काफी है। वहां से DAC हटाइए और slot में बाकी तीन जैसा ही module लगाइए।
flap detector वाले port के लिए, उसे bounce करना अभी भी documented recovery है:
उसके बाद, उस link पर spanning tree की configuration वापस पढ़िए और copper और fibre को हाथ से एक-एक करके check कीजिए। किसी भी configuration change के बाद reload ज़रूर कीजिए, वरना running state चुपचाप उससे अलग हो जाती है जो आपने सोचा था कि set किया है।
दो चीज़ों की उम्मीद मत रखिए। इन सात states में से दो timeout खत्म होने के बाद भी port को down रखती हैं और port पर हाथ लगाने की मांग करती हैं। और कोई firmware release इसे ठीक नहीं करती - vendor का कहना है कि आप configuration से इसके इर्द-गिर्द रास्ता निकालें, तो हर trunk member में identical modules रखना और fibre साफ रखना, prevention में बस इतना ही हो सकता है।
मैं यहीं से शुरू करूंगा: एक ही paste में दो अलग-अलग reasons। क्या कोई particular port हमेशा एक ही reason से disabled होकर वापस आता है, या जो इस boot में capabilities पर गिरा वह अगली बार flap detector को trip करता है? एक reason जो per-port fixed रहता है और एक जो घूमता रहता है, ये दो अलग investigations हैं, और इनमें से सिर्फ एक का अंत hardware खरीदने पर होता है।
दूसरी चीज़ जो पक्की करनी ज़रूरी है वह यह है कि core पर spanning tree के लिए क्या चल रहा है। आप MSTP पर हैं; अगर far side उन uplinks पर Cisco-flavoured PVST BPDUs डाल रहा है, तो इस switch में एक protection mechanism है जो ठीक इसी पर react करता है और port को down कर देता है, और बाहर से देखने पर यह वैसा ही लगता है जैसी failure आप पहले से chase कर रहे हैं। क्या आप बता सकते हैं कि कोई drop core पर topology change के साथ मिलता है, या सिर्फ आपके अपने boots के साथ?
Per port यह consistent है, पूरे box में नहीं। जो trunk members गिरते हैं वे हमेशा mismatched link capabilities के साथ वापस आते हैं, और port 5 वाला access port सिर्फ flap detector को trip करता है, किसी ऐसे interval पर नहीं जिसमें मुझे pattern मिले। तो लगता तो यही है कि ये एक ही जैकेट पहने दो अलग faults हैं।
far side पर spanning tree का जवाब मैं अभी नहीं दे सकता - core दूसरी team का है और मैंने उनसे पूछा है कि वे उन uplinks पर असल में क्या emit करते हैं। अभी तक हमारे log में कोई drop वहां के topology change से नहीं जुड़ता, लेकिन मैं उसे link events के लिए पढ़ रहा था, उसके लिए नहीं, इसलिए मैं इसे ruled out नहीं कहूंगा।
Vendor अलग है, shape वही है। हमारे यहां एक FortiGate 201F, FortiSwitch 548D से SFP+ पर लटका था, बीच में Fortinet का अपना DAC था, और 10Gbps link किसी भी हाल में stay up नहीं होता था - speed और duplex के साथ जो भी किया वह drop हो जाता, और दोनों ends को FortiOS 7.4 से 7.2.5 पर वापस लाने से भी कुछ नहीं बदला।
आखिर में जो चीज़ टिकी वह थी एक छोटा Fortinet DAC, उस एक link पर STP बंद करके, और तब से वह up है। जो बात आगे काम आएगी वह है बाद में निकाला गया तर्क: passive copper run जितना लंबा होगा, signal पहुंचते-पहुंचते उतना ही ज्यादा degrade हो चुका होगा, तो 10G पर कोई भी लंबा या borderline DAC suspect list में रहना चाहिए, चाहे उस पर लेबल कुछ भी लिखा हो। तीन optics और एक DAC वाले errdisable trunk में, मैं उस odd one out पर गहराई से नज़र डालूंगा।
hardware को हाथ लगाने से पहले एक काम करें: flaps की exact cadence को log timestamps के साथ मिलाकर लिख लें।
एक बिल्कुल अलग switch पर, एक TL-SG3452X, हर populated SFP+ port हर दस से पंद्रह मिनट में down होकर वापस up हो रहा था, हर flap पर log में STP messages के साथ, और सीधा नतीजा यही लगता था कि optics खराब हैं - जब तक कि एक first-party TL-SM5220-1M DAC ने बिल्कुल उसी rhythm में flap नहीं किया। इसने एक ही test में optics वाली theory खत्म कर दी और इशारा किया firmware regression की तरफ; वहां जो एकमात्र काम करने वाला जवाब था वह था पुराने build पर बने रहना।
एक regular interval का मतलब है कि कुछ किसी schedule पर timeout हो रहा है। random वाला मतलब कुछ physical है। सस्ता test है, और उन modules को खरीदने से बचाता है जिनकी ज़रूरत नहीं। पुरानी firmware image को संभालकर रखना भी काम आता है ताकि downgrade का option table पर बना रहे।