벤더 락과 “unsupported transceiver”

가장 흔한 트랜시버 문제입니다. 스위치와 NIC 벤더 — Cisco, Intel, HPE/Aruba, Juniper, Mellanox 등 — 는 모듈이 EEPROM에서 보고하는 식별 문자열을 확인해, 인식하지 못하는 모듈을 거부하거나 표시합니다.

엔지니어들이 뼈아프게 배우는 핵심은 이것입니다: “unsupported”가 “동작하지 않는다”는 뜻은 아닙니다. 대부분의 플랫폼에서 이 상태는 정보성일 뿐이며 포트를 올릴 수 있습니다.

증상

플랫폼	나타나는 증상
Cisco IOS	포트 `notconnect — unsupported`; 로그 `%C4K_TRANSCEIVERMAN-3-INCOMPATIBLE`
업그레이드 후의 Cisco IOS	포트가 `errdisable`로 전환, 이유 `gbic-invalid`
Mellanox	EEPROM은 읽히지만 링크가 안 됨: `speed and type: Not supported`
Intel X520/ixgbe	Intel 제품이 아닌 SFP에서 `no carrier`

해결 방법

Cisco. 모든 포트에서 서드파티 모듈을 허용하려고 기본 설정에 일상적으로 넣는 명령이 두 개 있습니다:

service unsupported-transceiver
no errdisable detect cause gbic-invalid

플랫폼별 특이사항: 일부 Catalyst 9200 빌드에서는 첫 번째 명령이 % Ambiguous command를 반환합니다 — 전체를 다 입력하십시오; Nexus 9000에서는 탭 완성이 안 되는 숨겨진 명령이지만 정상적으로 받아들여집니다.

Intel X520(Linux). Intel 제품이 아닌 모듈을 허용하는 옵션으로 드라이버를 로드합니다:

modprobe ixgbe allow_unsupported_sfp=1

NIC 자체 EEPROM의 비트를 바꿔 영구적으로 적용하는 방법도 존재하며 아래 출처에 문서화되어 있습니다 — NIC EEPROM에 잘못 쓰면 현장에서 복구할 수 없으므로 주의해서 다루십시오.

ASR 9000 시리즈. 이미 업 상태인 포트에 모듈을 꽂으면 인식되지 않을 수 있습니다: 포트를 shut하고 모듈을 꽂은 다음 no shut합니다.

근본적인 해결책 — 모듈을 재코딩합니다. 모듈의 벤더 ID와 부품 번호를 다시 써서 순정 모듈처럼 보이게 만듭니다. CodingBox가 EEPROM editor에서 하는 일이 바로 이것으로, CC_BASE/CC_EXT를 다시 계산하고 먼저 백업을 남깁니다. 구체적인 방법은 EEPROM 재코딩을 참고하십시오.

누구나 반복하는 조언

종류별로 정품 OEM 모듈을 하나씩 선반에 보관해 두십시오. 지원 티켓을 열기 전에 이것으로 바꿔 끼우면, 벤더가 문제를 서드파티 광학 부품 탓으로 돌릴 수 없습니다.

스위치에서 확인하기

위 방법 중 무엇을 쓰든, 모듈이 인식되고 읽히는지 확인하십시오: NOS별 명령은 스위치에서 옵틱스 검증을 참고하고, CodingBox가 벤치에서 읽은 식별 정보와 비교합니다.

호스트가 정확히 무엇을 비교하는지 — 이름, PN, OUI, 시리얼 패턴, 벤더 시그니처 — 그리고 기동 과정의 어느 단계에서 거부하는지: 벤더 필드, 호스트가 하는 일.

벤더별 검증 동작과 우회 방법을 표 하나로 정리: 각 NOS가 모듈을 검증하는 방식; 플랫폼이 기대하는 정확한 PN 문자열: OEM 부품 번호; NOS별 명령 구문: 포트 설정 레시피.

이 문서에서 부정확한 내용이나 오류를 발견하면 해당 부분을 선택하고 Ctrl+Enter를 눌러 해 주세요.