चेकसम: CC_BASE, CC_EXT, CC_DMI, CMIS पेज

हर मैनेजमेंट स्पेसिफ़िकेशन अपने आइडेंटिटी ब्लॉक को एक या ज़्यादा चेकसम से सुरक्षित रखता है — एक सिंगल बाइट, जो होस्ट को कंटेंट पर भरोसा करने से पहले करप्ट या आधा-लिखा EEPROM पहचानने देता है। इन्हें कैलकुलेट करना बहुत आसान है, और भूलना भी उतना ही आसान: एडिट के बाद पुराना पड़ा चेकसम ही सबसे आम वजह है कि अभी-अभी कोड किया गया मॉड्यूल invalid बताया जाता है।

एल्गोरिद्म

इन सबका नियम एक जैसा है: कवर की गई रेंज के बाइट को अनसाइन्ड 8-बिट वैल्यू के तौर पर जोड़ें और सम के निचले 8 बिट रखें (sum modulo 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 वैलिडेट करना (ज़्यादातर स्विच और राउटर)	मॉड्यूल invalid, unsupported या EEPROM checksum error दिखाया जाता है; पोर्ट errdisable हो सकता है; लेज़र अक्सर बंद रखा जाता है
CC_EXT भी वैलिडेट करना	वही, या प्लैटफ़ॉर्म अनुसार सिर्फ़ एक लॉग एंट्री
CC_DMI वैलिडेट करना	DDM not supported दिखाया जाता है या वैल्यू इग्नोर होती हैं; लिंक ख़ुद प्रभावित नहीं होता
चेकसम इग्नोर करना (कई NIC, कुछ ओपन स्विच)	मॉड्यूल काम करता है; एरर सिर्फ़ टूल में दिखता है

चेकसम फ़ेल्योर पहचान जानकारी के साथ ही रिपोर्ट होता है, इसलिए जिस मॉड्यूल में पॉलिसी की समस्या भी हो उसमें एक मैसेज दूसरे को छुपा देता है — पहले चेकसम जाँचें, यही सबसे आसान फ़िक्स है। लक्षण मैप: लक्षण इंडेक्स।

कब दोबारा कैलकुलेट करना ज़रूरी है

कवर की गई रेंज में कुछ भी एडिट करने के बाद — विक्रेता नाम, पार्ट नंबर, सीरियल नंबर, डेट कोड, कंप्लायंस कोड, तरंगदैर्ध्य, लंबाई, विकल्प, पावर क्लास।
SFP (CC_DMI) पर थ्रेशोल्ड या कैलिब्रेशन कॉन्स्टेंट लागू करने के बाद।
किसी दूसरे मॉड्यूल से आंशिक इमेज रीस्टोर करने के बाद।
वेंडर स्पेस, यूज़र EEPROM या A2h कंट्रोल बाइट में बदलाव के लिए ज़रूरी नहीं।

क्रम: एडिट → हर प्रभावित चेकसम दोबारा कैलकुलेट करें → राइट करें → वापस पढ़ें → वेरिफ़ाई करें। चेकसम बाइट को उस डेटा से पहले लिखने पर एक ऐसी विंडो बन जाती है जहाँ पावर लॉस होने पर मॉड्यूल invalid हो सकता है।

चेकसम और वेंडर लॉक

सही चेकसम ज़रूरी हैं, लेकिन काफ़ी नहीं। एक सख़्त प्लैटफ़ॉर्म वेंडर ब्लॉक भी जाँचता है, और लॉक्ड डिज़ाइन पर वेंडर स्पेस में एक प्रोप्राइटरी सिग्नेचर भी, जिसके बारे में स्पेसिफ़िकेशन के चेकसम कुछ नहीं जानते। CC_BASE पास होना और पहचान जानकारी रिजेक्ट होना vendor lock का मामला लगता है, चेकसम का नहीं — विक्रेता लॉक, विक्रेता फ़ील्ड।

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 दबाकर ।