Aruba 2530-48G pair नए 200 m OM4 run पर: port 51 Down, जबकि J4858C modules का self-test पास हो रहा है
कुछ समय पहले दो buildings के बीच 200 m का OM4 backbone खींचा गया था और अब मैं उसे अपने पास मौजूद kit से light करने की कोशिश कर रहा हूं। दोनों तरफ 2530s हैं, दोनों modules HPE वाले part हैं, और link बिल्कुल up नहीं हो रहा।
- 2x Aruba 2530-48G
- 2x J4858C 1000SX, दोनों तरफ port 51
- करीब 200 m ताजा लगा हुआ OM4, contractor ने certify किया था कि ठीक है
- patch panel से switch तक Digitus DK-2533-01 OM2 LC jumpers
उस port के लिए show tech transceivers यह देता है:
Port 51 Down Auto 1000FDx 1000SX multiअब तक मैंने क्या किया:
- दोनों switches पर module self test चलाया, दोनों pass
- दोनों तरफ
interface 51 enableकिया, कोई फर्क नहीं, port Down ही रहता है - दोनों modules को switches के बीच swap किया, दोनों तरफ same result
- panel और switch पर jumpers reseat किए
मैं दो theories के बीच फंसा हूं: या तो दोनों modules शुरू से ही dud हैं, या OM4 trunk पर OM2 jumpers यही problem कर रहे हैं। कौन सी ज्यादा likely है, और इनमें से किसी एक को prove करने के लिए आगे क्या test करना चाहिए?
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 4
आगे theorize करने से पहले, link को छोटा कर दो। एक switch को दूसरे के पास ले जाओ, दोनों J4858C डालो, और एक ही patch cord से जोड़ दो - एक jumper, कोई panel नहीं, कोई installed fibre नहीं। अगर ऐसे में port 51 Up आ जाता है, तो एक ही move में दोनों modules और दोनों switch ports clear हो गए, और जो बचता है वो line के दूसरी तरफ है: installed fibre, panels, couplers, terminations।
जिस case पर मैंने काम किया था वो ऐसे ही निकला। same 2530-48G pair, same J4858C, installed run पर port 51 Down और जैसे ही दोनों modules एक cord पर back to back हुए, Up। इस evidence पर मैं optics को शक करना बंद कर दूंगा - पर यह साफ रहे कि test तुम्हें क्या देता है। यह सिर्फ segment isolate करता है, बस इतना ही। trace का कौन सा हिस्सा खराब है, panel, splice, connector, या बस गलत pair patch हो गया, यह तब तक खुला रहेगा जब तक कोई meter या OTDR ना लगाए।
साथ ही, OM2 वाली theory को parked कर दो। 200 m पर 1000SX के लिए jumper grade तुम्हें रोक नहीं रहा, और वैसे भी OM3 और OM4 आपस में compatible हैं। grades mix करना अच्छी practice नहीं है और मैं नया plant इस तरह नहीं बनाऊंगा, पर यह वो fault नहीं है जिसके पीछे तुम हो।
back to back test pass होने के बाद, जिसने भी fibre खींची थी उसके पास वापस जाओ और certification results लिखित में मांगो, per fibre, loss और length के साथ। उनके अपने test ने link को good बताया था, तो या तो कुछ बिना ठीक से check किए pass कर दिया गया, या उन्होंने वो pair नहीं बल्कि कोई और pair measure किया जिस पर तुम patched हो - और यही वो ground है जिस पर खड़े होकर उन्हें वापस बुलाकर दोबारा करने को कह सकते हो।
सबसे पहले, दो अलग-अलग faults को अलग करो जो दोनों Down दिखते हैं। एक port जो administratively down है या misconfigured है वो एक problem है, और एक port जो enabled है पर उसके receiver पर कोई light नहीं आ रही वो बिल्कुल अलग problem है। तुम पहले ही
interface 51 enableचला चुके हो और वो अब भी Down दिखा रहा है, तो मामला layer 1 का है और config का सवाल ही नहीं उठता।दो चीज़ें इसे narrow down कर सकती हैं। दोनों switches के बीच physically क्या है - कितने patch panels, कोई splice trays, कोई couplers जो run को पहुंचाने के लिए जोड़े गए हों? और क्या तुम्हारे पास contractor की certification report है जिसमें per fibre actual loss के figures हों, या बस ज़ुबानी "सब ठीक टेस्ट हुआ"?
यह भी confirm कर लो कि duplex jumpers दोनों panels पर same तरीके से wired नहीं हैं। दोनों सिरों पर straight through होने से TX सीधे TX में चला जाता है, और यह बिल्कुल वैसा दिखेगा जैसा तुम describe कर रहे हो।
जब दोनों switches को एक ही room में नहीं ला सकते तब उसी test का एक variation: module को खुद पर loop करो। same duplex module पर TX से RX तक patch cord, और अगर high power part है तो बीच में attenuator लगाओ ताकि receiver ना जले। अगर port up आ जाता है, तो host port और module electrically और optically दोनों तरह से ठीक हैं, और fault far end पर है, fibre में या pairing में।
यही मैंने एक MES3324F पर एक FIBO SFP+ के साथ किया था जो switch to switch link होने से मना कर रहा था - loop तुरंत up आ गया, जिससे search module से हटकर span पर चली गई। एक caveat: BiDi modules पर self loop बेकार है, क्योंकि TX और RX अलग-अलग wavelengths पर होते हैं। इसके बजाय एक matched pair को एक-दूसरे के against loop करो।
अगले batch के लिए, modules को किसी wall के पास जाने से पहले test कर लो। EEPROM और DDM पढ़ो (vendor, part number, temperature, TX और RX power), meter से TX power measure करो और attenuator से sensitivity check करो, ऊपर बताए तरीके से loop करो, फिर target rate पर traffic के साथ असली link चलाकर error counters देखो - इन आखिरी दो के लिए अगर host हाथ में है तो
ethtool -mऔरiperf3काम आ जाते हैं। जिन links की तुम्हें असल में परवाह है, उन पर एक PRBS-31 BER run इतनी देर चलाओ कि NRZ के लिए 1e-12 से नीचे confirm हो जाए, तभी module prove होता है। कोई एक instrument सब कुछ validate नहीं करता।WISP वालों से उधार ली एक और habit जिसने मुझे दो बार बचाया: service में डालने से पहले हर module को warm reboot, cold reboot और reseat से गुज़ारो। कुछ parts insert करते ही link हो जाते हैं पर power cycle के बाद dead वापस आते हैं - GLC-T-OEM इसका classic example है, वो reseat के बाद ही up आता है - और कुछ ऐसा link state report करते हैं जो असल में real नहीं होता। यह bench पर पकड़ना roof पर पकड़ने से कहीं सस्ता है।