FortiGate 101F에서 FortiOS 업그레이드 후 공유 RJ45/SFP 포트 17-20이 죽음
40명 규모 사무실에서 FortiGate 101F 두 대를 쓰고 있어요, 특이할 거 없는 구성이에요. port17은 코어 스위치로 가는 SFP 업링크고, port19는 서버실로 가는 RJ45 회선인데, 둘 다 공유 RJ45/SFP 블록(포트 17-20) 안에 있어요. 지난달 유지보수 시간에 이 두 대를 FortiOS 7.4.4로 올렸는데, 그 뒤로 그 블록이 죽었어요.
- FortiGate 101F, 두 번째 사이트의 FortiGate 100F도 똑같은 증상
- port17: 스택 액세스 스위치로 가는 1G SFP 모듈
- port19: 1G 스위치 포트로 가는 RJ45
- FortiOS 7.4.4, 7.2 빌드에서 업그레이드
포트 1-16은 멀쩡하고 공유 포트만 죽었어요. 눈에 띈 건 GUI의 속도 옵션이 업그레이드 전이랑 다르게 보인다는 거고, 지금 running config에는 이렇게 들어가 있어요:
config system interface
edit "port17"
set speed 1000full
next
end
여기서 아무도 이걸 친 사람이 없어요. 업그레이드 전에는 이 장비의 모든 포트가 auto였어요.
지금까지 해본 것:
- SFP를 다시 꽂아보고 정상 작동하는 걸로 바꿔봐도 그대로예요
- 반대쪽 끝을 다른 스위치 포트로 옮겨봤어요
- 방화벽을 콜드 리부팅해도 설정은 위와 같이 그대로 남아요
100F/101F의 공유 RJ45/SFP 블록은 업그레이드 중에 auto가 없어지는 게 원래 그런 건가요, 아니면 저희 설정이 어디선가 꼬인 건가요? 그리고 이걸 원래대로 되돌리는 올바른 방법은 뭔가요?
Comments 5
사무실 누군가가 설정을 꼬은 게 아니라 업그레이드가 그렇게 만든 거예요. 100F랑 101F에서는 업그레이드가 조용히 공유 RJ45/SFP 포트의 auto를 고정된 1000full로 바꿔버려요, 반대편이 그 속도를 받아들일 수 있는지는 묻지도 않고요. 반대편 상황에 따라 잘못된 속도로 링크가 뜨거나 아예 링크가 안 뜨는데, 그래서 전용 포트는 멀쩡한데 17-20만 딱 죽은 거예요. Fortinet도 이걸 known issue 989629로 등록해뒀고, 7.2.9 릴리스 노트에 적혀 있어요. 영향받는 트레인은 v7.2.8 이상, v7.4.2 이상, v7.6.0 이상이에요.
속도는 포트별로 손으로 되돌리세요:
v7.2.8이랑 v7.4.2부터 v7.4.4까지는 목록에 그냥 auto가 안 나오는데, GUI가 다르게 보인다고 하신 게 바로 이거예요. 그 버전들에서는 1000auto를 쓰세요. v7.2.9, v7.4.5, v7.6.0 이상에서는 원래 옵션이 돌아와서 이렇게 쓰시면 돼요:
port18부터 port20까지도 쓰고 있으면 똑같이 반복하세요. 그리고 다음 작업 시간을 위해: management 경로가 17-20 포트를 거치지 않는지 미리 확인하세요, 안 그러면 장비가 돌아왔을 때 액세스 포트가 1000full로 고정돼 있어서 콘솔로 고치러 직접 현장까지 가야 할 수도 있어요.
정확히 어느 빌드에서 올라오신 거예요? "7.2 빌드"라고 하면 범위가 너무 넓고, 이걸 고치려고 쳐야 하는 명령도 트레인마다 달라요. 그리고 알아두면 좋은 게, 반대편이 autonegotiation을 지원하는지 아니면 자기도 고정돼 있는지예요. autonegotiation만 하는 상대는 고정 속도로 묶인 포트 앞에서 그냥 아무것도 안 하고 있을 거예요.
뭘 바꾸기 전에 하나 정리하고 가야 하는 게, management 경로가 17-20 포트 중 하나를 거치나요? 그렇다면 다음 변경은 네트워크 말고 콘솔에서 하세요.
공유 포트가 이상하게 구는 문제로 여기 들어온 다른 분들을 위해 일반적인 얘기 하나 보태요: 대부분 장비에서는 정말로 둘 중 하나만 써야 해요. NETGEAR는 GS716T-200에서 이걸 dual personality라고 부르는데, SFP 케이지 두 개가 각각 마지막 구리 포트 하나랑 짝지어져 있어서, 그 짝 중 한쪽만 살아 있을 수 있어요. 그래서 모듈을 꽂으면 조용히 짝이 되는 RJ-45가 꺼져버려요. 그 모델은 어차피 모든 포트가 기가비트라서, 광 업링크는 대역폭이 아니라 케이블 경로를 사는 셈이고요.
FortiGate 블록도 똑같은 개념이니까, 지금 port17에서 실제로 보고 있는 게 어느 쪽인지 확인해보세요. 같은 포트의 케이지에 모듈을 꽂고 구리 쪽에도 패치코드를 꽂아두는 건 전형적인 자책골인데, CLI에서 보면 속도 문제처럼 보이거든요.
벤더는 다른데 고생한 결은 똑같네요. EX-UM-2X4SFP 업링크 모듈을 꽂은 EX4200이었는데, xe-0/1/0은 10G가 잘 됐는데 xe-0/1/1은 VLAN에 넣지도 못하고 트래픽도 하나도 안 지나갔어요. 두 포트 다 1G로는 됐고, show chassis hardware에서 SFP+도 완전히 잘 보였어요. 모듈을 바꿔보고, 예비 EX-UM-2X4SFP도 써보고, 공장 초기화까지 했는데, 그러고 나서야 누가 그 모듈이 실제로 뭔지 알려줬어요.
고장 난 건 하나도 없었어요. 그 모듈은 케이지 네 개 중 하드웨어 번호로 0번과 2번, 이 두 개에서만 SFP+를 받고, 나머지 한 쌍은 1G 광모듈까지만 되고 그 이상은 안 돼요. 그러니까 결국 10G로 쓸 수 있는 인터페이스는 xe-0/1/0이랑 xe-0/1/2뿐이고, 제가 계속 씨름하던 xe-0/1/1은 뭘 꽂아도 애초에 10G가 될 수 없는 포트였던 거예요. 광모듈을 케이지 하나 옆으로 옮기고 xe-0/1/2를 설정하니까 바로 됐어요. 모드가 섞인 케이지라면 뭘 반품하기 전에 그 블록이 뭘 지원하는지부터 읽어보세요.
combo 포트 배타성 얘기는 조심해야 하는 게, 이 케이스는 그걸로 설명이 안 돼요. 업그레이드 전에는 포트가 멀쩡했고 업그레이드 후에 공유 블록만 망가졌는데, 게다가 아무도 안 친 속도 줄이 설정에 들어가 있잖아요. 그건 케이지 우선순위가 아니라 설정을 다시 써버린 거예요.
그런데 반대 방향의 실수도 사람 잡아요. 예전에 D-Link DES-1210-52 스위치들을 OSNOVO NS-SW-8GX2G에 광으로 업링크해놓고 일주일을 붙잡고 있었던 적이 있어요: 광 포트에는 링크 표시가 뜨는데 LAN도 인터넷도 아예 안 됐고, 같은 스위치들을 구리로 체인 연결하면 멀쩡했고, 펌웨어 업데이트도 아무 소용 없었어요. 며칠 동안 combo 포트가 가장 유력한 용의자였죠. 그런데 진짜 원인은 반대쪽에 있었어요: 그 SFP 모듈들이 꽂힌 OSNOVO 포트 자체가 내부적으로 죽어서 타버린 거였고, 거기 꽂힌 광모듈들은 멀쩡했어요.
그러니까 로컬 설정이 맞다는 게 확인되면, 본인 장비에 대해 뭔가 결론 내리기 전에 정상 작동하는 모듈을 반대편의 정상 작동하는 포트에 꽂아서 확인해보세요.