ভেন্ডর লক ও কোডিং

অনেক সুইচ ট্রান্সিভারের শনাক্তকরণ তথ্য পরীক্ষা করে (ভেন্ডরের নাম, পার্ট নম্বর, কখনো সিরিয়ালও) এবং অনুমোদিত তালিকার সঙ্গে না মেলা মডিউলকে “অসমর্থিত” গণ্য করে। এটাই ভেন্ডর লক; সেই কারণেই সম্পূর্ণ ভালো একটি অপটিক্স এক সুইচে প্রত্যাখ্যাত হয়, অথচ অন্য সুইচে কাজ করে।

সুইচ কীভাবে সাড়া দেয়

• কিছু প্ল্যাটফর্ম সতর্ক করে, কিন্তু মডিউলটি চলতে দেয়।
• কিছু প্ল্যাটফর্ম অচেনা অপটিক্সের ক্ষেত্রে পোর্ট বন্ধ করে দেয় বা ডায়াগনস্টিকস দিতে অস্বীকার করে।
• যেমন Cisco IOS-এ একটি গ্লোবাল service unsupported-transceiver কমান্ড আছে, যা তৃতীয় পক্ষের অপটিক্সকে অনুমতি দেয়।

কোডিং কী করে

কোডিং টার্গেট সুইচ যে ভেন্ডর ও পার্ট নম্বরের ফিল্ড আশা করে, তা মডিউলের মেমোরিতে লিখে দেয়, ফলে সুইচ মডিউলটি গ্রহণ করে। ওই ফিল্ডগুলো চেকসাম দিয়ে সুরক্ষিত, তাই পরিবর্তনের পর চেকসাম আবার গণনা করতে হয়; CodingBox EEPROM editor-এ CC_BASE ও CC_EXT স্বয়ংক্রিয়ভাবে নতুন করে গণনা করে।

নিরাপদে করার উপায়

1. মডিউলটি পড়ুন এবং CodingBox-কে তা code database-এ সংরক্ষণ করতে দিন; যেকোনো লেখার আগে ব্যাকআপ নেওয়া হয়।
2. শনাক্তকরণ ফিল্ডগুলো সম্পাদনা করুন (দরকার হলে সুরক্ষিত পেজ আনলক করুন)।
3. নির্বাচিত পেজগুলো লিখুন, তারপর নিশ্চিত হতে আবার পড়ুন।

ট্রান্সিভার কোড করুন শুধু সেই ইন্টারঅপারেবিলিটির জন্য, যার অধিকার আপনার আছে, এবং আপনার প্রতিষ্ঠানের ও ভেন্ডরদের নীতি মেনে চলুন।

আরও পড়ুন

• প্রতিটি NOS কীভাবে মডিউল যাচাই করে: কী মেলানো হয়, ব্যর্থ হলে কী ঘটে, নথিভুক্ত ওভাররাইড, ভেন্ডর অনুযায়ী।
• পোর্ট কনফিগারেশনের রেসিপি: 12টি সিস্টেমের গতি, FEC, AN, ব্রেকআউট ও ওভাররাইডের কমান্ড পাশাপাশি।
• সামঞ্জস্য ম্যাট্রিক্স ও ফার্মওয়্যার: সমর্থনের তথ্য কোথায় প্রকাশিত হয়, কীভাবে পড়তে হয়, আপগ্রেডে কী বদলায়, ফ্লিট-রীতি।