চেকসাম: CC_BASE, CC_EXT, CC_DMI, CMIS পেজ

প্রতিটি ম্যানেজমেন্ট স্পেসিফিকেশন তার শনাক্তকরণ তথ্যের ব্লককে এক বা একাধিক চেকসাম দিয়ে সুরক্ষিত রাখে; এটি একটিমাত্র বাইট, যা দেখে হোস্ট EEPROM-এর বিষয়বস্তুর ওপর ভরসা করার আগেই বুঝতে পারে যে সেটি নষ্ট হয়েছে বা অর্ধেক লেখা অবস্থায় আছে। হিসাব করা খুবই সহজ, অথচ ভুলে যাওয়াও সহজ: এডিটের পর পুরোনো চেকসাম থেকে যাওয়াই সদ্য কোড করা মডিউলকে অবৈধ দেখানোর সবচেয়ে সাধারণ কারণ।

অ্যালগরিদম

সবগুলোতে একই নিয়ম: আওতাভুক্ত পরিসরের বাইটগুলো আনসাইনড 8-বিট মান হিসেবে যোগ করা হয় এবং যোগফলের নিচের 8 বিট রাখা হয় (যোগফল মডুলো 256)। CRC নেই, পলিনোমিয়ালও নেই।

sum = 0
for each byte b in range:
    sum = (sum + b) & 0xFF
checksum = sum

উদাহরণ: 10GBASE-SR SFP-এর প্রথম পাঁচটি বাইট 03 04 07 10 00 হলে যোগফল 3 + 4 + 7 + 16 + 0 = 30 = 1Eh। বাইট 62 পর্যন্ত যোগ করে গেলে যে ফল আসে, সেটিই CC_BASE।

প্রতিটি চেকসাম কোথায় থাকে

স্পেসিফিকেশন	চেকসাম	অবস্থান	যা আওতায় পড়ে
SFF-8472 (SFP)	CC_BASE	A0h বাইট 63	A0h বাইট 0–62
SFF-8472	CC_EXT	A0h বাইট 95	A0h বাইট 64–94
SFF-8472	CC_DMI	A2h বাইট 95	A2h বাইট 0–94 (থ্রেশহোল্ড ও ক্যালিব্রেশন ধ্রুবক)
SFF-8636 (QSFP)	CC_BASE	বাইট 191	আপার পেজ 00h-এর বাইট 128–190
SFF-8636	CC_EXT	বাইট 223	বাইট 192–222
INF-8077i (XFP)	CC_BASE	বাইট 191	বাইট 128–190
INF-8077i	CC_EXT	বাইট 223	বাইট 192–222
CMIS	পেজ চেকসাম	পেজ 00h বাইট 222	পেজ 00h-এর বাইট 128–221
CMIS	পেজ চেকসাম	পেজ 01h বাইট 255	পেজ 01h-এর বাইট 130–254 (128–129-এ নিষ্ক্রিয় ফার্মওয়্যারের সংস্করণ থাকে, তাই সেগুলো বাদ)
CMIS	পেজ চেকসাম	পেজ 02h বাইট 255	পেজ 02h-এর বাইট 128–254
CMIS	পেজ চেকসাম	পেজ 04h বাইট 255	পেজ 04h-এর বাইট 128–254

কোনো চেকসামের আওতায় পড়ে না: ভেন্ডর-নির্দিষ্ট অংশ (SFP A0h 96–127, QSFP 224–255, CMIS 223–255), ইউজার EEPROM, লাইভ পরিমাপকৃত মান ও ফ্ল্যাগ, QSFP পেজ 03h-এর থ্রেশহোল্ড এবং CMIS লেন পেজ। ভেন্ডররা ভেন্ডর স্পেসে নিজেদের ইন্টেগ্রিটি ফিল্ড যোগ করতে পারে; সেগুলো স্পেসিফিকেশনের অংশ নয়।

হোস্ট এগুলো দিয়ে কী করে

