网络设备（特指 TP-Link ）距离正确处理 IPv6 Fragmentation 还有多远

Published on: 2025年2月3日2025年2月4日Author: 陈泱宇 (Yangyu Chen)Comment: 0

Table of Contents

背景

过年在外婆家住了几天，因为这里没有装宽带于是带上了 5G CPE ，以及随便购买了 TP-Link 7DR3630 路由器（已准备退货换其他产品），由于我的大部分工作数据放在家里的服务器上，出于习惯一般喜欢连接 WireGuard VPN 回家。而连接公共 WiFi 时我一般习惯加上默认路由到 VPN ，结果今天回到外婆家里连着 5G CPE 的网忘删除默认路由发现上网非常卡顿，表现为网页打开缓慢，视频网站移动进度条缓慢，而 iperf 测下行带宽却没有发现任何问题，经过一些随机探索，最后发现问题出在了 MTU 上。而经过调查发现，最终的问题在于经过的 TP-Link 路由器的 IPv6 桥接模式会把 IPv6 Fragmentation 拼接。

环境介绍

CPE: VN007 (软件版本为最新 3.12.0 )
路由器：TP-Link 7DR3630 （软件版本1.0.13，路由模式，IPv6设置为桥模式）
SIM：AS4134 5G 融合 QCI-6 1000Mbps
CPE连线方式：Ethernet
地理位置：福建省南平市
WireGuard Peer：AS9808 福建省厦门市 PPPoE 家庭宽带 IPv6
WireGuard MTU: 1408
TCP congestion control: BBR
5G MTU: 1500

拓扑图：

Mac+RTL8156<->TP-Link 7DR3630<->VN007

一个简单的测试结果

经过对 WireGuard MTU 进行 binary search，最终找到了最大值：1352

TL; DR.
Upload from 5G to Home:
WireGuard MTU 1352 (5G MTU 1432): 38.8 Mbits/sec
WireGuard MTU 1360 (5G MTU 1440): 3.45 Mbits/sec

 cyy@Yangyus-MacBook-Pro  ~  sudo ip link set utun13 mtu 1360
Executing: /usr/bin/sudo /sbin/ifconfig utun13 mtu 1360

 cyy@Yangyus-MacBook-Pro  ~  iperf3 -c 10.12.2.248 -t 3
Connecting to host 10.12.2.248, port 5201
[  5] local 10.12.3.66 port 50772 connected to 10.12.2.248 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   128 KBytes  1.05 Mbits/sec
[  5]   1.00-2.00   sec   512 KBytes  4.19 Mbits/sec
[  5]   2.00-3.00   sec   768 KBytes  6.28 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-3.00   sec  1.38 MBytes  3.84 Mbits/sec                  sender
[  5]   0.00-3.04   sec  1.25 MBytes  3.45 Mbits/sec                  receiver

iperf Done.
 cyy@Yangyus-MacBook-Pro  ~  sudo ip link set utun13 mtu 1352
Executing: /usr/bin/sudo /sbin/ifconfig utun13 mtu 1352

 cyy@Yangyus-MacBook-Pro  ~  iperf3 -c 10.12.2.248 -t 3
Connecting to host 10.12.2.248, port 5201
[  5] local 10.12.3.66 port 50790 connected to 10.12.2.248 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec  7.12 MBytes  59.5 Mbits/sec
[  5]   1.01-2.00   sec  4.25 MBytes  35.8 Mbits/sec
[  5]   2.00-3.00   sec  4.00 MBytes  33.6 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-3.00   sec  15.4 MBytes  43.0 Mbits/sec                  sender
[  5]   0.00-3.22   sec  14.9 MBytes  38.8 Mbits/sec                  receiver

iperf Done.
 cyy@Yangyus-MacBook-Pro  ~ 

继续探索

打开 WireShark 抓包分析 WireGuard MTU 1360 时的通信，结果更是震撼了我。

可以看到，我的电脑已经从先前的经验学习到，去往该地址可用的最大 MTU 为 1432 ，于是 WireGuard 已经将 UDP 进行了 Fragment ，去除 14 Bytes Ethernet Frame 后仅发出了 1432 大小的包。

然而，处于同一 /64 下的我的 5G CPE 却依然不断地在向我的电脑发送 ICMPv6 Packet too Big 。许多数据包最终也正确送达了我家里的 WireGuard Server ，但可能由于软件分片的处理流程复杂导致网络缓慢。

至此，我已经认为是 5G CPE 对 IPv6 Fragmentation 处理存在问题了，似乎有一种神秘的力量在链路上把这些 Fragmented Packet 又组合了一遍，然后 CPE 向我电脑发出了 Packet too big 的警告。

实在是离谱！

iPhone 热点对比

于是我又使用 iPhone 热点进行了测试，这多么正常啊：

由于我的电脑和 WireGuard Peer 处理 Fragment 速度足够快， 5G 的带宽相对较低，实测起来相比手动降 MTU 也没有明显速度差异。

离奇的发现

在 twd2 的指点下，我继续进行了一些测试，最后发现，这一现象仅出现在我连着 TP-Link 路由器的时候，而使用 Wi-Fi 直连 CPE 时并不存在，如图所示：

于是我又将电脑 Wi-Fi 关闭，用网线跳过 TP-Link 路由器，直连 CPE 的有线网口，发包一切正常，和我直连 CPE Wi-Fi 的情况相同。至此，我们可以确定，TP-Link 7DR3630 的 IPv6 桥接模式会自动进行分片重组，损坏了 narrow MTU 的上游的 UDP 发送功能。

解决方法

最终将我的所有 Client 性质的 WireGuard VPN 都改为了 MTU 1280，来应对这些倒闭网络设备的错误情况。

结论

TP-Link 7DR3630 路由器居然会错误地将 IPv6 桥接模式下的分片重组，导致无法正确处理 IPv6 Fragmentation 导致了我连回家的 WireGuard VPN 出现了巨大的性能损失。而该问题在使用 iPhone 开热点以及直接使用 VN007 5G CPE 时并不存在。

反思

如今，骨干网 MTU 一般在 1500 以上， MTU 的下降通常只出现在最后一公里的接入中，因此大部分情况我们依赖 TCP MSS Clamp 解决了大多数情况下的 MTU 协商问题。而由于在过去的 IPv4 + NAT 的时代，许多 NAT 路由器对于 UDP Fragmentation 的处理采用了直接 Drop 的方式（想想为什么？因为通常只有一个 Fragmentation 能看到端口，网络设备必须先组包再查 NAT 表，对于硬件 Flow Table 等实现而言，做起来实在困难），导致了大部分 UDP 应用都 assume 了网络不会为自己过大的 Packet 负责。导致在 NAT 时代习惯了之后， IPv6 时代这样的问题导致现实应用出现性能问题的概率也相当低，如果设备厂商没有足够的验证 coverage 很容易忽视这样的问题。但这样的问题或许也需要得到更多的重视，并研究更多的自动化方法来及时发现和解决。

背景