Brocade G720, DD PoD 라이선스를 적용해도 모든 64G SFP-DD 포트가 Module_Invalid에 머묾
새 패브릭용으로 Connectrix DS-7720B(Brocade G720) 한 쌍을 물려받았는데, 아직 존 설정 근처에도 못 갔습니다. 더블 덴시티 포트가 단 하나도 안 올라오기 때문입니다. switchshow에서는 전부 다 똑같은 내용이 나옵니다.
Index Port Address Media Speed State Proto
====================================================
48 48 031800 dd -- Module_Invalid (Speed Mismatch / Incompatible SFP)
49 49 031900 dd -- Module_Invalid (Speed Mismatch / Incompatible SFP)랙에 있는 것:
- Connectrix DS-7720B / Brocade G720, Fabric OS는 납품 당시 그대로인 9.0.x 라인
- Double Density Ports on Demand 라이선스 설치됨, 적용 상태로 표시됨
- Brocade 정품 64G FC SFP-DD 트랜시버, 부품번호 57-1000505-01
- 광모듈과 같은 박스에서 나온 공장 출고 패치코드
뻔한 얘기가 나오기 전에 미리 말씀드리면, 모듈은 전부 재장착했고 두 개는 포트 사이로 옮겨봤는데 장애는 모듈을 따라다니지 않고 포트에 그대로 남습니다. Double Density Ports on Demand 라이선스는 정말로 적용돼 있지 주문만 된 게 아니라는 것도 두 번 확인했습니다. 패치코드도 바꾸고 단자도 청소했는데 차이가 없습니다. 같은 섀시의 일반 포트들은 트래픽을 아주 잘 나르고 있으니 죽은 스위치는 아닙니다.
더블 덴시티 광모듈 불량 재고를 받은 건가요, 아니면 스위치가 케이지 안을 제대로 살펴보기도 전에 미리 못 쓴다고 적어버리는 건가요?
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
광모듈은 멀쩡합니다. 문제는 펌웨어입니다.
G720에서 64G FC SFP-DD는 Fabric OS 9.1.0부터 지원됩니다. 9.0.x 펌웨어는 그 폼팩터 자체를 전혀 모르기 때문에 케이지 안에 뭐가 있는지 식별을 못 하고 호환 안 됨으로 되돌아가 버립니다. 그게 바로 모든 더블 덴시티 포트에서 보고 계신 Module_Invalid with Speed Mismatch / Incompatible SFP입니다. 직접 하신 실험도 반대 방향에서 같은 얘기를 해줍니다. dd 모듈을 거부하는 바로 그 포트에서 평범한 광모듈은 잘 들어오고, 두 번째 섀시도 똑같은 펌웨어라서 동일하게 동작하는 거고요.
갖고 계신 부품인 57-1000505-01은 Brocade Transceiver Support Matrix에 등재돼 있고, 그 매트릭스에 플랫폼별 최소 펌웨어가 적혀 있습니다. G720의 경우 그 항목은 9.1.0부터 시작합니다. 9.1.0 이상으로 올리면 이미 꽂혀 있는 광모듈 그대로 그 포트들이 올라옵니다.
상자 안에 있는 그 블레이드도 같은 이야기입니다. Gen 7 플랫폼은 전부 매트릭스에 자기만의 최소 기준이 있습니다. G730(DS-7730B), 7850(MP-7850B), FC64-64도 마찬가지고요. 그러니 더블 덴시티 광모듈을 옮기기 전에 하나하나 찾아보세요. 안 그러면 다음 박스에서 오늘 오후를 한 번 더 날리게 됩니다.
다른 건 몰라도 모듈은 반품하지 마세요.
RMA 서류는 일단 미뤄두세요. 여기서 보기엔 불량 재고 전체 배치인 것 같지는 않습니다. media 칸에 이미 dd가 찍혀 있는 Module_Invalid는 스위치가 케이지에서 뭔가를 읽어내긴 했는데 그 내용이 마음에 안 든다는 뜻입니다. 진짜로 죽은 모듈은 보통 거기까지도 못 갑니다. no-module 상태가 나왔겠죠.
비용 들이지 않고 범위를 좁힐 방법 세 가지.
그리고 지금은 라이선스는 생각에서 빼두세요. Ports on Demand는 포트를 풀어주는 거지, 펌웨어에게 한 번도 본 적 없는 폼팩터를 가르쳐주는 게 아닙니다.
빌린 광모듈 얘기, 좋은 지적이었습니다. 정상 포트 중 하나에서 동작하는 Brocade 모듈을 뽑아서 48번 포트에 꽂았더니 바로 F-Port로 온라인이 됐습니다. 같은 포트에 64G SFP-DD를 다시 꽂으니 1-2초 안에 다시 Module_Invalid입니다. 그러니까 케이지는 살아 있고 라이선스도 제 역할을 하고 포트 자체도 멀쩡합니다. 스위치가 안 받아주는 건 오직 더블 덴시티 모듈뿐입니다.
두 스위치 다요, 맞습니다. 두 번째 DS-7720B는 아직 대부분 크레이트 안에 있지만, dd 모듈 두 개를 벤치에서 꽂아보니 똑같은 줄이 그대로 나왔습니다. 그러니 한 섀시만 결함이 있는 게 아닙니다.
다른 Gen 7 장비는, 아직 프로덕션에는 없는데 디렉터 슬롯을 기다리는 박스 안에 FC64-64 블레이드가 하나 있고, 정확히 이 광모듈을 쓰려고 산 겁니다. 거기서도 똑같이 물릴 거라면 마이그레이션 기간 중이 아니라 지금 알고 싶네요.
벤더는 다른데 함정 모양은 같습니다. 누군가 모듈을 케이지에서 뽑았다 꽂았다 하며 오후를 날리는 걸 막을 수 있을까 해서 올립니다.
Dell S5248F-ON, SONiC 마스터 빌드입니다. SFP28 포트가 단 하나도 동작하지 않았습니다. 포트 LED는 전부 켜져 있는데 show interface transceiver presence는 트랜시버가 전혀 없다고 나왔고, 케이지 안 광모듈은 완전히 멀쩡했습니다.
광학적인 문제는 하나도 없었습니다. 플랫폼 모니터 컨테이너가 죽어 있었습니다. pmon이 안 돌고 있었고 pcied, xcvrd, psud도 마찬가지였습니다. xcvrd가 모듈들과 I2C로 대화하는 프로세스라서, 그게 죽어 있으면 아무도 EEPROM을 읽지 않는 거고, CLI는 자기가 아는 걸 정직하게 보고한 것뿐입니다. 아는 게 없었을 뿐이죠. docker ps와 show system-health detail이 1분 만에 전체 사정을 알려줬는데, 그건 이미 모듈을 반나절 동안 이리저리 바꿔 꽂아본 뒤였습니다.
Z9264F에서도 같은 부류의 일이 있었는데, 플랫폼 플러그인의 Sfp 생성자가 AttributeError: 'Sfp' object has no attribute 'port_type'로 죽으면서 부팅 시 determine-reboot-cause.service까지 같이 끌고 내려갔습니다. 포트 한 부류 전체가 정확히 똑같은 방식으로 오동작하면, 광모듈은 제일 먼저 의심할 대상이 거의 아닙니다.
이 문제의 나머지 절반은 화려하지 않은 부분인데, 실제로 시간이 거기서 갑니다. 아직 뒤에 아무것도 안 걸린 스위치라도 Fabric OS를 올리는 건 회의 두 개 사이에 뚝딱 하는 일이 아니라 여전히 변경 작업 창(change window)입니다. 그러니 패브릭에서 같이 움직여야 할 게 또 뭐가 있는지 먼저 파악하고 다운타임을 제대로 잡아두세요.
그 FC64-64가 아직 상자 안에 있다면, 더블 덴시티 광모듈을 보기 전에 9.1.0 이상으로 올려두세요. 안 그러면 엣지 스위치가 아니라 디렉터에서, 그것도 사람들 보는 앞에서 이 스레드를 재현하게 됩니다.
실용적인 것 하나 더. 공급업체가 RMA를 접수하기 전에 먼저 연락하세요. 그 모듈들은 스스로를 완벽하게 식별하고 있고, 호스트 쪽에 아직 그 항목이 테이블에 없을 뿐입니다. 공급업체가 불량으로 받아들이면 정확히 똑같이 동작하는 교체 배치를 3주 기다렸다가 그다음에 또 업그레이드까지 해야 합니다.
확인됐습니다, 펌웨어가 맞았습니다.
주말 작업 창에 두 스위치 다 9.1.0으로 올렸고, 재부팅하자 모든 더블 덴시티 포트가 Module_Invalid에서 벗어나 그동안 계속 꽂혀 있던 바로 그 57-1000505-01 광모듈로 64G에서 온라인이 됐습니다. 재장착도, 교체도, 재배선도 없었습니다.
라이선스는 제가 계속 쫓아다니던 허수아비였던 걸로 드러났습니다. 처음부터 제대로 적용돼 있었을 뿐, 9.0.x에서는 그냥 쓸모 있는 일을 할 수가 없었던 겁니다. 그 블레이드는 디렉터 슬롯 근처에도 가기 전에 9.1.0으로 올리기로 했고, 지금 놓여 있는 상자에 그렇게 써서 붙여놨습니다. 덕분에 RMA 한 번과 공급업체와의 꽤 어색한 대화를 아꼈습니다.