체크섬: CC_BASE, CC_EXT, CC_DMI, CMIS 페이지

모든 관리 규격은 식별 정보 블록을 하나 이상의 체크섬으로 보호합니다. 체크섬은 한 바이트로, 호스트가 내용을 신뢰하기 전에 손상되었거나 절반만 기록된 EEPROM을 감지할 수 있게 해줍니다. 계산 자체는 아주 간단하지만 잊어버리기도 쉽습니다. 방금 코딩한 모듈이 invalid로 표시되는 가장 흔한 원인은 편집 후 갱신하지 않은 낡은 체크섬입니다.

알고리즘

모든 체크섬은 같은 규칙을 씁니다: 해당 범위의 바이트를 부호 없는 8비트 값으로 더하고 합계의 하위 8비트만 남깁니다(합계 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입니다.

각 체크섬의 위치

어떤 체크섬으로도 보호되지 않는 영역: 벤더 전용 영역(SFP A0h 96–127, QSFP 224–255, CMIS 223–255), 사용자 EEPROM, 실시간 모니터와 플래그, QSFP page 03h 임계값, CMIS 레인 페이지입니다. 벤더는 벤더 영역에 자체 무결성 필드를 추가하기도 하지만, 이는 규격의 일부가 아닙니다.

호스트의 대응 방식

체크섬 오류는 식별 정보와 함께 보고되므로, 정책 문제까지 겹친 모듈은 한 메시지가 다른 메시지를 가리기도 합니다. 체크섬은 고치기 쉬우니 먼저 확인하십시오. 증상별 정리: 증상 색인.

다시 계산해야 하는 경우

• 보호 범위 안의 어떤 내용이든 편집한 뒤: 벤더명, 부품 번호, 시리얼 번호, 날짜 코드, 컴플라이언스 코드, 파장, 길이, 옵션, 전력 등급.
• SFP에서 임계값이나 교정 상수를 적용한 뒤(CC_DMI).
• 다른 모듈에서 가져온 부분 이미지를 복원한 뒤.
• 벤더 영역, 사용자 EEPROM, A2h 제어 바이트를 변경한 경우에는 필요 없음.

작업 순서: 편집 → 영향받는 모든 체크섬 재계산 → 쓰기 → 다시 읽기 → 검증. 체크섬 바이트를 그 대상 데이터보다 먼저 쓰면, 그 사이에 전원이 끊길 경우 모듈이 invalid 상태가 되는 취약한 구간이 생깁니다.

체크섬과 벤더 락

올바른 체크섬은 필요조건이지 충분조건이 아닙니다. 엄격한 플랫폼은 벤더 블록도 확인하며, 락이 걸린 설계에서는 규격의 체크섬이 전혀 알지 못하는 벤더 영역의 독자 서명까지 확인합니다. 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).