Arista 7050T(EOS 4.10.6)에서 서드파티 DWDM SFP+가 계속 다운: 이미지 패치 말고 다른 방법 있나요
작은 지역 네트워크를 운영하고 있는데, 재고에 남아 있던 7050T를 꺼내서 DWDM 집선 장비로 쓰려고 했어요. 여기 맞는 Arista 코드 DWDM 광모듈은 가격이 스위치 값에 거의 맞먹어서, 대신 서드파티 DWDM SFP+를 샀는데 이제 스위치가 이걸 아예 안 받아줘요.
- Arista 7050T, EOS 4.10.6
- 범용 서드파티 DWDM SFP+, Arista 코딩 없음
- 반대편은 Arista가 아닌 장비인데, 같은 모듈이 거기서는 아무 말썽 없이 올라옴
이 모듈을 꽂는 순간 포트가 계속 다운돼요. 제가 보기엔 트랜시버 에이전트가 포트를 올리기 전에 모듈을 먼저 검증하는데, Arista가 아닌 모듈은 presence와 인증 체크 자체를 통과 못 하는 것 같아요:
/usr/lib/python2.7/site-packages/XcvrAgent.py, around line 172
assert xcvrStatus.presence == 'xcvrPresent'이미 해본 것:
- 모듈을 다시 꽂고 여러 포트로 옮겨봄, 어디서나 결과 동일
- 같은 포트에 Arista 코드 10G 모듈을 꽂으니 바로 올라옴, 그러니 포트/패치/광섬유는 멀쩡함
- 검사를 완화하는 설정 옵션을 찾아봤는데 이 릴리스에는 없음
EOS 이미지를 다시 빌드해서 그 줄들을 주석 처리하는 방법이 계속 머릿속에 맴도는데, 거기 가기 전에요: 이 장비가 이 광모듈을 받아들이게 하는 지원되는 방법이 있나요? 4.10.6에서 정말 이미지 패치만이 유일한 방법이라면, 나중에 대가가 뭘까요?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
누가 이미지 얘기 꺼내기 전에 두 가지만요.
그 7050T가 실제로 묶여 있는 EOS 트레인이 어느 거예요? 4.10.6에 계속 머물러야 한다면 빌드 전용 해킹도 나름 일관성은 있어요. 옮길 수 있다면, 트랜시버 처리 로직이 이후 릴리스에서 재구성돼서 4.10.6용으로 쓴 레시피는 그대로 안 옮겨간다는 걸 알아두세요.
그리고 그 공급사가 실제로 뭘 구워넣을 수 있나요? 프로그래머 장비에 Arista 프로필이 아예 있는지, 아니면 대부분이 갖고 있는 플랫폼별 Cisco 코딩뿐인지 물어볼 만해요 - 예를 들어 ASR9K 부품은 자기만의 프로필이 필요하고 광모듈 벤더들이 그걸 유지보수해요. 배치를 재코딩받는 게 수정된 이미지로 사는 것보다 훨씬 싸요. 별개로: 계정 담당팀에 unsupported-transceiver 키는 물어보셨어요, 아니면 상업적인 이유로 그건 아예 논외인가요?
이미지 패치는 정확히 그 빌드에서는 돼요, 일도 그렇게 많지 않고요 - 다만 랩이나 예비 장비에서만 하세요, 트래픽 나가는 장비에는 절대 하지 마시고요.
대략적인 모양: EOS-4.10.6.swi를 unzip해서 구성원인 boot0, initrd-i386, linux-i386, rootfs-i386.sqsh, version을 남겨두세요. 루트 파일시스템을 root로 풀고, 에이전트를 수정하고, 다시 패킹하세요:
수정 자체는 squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py 안에 있어요: 172번 줄 근처에서 presence 상태를 assert하고 그다음 트랜시버 인증을 돌리는 네 줄을 주석 처리하세요. zip의
-Z store는 선택이 아니에요, swi는 비압축 상태를 유지해야 장비가 부팅해요.그 이후로는 뭘 꽂든 포트가 올라와요, 더 이상 아무것도 검증을 안 하니까요. 대가는 두 가지예요: 수정된 이미지에서는 벤더 지원이 없고, 패치는 이 빌드에 묶여 있어서, 뭔가 틀어졌을 때 다시 부팅할 수 있게 정품 .swi를 플래시에 남겨두세요.
위 질문들에 답하자면: 이 장비는 지원 계약이 없는 예비 장비고, 공급사 프로그래머에는 Arista 프로필이 아예 없어요 - Cisco 플랫폼용으로만 코딩하고 그게 목록의 끝이라, 이 배치를 재코딩받는 건 안 된대요. 계정 담당팀 경로가 아예 막힌 건 아닌데, 이번 주 안에는 도움이 안 돼요.
설명하신 대로 4.10.6을 다시 빌드해서 패치된 이미지로 부팅했더니, DWDM 포트 둘 다 첫 시도에 올라왔어요. 정품 이미지는 여전히 플래시에 있고요. 그 뒤로 링크는 계속 안정적이고, 반대편에서도 이상한 건 안 보인대요.
잘 됐다니 다행인데, 이 패치의 유효기간에 대해서는 스스로 냉정하게 보세요. 위 스레드가 실제보다 더 일반적인 것처럼 들리게 하고 있어서요.
이건 딱 4.10.6용으로 쓰인 거고 그 이상은 아니에요. 4.14.5F, 4.14.7M, 4.23.8M에서 재현하는 방법을 물어본 사람들이 있었는데 아무도 되는 답을 올린 적이 없어요, 트랜시버 매니저가 이후 릴리스에서 재구성돼서 그 네 줄이 그 자리에 그대로 기다리고 있지 않거든요. 업그레이드할 때마다 이미지 자체가 바뀌니까 패치는 사라지고, 다음번에 누가 정기 점검만 해도 포트가 다시 내려가요.
업그레이드에서도 살아남는 경로는 계정 담당팀이 발급하는 고객 전용
service unsupported-transceiver키, 그리고 구형 플랫폼에서는 enable3px 마커 파일이에요. 패치된 이미지는 오래된 장비 하나 계속 쓰는 용도로만 쓰고, 네트워크 전체 표준으로 삼지는 마세요.Cisco 쪽도 같은 싸움을 했는데, 옮겨둘 만한 디테일이 하나 있어요. 서드파티 80km DWDM SFP+(Pro10Optix, SFP-10G-DWDM-192로 표기)가 Catalyst 6500 스위치에서는 아무 문제 없이 돌고 있었어요. IOS XR 5.3.3의 ASR 9001 내장 SFP+ 포트로 옮기니 이렇게 나왔어요:
포트 LED는 빨간색, 인터페이스는 다운, 상태는 루프백 없는 link loss나 low light로 나왔고, 파장은 0nm로 읽히고 레이저는 아예 안 켜졌어요. 인터페이스의
transceiver permit pid all은 그것만으로는 아무것도 안 바꿨고, 거기에 전역service unsupported-transceiver를 더해도 그 배치는 구제가 안 됐어요. 이 플랫폼은 자체 광모듈 매트릭스에서 DWDM-SFP10G-xx.yy 형태의 부품번호를 기대하는데, 범용 PID는 어떤 지원 광모듈로도 매핑이 안 돼서, 오버라이드가 완화해줄 대상 자체가 없어요.같은 릴리스에서 다른 사람은 Skylane SPDTU080100D139 80km 모듈을 9001에서 돌리는 데 성공했어요 - 다만 두 명령을 다 설정했을 때만 그랬고, 안 그러면 링크가 한 번 끊겼다 붙을 때 인터페이스가 복구되지 않았대요. 문제의 배치는 결국 제대로 코딩된 모듈로 교환됐어요.
공급사한테 다시 갈 때 한 번 덜 왔다갔다 하게 해주는 팁 하나 보태자면: 브랜드가 아니라 플랫폼 기준으로 코딩해달라고 요청하세요. 이런 스레드 상당수는 모듈이 벤더는 맞게 식별되는데 그 플랫폼 매트릭스가 들어본 적 없는 부품번호를 달고 있는 경우고, permit 계열 오버라이드는 어차피 장비 눈에 그럴듯하게 보이는 모듈의 검사만 완화해줘요.
모듈이 아직 작업대에 있을 때, EEPROM이 SFF-8472를 엄격히 준수하는지 확인해달라고 하세요. A2h 데이터가 엉성하면 읽어봤자 헛값이 나오는데 - 위에서 말한 0nm 파장이 정확히 그런 경우예요 - 판독값이 깨끗한데도 플랫폼이 여전히 그 부품을 거부한다면, 그때는 서드파티 광모듈에 대한 막연한 주장이 아니라 벤더 지원팀에 들이밀 구체적인 근거가 생기는 거예요.