Arista 7050T पर EOS 4.10.6 के साथ third-party DWDM SFP+ down ही रहता है - image patch किए बिना कोई रास्ता?

कोई आपको image की तरफ इशारा करे, उससे पहले दो बातें।

उस 7050T पर आप असल में किस EOS train से बंधे हैं? अगर इसे 4.10.6 पर ही रहना है, तो एक build-specific hack कम से कम अपने आप में consistent है। अगर move कर सकते हैं, तो समझ लें कि बाद के releases में transceiver handling reorganise हुई है और 4.10.6 के लिए लिखा कोई recipe आगे transfer नहीं होता।

और वह supplier असल में इनमें क्या burn कर सकता है? यह पूछना बनता है कि उनका programmer Arista profile रखता भी है या नहीं, या सिर्फ per-platform Cisco coding जो ज़्यादातर रखते हैं - जैसे ASR9K parts को अपना अलग profile चाहिए और optics vendors एक maintain करते हैं। batch को recode करवाना modified image पर जीने से कहीं सस्ता पड़ता है। अलग से: क्या आपने अपनी account team से unsupported-transceiver key अभी तक मांगी है, या यह commercial वजहों से table से बाहर है?

उस exact build पर image patch वाकई काम करता है, और ज़्यादा मेहनत का नहीं है - पर इसे lab या spare box पर करें, कभी भी traffic ले जा रही किसी चीज़ पर नहीं।

इसका shape: EOS-4.10.6.swi unzip करें और members रखें, जो हैं boot0, initrd-i386, linux-i386, rootfs-i386.sqsh और version। root filesystem को root की तरह unpack करें, agent edit करें, repack करें:

unsquashfs rootfs-i386.sqsh
mksquashfs squashfs-root/ rootfs-i386.sqsh
zip -Z store EOS-4.10.6a.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

edit खुद squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py में है: line 172 के पास वो चार lines comment out करें जो presence state assert करती हैं और फिर transceiver authentication चलाती हैं। zip पर -Z store optional नहीं है, swi को uncompressed रहना ही होगा वरना box इसे boot नहीं करेगा।

उसके बाद जो भी plug करो, ports आ जाते हैं, क्योंकि अब कुछ भी validate नहीं हो रहा। दो कीमतें: modified image पर आपके पास कोई vendor support नहीं रहता, और patch इसी build से बंधा है, तो जब कुछ गड़बड़ हो तो वापस boot करने के लिए stock .swi flash पर रखें।

ऊपर के सवालों का जवाब: यह box एक spare है जिस पर कोई support contract नहीं है, और supplier के programmer में बिल्कुल कोई Arista profile नहीं है - वे सिर्फ Cisco platforms के लिए code करते हैं और list वहीं खत्म हो जाती है, तो इस batch को recode करवाना offer में नहीं है। account team वाला रास्ता table से बाहर नहीं है, बस इस हफ्ते मेरे किसी काम का नहीं।

बताए अनुसार 4.10.6 rebuild किया, patched image boot की, और दोनों DWDM ports पहली ही कोशिश में आ गए। Stock image अभी भी flash पर पड़ी है। तब से link steady है, और दूर वाले सिरे को कुछ भी असामान्य नहीं दिख रहा।

अच्छा हुआ कि काम कर गया, पर उस patch की shelf life को लेकर खुद से साफ रहें, क्योंकि ऊपर वाला thread इसे असल से ज़्यादा general बना देता है।

यह सिर्फ 4.10.6 के लिए लिखा है, और कुछ नहीं। लोगों ने पूछा है कि इसे 4.14.5F, 4.14.7M और 4.23.8M पर कैसे दोहराएं और किसी ने कभी काम करने वाला जवाब पोस्ट नहीं किया, क्योंकि बाद के releases में transceiver manager reorganise हो चुका है और वे चार lines अब वहां आपका इंतज़ार नहीं कर रहीं। हर upgrade image भी बदल देता है, तो patch चला जाता है और अगली बार कोई routine maintenance करते ही ports गिर जाते हैं।

जो रास्ते upgrade के बाद भी बचते हैं वे हैं account team द्वारा जारी customer-specific service unsupported-transceiver key, और पुराने platforms पर enable3px marker file। patched image का इस्तेमाल किसी पुराने box को काम लायक बनाए रखने के लिए करें, network के लिए standard के तौर पर नहीं।

Cisco की तरफ भी वही लड़ाई है, पर एक detail साथ ले जाने लायक है। Third-party 80 km DWDM SFP+ (Pro10Optix, labelled SFP-10G-DWDM-192) Catalyst 6500 switches में बिना किसी शिकायत के चल रहे थे। IOS XR 5.3.3 पर एक ASR 9001 के built-in SFP+ ports में डालते ही ये मिला:

%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR: SFP Module is not supported
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED: Not supported Product ID

Red port LED, interface down, state link loss या low light बताता है बिना किसी loopback के, wavelength वापस 0 nm पढ़ी गई और laser कभी fire ही नहीं हुआ। interface पर transceiver permit pid all अपने आप में कुछ नहीं बदलता, और उसके ऊपर global service unsupported-transceiver भी उस batch को नहीं बचा पाया। यह platform अपने खुद के optics matrix से DWDM-SFP10G-xx.yy वाले shape में part number expect करता है, और generic PID किसी भी supported optic से match नहीं होता, तो override के पास ढीला करने के लिए कुछ बचता ही नहीं।

उसी release पर किसी और के पास Skylane SPDTU080100D139 80 km modules एक 9001 पर काम कर रहे थे - पर सिर्फ तब जब दोनों commands configured हों, वरना link bounce के बाद interface recover नहीं करता था। fail होने वाला batch आखिरकार ठीक से coded modules से exchange कर दिया गया।

एक बात और जोड़ रहा हूं जो supplier के पास दोबारा जाने से बचा देती है: उनसे platform के लिए code करने को कहें, brand के लिए नहीं। इन threads का बड़ा हिस्सा ऐसे modules का है जो सही vendor की तरह पहचान तो देते हैं पर ऐसा part number रखते हैं जिसे platform के matrix ने कभी सुना ही नहीं, और permit-style overrides सिर्फ उन modules के लिए check ढीला करते हैं जो वैसे तो box को सही लगते हैं।

जब तक modules उनकी bench पर हों, उनसे confirm करवाएं कि EEPROM strictly SFF-8472 के अनुरूप है। ढीला-ढाला A2h data पढ़ने पर बकवास जैसा आता है - ऊपर बताई गई 0 nm wavelength ठीक उसी तरह की है - और एक बार readout साफ हो जाए और platform फिर भी part को reject करे, तो third-party optics के बारे में general दलील के बजाय आपके पास vendor support के लिए कुछ ठोस होगा।