# 小包通大包断：一起「能聊微信、打不开网页」的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报文的处理方式，标准允许多种实现，具体行为以各厂家官方文档为准。 常见的叠加封装及其开销大致如下： | 封装方式 | 典型叠加开销 | 说明 | |---|---|---| | GTP-U over IPv4/UDP | 约36字节 | 外层IP头20 + UDP头8 + GTP-U头8 | | GTP-U（带序列号等字段） | 约40字节 | GTP-U头扩展至12字节 | | GRE隧道 | 24字节 | 外层IP头20 + GRE头4 | | VXLAN | 约50字节 | 外层以太头14 + IP头20 + UDP头8 + VXLAN头8 | | IPsec ESP隧道模式 | 约50~73字节 | 随加密算法、IV长度与填充而变 | | IPv6 over IPv4手工隧道 | 20字节 | 仅外层IPv4头 | 单独一层36字节也许还能靠规划吃掉，问题是现网往往层层叠加：回传段为了专线安全跑IPsec，数据中心互联跑VXLAN，核心网内部还有GRE——**1500字节的用户包套两层壳直接奔着1600去了**。这还没完：如果防火墙再把ICMP过滤掉，PMTUD失灵，黑洞就此形成。4G/5G互操作、企业专线APN再叠一层L2TP的场景，坑只会更多。 用一张图看清隧道叠加如何让标准包超限： ```mermaid 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」——两个看似不相干的配置凑在一起，构成了完整的黑洞。 完整的破案链条如下： ```mermaid 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台账与验收拨测项"] ``` 故障时间线： | 时间 | 动作 | 关键发现 | |---|---|---| | D日09:30 | 客服工单激增，启动排查 | 投诉集中在两地市，「网页打不开」 | | 09:50 | 核心网信令KPI核查 | 附着/承载/DNS全部正常 | | 10:20 | 用户侧大包拨测 | 1472字节DF包全丢，1200字节全通 | | 11:20 | 传输段二分定位 | 收敛至某汇聚传输段 | | 12:10 | 段两端抓包 | 大包有去无回，无ICMP 3/4回报 | | 13:30 | 核对割接记录 | 前夜新上线IPsec加密设备 | | 14:00 | 应急旁路该加密段 | 投诉迅速回落 | | D+1日 | 正式整改 | MTU与MSS调整、放行ICMP后恢复加密承载 | 这里插一句为什么应急动作是「旁路」而不是「线上调参数」：大包故障影响面以地市计，而加密设备的策略变更要走安全审批流程，等不起。**先恢复业务、再修复根因**，是铁律。 ## 五、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）](https://blog.cloudflare.com/path-mtu-discovery-in-practice/) — 本文主锚定来源。Cloudflare工程师复盘ECMP哈希导致ICMP 3/4送达错误服务器、引发隧道用户连接卡死的真实事故，含tcpdump/iptables命令、三种修复方案及开源pmtud工具。文中ECMP哈希细节、1280/1024参数均出自此文。 2. [RFC 1191 — Classless Route / Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc1191) — PMTUD的原始标准，定义了路由器在DF置位时必须回送ICMP type 3 code 4的行为。 3. [RFC 4821 — Packetization Layer Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc4821) — TCP层MTU探测与黑洞检测机制，Cloudflare引用其1024字节起始MSS建议。 4. [3GPP TS 29.281 — GTP-U协议规范](https://www.3gpp.org/dynareport/29281.htm) — GTP-U头部结构（8字节必选/12字节含序列号）与N3接口隧道封装的标准依据。 5. [Cloudflare pmtud 开源仓库](https://github.com/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 等场景全覆盖。