TL-SG3428X-M2 (V1): किसी भी TL-SM5310-T के साथ SFP+ cage 26 में link नहीं आता, cage 27 उसके साथ blink करके गिरता है
मैं एक छोटे ऑफिस नेटवर्क को संभालता हूं, एक ही switch closet है, और हमारे access switch पर चार SFP+ cages सर्वर रैक तक 10G लिंक ले जाते हैं। यह महीनों बिना किसी दिक्कत के चलता रहा और अब एक cage बस गायब हो गया है।
- TP-Link TL-SG3428X-M2 (V1), firmware 1.20.4 Build 20241104 Rel.40746, Omada में adopted
- SFP+ ports 25-28 में चार TP-Link TL-SM5310-T 10GBASE-T modules
- CAT6A patch cords, दूसरे सिरे पर दो servers और एक NAS
अभी port states ऐसे हैं:
port 25 up, 10G
port 26 down, no link LED with any module
port 27 up, 10G, but drops for a moment whenever a cable goes into or out of port 26
port 28 up, 10Gमैंने जो किया:
- सभी चार cages में modules घुमाकर देखे: 26 वाला module 25 और 28 में ठीक से link करता है, और जो भी module मैं 26 में डालता हूं वह dark ही रहता है, यानी modules खुद ठीक हैं
- नए patch cords, अलग far-end ports, कोई फर्क नहीं
- switch reboot, port disable/enable, कोई फर्क नहीं
जो बात मैं समझ नहीं पा रहा वह यह है कि port 27 तब हिलता है जब मैं सिर्फ port 26 को छूता हूं। क्या cage 26 खराब हो चुका है और RMA के लायक है, या पहले कुछ और चीज़ें rule out करनी चाहिए?
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 6
यह 1.20.4 Build 20241104 में firmware regression है, hardware खराब नहीं हुआ। जो पैटर्न आपने बताया - एक SFP+ cage जो known-good modules के साथ भी कभी नहीं जलता, साथ ही एक पड़ोसी port जो मरे हुए cage को छेड़ने पर झपकता है - यही उस build का TL-SM5310-T copper modules के साथ व्यवहार है।
switch को पिछले release पर वापस ले जाएं और ports वापस आ जाएंगे। व्यवहार में:
TP-Link के अपने लोगों ने माना कि controller v5.14 के लिए adapt किए गए Omada switches पर उस release में कुछ गड़बड़ है, कहा कि इस पर देखा जा रहा है, और फिलहाल पुरानी firmware पर बने रहने की सलाह दी। तो support case hardware पर नहीं, build number पर खर्च करें।
अगर आप वाकई downgrade नहीं कर सकते, तो बस एक ही रास्ता बचता है: जो तीन cages काम कर रहे हैं उन्हीं पर चलें और port 26 खाली रखें। यह कोई fix नहीं है, बस सही release आने तक सेवा में बने रहने का तरीका है।
RMA form भरने से पहले: यह शुरू कब हुआ, और क्या उसी समय के आसपास switch ने कोई firmware update उठाया था? 1.20.4 Build 20241104 काफी नया है, और अगर automatic upgrades चालू छोड़े थे तो controller खुशी-खुशी अपने आप नई image push कर देता है।
यह भी जांच लें: क्या port 27 सिर्फ तब हिलता है जब 26 में कोई module लगा हो, या 26 खाली होने पर भी? एक मरा हुआ cage आमतौर पर पड़ोसी को flap नहीं कराता। यह हिस्सा टूटे हुए solder joint से कहीं ज़्यादा ports के पीछे वाले software जैसा लगता है।
यहां भी वही switch, वही build है, तो आप अकेले नहीं हैं। port 25 ठीक था, port 26 पर मेरे पास मौजूद हर module के साथ link LED नहीं आती थी, और 27 व 28 आते-जाते रहते थे - इनमें से एक EAP783 को feed करता है, तो हर drop बहुत साफ दिखता था। मैंने बिल्कुल वही module बदलने वाली रस्म निभाई और खुद को यकीन दिला लिया कि cage मर चुका है।
cage की गलती नहीं थी। दिक्कत शुरू होने से थोड़ा पहले box ने एक firmware update लिया था, और पिछली image पर वापस जाने से चारों SFP+ ports लौट आए। कहीं कुछ भेजने से पहले update history चेक कर लें।
पुष्टि हो गई, और शर्मिंदगी की बात है कि मैं switch वापस भेजने के कितने करीब पहुंच गया था। update history में दिख रहा है कि ports अजीब होने से कुछ दिन पहले 1.20.4 Build 20241104 आया था, और मैंने इसे कभी हाथ से शुरू नहीं किया, तो यह अपने आप आया।
पिछले release पर rollback किया, re-adopt किया, और अब port 26 समेत चारों cages 10G पर up हैं। जब मैं 26 पर काम करता हूं तो port 27 अब नहीं हिलता। automatic upgrades अब बंद हैं और पुरानी image file server पर config backup के बगल में रखी है।
रिकॉर्ड के लिए: इसी family में एक और firmware trap है जो जानने लायक है। एक TL-SX3008F (V1) पर, जिसमें एक SM5310-T(UN) workstation को feed करता है, firmware 1.20.2 और 1.20.3 में PC sleep में जाते ही या shutdown होते ही SFP+ port मर जाता था। module को खाली cage में ले जाना हर cage पर बस एक बार काम करता था, और सभी cages इस्तेमाल हो जाने के बाद सिर्फ switch reboot से ही ports वापस आते थे। port को 1G पर pin करने से यह टल जाता था, उस speed की कीमत पर जो आपने खरीदी थी।
एक और owner को यही चीज़ Iocrest AQC113 adapter के पीछे 10Gtek (ASF-10G2-T), Wiitek और Xicom के RJ45 modules के साथ मिली। 1.20.0 Build 20231011 Rel.42220 पर downgrade करने से हम दोनों के लिए मसला सुलझ गया। लक्षण अलग, सबक वही: इन builds में bugs copper SFP+ handling में ही बैठे हैं।
switches की इस लाइन के साथ एक और बात दिमाग में रखें: एक idle module port से ज़्यादा महंगा पड़ सकता है। 1.0.0 Build 20210730 Rel.65115 पर चल रहे एक TL-SX3016F पर बिना किसी traffic के भी CPU 87-89% पर बैठा रहता था और हर तीन मिनट में log में एक CPU RISING THRESHOLD लाइन डाल देता था।
load लगे हुए modules की संख्या के साथ बदलता था - एक module 0-1%, दो 73-76%, तीन या ज़्यादा 88-90% - और वजह थी Mellanox MFM1T02A-SR modules जिनमें fibre लगी थी पर दूसरे छोर पर कुछ जला नहीं था, तो link down ही रहता था। इन्हें Ubiquiti UF-MM-10G से बदलने पर port चाहे जो भी कर रहा हो CPU कम रहता था, और सिर्फ बिना इस्तेमाल वाले modules निकाल देने से भी यह ठीक हो जाता था। TP-Link का अपना जवाब यह था कि link down अवस्था में पड़ा module chipset के लिए महंगा ही होता है, और port ठीक से link होते ही load वापस नीचे आ जाता है। इससे एक अजीब हिस्सा अनसुलझा रह जाता है: brand बदल दो, module उतना ही idle रहने दो, और CPU फिर भी शांत रहता है। तो पुरानी firmware पर वापस जाने के बाद CPU graph पर भी एक नज़र डाल लें।