विक्रेता लॉक और “unsupported transceiver”
सबसे ज़्यादा आम ट्रांसीवर समस्या। स्विच और NIC वेंडर — Cisco, Intel, HPE/Aruba, Juniper, Mellanox और अन्य — मॉड्यूल के EEPROM से मिलने वाली आइडेंटिफ़िकेशन स्ट्रिंग जाँचते हैं और जिन मॉड्यूल को वे नहीं पहचानते उन्हें अस्वीकार कर देते हैं या फ़्लैग कर देते हैं।
जो सबसे अहम बात इंजीनियर मुश्किल तरीक़े से सीखते हैं वह यह है: “unsupported” का मतलब यह नहीं कि मॉड्यूल “काम नहीं करेगा”। ज़्यादातर प्लैटफ़ॉर्म पर यह स्टेटस सिर्फ़ सूचनात्मक होता है और पोर्ट को ऊपर लाया जा सकता है।
लक्षण
| प्लैटफ़ॉर्म | आपको क्या दिखता है |
|---|---|
| Cisco IOS | पोर्ट notconnect — unsupported; लॉग %C4K_TRANSCEIVERMAN-3-INCOMPATIBLE |
| अपग्रेड के बाद Cisco IOS | पोर्ट errdisable में चला जाता है, कारण gbic-invalid |
| Mellanox | EEPROM पढ़ा जाता है पर लिंक नहीं होता: speed and type: Not supported |
| Intel X520 / ixgbe | ग़ैर-Intel SFP के साथ no carrier |
क्या काम करता है
Cisco. सभी पोर्ट पर थर्ड-पार्टी मॉड्यूल की इजाज़त देने के लिए दो कमांड आमतौर पर बेस कॉन्फ़िग में शामिल कर दी जाती हैं:
service unsupported-transceiver
no errdisable detect cause gbic-invalid
प्लैटफ़ॉर्म की ख़ासियतें: कुछ Catalyst 9200 बिल्ड पर पहली कमांड % Ambiguous command लौटाती है — इसे पूरा टाइप करें; Nexus 9000 पर यह एक छुपी हुई कमांड है जिसमें टैब-कम्पलीशन नहीं है, लेकिन यह स्वीकार होती है।
Intel X520 (Linux)। ड्राइवर को उस ऑप्शन के साथ लोड करें जो ग़ैर-Intel मॉड्यूल की इजाज़त देता है:
modprobe ixgbe allow_unsupported_sfp=1
एक स्थायी वेरिएंट भी मौजूद है जो NIC के अपने EEPROM में एक बिट पलट देता है, और यह नीचे दिए स्रोतों में दस्तावेज़ है — इसे सावधानी से इस्तेमाल करें, क्योंकि NIC EEPROM पर ग़लत राइट फ़ील्ड में रिकवर नहीं की जा सकती।
ASR 9000 सीरीज़। पहले से ऊपर पोर्ट में डाला गया मॉड्यूल शायद डिटेक्ट न हो: पोर्ट को shut करें, मॉड्यूल डालें, फिर no shut करें।
कट्टर उपाय — मॉड्यूल को रीकोड करें। मॉड्यूल की वेंडर ID और पार्ट नंबर दोबारा लिखें ताकि वह ख़ुद को एक नेटिव मॉड्यूल की तरह पेश करे। यही CodingBox EEPROM editor में करता है, CC_BASE/CC_EXT दोबारा कैलकुलेट करते हुए और पहले एक बैकअप लेते हुए। मैकेनिक्स के लिए देखें EEPROM रीकोडिंग।
वह सलाह जो हर कोई दोहराता है
शेल्फ़ पर हर टाइप का एक ओरिजिनल OEM मॉड्यूल रखें। सपोर्ट टिकट खोलने से पहले इसे लगा दें, ताकि विक्रेता समस्या का दोष थर्ड-पार्टी ऑप्टिक्स पर न डाल सके।
स्विच पर वेरिफ़ाई करना
ऊपर में से किसी के बाद, पुष्टि करें कि मॉड्यूल दिख रहा है और पढ़ा जा रहा है: प्रति-NOS कमांड के लिए देखें स्विच पर ऑप्टिक्स वेरिफ़ाई करना, और इसकी तुलना उस पहचान जानकारी से करें जो CodingBox बेंच पर पढ़ता है।
होस्ट ठीक-ठीक क्या तुलना करता है — नाम, PN, OUI, सीरियल पैटर्न, वेंडर सिग्नेचर — और ब्रिंग-अप के किस चरण में वह अस्वीकार करता है: वेंडर फ़ील्ड, होस्ट क्या करता है।
प्रति-विक्रेता वैलिडेशन व्यवहार और ओवरराइड एक टेबल में: हर NOS मॉड्यूल को कैसे वैलिडेट करता है; प्लैटफ़ॉर्म को जो ठीक PN स्ट्रिंग चाहिए: OEM पार्ट नंबर; प्रति-NOS कमांड सिंटैक्स: पोर्ट कॉन्फ़िगरेशन रेसिपी।