小包通大包断：一起「能聊微信、打不开网页」的MTU排查实战

概述：本文回答一个核心网与传输运维工程师都绕不开的问题——为什么用户信令全通、ping也通，业务却大面积打不开？文章以一起典型的「小包通、大包断」故障复盘为主线，讲清MTU、IP分片、路径MTU发现（PMTUD）与ICMP黑洞之间的连环关系，解释移动网络为何因GTP-U隧道叠加成为MTU问题重灾区，并引用Cloudflare 2015年ECMP导致的真实PMTUD事故，最后给出可直接落地的排查命令清单与全网整改方案。

目录

• 一、幽灵故障：投诉激增，但KPI一片绿
• 二、三分钟原理：MTU、DF位与PMTUD
• 三、移动网络为什么是MTU重灾区
• 四、破案过程：时间线与工具链
• 五、Cloudflare的教训：ECMP把ICMP送错了门
• 六、整改清单：把MTU问题关进笼子
• 七、经验教训
• 参考来源

一、幽灵故障：投诉激增，但KPI一片绿

干核心网运维这么多年，最怕的不是全网瘫了，而是「KPI一片绿、投诉满天飞」的幽灵故障。全网瘫了反而好办——重大故障流程一启动，各部门全上，问题跑不掉。真正磨人的是那种用户面悄悄劣化、信令面干干净净的故障，它躲在所有网管告警的盲区里。

下面这起案例由我亲历的多起同类故障合并改写，网络与时间信息已脱敏。那天上午九点半，某省客服工单量突然冲到日常三倍，投诉高度集中在两个地市，现象出奇一致：微信能收发，网页打不开，视频App转圈。语音用户基本无感。

第一反应是按套路走：查核心网KPI。附着成功率正常，承载建立成功率正常，DNS服务器负载正常，N3口无告警——信令面干净得像刚割接完。这就怪了：如果DNS坏了，微信域名解析不出来，消息也发不出去；如果附着有问题，微信根本登录不上。用户能登录、能收发消息，说明小包业务是通的；打不开网页，问题极可能出在大包上。

干过传输的老同事有句口头禅：「ping得通不代表业务通，ping得小不代表ping得大。」 这句土话背后，就是本文的主角——MTU。

二、三分钟原理：MTU、DF位与PMTUD

MTU（Maximum Transmission Unit，最大传输单元）是一条链路上一单次能承载的最大报文字节数。以太网口最常见的是1500字节。发端主机把数据切块时按自己出口的MTU来切，但它并不知道中间路径上哪一段的MTU更小。

遇到「我这跳MTU比你这个包小」的情况，IP协议历史上提供了两条路：

1. IP分片：路由器把大包剁成两半分别转发，到接收端再拼回来。听起来美好，实践中却人人避之不及——分片消耗转发资源、任何一片丢失整包报废、中间盒（防火墙、DPI）对分片重组的支持参差不齐。Cloudflare的文章里明确写了这句：「IP分片有严重缺点，实践中是被回避的」。
2. 禁止分片（DF位）+ 路径MTU发现：TCP默认在报文上打上DF（Don't Fragment）标记，谁也不许剁。此时收到大包的路由器按RFC 1191的要求，必须向源地址回送一条ICMP报文——类型3、代码4，含义是「分片需要但DF已置位」，并在这条ICMP里告诉对方：我这段路径的MTU是多少，请把包改小。发送端收到后自动降低发送尺寸，连接继续。这套自动协商机制就叫路径MTU发现（Path MTU Discovery，PMTUD）。

PMTUD成立有一个隐含前提：那条ICMP type 3 code 4 必须能活着回来。而现实里，大量网络管理员出于安全习惯在防火墙上过滤ICMP——他们只记得ping可以被用来探测网络，却忘了ICMP家族里还有一种报文是TCP正常工作的「信使」。ICMP被丢、大包又被DF位拦下、发送端又收不到「改小一点」的提示，连接就卡死在这里：发送端反复重传大包，接收端只能确认收到的小包。这个状态有个形象的学名——ICMP黑洞（black hole）。

