IBM Flex System EN4093, 부팅 시와 운용 중에 SFP+ 트렁크 포트가 ERRDISABLE로 떨어짐
Flex System 인클로저 두 대에 각각 네트워크 모듈로 EN4093R 10Gb Scalable Switch(옵션 49Y4270)가 들어 있습니다. 섀시 전원 이벤트 이후 포트가 error-disabled 상태로 돌아오고, 드물게는 정상 운용 중에도 같은 상태로 떨어집니다. 매번 같은 포트가 아니라서 추적하기가 여간 성가신 게 아닙니다.
구성:
- IBM Flex System EN4093 10Gb Scalable Switch, 옵션 49Y4270
- 코어까지 4포트 업링크 트렁크, IBM 광모듈에 나중에 추가한 DAC 하나
- 두 번째 인클로저 쪽으로 브레이크아웃된 QSFP+ 포트
- 저희 쪽은 MSTP, 코어는 다른 벤더
부팅 후 포트 목록에 나오는 내용:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilities시도한 것:
- 해당 포트에 shutdown / no shutdown을 하면 대부분 다음 이벤트 전까지는 돌아옴
- 트렁크의 모든 광섬유를 청소하고 재장착했는데 패턴에 변화 없음
- 반대편 포트 설정을 비교했는데 서류상으로는 속도가 일치함
실제로 이 포트들을 errdisable로 밀어넣는 게 뭔가요, 그리고 매번 수동으로 클리어하는 대신 부팅할 때마다 이런 일이 안 생기게 막을 방법이 있나요?
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 5
이 스위치에는 포트를 비활성화하는 문서화된 상태가 일곱 가지 있고, 서로 거의 관계가 없습니다.
여기 해당하는 건 네 번째입니다. 이게 대부분이 겪는 이유인데, 자기가 자초하는 경우이기 때문입니다. 트렁크 하나 안에 모듈 속도나 종류를 섞으면 스위치가 반발합니다. 광모듈 세 개 옆에 DAC 하나 있는 걸로도 충분합니다. 거기서 DAC를 빼고 나머지 셋과 맞는 모듈로 그 슬롯을 채우세요.
플랩 감지기에 걸린 포트는 여전히 문서에 나온 복구법이 통합니다.
그 다음 그 링크의 스패닝 트리 설정을 다시 읽어보고 구리와 광섬유를 손으로 직접 점검하세요. 설정을 바꾼 뒤에는 꼭 reload를 하세요. 안 그러면 운용 중인 상태가 조용히 설정한 값과 어긋나기 시작합니다.
기대하지 말아야 할 것 두 가지. 그 일곱 상태 중 둘은 타임아웃이 지나도 포트가 내려간 채로 남아서 손으로 손봐줘야 합니다. 그리고 이걸 고쳐주는 펌웨어 릴리스는 없습니다. 벤더 입장은 설정으로 우회하라는 거라서, 트렁크 멤버 전부 같은 모듈에 광섬유를 깨끗하게 유지하는 게 예방의 한계입니다.
저라면 붙여넣은 내용에 이유가 두 가지 섞여 있다는 데서 시작하겠습니다. 특정 포트가 매번 같은 이유로 비활성화되나요, 아니면 이번 부팅에는 capabilities로 걸렸던 포트가 다음엔 플랩 감지기에 걸리나요? 포트별로 이유가 고정된 경우와 이유가 왔다갔다하는 경우는 서로 다른 조사이고, 그중 하나만 하드웨어를 사는 걸로 끝납니다.
두 번째로 확인할 건 코어가 스패닝 트리를 뭘로 돌리는지입니다. 여기는 MSTP인데, 반대편이 그 업링크에 Cisco 방식 PVST BPDU를 올리면 이 스위치는 정확히 그런 상황에 반응하는 보호 메커니즘이 있어서 포트를 내립니다. 밖에서 보면 지금 쫓고 계신 장애처럼 보이고요. 드롭 중에 본인 쪽 부팅이 아니라 코어의 토폴로지 변경과 맞물리는 게 있는지 확인할 수 있나요?
포트별로는 일관되는데 박스 전체로 보면 아닙니다. 쓰러지는 트렁크 멤버들은 항상 mismatched link capabilities로 돌아오고, 5번 액세스 포트는 항상 플랩 감지기만 걸리는데 패턴을 찾을 수 있는 주기가 없습니다. 그러니 같은 겉옷을 입은 서로 다른 두 장애처럼 보이네요.
반대편 스패닝 트리는 아직 답을 못 드립니다. 코어는 다른 팀 소관이라 그 업링크로 실제로 뭘 내보내는지 물어봤습니다. 지금까지 저희 로그에는 드롭이 그쪽 토폴로지 변경과 연결되는 게 없는데, 그걸 찾으려고 본 게 아니라 링크 이벤트를 보려고 본 거라서 배제됐다고는 못 하겠습니다.
벤더는 다른데 모양은 같네요. FortiGate 201F를 FortiSwitch 548D에 SFP+로 물리고 그 사이에 Fortinet 정품 DAC를 넣었는데, 10Gbps 링크가 도무지 유지가 안 됐습니다. 속도와 듀플렉스를 뭘로 바꾸든 떨어졌고, 양쪽을 FortiOS 7.4에서 7.2.5로 롤백해도 바뀌는 게 없었습니다.
결국 버틴 건 더 짧은 Fortinet DAC에 그 링크만 STP를 꺼둔 조합이었고, 그 뒤로 쭉 유지되고 있습니다. 옮겨둘 만한 건 그 다음에 나온 논리입니다. 수동 구리 구간이 길수록 도착할 때쯤엔 신호가 더 열화돼 있으니, 10G에서는 길거나 애매한 DAC라면 라벨이 뭐라고 찍혀 있든 일단 의심 목록에 올려야 합니다. 광모듈 셋에 DAC 하나가 낀 errdisable 트렁크라면, 저라면 그 낀 하나를 집중적으로 의심하겠습니다.
하드웨어를 건드리기 전에 할 일이 하나 있습니다. 플랩이 로그 타임스탬프상 정확히 어떤 주기로 일어나는지 적어두세요.
전혀 관계없는 스위치인 TL-SG3452X에서, 모듈이 꽂힌 SFP+ 포트가 전부 10-15분마다 내려갔다 올라왔고 플랩마다 로그에 STP 메시지가 남았습니다. 당연히 광모듈 불량이라는 결론이 나올 법했는데, 정품 TL-SM5220-1M DAC가 정확히 같은 리듬으로 플랩하기 전까지였습니다. 이 테스트 한 번으로 광모듈 쪽 가설이 무너지고 대신 펌웨어 리그레션을 가리키게 됐고, 거기서 유일하게 통한 답은 이전 빌드에 머무는 것이었습니다.
일정한 간격이면 뭔가 스케줄상 타임아웃되고 있다는 뜻입니다. 무작위 간격이면 물리적인 문제라는 뜻이고요. 저렴한 테스트고, 필요 없는 모듈을 사는 걸 막아줍니다. 이전 펌웨어 이미지를 남겨둬서 다운그레이드 옵션을 살려두는 것도 도움이 됩니다.