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 那一侧慢慢消化掉。缓冲区一满，交换机就丢包。rx-overflow 计数器涨的正是这个信号，也正因为如此，直连 100G 时才什么都不丢——那条路径上根本没有降速这个步骤需要缓冲。
光模块是清白的。不管这个笼位里插的是铜模块还是光模块，表现都会一样，因为丢包发生在 100G 降到 1G 这一步，而不是模块内部。
要做两件事。真正的修法在发送端：把发送节奏调匀，让包均匀分布，而不是成批写出去。一旦源端不再产生超过出向速率的突发，丢包就会消失。
在交换机这边，可以让缓冲区的处境宽松一些：
这能争取到一些余量，让突发能撑得更久，但并不能消除根本原因——如果发送端的突发足够猛、持续足够久，再大的缓冲也救不了。改完之后继续盯着交换机的 QoS 统计和 rx-overflow 计数器，看看是仍然顶到上限，还是只是偶尔碰一下。
值得记住的一般性结论是：一个链路干净、没有任何报错、模块也健康的端口，仍然可能因为端口之间的降速这一个原因，丢掉两位数比例的流量。
在怀疑模块之前，先看看端口计数器到底怎么说。在 100G 入向端口和插着 S+RJ10 的那个笼位上分别执行
重点看 rx-overflow 这一行，而不是常见的 rx/tx 错误计数器。一个真正坏掉的铜质 SFP+，表现出来的会是 FCS 错误或者链路反复抖动，而不是从一条本来健康的流量里干净利落地削掉 15%。
第二个问题：这条路径的平均速率是多少，你对峰值有没有大致的了解？在 CPU 只有 1% 的情况下每七个包丢一个，闻起来更像是出向端口的缓冲区不够用，而不像是光模块故障。
先说计数器：两个端口都没有报错，链路全程保持 up，模块也没有报告任何异常。唯一有变化的数字就是 rx-overflow。
关于速率，这条路径平均是 400-500 Mbps，纸面上远远没有跑满 1G 那一侧。峰值我没有测过，但流量本身就是突发性的——发送端写一批数据，然后安静一段时间。丢包发生的同时，CPU 依然是 1%。
不一样的故障，但同样的教训：相信计数器，而不是直觉。我遇到过一台跑 SwOS 2.18 的 CRS354-48G-4S+2Q+RM，两个 QSFP+ 端口上的 Rx FCS Errors 在持续增长，Rx MAC Errors 也在以更低的速率增长。两个端口都是 40G 全双工，MTU 1500，对端是装了 Mellanox ConnectX-3 Pro CX324A 网卡的 ESXi 主机。
有意思的一点是：网卡那一侧什么都没报。
干干净净。换成确认良好的线缆也没有任何变化，同一台设备的 10G SFP+ 端口全程没有任何报错。我最终也没得到一个真正的诊断结论——把交换机从 SwOS 换成 RouterOS 之后，这些计数器就消失了，我更愿意把这理解成把问题藏起来了，而不是解决了问题。
真正管用的方法是：清零计数器，按固定的时间间隔重新读取，看错误数是不是跟着流量走。在你的情况里它们会跟着突发走，在我的情况里它们没有跟着任何有意义的东西走，光是这个差异就能告诉你该往哪一侧继续挖。
在那个端口上继续试验的时候，有件事要留意：不要拿强制速率和双工模式当出路。MikroTik 铜模块（S-RJ01 和 S+RJ10 都一样）官方记录的行为是，它们只在开启自动协商时才能工作——把速率写死，链路根本起不来。实际情况和这个说法有点出入，因为有几位 RB5009 和 RB4011 的用户反映情况正好相反，他们的 S-RJ01 只有强制 1G 全双工才能稳定，所以这更像是「自己在手头硬件上都试一遍」的事，而不是一条铁律。不管怎样，这都是绕开了你真正的问题，你的问题出在缓冲区那一侧。
关于 S+RJ10 还有一点值得以后留意：它的功耗明显比普通光模块高，运行起来也比较烫，所以不建议在没有额外风道的无源散热设备里使用。如果这个模块在一个偏热的机箱里开始出问题，温度是我第一个会去查的地方。