与MTU配套的还有TCP里的MSS（Maximum Segment Size）：TCP载荷的单段上限，在三次握手的SYN里协商，数值上约等于「MTU减去IP头20字节和TCP头20字节」，1500的MTU对应1460的MSS。MSS是「载荷尺寸」，MTU是「整包尺寸」，运维里最常用的止血手段之一就是把MSS钳制（clamping）调小——各厂家设备普遍支持该通用功能，具体配置命令以各厂家官方文档为准。

三、移动网络为什么是MTU重灾区

公网上MTU问题已属常见，移动网络更是重灾区，根源就一个字：套。用户报文从终端到核心网，要在NSI（隧道）里反复套壳，每一层壳都吃掉宝贵的字节数。

以最核心的N3接口（5G中gNB到UPF的用户面隧道）为例，承载协议是GTP-U over UDP/IP，由3GPP TS 29.281定义。GTP-U头部必选部分8字节（含TEID），携带序列号等可选字段时为12字节。套上外层IPv4头（20字节）和UDP头（8字节），用户每发一个报文，线上就要多扛约36~40字节的开销。终端按1500字节发出的包，出隧道时就成了1536+，恰好超过中间链路1500的MTU——一丢一个准。各设备对超长GTP-U报文的处理方式，标准允许多种实现，具体行为以各厂家官方文档为准。

常见的叠加封装及其开销大致如下：

单独一层36字节也许还能靠规划吃掉，问题是现网往往层层叠加：回传段为了专线安全跑IPsec，数据中心互联跑VXLAN，核心网内部还有GRE——1500字节的用户包套两层壳直接奔着1600去了。这还没完：如果防火墙再把ICMP过滤掉，PMTUD失灵，黑洞就此形成。4G/5G互操作、企业专线APN再叠一层L2TP的场景，坑只会更多。

用一张图看清隧道叠加如何让标准包超限：

flowchart TD
    A["UE发出1480字节"] --> B["gNB封装GTP-U"]
    B --> C["叠加外层IP与UDP头"]
    C --> D["出口报文约1516字节"]
    D --> E["中间传输链路MTU 1500"]
    E --> F["超限被丢弃"]
    F --> G["ICMP提示若被防火墙吞掉"]
    G --> H["发送端蒙在鼓里 反复重传"]

四、破案过程：时间线与工具链

回到那起故障。定性「小包通、大包断」之后，排查就变成了三件事：验证假设、缩小范围、找到变更。

第一步，验证假设。 在受影响地市找一台接入用户侧环境，用禁止分片的大包拨测：

ping -s 1472 -M do 目标地址
ping -s 1200 -M do 目标地址

-M do 就是给包打上DF位。1472 = 1500 − 20（IP头）− 8（ICMP头），是1500 MTU下的极限载荷。结果：1200字节全通，1472字节全丢——假设成立，路径上存在小于1500的瓶颈且PMTUD没有生效。

第二步，二分法缩圈。 从用户侧到服务器侧逐段telnet/netconf登录传输设备，分别在两端做同样的大包拨测，中间任何一段「进得去出不来」的就是嫌疑段。一小时后范围收敛到某汇聚传输段。

第三步，抓包定性。 在嫌疑段两端同时镜像抓包，重点看两样东西：TCP大包是否反复重传、ICMP type 3 code 4 是否出现。抓ICMP提示用Cloudflare文章里同款姿势：

tcpdump -s0 -p -ni eth0 'icmp and icmp[0] == 3 and icmp[1] == 4'

结果：上行方向大包有去无回，沿途没有一条ICMP 3/4回报——典型的黑洞形态。

