这是一个创建于 282 天前的主题，其中的信息可能已经有所发展或是发生改变。
概要
局域网内高速端口向低速端口发送数据，流控不当会有严重的帧溢出风险，引发上层丢包、乱序、重放等问题导致 TCP 重传；从而导致对重传敏感的无线信道性能急剧劣化。建议正确的全链路配置 802.3x 标准支持实现链路层流控，同时高速发送端使用对丢包不敏感的拥塞控制算法 BBR 。对于带无线接入的家庭环境，放弃 TrueNAS Core ，使用 TrueNAS SCALE 并配置 BBR 。
背景
NAS 使用 TrueNAS Core ，万兆 SFP+ 直连主路由（ RB5009 ），AP 使用 U6 Enterprise ，2.5GbE 接入主路由。AP 下连客户端协商速率隔墙可达 1.7Gbps ，SMB 从 NAS 中下载文件速率不足 30MB/s ，视无线环境可能更糟，上行可以正常跑到 110MB/s 以上，最高可达 150MB/s ，iperf3 双向测速情况和 SMB 表现基本一致，多线程可缓解，有线条件下一切正常。降级到全千兆接入，问题也极大缓解。
下载：
上传：
发现
问题最早发现的时候还不是这套无线设备，经过漫长的更换设备排查和观察定位，发现以下现象：
1 、主路由 SFP+ 口处发现海量 RX Overflow
2 、客户端上抓包发现大量的 Dup ACK 和由此导致的 Retransmission ，还能看到很多 Out-of-Order 此处未截出
3 、TrueNAS Core 默认拥塞控制算法为 NewReno ，更换为 Cubic 之后好了一点，但很有限
解决
基本可以确定是高速端口在向低速端口发送数据的时候，因为没有正确的流控导致交换设备出现严重的溢出；同时更上层的拥塞控制算法，因为对丢包过于敏感，未能将发送窗口协商至合理的链路带宽；加之无线信道对重传也敏感的多，多种因素综合导致了无线下行拥塞大爆炸，下行速率远劣于上行。问题找到了，于是动手解决：
1 、RouterOS 所有端口手动配置 Flow Control （是的，默认未启用）
2 、更换 NAS 系统为 TrueNAS SCALE 并配置 BBR
下行立刻恢复至 130MB/s：
解决了困扰很久的问题，希望对你有帮助
 |
1
cjpjxjx 282 天前
想起来之前也好像遇到过类似的问题，软路由接千兆交换机，千兆交换机下面接了一台百兆端口的无线路由器和其他设备，当这台无线路由器的下载速率达到 80Mbps 以上时，千兆交换机下面的其他设备访问软路由的延迟却增加到了几百 ms ，访问外网更是疯狂丢包，后来把百兆的无线路由器换成了千兆的，问题消失
|
 |
2
datocp 281 天前 via Android
还是华为的好，当年第一次用就发现华为的傻瓜交换有对网络风暴自闭端口功能。
当年真正遇到的是，6 间教室使用 netop school 会发送大量的多播包实际是广播包，大量的广播包冲击百兆路由端口导致网络不通。交换是 tplink 的傻瓜交换没得解决。路由用了 ddwrt 用 ebtables 过滤了广播/多播，网络立马正常。按照文档描述属于广告包冲击路由，导致 cpu 反应不过来。 |
 |
3
titanium98118 281 天前
所以是同一局域网的交换机都开启 Flow Control ，就能避免这个问题?
|
 |
4
ZRS OP @titanium98118 亲测是不能完全解决的，问题的核心在发送方做合理的拥塞控制。更换 BBR 后我尝试关闭了链路层流控，此时也不会再大量出现 RX Overflow 的现象。也有可能是我链路上某些设备未能正确配置，但排查起来成本太高，不打算细究了。
|
 |
7
cnbatch 281 天前
flow control 不但需要中间设备开启，终端设备也应该开启的
|
 |
8
kaname0117 281 天前 via Android
！！！这好像也是困扰了我的问题……
我的环境是：主路由器两个 10G 电口，一个接在笔记本 2.5G ，另一个通过光转电接上 ST5008F ，交换机下面挂着一台双 10G 光口 truenas scale 和一台 10G 光口的 AP 。现象是：笔记本往 truenas 传能稳定 280M ，反向只有 20-30M ；手机连 AP 内网测速下行 2.2Gbps 上行几十兆。 等下班回去看看 st5008f 里是不是有类似 overflow 的报错…… |
|
9
ZRS OP  1
@Livid 感谢
@cnbatch Rx Overflow 发生在交换设备的高速端口处，按理说只要交换机和端口上游（即 NAS 的网卡和系统）支持并启用（我使用的 ESXi 虚拟化方案和 CX4 网卡，应该都默认启用了），就可以暂停这条链路上的发送了。 启用后确实遏制了万兆口处 Rx Overflow 的进一步增长，但对速度的提升效果没预期那么好。有可能这个时候卡点变成了 AP 的无线链路本身，这里的 Flow Control 行为我就不太能控制了，Unifi App 里自己的 Flow Control 设置似乎是针对它家交换机的。 而且 802.3x 还有另外的副作用，就是会无差别暂停掉整个链路的发送，在多设备重负载场景下对链路稳定性有负面影响。这个特性行为简单，应该是用来减缓一些没有流控和完整性保证能力的简单协议的丢包的。像 TCP 这种传输层协议，最好还是传输层自己做流控的保证，选用合适的拥塞控制算法。 |
 |
10
firemeteor 280 天前 via Android
跟这个有关系么？
www.bufferbloat.net/projects/ |
Select Language