CRS518-16XS-2XQ의 S+RJ10 구리 SFP+ 구간에서 패킷 15% 정도 유실, 직결 100G 경로는 깨끗함
랩 서버에서 CRS518-16XS-2XQ로 100G QSFP28 업링크를 통해 트래픽을 밀어넣고 있고, 스위치를 나갈 때는 MikroTik S+RJ10 구리 SFP+를 거쳐 일반 1G RJ45 호스트로 들어갑니다. 수신 쪽에서 패킷 상당수가 빠지는데 뭐가 문제인지 딱히 짚이는 게 없습니다.
구성:
- MikroTik CRS518-16XS-2XQ, 트래픽 소스에서 100G QSFP28 업링크
- 케이지 하나에 MikroTik S+RJ10 구리 SFP+, 반대편은 1G RJ45 장치
- 수신 호스트에서 캡처 실행 중
캡처 결과:
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%해본 것:
- 같은 소스를 100G로 직결, 유실 전혀 없음, 그러니까 송신 측 자체는 멀쩡함
- 스위치 CPU 부하를 낮춤, 지금은 1%인데도 유실은 여전함
- S+RJ10 재장착, 1G 장치 쪽 패치코드 교체
지금은 구리 모듈을 제일 의심하고 있는데, 링크는 깨끗하고 인터페이스에 에러도 전혀 없습니다. S+RJ10이 원래 이렇게 트래픽을 까먹는 걸로 알려져 있나요, 아니면 스위치 안 다른 데를 봐야 할까요?
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
버스티한 송신원에서 평균 400-500 Mbps라는 게 이야기의 전부입니다. 트래픽이 고르게 퍼져 있지 않은 거예요. 짧은 버스트가 소스에서 1 Gbps보다 빠르게 나가고, 그 선을 넘는 모든 건 1G 쪽이 비워줄 때까지 포트의 egress 버퍼에 앉아 있어야 합니다. 버퍼가 차면 스위치가 드롭합니다. rx-overflow가 움직이는 게 정확히 그걸 말해주는 거고, 직결 100G 연결에서는 아무것도 안 보이는 이유도 그겁니다. 거기엔 버퍼링을 걸어야 할 속도 단차가 없으니까요.
트랜시버는 무죄입니다. 그 케이지에 구리든 광이든 뭐가 들어있든 똑같이 동작했을 겁니다. 드롭은 100G에서 1G로 내려가는 단차에서 일어나는 거지 모듈 안에서 일어나는 게 아니니까요.
할 일은 두 가지입니다. 진짜 해결책은 송신 쪽에 있습니다. 패킷을 버스트로 몰아서 쓰지 말고 고르게 퍼지도록 페이싱하세요. 소스가 egress rate를 넘는 버스트를 더 이상 안 만들면 유실이 사라집니다.
스위치에서는 버퍼 상황을 덜 나쁘게 만들 수 있습니다.
이건 여유를 벌어서 버스트를 좀 더 오래 버티게 해주지만 원인 자체를 없애지는 못합니다. 송신원이 충분히 세게, 충분히 오래 버스트하면 어떤 버퍼 크기로도 못 막습니다. 바꾼 뒤에도 스위치 QoS 통계랑 rx-overflow 카운터를 계속 지켜보면서, 여전히 천장에 부딪히는 중인지 아니면 가끔씩만 닿는 정도인지 확인하세요.
새겨둘 만한 일반적인 교훈이 있습니다. 링크 깨끗하고, 에러 없고, 모듈도 멀쩡한 포트라도 포트 사이의 속도 단차 하나만으로 두 자릿수 비율의 트래픽을 드롭할 수 있다는 것.
모듈을 탓하기 전에 포트 카운터가 실제로 뭐라고 하는지부터 보세요. 실행하세요.
100G ingress 포트랑 S+RJ10이 꽂힌 케이지에서 돌려보고, 평소 보는 rx/tx 에러 카운터 말고 특히 rx-overflow 줄을 보세요. 진짜로 고장난 구리 SFP+는 FCS 에러나 흔들리는 링크로 자기 존재를 알리지, 멀쩡한 스트림에서 깔끔하게 15%만 잘려나가는 식으로 나타나지 않습니다.
두 번째 질문. 그 경로의 평균 레이트가 얼만가요, 피크는 대략 짐작 가는 게 있나요? CPU 1%에서 일곱 개 중 하나가 유실되는 건 트랜시버 고장보다는 egress 포트가 버퍼를 다 쓰는 쪽에 훨씬 가까운 냄새가 납니다.
카운터부터. 양쪽 포트 다 에러 없고, 링크는 계속 up이고, 모듈도 이상 없다고 합니다. 숫자가 조금이라도 움직이는 곳은 rx-overflow뿐입니다.
레이트는 그 경로 평균이 400-500 Mbps라서 서류상으로는 1G 쪽을 포화시키는 것과는 거리가 멉니다. 피크 측정은 못 했는데, 트래픽 자체가 원래 버스티합니다. 송신 쪽이 한 덩어리를 쓰고 한동안 조용해지는 식이거든요. 패킷이 빠지는 동안에도 CPU는 여전히 1%입니다.
다른 종류의 고장이지만 직관보다 카운터를 믿으라는 교훈은 똑같습니다. SwOS 2.18 돌리는 CRS354-48G-4S+2Q+RM이 있었는데 두 QSFP+ 포트에서 Rx FCS Errors가 꾸준히 늘어나고 있었고 Rx MAC Errors도 더 낮은 비율로 늘고 있었습니다. 두 포트 다 MTU 1500에 40G full duplex였고, 반대편에는 Mellanox ConnectX-3 Pro CX324A 카드가 꽂힌 ESXi 호스트가 있었습니다.
흥미로운 부분은 NIC 쪽은 아무것도 보고하지 않았다는 겁니다.
깨끗했습니다. 멀쩡하다고 알려진 케이블로 바꿔도 아무것도 안 바뀌었고, 같은 박스의 10G SFP+ 포트들은 내내 에러 없이 유지됐습니다. 진짜 진단은 결국 못 받았고, 스위치를 SwOS에서 RouterOS로 옮기니 카운터가 사라졌는데, 이건 문제를 해결한 게 아니라 숨긴 걸로 칩니다.
살아남은 방법은 이겁니다. 카운터를 초기화하고, 일정 간격으로 다시 읽어서 에러가 트래픽 양을 따라가는지 보는 것. 님 경우엔 버스트를 따라갈 거고, 제 경우엔 쓸모있게 따라가는 게 아무것도 없었는데, 그 차이 하나만으로도 어느 쪽을 계속 파야 할지 알려줍니다.
그 포트로 실험하는 동안 하나 기억해두세요. 속도랑 duplex 강제를 탈출구로 쓰지 마세요. MikroTik 구리 모듈들, S-RJ01이든 S+RJ10이든 문서화된 동작은 auto-negotiation을 켜둬야만 동작한다는 겁니다. 레이트를 고정으로 박으면 링크가 아예 안 올라옵니다. 실제로는 이게 부분적으로 반대인 경우도 있어서, RB5009랑 RB4011 사용자 몇몇은 반대로 보고했고 1G full duplex를 강제해야만 S-RJ01이 안정적이었다고 하니, 규칙이라기보다는 "본인 하드웨어에서 둘 다 시도해보라"는 쪽에 가깝습니다. 어느 쪽이든 이건 진짜 문제인 버퍼 쪽에서 벗어난 우회로입니다.
나중을 위해 알아두면 좋을 S+RJ10의 다른 특징. 일반 옵틱보다 눈에 띄게 전력을 더 먹고 뜨거워지기 때문에, 추가 통풍 없는 패시브 냉각 장치에는 권장되지 않습니다. 그 모듈이 따뜻한 섀시에서 언젠가 이상하게 굴기 시작하면, 제일 먼저 확인할 게 온도입니다.