第四步，查变更。 翻前夜割接记录：该段新上线了一台IPsec加密设备用于专线安全改造。加密设备以内层1480 MTU转发、外层封装后超过物理口1500，而安全策略模板默认「拒绝所有ICMP」——两个看似不相干的配置凑在一起，构成了完整的黑洞。

完整的破案链条如下：

flowchart TD
    A["投诉激增 能聊微信打不开网页"] --> B["核心网KPI核查 正常"]
    B --> C["DNS正常 ping小包正常"]
    C --> D["定性为疑似大包丢失"]
    D --> E["ping 1472 禁止分片拨测"]
    E --> F{"大包是否可通"}
    F -->|通| G["排除MTU 另查服务器侧"]
    F -->|不通| H["传输段二分法缩圈"]
    H --> I["嫌疑段两端同步抓包"]
    I --> J{"是否见到ICMP 3/4"}
    J -->|见到| K["查接收端PMTUD处理"]
    J -->|未见到| L["判定ICMP黑洞"]
    L --> M["核查沿途防火墙ICMP策略"]
    M --> N["锁定前夜上线的加密设备"]
    N --> O["调整MTU 钳制MSS 放行ICMP"]
    O --> P["补全全网MTU台账与验收拨测项"]

故障时间线：

这里插一句为什么应急动作是「旁路」而不是「线上调参数」：大包故障影响面以地市计，而加密设备的策略变更要走安全审批流程，等不起。先恢复业务、再修复根因，是铁律。

五、Cloudflare的教训：ECMP把ICMP送错了门

自建网络里「防火墙手贱丢ICMP」是最常见的黑洞成因，但Cloudflare在2015年2月4日发布的复盘文章《Path MTU discovery in practice》里，讲了一个更刁钻的成因，对如今大规模部署ECMP的核心网/数通团队极具参考价值。

事情是这样的：Cloudflare内部用iBGP在服务器间做高可用，后来为了扩容把内部BGP的metric调成相等，启用了ECMP（等价多路径）负载均衡。ECMP路由器为保证一条TCP连接的包始终命中同一台服务器，对每个包算哈希——对TCP，哈希的是四元组（源IP、源端口、目的IP、目的端口），同一条流的包必然落到同一台服务器。但对ICMP，路由器只能拿到（源IP、目的IP）来算哈希——ICMP type 3 code 4的源地址是沿途某台路由器，哈希结果很可能把它送到另一台根本没有这条TCP连接的服务器上。结果就是：PMTUD的「改小一点」提示在网络里迷路了，走隧道的用户（隧道MTU必然小于1500）连接卡死。

Cloudflare的应对分三层，每一层都值得抄进运维手册：

1. 临时止血：把IPv6出向路径的MTU统一降到1280——这是IPv6协议规定的最小MTU，降到这个值意味着永远不需要PMTUD也能通。文中提到「很多其他厂商也用这一招」。IPv4侧则启用RFC 4821的MTU探测。
2. 内核兜底：开启Linux的 tcp_mtu_probing（写1启用），并按RFC 4821建议把 tcp_base_mss 从512提到1024。这组参数让TCP在怀疑遭遇黑洞时主动降速试探，不再死等那条永远到不了的ICMP。
3. 根治方案：开源了自家的小工具pmtud守护进程，思路朴素而有效——既然ECMP可能把ICMP送错门，那就让ICMP MTU消息广播给数据中心里的所有服务器，保证命中处理那条流的那一台。

对通信运维的启示很直接：随着核心网云化，SBA服务化接口之间、虚拟机与容器节点之间的流量同样跑在ECMP和overlay网络上，「ICMP送错门」的问题在任何大规模数据中心都可能复现。Cloudflare这篇2015年的老文章，至今仍是数据中心网络团队的新员工必读。

六、整改清单：把MTU问题关进笼子

故障恢复只是及格线。这类故障的真正风险在于它会换个马甲反复回来：下次可能不是加密设备，而是一段新租用的专线、一次VXLAN改造、一个新叠加的切片承载网。我们事后把整改固化成了六条：

