CodingBox Q&A Ask question

second-hand DCS-7150S-24 पर third-party SFP+ optics down ही रहते हैं: क्या enable3px flash file अब भी एक option है

Asked Active Viewed 69 AI translation from English
5

मैंने 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 से:

bash touch /mnt/flash/enable3px
write memory
reload

एक खाली 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 करो।

1 South Koreawaverunner63KR Show original (English) AI translation

उस 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 नीचे जाना है।

4 KazakhstanrackhubKZ Show original (English) AI translation

box आने के बाद से EOS को कभी हाथ नहीं लगाया, तो यह अब भी उसी train पर है जो seller छोड़ गया था - जो किस्मत से अच्छा निकला। touch, write memory, reload किया - और जो third-party SFP+ modules पहले मरे हुए थे वो अब आम ports की तरह up हो गए। न key, न account team, कुछ और नहीं चाहिए था। DACs जैसी उम्मीद थी वैसे पूरे समय काम करते रहे।

3 United Statesphotonrunner70US Show original (English) AI translation

जो कोई भी यहां नए box के साथ आया हो: वहां file को genuinely नज़रअंदाज़ किया जाता है, और इकलौता रास्ता एक per-customer cryptographic key है जो running configuration में इस तरह रहती है

service unsupported-transceiver CUSTOMERNAME LICENSEKEY

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 के लिए रख सकते हो जिन्हें असल में उनकी ज़रूरत है।

1 Egyptnetadmin16EG Show original (English) AI translation

"running configuration में रहती है" पर एक छोटी सी correction: जिस पुराने code के साथ मैंने काम किया था उसमें उसी command का एक undocumented variant भी था, तो अगर आपको ऐसा कोई reference मिले जो ऊपर वाले syntax से मेल न खाए, तो वो वहीं से आता है, किसी के गलत type करने से नहीं।

मेरे experience में key बिना reboot के भी असर करती थी - command डालते ही ज़्यादातर third-party optics काम करने लगे थे, हालांकि कुछ modules फिर भी कुछ भी करो मना करते रहे। यह काफी पहले की बात है उस hardware पर जो अब मेरे पास नहीं है, तो इसके इर्द-गिर्द maintenance window plan करने से पहले अपने box पर check कर लो।

2 United Arab Emirateslambdahawk88AE Show original (English) AI translation

चूंकि यह तुलना हर बार यह subject आने पर होती है: Cisco IOS-XE और IOS XR पर बराबर की चीज़ एक की बजाय दो steps है। सिर्फ global command काफी नहीं, हर उस physical port पर per-interface वाला भी चाहिए जिसे module लेना है:

service unsupported-transceiver
transceiver permit pid all

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 में सोच-समझकर लेने लायक फैसला।

4 Egyptnetadmin16EG Show original (English) AI translation
Log in to comment. Log in