ConnectX-4 MCX456A-ECAT 100GBASE-LR4 पर Cisco NCS से link नहीं करता जबकि loopback दोनों सिरों पर pass होता है
हम racks की एक जोड़ी चलाते हैं जो carrier-facing Cisco NCS को hand off करती है, और 100G server uplinks में से एक build के बाद से कभी up नहीं हुआ। server को दूसरे cabinet में अलग patch panel के साथ move करने पर भी वही नतीजा, तो अब मैंने इसे one-off मानना बंद कर दिया है।
- Supermicro server, NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT, दोनों ports free
- generic 100GBASE-LR4 QSFP28, single mode, 10 km reach, एक-एक हर सिरे पर
- Cisco NCS दूसरी तरफ, dark fibre दोनों rooms के बीच
जो हिस्सा मुझे अटकाए हुए है: हर module अपने device पर loopback pass करता है। fibre को उसी QSFP28 में वापस loop करने पर NIC एक साफ 100G link report करता है, और NCS अपनी तरफ वही करता है। बीच में असली span डालो तो कुछ नहीं।
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: noअब तक जो कोशिश की:
- दोनों modules को उसी batch के spares से बदला, कोई फर्क नहीं
- server move किया और अलग panel से re-patch किया
- NIC vendor के साथ एक case खोला, और जवाब firmware release notes में validated transceiver list की तरफ इशारा था, जो यह नहीं बताता कि loopback क्यों काम करता है
क्या ConnectX-4 पर LR4 में कुछ ऐसा है जो इसे locally link करने देता है पर असली span पर कभी नहीं, या मैं इसके गलत सिरे का पीछा कर रहा हूं?
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
यह dirty path जैसा लगता है, compatibility problem जैसा नहीं।
अब तक जो कुछ भी तुमने बदला है वह उस साइड पर बैठा है जो पहले ही अच्छी test हो चुकी थी, इसीलिए कुछ बदला नहीं - span खुद वह अकेली चीज़ है जो अभी तक untouched है। तो path पर काम करो:
जिस validated transceiver list की तरफ तुम्हें भेजा गया वह देखने लायक है, पर जो module loopback में साफ-साफ up हो जाता है वह पहले से ही NIC से सही तरीके से drive हो रहा है। Compatibility lists उन modules को समझाती हैं जिन्हें सीधे reject कर दिया जाता है, उन modules को नहीं जो locally link करते हैं और span पर मर जाते हैं।
अगर cleaning से काम नहीं बनता, अगला step dark fibre पर एक light source और power meter है, या अगर उधार मिल जाए तो एक OTDR, इससे पहले कि तुम कोई और NIC या optics की कोई और जोड़ी खरीदो।
एक loopback सिर्फ यह साबित करता है कि एक port खुद को सुन सकता है - laser, receiver, rate settings। यह तुम्हारे दोनों rooms के बीच के glass के बारे में कुछ नहीं बताता, और वही अकेला हिस्सा है जो अभी तक test नहीं हुआ। तो दोबारा NIC को दोष देने से पहले, असली span लगाकर दोनों सिरों से numbers लो: NCS port पर Rx power क्या है, और NIC पर क्या है? span लगे रहने पर Rx का Low Warn threshold से नीचे बैठना local port की बजाय far end या path की तरफ classic इशारा है। Linux side पर
ethtool -mको वही reading देनी चाहिए, और अगर वहCannot get module EEPROM information: Input/output errorके साथ वापस आता है तो इसे dead module मत समझो - mlx5 पर यह आमतौर पर firmware-side module access होता है, औरmst start,mst cable addऔर फिरmlxcablesफिर भी values दे देंगे।Cleaning ही जवाब थी। हमने end faces पर scope लगाई और दोनों modules के साथ दोनों patch cords भी contaminated निकले; inter-room panel से गुज़रने वाली cord दोनों में ज्यादा खराब थी। path में सब कुछ clean किया, re-seat किया, और NCS तक 100G link पहली ही कोशिश में up हो गया और तब से up है।
खुद पर हल्का सा गुस्सा आता है कि compatibility वाले angle पर इतना समय लगाया जबकि loopback का नतीजा शुरू से ही बता रहा था कि modules ठीक थे और path नहीं था। जो कोई बाद में यहां पहुंचे उनके लिए: loopback port को साबित करता है, fibre को नहीं।