1. 全网MTU台账。从RAN、传输、防火墙到核心网，逐段登记接口MTU与封装方式，计算出每条业务路径的「有效净荷MTU」，任何一段变更必须触发台账复核。没有台账，就没有MTU治理。
2. 隧道段MSS钳制常态化。凡叠加封装的边界设备（加密网关、隧道端点、防火墙），统一配置TCP MSS钳制，把协商值压到「路径最小MTU − 40」以下。宁可牺牲几个百分点的承载效率，换全路径通吃。
3. 防火墙放行ICMP type 3 code 4。与安全团队联合发布基线：ICMP过滤策略必须对「destination unreachable / fragmentation needed」开白名单。这条建议直接写进了我们的防火墙基线模板。
4. 开局验收增加大包拨测项。新开专线、新割接传输段，验收测试必须包含 ping -s 1472 -M do 全路径测试和一次真实HTTPS大页面访问，不能只ping通小包就签字。
5. 服务器侧内核兜底。云化核心网的宿主机统一开启 tcp_mtu_probing=1、tcp_base_mss=1024，纳入镜像基线。这是给「下次PMTUD再失灵」上的保险。
6. 变更联动纪律。传输和安全设备的任何MTU/策略变更，纳入割接评审必查项——本次故障的直接导火索，就是一次没有通知核心网团队的加密改造。

把这一套跑顺之后，我们的信令异常工单里「疑似无线问题」的比例肉眼可见地降了下去——因为很多被推给无线的「怪故障」，最后都在传输段的大包拨测里现了形。

七、经验教训

复盘多了，我对这类故障有三点沉淀：

第一，「小包通、大包断」是一类病，不是一个案。 症状群高度一致：即时消息正常、DNS正常、TLS握手卡死（服务器证书链动辄两三千字节，正是最容易触发丢包的大包）、网页超时。下次再看到这个症状组合，先做大包拨测，再谈别的。

第二，ping通不是验收标准。 1500字节以下的全通，可能掩盖着1472以上的全军覆没。运维工具链里应该让大包禁分片拨测成为和「ping网关」同级别的习惯动作，写进开局模板和应急预案。

第三，MTU问题的本质是「信息在不同团队之间断了」。 隧道叠加是设计使然，谁也没做错；ICMP被过滤是安全惯性，动机也没错。错的是加密改造不知道传输的MTU规划，防火墙基线不知道PMTUD依赖ICMP。跨团队的变更联动与一份活的MTU台账，比任何一台昂贵的探针都更能预防这类故障。 移动网络的隧道只会越套越多——切片、回传加密、多云互联都在路上——把「路径有效净荷」当作和带宽一样的头等资源去管理，是云化时代核心网运维的基本功。

参考来源

1. Path MTU discovery in practice — Cloudflare Blog（2015-02-04） — 本文主锚定来源。Cloudflare工程师复盘ECMP哈希导致ICMP 3/4送达错误服务器、引发隧道用户连接卡死的真实事故，含tcpdump/iptables命令、三种修复方案及开源pmtud工具。文中ECMP哈希细节、1280/1024参数均出自此文。
2. RFC 1191 — Classless Route / Path MTU Discovery — PMTUD的原始标准，定义了路由器在DF置位时必须回送ICMP type 3 code 4的行为。
3. RFC 4821 — Packetization Layer Path MTU Discovery — TCP层MTU探测与黑洞检测机制，Cloudflare引用其1024字节起始MSS建议。
4. 3GPP TS 29.281 — GTP-U协议规范 — GTP-U头部结构（8字节必选/12字节含序列号）与N3接口隧道封装的标准依据。
5. Cloudflare pmtud 开源仓库 — Cloudflare在上述复盘中开源的Path MTU守护进程，用于在ECMP环境下广播ICMP MTU消息。

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。