중고 DCS-7150S-24에서 서드파티 SFP+ 옵틱이 계속 다운: enable3px 플래시 파일이 아직도 되나?
랩용으로 중고 Arista 스위치를 몇 대 구했는데 바로 옵틱 게이트에 걸렸습니다. Arista 코딩 모듈은 링크되고, 패시브 DAC 케이블도 링크되는데, 서드파티는 뭐든 포트가 다운 상태로 남습니다.
랩 구성:
- 중고로 구매한 DCS-7150S-24, 지원 계약도 없고 뒤에 계정 담당팀도 없음
- 이것저것 섞인 서드파티 SFP+ 모듈
- 랙 내부 짧은 구간용 패시브 DAC 케이블
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes up지금까지 파악한 것:
- DAC는 올라오고 옵틱은 안 되는 걸 보면 배선이나 죽은 케이지가 아니라 코딩 체크 문제
service unsupported-transceiver CUSTOMERNAME LICENSEKEY형태의 설정 명령이 있는데, 당연히 제가 구할 방법이 없는 키를 요구함- 예전 글들은 키 대신 플래시의 마커 파일 얘기를 하는데, 어느 세대에 해당하는 건지 알 수가 없음
이 연식의 장비에는 이 둘 중 어느 메커니즘이 해당하나요, 그리고 7150S에서 플래시 파일이 아직 되는 건가요, 아니면 이제 키만 남은 건가요?
Comments 6
이 세대에서는 파일 방식이고, 들리는 것만큼이나 투박합니다. EOS CLI에서:
빈 파일이고 안에는 아무것도 없습니다 - 그냥 존재하는 것만으로 reload 후 서드파티 옵틱이 켜집니다. 이게 먹히는 플랫폼 목록은 깁니다 - DCS-7120T-4S, DCS-7050 제품군, DCS-7150S 라인 전체를 비롯해서요. 모델마다 이 파일을 여전히 존중하는 최신 EOS 릴리스가 다른데, 가장 오래된 장비의 4.13.16M부터 7150S의 4.23 트레인까지 대략 걸쳐 있습니다. 더 신형 스위치는 이 파일을 완전히 무시합니다.
그러니 7150S-24는 그 경계선의 좋은 쪽에 있습니다, 다만 그 모델이 지원하는 범위를 넘어서 업그레이드하지 않았다는 전제하에요. 키 쪽 방법 근처에 가시기 전에 이것부터 시도해보세요.
그 7150S-24는 어느 EOS 트레인인가요, 그리고 구매 후에 업그레이드하셨나요? 이게 중요한 이유는, 컷오프가 제품군이 아니라 플랫폼별로 다르기 때문입니다. 플래그 파일은 7048T, 7120T-4S, 7140T-8S, 7124와 7148 SFP+ 변형, 7050과 7150S 시리즈, 7548S-LC 라인카드에서 동작한다고 문서화돼 있지만, 이걸 여전히 존중하는 마지막 EOS 릴리스는 기종마다 다릅니다.
중고 장비에서 이미 EOS를 업그레이드하셨다면, 그 트릭 밖으로 스스로를 업그레이드해버렸을 가능성이 꽤 있고, 그렇다면 값싼 해결책은 키를 찾아 헤매는 게 아니라 트레인을 도로 내리는 겁니다.
장비가 도착한 뒤로 EOS는 한 번도 안 건드려서, 판매자가 남겨둔 트레인 그대로였습니다 - 이게 운이 좋았던 거네요. touch, write memory, reload를 하니 전에 죽어 있던 서드파티 SFP+ 모듈이 이제 일반 포트로 올라옵니다. 키도, 계정 담당팀도, 다른 어떤 것도 필요 없었습니다. DAC는 예상대로 그동안 계속 잘 동작했습니다.
더 신형 장비를 갖고 여기 오신 분들을 위해 - 거기서는 이 파일이 정말로 무시되고, 유일한 방법은 러닝 컨피그에 다음과 같이 들어가는 고객별 암호화 키입니다
이 키는 지원팀이 아니라 계정 담당팀이나 영업팀에서 나옵니다 - TAC는 unlock 키를 발급할 권한이 없고 계정 관리 쪽으로 돌려보낼 텐데, 스위치가 중고 시장에서 온 경우라면 막다른 길입니다.
랩 구축을 위해 다시 한번 말씀드리면, 패시브 DAC 케이블은 unlock 상태가 뭐든 기본적으로 받아들여집니다. 구간이 충분히 짧다면 DAC로 배선하고 옵틱은 정말로 필요한 링크에만 남겨서 이 질문 전체를 피해갈 수 있습니다.
"러닝 컨피그에 들어간다"에 작은 정정 하나 - 예전에 제가 다뤘던 구형 코드에는 같은 명령의 비공식 변형도 있었습니다. 그러니 위 문법과 안 맞는 레퍼런스를 보시더라도, 누가 오타를 낸 게 아니라 거기서 나온 겁니다.
제 경험으로는 이 키가 리부트 없이도 바로 적용됐습니다 - 명령을 넣은 직후 대부분의 서드파티 옵틱이 동작하기 시작했는데, 그래도 모듈 몇 개는 뭘 해도 계속 거부했습니다. 그건 꽤 예전 일이고 지금은 제게 없는 하드웨어였으니, 이걸 근거로 점검 시간을 잡으시기 전에 직접 갖고 계신 장비에서 확인해보세요.
이 주제가 나올 때마다 이 비교도 같이 나오니 말씀드리면 - Cisco IOS-XE와 IOS XR에서는 대응되는 게 한 단계가 아니라 두 단계입니다. 전역 명령만으로는 부족하고, 모듈을 받아야 할 물리 포트마다 인터페이스별 명령도 필요합니다:
인터페이스별 라인이 product-ID 체크를 건너뛰게 해주는 것이라, 포트가 적어도 옵틱을 켜보려는 시도는 합니다 - 그 뒤에 모듈이 실제로 동작한다는 보장은 아니고, 플랫폼이 거부를 멈춘다는 것뿐입니다. 저는 IOS XR 5.3.3과 IOS-XE 장비들에서 해봤습니다.
이 주의사항은 두 벤더 다 똑같고, 사람들이 이걸 계속 논쟁하는 이유이기도 합니다 - 장애가 고객이 설치한 서드파티 트랜시버로 추적되면 보증이나 계약상의 지원이 거부될 수 있습니다. 랩이라면 괜찮지만, 운영 환경에서는 의식적으로 내려야 할 결정입니다.