Supermicro E300-9A पर pfSense Plus 22.05: ix2 और ix3 no carrier पर अटके रहते हैं, जबकि वही DAC USW-Aggregation पर ठीक link करता है
मेरा firewall एक Supermicro E300-9A है जिस पर pfSense Plus 22.05 चलता है, और दोनों 10G SFP+ ports up होने से मना कर देते हैं। cage में जो भी डालूं, न तो ix2 और न ix3 कभी carrier दिखाता है।
Hardware:
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M और एक 10Gtek passive twinax cable
- विकल्प के तौर पर Supermicro AXS85-192-M3 fibre modules
- switch side पर Ubiquiti USW-Aggregation
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 भी वैसा ही दिखता है।
अब तक जो आज़माया:
- दोनों cables USW-Aggregation पर बाकी devices के बीच काम करते हैं, तो वो dead नहीं हैं
- copper को AXS85-192-M3 fibre modules से बदला, दोनों ports पर वही no carrier
- appliance को कई बार reboot किया, module को चलते हुए डालना भी शामिल
क्या इस box में कुछ ऐसा है जिसे cages काम शुरू करने से पहले कुरेदना पड़ता है, या मैं दो dead ports देख रहा हूं?
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
Warm reboots से कहीं नहीं पहुंचोगे - वो ports एक media state latch कर लेते हैं और restart पर दोबारा probe करते ही नहीं। appliance को ठीक से shut down करो, power adapter को कुछ मिनट के लिए निकाल दो, फिर module पहले से डाले हुए ही इसे वापस start करो। यहां दोनों ports इसी से वापस आए, और किसी और ने एक Intel X552 port पर बिल्कुल वैसा ही व्यवहार बताया, इसीलिए मुझे लगता है कि यह pfSense की समस्या नहीं बल्कि एक stale media state है।
अगर system चलते हुए ही कोई module डालते हो, तो reboot करने की बजाय interface bounce करो:
इससे driver cage को दोबारा देखता है। यह किसी चीज़ का permanent fix नहीं है, पर bench पर modules बदलते वक्त reboot बचा देता है। नतीजा front panel की बजाय
ifconfig -aसे check करो।पहले पूरा power removal करो और switch side को छूने से पहले DAC से दोनों cages confirm कर लो। एक बार में एक चीज़ debug करना यहां मायने रखता है, क्योंकि "हर module के साथ no carrier" और "link गलत speed पर up होना" आमतौर पर दो अलग faults होते हैं जो संयोग से एक ही cable run में मिल जाते हैं।
पूरे power removal ने काम कर दिया। Shut down किया, adapter निकाला, कुछ मिनट wait किया, वापस power on किया - दोनों ports up हो गए। ix2 और ix3 के बीच DAC से loop किया और साफ-सुथरा 10G link मिला, और AXS85-192-M3 जोड़ी भी दोनों ports के बीच 10G करती है, तो cages और modules ठीक हैं।
switch side एक अलग कहानी है। USW-Aggregation की तरफ link हमेशा सिर्फ 1G पर ही negotiate करता है, और अगर किसी भी सिरे पर 10G force करूं तो वो down हो जाता है और down ही रहता है। तो आधी समस्या गई, और परेशान करने वाला आधा हिस्सा अभी भी यहीं है।
1G fallback वाला आधा हिस्सा बहुत जाना-पहचाना लगता है। मैंने वही symptom एक TL-SG3428X और एक TL-SX3008F पर पीछा किया था: उन SFP+ ports में से किसी एक से लटके server को restart करो और वो चाहे switch port कुछ भी configured हो, वापस 1G पर negotiated होकर आता। Intel X520-DA2, Mellanox और HP adapters, Intel E10GSFPSR और 10GTek optics, firmware updates, Linux और Windows पर कई driver versions, port profiles - इनमें से किसी ने कुछ नहीं बदला। एक switch reboot, या port speed को 10G से हटाकर वापस करना, अगले host reset तक 10G link वापस ला देता था।
जिसने असल में fix किया वो host की कोई चीज़ नहीं, optics बदलना था: switch वाले सिरे पर TP-Link SM5110-SR modules, और link हर बार 10G पर वापस आया। किसी और ने SG3428XMPP पर भी यही confirm किया। समझ यह बनी कि host-side link reset के बाद switch कुछ third-party modules के साथ mis-negotiate करता है।
तुम्हारी तरफ vendor अलग है, पर shape मेल खाती है। कुछ भी खरीदने से पहले, एक अकेला Ubiquiti-branded module उधार लो और aggregation switch पर एक port test करो।
10G force करने की बात: इसे सिर्फ एक सिरे पर करना चीज़ें बेहतर नहीं, बदतर बनाता है। peer अभी भी negotiate करने की कोशिश कर रहा होता है और एक fixed setting उसे negotiate करने के लिए कुछ देती ही नहीं, तो link बस down रह जाता है - बिल्कुल वही व्यवहार जो तुमने बताया। speed और duplex दोनों सिरों पर fix करो, या किसी पर भी मत करो।
MikroTik की दुनिया से दो जुड़े हुए cases, शायद कुछ याद दिला दें। एक RB4011 पर एक Finisar FTLF8524P2BNV-BR detect हुआ जिसमें sfp-rx-loss और sfp-tx-fault दोनों no दिखा रहे थे, और interface फिर भी no-link कहता रहा, क्योंकि SFP+ cage में 1G SFP को negotiate नहीं, pin करना पड़ता है:
और, फिर से, दोनों सिरों पर। दूसरा case एक CCR1072 था जहां link loss के बाद auto-negotiation DONE पर अटका रह गया और driver ने उसे कभी restart नहीं किया; autoneg disable करके speed fix करने से link वापस आ गया, इसकी कीमत ठीक-ठाक link-down detection के रूप में चुकानी पड़ी।