English 
简体中文 
繁體中文 
Русский 
Español 
Deutsch 
Français 
Português 
Italiano 
Türkçe 
Polski 
Nederlands 
日本語 
한국어 
Bahasa Indonesia 
Bahasa Melayu 
العربية 
हिन्दी 
Tiếng Việt 
ภาษาไทย 
বাংলা 
اردو 
Kiswahili 
Oʻzbekcha 
አማርኛ 
فارسی ভেন্ডর লক ও “unsupported transceiver”
ট্রান্সিভার নিয়ে সবচেয়ে বেশি ঘটা সমস্যা। সুইচ ও NIC-এর ভেন্ডররা (Cisco, Intel, HPE/Aruba, Juniper, Mellanox ও আরও অনেকে) মডিউল তার EEPROM থেকে যে শনাক্তকরণ স্ট্রিং জানায়, তা যাচাই করে এবং যে মডিউল চেনে না, তা প্রত্যাখ্যান করে বা চিহ্নিত করে দেয়।
ইঞ্জিনিয়াররা ঠেকে যে কথাটি শেখেন: “অসমর্থিত” মানে “কাজ করবে না” নয়। বেশির ভাগ প্ল্যাটফর্মে এই স্ট্যাটাস শুধু তথ্য জানায়, আর পোর্টকে চালু করানো যায়।
লক্ষণ
| প্ল্যাটফর্ম | যা দেখা যায় |
|---|---|
| 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-এর কমান্ডের সিনট্যাক্স: পোর্ট কনফিগারেশন রেসিপি।