CRS328 के साथ Alcatel-Lucent G-010S-P GPON stick: सिर्फ TX, कोई RX नहीं, wavelength 33685 nm दिखाता है
अपनी घर की FTTH line को operator के ONT से हटाकर अपने router में एक GPON stick पर ले जा रहा हूं, ताकि fibre सीधे rack में आए और मेरे पास दो की बजाय एक ही box रहे। stick recognised होता है, port up होता है, और फिर कुछ वापस नहीं आता।
- MikroTik CRS328-24P-4S+, stick sfp-sfpplus1 में
- Alcatel-Lucent G-010S-P GPON ONU
- Bell Canada FTTH, wall box से fibre सीधे module में
- port pinned, autoneg off:
/interface/ethernet set sfp-sfpplus1 auto-negotiation=no speed=1G-baseXTX counters बढ़ते हैं, RX counters zero पर बने रहते हैं, और module page ऐसा दिखता है:
wavelength: 33685.00nmमैंने पहले ही जो किया:
- connector reseat और clean किया, दूसरा SFP+ cage आज़माया
- fibre पूरी तरह निकाल दी - wavelength value नहीं बदलती, उसके साथ हो या बिना
- port को 1G पर एक घंटे के लिए pinned छोड़ा, कहीं यह कोई धीमी ranging वाली बात तो नहीं
तो: क्या 33685.00nm इस बात का सबूत है कि इस stick के optics मर चुके हैं, या switch बस GPON module के लिए उस EEPROM field को गलत decode कर रहा है? और क्या operator की तरफ कुछ ऐसा है जो SFP ONU को range करने की इजाज़त मिलने से पहले होना चाहिए?
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
तुम्हारी post में दो अलग चीज़ें हैं और उनमें से सिर्फ एक ही fault है।
33685.00nm एक decoding artefact है, कोई measurement नहीं। ये sticks dual-wavelength होते हैं - upstream 1310, downstream 1490 - और switch EEPROM से एक ही wavelength field ऐसे पढ़ता है जैसे वो एक लेज़र वाला साधारण transceiver हो। जो stick खुशी-खुशी traffic pass कर रहा हो उस पर भी तुम्हें वही नंबर दिखेगा, तो यह diagnostic के तौर पर बेकार है। इसे किनारे रख दो।
one-way traffic असली चीज़ है। मैं इससे उसी switch, एक CRS328-24P-4S+, पर गुज़रा हूं: G-010S-P transmit करता था और कभी कुछ receive नहीं करता था, और line उसी पल up हो गई जब मैंने उसी family का दूसरा module लगाया - एक O-010S-P, extended-temperature variant। same account, same fibre, कोई config change नहीं। तो पहला stick या तो defective था या उस line के लिए गलत variant था।
test करते वक्त port को pinned रखो, वरना एक दूसरा variable जुड़ जाएगा:
serial में ALCLFAB होने और account पहले से SFP ONU पर switch होने के साथ, तुम्हारा operator वाला आधा हिस्सा हो चुका है। इस पर एक और शाम खर्च करने से पहले हाथ में दूसरा stick ले आओ।
optics को खारिज करने से पहले, बोरिंग आधा हिस्सा check करो। काफी सारे FTTH accounts पर SFP ONU operator के box की जगह सीधे drop-in नहीं होता: account को इसके लिए हाथ से re-provision करना पड़ता है, और कुछ operators सिर्फ वही module accept करते हैं जिसके serial में उनका अपना vendor prefix हो। TX के साथ कुछ भी वापस न आना ठीक वैसा ही दिखता है जैसा एक unauthorised ONU subscriber की तरफ से दिखता है।
stick vendor और serial के लिए क्या रिपोर्ट करता है वो पोस्ट करो, और बताओ WAN side पर क्या configure किया है - VLAN tag, PPPoE या DHCP।
Serial ALCLFAB से शुरू होता है, जो यहां business FTTH account पर चाहिए होने वाला prefix है। account को SFP ONU के लिए भी हाथ से reconfigure किया गया - इसके लिए फ़ोन कॉल करनी पड़ी, first line को अंदाज़ा ही नहीं था कि मैं क्या मांग रहा हूं।
router side पर SFP port पर VLAN 35 है और उसके ऊपर एक PPPoE client। client discovery से आगे कभी नहीं बढ़ता। RX counters अभी भी flat हैं, और readout fibre लगी हो या न हो, 33685.00nm पर unchanged है।
wavelength वाली बात को आगे बढ़ाऊं तो: switch जो field पढ़ता है वो SFF-8472 वाले हिस्से में रहता है और एक लेज़र वाले module के लिए defined था। GPON ONU में burst-mode transmitter और अलग wavelengths पर एक receiver होता है, तो वहां डालने के लिए कोई एक सही value होती ही नहीं, और vendors जो उन्हें ठीक लगे वो लिख देते हैं। standard में host को उस byte को print करने से पहले sanity-check करने की कोई बाध्यता नहीं है, इसी वजह से पांच अंकों वाले nanometres मिल जाते हैं।
यही logic इन sticks की optical power lines पर भी लागू होता है। अगर तुम्हें जानना है कि PON side कैसा कर रहा है, तो वो ONU की अपनी state से लो, switch के diagnostics page से नहीं।
यह कहना ज़रूरी है कि इसका host वाला सिरा कोई MikroTik quirk नहीं है। 7210 SAS family पर vendor documentation साफ-साफ कहता है: शुरुआती releases DDM implement करते ही नहीं थे, तो ports उन modules के साथ भी कोई optical power या temperature नहीं दिखाते जो इसे support करते हैं, और तुमसे कहा जाता है कि चेक करो कि तुम्हारे variant के लिए कौन सा release यह function जोड़ता है। जो modules vendor ने supply नहीं किए उनके लिए, वही guide कहती है कि diagnostics दिख तो सकते हैं पर उनकी formatting या accuracy की कोई जिम्मेदारी नहीं ली जाती।
module EEPROM में एक capability flag भी होता है जो तय करता है कि platform किसी SFP को DDM-capable मानता है या नहीं, और जो modules इसे set नहीं करते वो फिर भी plausible दिखने वाले नंबर print कर सकते हैं जिन्हें किसी ने validate नहीं किया। वहां इसे पढ़ने की जगह
show port <port> detailहै। मैं उस box पर third-party value को एक संकेत मानता हूं, कभी measurement नहीं - जो लगभग वही रवैया है जिसका हकदार तुम्हारा 33685 है।इसे बंद करता हूं: दूसरे stick ने ठीक कर दिया। एक O-010S-P लगाया, PPPoE client एक मिनट के भीतर VLAN 35 पर up हो गया, operator side पर कोई बदलाव नहीं और port config में कुछ छुआ तक नहीं। पुराना G-010S-P दूसरे cage में भी वही TX-only वाला काम करता है, तो मेरे हिसाब से वो मर चुका है।
और हां - working module भी 33685.00nm रिपोर्ट करता है। अच्छा हुआ मैंने उस नंबर के पीछे पूरा हफ्ता नहीं गंवाया।