second-hand DCS-7150S-24 पर third-party SFP+ optics down ही रहते हैं: क्या enable3px flash file अब भी एक option है
मैंने lab के लिए दो-एक second-hand Arista switches लिए और सीधे optics gate में जा टकराया। Arista-coded modules link up हो जाते हैं, passive DAC cables link up हो जाते हैं, और जो भी third-party है उसका port down रह जाता है।
Lab side:
- DCS-7150S-24, इस्तेमाल किया हुआ खरीदा, न support contract न पीछे कोई account team
- कई तरह के third-party SFP+ modules
- rack के अंदर छोटे runs के लिए passive DAC cables
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes up
अब तक जो समझ आया:
- DAC का up हो जाना जबकि optics न हों, यह बताता है कि यह एक coding check है, न cabling और न कोई मरा हुआ cage
service unsupported-transceiver CUSTOMERNAME LICENSEKEYजैसा एक configuration command है, जिसे जाहिर है एक ऐसी key चाहिए जो मुझे कहीं से मिलने वाली नहीं- पुराने write-ups key की बजाय flash पर एक marker file का ज़िक्र करते हैं, पर मुझे नहीं पता वो किस generation पर लागू होता है
इस उम्र के box के लिए इन दो mechanisms में से कौन सा है, और क्या 7150S पर flash file अब भी एक option है, या अब सिर्फ key वाला रास्ता बचा है?
Comments 6
उस generation पर वो file वाला तरीका है, और यह उतना ही crude है जितना सुनने में लगता है। EOS CLI से:
एक खाली file, अंदर कुछ नहीं - इसका बस मौजूद होना reload के बाद third-party optics on कर देता है। जिन platforms पर यह काम करता है उनकी list लंबी है: DCS-7120T-4S, DCS-7050 family और पूरी DCS-7150S line समेत कई और, और हर model की एक नई EOS release है जो अब भी इस file को मानती है, सबसे पुराने boxes पर करीब 4.13.16M से लेकर 7150S पर 4.23 train तक। नए switches इस file को पूरी तरह नज़रअंदाज़ करते हैं।
तो 7150S-24 उस line के सही side पर है, बशर्ते आप model के support से आगे न बढ़े हों। key वाले रास्ते के पास जाने से पहले इसे try करो।
उस 7150S-24 पर कौन सा EOS train है, और खरीदने के बाद आपने इसे upgrade किया था क्या? यह मायने रखता है, क्योंकि cut-off family के हिसाब से नहीं बल्कि platform के हिसाब से है। flag file 7048T, 7120T-4S, 7140T-8S, 7124 और 7148 के SFP+ variants, 7050 और 7150S series और 7548S-LC line cards पर काम करने के लिए documented है, पर आखिरी EOS release जो इसे अब भी मानती है वो हर एक के लिए अलग है।
अगर आपने used box पर पहले ही EOS upgrade कर दिया है, तो अच्छी संभावना है कि आपने खुद को इस trick से बाहर upgrade कर लिया है, और तब सस्ता fix key ढूंढने की बजाय एक train नीचे जाना है।
box आने के बाद से EOS को कभी हाथ नहीं लगाया, तो यह अब भी उसी train पर है जो seller छोड़ गया था - जो किस्मत से अच्छा निकला। touch, write memory, reload किया - और जो third-party SFP+ modules पहले मरे हुए थे वो अब आम ports की तरह up हो गए। न key, न account team, कुछ और नहीं चाहिए था। DACs जैसी उम्मीद थी वैसे पूरे समय काम करते रहे।
जो कोई भी यहां नए box के साथ आया हो: वहां file को genuinely नज़रअंदाज़ किया जाता है, और इकलौता रास्ता एक per-customer cryptographic key है जो running configuration में इस तरह रहती है
key account या sales team से आती है, support से नहीं - TAC unlock keys issue करने के लिए authorised नहीं है और आपको वापस account management की तरफ भेज देगा, जो dead end है जब switch second-hand market से आया हो।
lab builds के लिए दोहराने लायक: passive DAC cables unlock state चाहे जो हो, default रूप से accepted हैं। अगर runs इतने छोटे हैं, तो आप DAC से cable करके पूरे सवाल को टाल सकते हो और optics सिर्फ उन links के लिए रख सकते हो जिन्हें असल में उनकी ज़रूरत है।
"running configuration में रहती है" पर एक छोटी सी correction: जिस पुराने code के साथ मैंने काम किया था उसमें उसी command का एक undocumented variant भी था, तो अगर आपको ऐसा कोई reference मिले जो ऊपर वाले syntax से मेल न खाए, तो वो वहीं से आता है, किसी के गलत type करने से नहीं।
मेरे experience में key बिना reboot के भी असर करती थी - command डालते ही ज़्यादातर third-party optics काम करने लगे थे, हालांकि कुछ modules फिर भी कुछ भी करो मना करते रहे। यह काफी पहले की बात है उस hardware पर जो अब मेरे पास नहीं है, तो इसके इर्द-गिर्द maintenance window plan करने से पहले अपने box पर check कर लो।
चूंकि यह तुलना हर बार यह subject आने पर होती है: Cisco IOS-XE और IOS XR पर बराबर की चीज़ एक की बजाय दो steps है। सिर्फ global command काफी नहीं, हर उस physical port पर per-interface वाला भी चाहिए जिसे module लेना है:
per-interface line वही है जो product-ID check को skip करती है, तो port कम से कम optic को light करने की कोशिश तो करेगा - इसकी कोई गारंटी नहीं कि module फिर काम करेगा, बस इतना कि platform उसे मना करना बंद कर देता है। मैंने यह IOS XR 5.3.3 पर और IOS-XE boxes पर किया है।
चेतावनी दोनों vendors पर एक जैसी है, और यही वजह है कि लोग इस पर बहस करते रहते हैं: अगर कोई fault किसी customer-installed third-party transceiver तक traced हो, तो warranty या contract के तहत support रोका जा सकता है। lab के लिए ठीक है, production में सोच-समझकर लेने लायक फैसला।