আচরণ	ভুল চেকসামের ফল
CC_BASE যাচাই করে (বেশির ভাগ সুইচ ও রাউটার)	মডিউল অবৈধ, অসমর্থিত বা EEPROM চেকসাম ত্রুটি হিসেবে দেখায়; পোর্ট এররডিজেবল অবস্থায় চলে যেতে পারে; লেজার প্রায়ই বন্ধ রাখা হয়
CC_EXT-ও যাচাই করে	একই ফল, অথবা প্ল্যাটফর্মভেদে শুধু লগে একটি এন্ট্রি
CC_DMI যাচাই করে	DDM সমর্থিত নয় বলে দেখায় বা মানগুলো উপেক্ষা করে; লিংকটি নিজে প্রভাবিত হয় না
চেকসাম উপেক্ষা করে (অনেক NIC, কিছু ওপেন সুইচ)	মডিউল কাজ করে; ত্রুটিটি শুধু টুলে ধরা পড়ে

চেকসামের ব্যর্থতা শনাক্তকরণ তথ্যের সঙ্গে একই বার্তায় জানানো হয়, তাই যে মডিউলে নীতিমালাজনিত সমস্যাও আছে, সেখানে একটি বার্তা অন্যটিকে আড়াল করে; আগে চেকসাম যাচাই করুন, কারণ এটিই সস্তা সমাধান। লক্ষণ থেকে সমস্যা খোঁজার সূচি: লক্ষণ সূচি।

কখন আবার হিসাব করতে হয়

আওতাভুক্ত পরিসরের যেকোনো কিছু এডিট করার পর: ভেন্ডরের নাম, পার্ট নম্বর, সিরিয়াল নম্বর, ডেট কোড, কমপ্লায়েন্স কোড, তরঙ্গদৈর্ঘ্য, দৈর্ঘ্য, অপশন, পাওয়ার ক্লাস।
SFP-তে থ্রেশহোল্ড বা ক্যালিব্রেশন ধ্রুবক প্রয়োগ করার পর (CC_DMI)।
অন্য মডিউল থেকে আংশিক ইমেজ পুনরুদ্ধার করার পর।
ভেন্ডর স্পেস, ইউজার EEPROM বা A2h কন্ট্রোল বাইটের পরিবর্তনে দরকার নেই।

কাজের ক্রম: এডিট করুন, তারপর প্রভাবিত প্রতিটি চেকসাম আবার হিসাব করুন, তারপর লিখুন, আবার পড়ে যাচাই করুন। যে ডেটা চেকসামের আওতায় পড়ে তার আগে চেকসাম বাইট লিখলে একটা ফাঁক তৈরি হয়, যার মধ্যে বিদ্যুৎ চলে গেলে মডিউল অবৈধ হয়ে যায়।

চেকসাম ও ভেন্ডর লক

সঠিক চেকসাম প্রয়োজনীয়, কিন্তু যথেষ্ট নয়। কড়া প্ল্যাটফর্ম ভেন্ডর ব্লকও যাচাই করে, আর লক করা ডিজাইনে ভেন্ডর স্পেসে থাকা একটি প্রোপ্রাইটারি সিগনেচারও দেখে, যার বিষয়ে স্পেসিফিকেশনের চেকসামগুলোর কোনো ধারণা নেই। CC_BASE পাস করেও শনাক্তকরণ তথ্য প্রত্যাখ্যাত হলে বিষয়টি ভেন্ডর লক সংক্রান্ত, চেকসাম সংক্রান্ত নয়: ভেন্ডর লক, ভেন্ডর ফিল্ড।

CodingBox-এ

CodingBox প্রতিটি লেখার সময় CC_BASE, CC_EXT, CC_DMI ও CMIS পেজ চেকসাম নিজে থেকে আবার হিসাব করে এবং মডিউল পড়ার সময় অমিল থাকলে তা হাইলাইট করে। Check transceiver বা EEPROM editor স্ক্রিনে চেকসাম ফিল্ড লাল দেখালে বুঝতে হবে, মডিউলটি অন্য কোথাও এডিট করা হয়েছে অথচ চেকসাম ঠিক করা হয়নি, অথবা EEPROM নষ্ট হয়ে গেছে।

প্রতিটি চেকসাম তার প্রতিবেশী বাইটগুলোর মধ্যে কোথায় বসে: SFF-8472 A0h (63, 95), A2h (95), SFF-8636 আপার (191, 223), CMIS আপার পেজ (222, 255), XFP (191, 223)।

এই নিবন্ধে কোনো অশুদ্ধ তথ্য বা ভুল পেলে সংশ্লিষ্ট অংশটি নির্বাচন করুন এবং Ctrl+Enter চেপে ।