Prüfsummen: CC_BASE, CC_EXT, CC_DMI, CMIS-Seiten
Jede Management-Spezifikation schützt ihren Identitätsblock mit einer oder mehreren Prüfsummen — einem einzelnen Byte, mit dem der Host ein beschädigtes oder halb geschriebenes EEPROM erkennt, bevor er dem Inhalt vertraut. Sie sind trivial zu berechnen und leicht zu vergessen: eine veraltete Prüfsumme nach dem Bearbeiten ist der häufigste Grund, warum ein frisch kodiertes Modul als ungültig gemeldet wird.
Der Algorithmus
Alle folgen derselben Regel: die Bytes des abgedeckten Bereichs als vorzeichenlose 8-Bit-Werte addieren und die unteren 8 Bit der Summe behalten (Summe modulo 256). Kein CRC, kein Polynom.
Summe = 0
für jedes Byte b im Bereich:
Summe = (Summe + b) & 0xFF
Prüfsumme = Summe
Beispiel — die ersten fünf Bytes eines 10GBASE-SR-SFP: 03 04 07 10 00 → 3 + 4 + 7 + 16 + 0 = 30 = 1Eh. Setzt man das bis Byte 62 fort, ergibt sich CC_BASE.
Wo jede Prüfsumme liegt
| Spezifikation | Prüfsumme | Ort | Abdeckung |
|---|---|---|---|
| SFF-8472 (SFP) | CC_BASE | A0h Byte 63 | A0h Byte 0–62 |
| SFF-8472 | CC_EXT | A0h Byte 95 | A0h Byte 64–94 |
| SFF-8472 | CC_DMI | A2h Byte 95 | A2h Byte 0–94 (Schwellwerte und Kalibrierkonstanten) |
| SFF-8636 (QSFP) | CC_BASE | Byte 191 | Upper Page 00h Byte 128–190 |
| SFF-8636 | CC_EXT | Byte 223 | Byte 192–222 |
| INF-8077i (XFP) | CC_BASE | Byte 191 | Byte 128–190 |
| INF-8077i | CC_EXT | Byte 223 | Byte 192–222 |
| CMIS | Seitenprüfsumme | Page 00h Byte 222 | Page 00h Byte 128–221 |
| CMIS | Seitenprüfsumme | Page 01h Byte 255 | Page 01h Byte 130–254 (128–129 enthalten die inaktive Firmware-Version und sind ausgeschlossen) |
| CMIS | Seitenprüfsumme | Page 02h Byte 255 | Page 02h Byte 128–254 |
| CMIS | Seitenprüfsumme | Page 04h Byte 255 | Page 04h Byte 128–254 |
Von keiner Prüfsumme abgedeckt: die herstellerspezifischen Bereiche (SFP A0h 96–127, QSFP 224–255, CMIS 223–255), das User-EEPROM, die Live-Monitore und Flags, die Schwellwerte auf QSFP Page 03h und die CMIS-Lane-Pages. Hersteller können in ihrem eigenen Bereich zusätzliche Integritätsfelder hinzufügen — diese sind nicht Teil der Spezifikation.
Was Hosts damit tun
| Verhalten | Ergebnis einer fehlerhaften Prüfsumme |
|---|---|
| CC_BASE prüfen (die meisten Switches und Router) | Modul wird als invalid, unsupported oder EEPROM checksum error angezeigt; Port kann errdisable gehen; Laser bleibt oft aus |
| Auch CC_EXT prüfen | dasselbe, oder je nach Plattform nur ein Logeintrag |
| CC_DMI prüfen | DDM wird als not supported angezeigt oder die Werte werden ignoriert; der Link selbst ist nicht betroffen |
| Prüfsummen ignorieren (viele NICs, manche offenen Switches) | Modul funktioniert; der Fehler zeigt sich nur in den Tools |
Ein Prüfsummenfehler wird zusammen mit der Identität gemeldet, sodass bei einem Modul, das zusätzlich ein Policy-Problem hat, eine Meldung die andere verdeckt — zuerst die Prüfsummen prüfen, sie sind die billige Korrektur. Symptomübersicht: Symptomindex.
Wann neu berechnet werden muss
- Nach dem Bearbeiten von irgendetwas in den abgedeckten Bereichen — Herstellername, Teilenummer, Seriennummer, Datumscode, Compliance-Codes, Wellenlänge, Längen, Optionen, Leistungsklasse.
- Nach dem Anwenden von Schwellwerten oder Kalibrierkonstanten bei SFP (CC_DMI).
- Nach dem Wiederherstellen eines Teil-Images von einem anderen Modul.
- Nicht nötig bei Änderungen im Herstellerbereich, im User-EEPROM oder bei A2h-Steuerbytes.
Reihenfolge: bearbeiten → jede betroffene Prüfsumme neu berechnen → schreiben → zurücklesen → prüfen. Wird das Prüfsummen-Byte vor den Daten geschrieben, die es abdeckt, entsteht ein Zeitfenster, in dem ein Stromausfall ein ungültiges Modul erzeugt.
Prüfsummen und Herstellersperren
Korrekte Prüfsummen sind notwendig, aber nicht hinreichend. Eine strikte Plattform prüft zusätzlich den Herstellerblock und bei gesperrten Designs eine proprietäre Signatur im Herstellerbereich, von der die Spezifikations-Prüfsummen nichts wissen. Ein bestandenes CC_BASE bei abgelehnter Identität sieht nach einem Fall von Herstellersperre aus, nicht nach einem Prüfsummenfall — Herstellersperre, Herstellerfelder.
In CodingBox
CodingBox berechnet CC_BASE, CC_EXT, CC_DMI und die CMIS-Seitenprüfsummen bei jedem Schreibvorgang automatisch neu und markiert eine Abweichung beim Lesen eines Moduls — ein rotes Prüfsummenfeld auf Check transceiver oder im EEPROM editor bedeutet, dass das Modul anderswo bearbeitet wurde, ohne die Prüfsumme zu korrigieren, oder dass das EEPROM beschädigt ist.
Wo jede Prüfsumme unter ihren Nachbarn liegt: SFF-8472 A0h (63, 95), A2h (95), SFF-8636 Upper (191, 223), CMIS Upper Pages (222, 255), XFP (191, 223).