Junos upgrade के बाद EX4200 SFP+ EEPROM को mis-programmed बता रहा है, जबकि MX960 अब भी DOM दिखा रहा है
हमारे यहाँ EX4200s से चलने वाले 80 km के कुछ DWDM spans हैं, दोनों सिरों पर third-party optics के साथ, क्योंकि vendor-branded DWDM parts कभी budget में फिट होने वाले नहीं थे। सालों तक सब ठीक चलता रहा। EX boxes को Junos 12.3 पर ले जाने के बाद optics वही same ports में लगे हैं और spans भी वैसे ही मौजूद हैं, लेकिन switch ने अब यह मानना ही बंद कर दिया है कि ये modules optics हैं भी।
- EX4200, Junos 12.3 (उसी chassis पर 11.4 में DOM ठीक काम करता था)
- Integra SFPP-C51-80-10GD, DWDM 80 km SFP+
- MX960 उसी span के दूसरे छोर पर, identical part number, DOM अब भी पूरा मिल रहा है
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableModule insert करने पर messages log में ठीक एक लाइन आती है: SFP+ of type 0 EEPROM is Mis Programmed।
मैं अब तक क्या-क्या rule out कर चुका हूँ:
- optic reseat किया और उसी chassis के किसी और port में लगाया, कोई फर्क नहीं पड़ा;
- lab में एक spare EX3300 और एक QFX5100 पर try किया, दोनों का व्यवहार बिलकुल वैसा ही है, तो यह एक box की खराबी नहीं है;
- दूसरे छोर को फिर से check किया, MX960 उसी order के उसी part के लिए पूरी diagnostics दे रहा है।
तो क्या EX driver EEPROM में कुछ ऐसा enforce कर रहा है जिसे पुराना release बस ignore कर देता था? और अगर हाँ, तो क्या optic के साथ कुछ किया जा सकता है, या यह बात supplier से करनी पड़ेगी?
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
वो log line कोई generic शिकायत नहीं है, driver असल में बता रहा है कि कौन सा check fail हुआ।
Page A0 के bytes 3 से 10 में वो transceiver compliance codes होते हैं जो SFF-8472 में बताए गए हैं - वही bits जो 10GBASE-SR, LR, ER, SONET codes, Fibre Channel वाले codes वगैरह बताते हैं। इस तरह के optic पर सभी आठ bytes zero हैं, इसीलिए message इसे type 0 कहता है। Spec की expectation है कि उस field में कम से कम एक bit कहीं न कहीं set हो; पूरी तरह zero compliance field कोई valid module description नहीं है। पुराना EX code कभी देखता ही नहीं था, सीधे diagnostics page parse करने चला जाता था, नया driver पहले field validate करता है और फिर module को known 10G optic मानने से मना कर देता है। इसी वजह से unknown cable और DOM गायब है। MX line उसी path पर वो check नहीं चलाती, और यही वजह है कि identical part वहाँ अब भी काम कर रहा है।
किसी से बहस करने से पहले इसे prove कर लो: shell में जाओ और उस port पर xcvrpeek page A0 चलाओ, फिर offsets 3 से 10 देखो। सब zero मिले तो case बंद।
इसे वहीं ठीक करने की कोशिश आमतौर पर यहीं फेल होती है। Theory में xcvrpoke वही bytes वापस लिख सकता है। Practice में बहुत से vendors A0 page को lock रखते हैं और write EIO return करता है, और switch की तरफ से इसमें कुछ नहीं किया जा सकता। बचता सिर्फ supplier: या तो वो optics असली compliance codes के साथ भेजें, या फिर A0 unlocked भेजें ताकि bits खुद set किए जा सकें। अगर वो दोनों में से कुछ नहीं कर सकते, तो यह supplier की problem है जो Junos का कॉस्ट्यूम पहने हुए है।
किसी के guess करना शुरू करने से पहले दो चीज़ें पक्की कर लेनी चाहिए।
पहली, हर box पर exact release क्या है। आपने कहा EX 12.3 पर गया, पर MX960 पर क्या चल रहा है? अगर वो अब भी किसी पुराने train पर है तो दोनों boxes असल में comparable नहीं हैं, और अभी यह फर्क कुछ नहीं बताता।
दूसरी, MX साइड वाला part लिटरली उसी batch का वही SFPP-C51-80-10GD है, या किसी और order का वही model? Batches आमतौर पर जितना कोई चाहे उससे ज्यादा अलग निकलते हैं।
दोनों सिरों से
show interfaces diagnostics opticspost करें, साथ ही optic निकालकर वापस लगाने पर messages log में जो कुछ भी आता है वो सब, सिर्फ वो एक line नहीं जो आपने already quote की है।दोनों सिरों पर same part है, SFPP-C51-80-10GD, same order, consecutive serials।
MX960 पर
show interfaces diagnostics opticsपूरा set देता है: temperature, laser bias current, TX power, RX power। EX4200 पर वही command interface header प्रिंट करता है और फिर unknown cable वाली line, बस इतना ही। Optic reinsert करने पर log मेंSFP+ of type 0 EEPROM is Mis Programmedआता है और बस, चाहे मैं कोई भी port use करूँ।जो बात मुझे परेशान कर रही है वो यह है कि upgrade से पहले यही optic इसी chassis और port में बिना किसी शिकायत के DOM report करता था।
यह जोड़ने लायक बात है कि इसका read-only हिस्सा दूसरी तरफ भी मौजूद है। Cisco पर,
show idprom interface <if> detailबिना किसी shell कसरत के identification bytes dump कर देता है, जो किसी batch को Juniper box के पास ले जाने से पहले किसी spare switch पर check करने के लिए काम आता है।पढ़ना हर जगह harmless है। Host से लिखना बिलकुल अलग चीज़ है: xcvrpoke एक internal tool है, modules ठीक करने के तरीके के तौर पर supported नहीं है, और जैसा बताया गया, यह करीब आधे मामलों में vendor lock की वजह से block भी हो जाता है। इसे इस्तेमाल करके यह prove करें कि EEPROM में क्या गड़बड़ है, फिर वह proof जिसने भी optics बेचे उसे थमा दें।
Problem की class वही है, symptom बिलकुल अलग, शायद कोई search से यहाँ पहुँचे तो काम आए।
हमने एक EX4600 के ge-0/0/1 में एक no-name 1G BiDi WDM SFP लगाया और interface था ही नहीं।
show interfaces terseमें गायब, और उसके खिलाफ कोई भी command चलाने परerror: device ge-0/0/1 not foundआता। Log में लिखा थाOPTIC State changed for port: 0/0/1और फिरFibre channel transceiver plugged in without Fibre channel configuration!!। EEPROM इस तरह coded था कि Junos ने module को Gigabit Ethernet की जगह Fibre Channel transceiver मान लिया, तो उसके लिए कोई Ethernet interface बना ही नहीं। इसे कोई भी configuration ठीक नहीं करती; सही coded module ही करता है।और यह सिर्फ सस्ते market का मामला नहीं है। Citrix-branded 10G SFP+ का एक batch था जिसकी वजह से NetScaler MPX और SDX appliances vendor के अपने ही parts पर boot के समय
*** Unsupported SFP+/SFP type !log करते थे। सही units के label पर A2 revision marking होती थी, खराब वाले RMA पर वापस गए। गलत coding हर price point पर होती है।Confirm हो गया, और precise offsets के लिए धन्यवाद।
Page A0 पर xcvrpeek, इन सभी SFPP-C51-80-10GD units पर offsets 3 से 10 zero दिखा रहा है जिन्हें मैंने check किया, उन units समेत जो अभी भी box में रखी हैं। xcvrpoke सीधे EIO के साथ वापस आता है, तो A0 locked है और हमारी तरफ से बचाने को कुछ नहीं है।
Byte offsets और quote की गई log line के साथ supplier के पास वापस गए। उन्होंने इसे accept कर लिया और batch को असली compliance codes के साथ re-code कर रहे हैं; जो units MX960 में लगी हैं वो वहीं रहेंगी, क्योंकि उस platform पर कोई शिकायत नहीं है। ऊपर वाले explanation को answer mark कर रहा हूँ।