开篇聊几句：做网络这行，ICMP 可能是你最早接触、却最容易低估的一个协议。说接触早，是因为刚学会用电脑时，就有人告诉你"ping 一下试试"，第一次看到 "Reply from 192.168.1.1: bytes=32 time=1ms TTL=64" 时的感觉，比后来配通第一条路由还兴奋。说容易低估，是因为大多数人对它的理解就停留在"能不能 ping 通"这一个点上，至于 ICMP 为什么叫控制信息协议、为什么在网络层、它内部有哪些报文类型、traceroute 又是怎么借它工作的，很少有人真正去拆开看。
我这些年排查网络故障，ICMP 的使用频率比任何路由协议都高。无论是确认链路通断、定位 MTU 问题、还是判断中间设备转发行为，ICMP 都是第一梯队的工具。这篇文章不打算把协议栈理论从头复述一遍，而是站在"我要用它干活"的角度，把 ICMP 的核心机制、报文结构、实操命令和排障技巧串起来。适合刚入门、想系统梳理协议知识的网络学习者，也适合工作几年、想补全自己知识遗漏的工程师。
1. ICMP 协议到底是什么：先把它在协议栈里摆清楚
1.1 为什么网络层还需要一个"控制信息"协议
IP 协议本身的设计哲学非常纯粹：它只负责尽力而为地转发数据报，报文丢了不重传，路径错了不纠正，网络拥塞了也不通知发送方。这种极简设计让 IP 可以跑在各种异构网络上，但代价就是——出了事没人管。
打个不太严谨的比方：IP 就像一个没有自动反馈的快递系统。你把包裹交给快递员，快递员按地址送，如果地址写错了、收件人搬家了、包裹在路上被烧了，快递公司不会主动回来告诉你，你只能自己反复发件去试。而 ICMP 要解决的，恰恰就是"把网络中的异常情况反馈给发送方"这件事。
ICMP 的全称是 Internet Control Message Protocol，即互联网控制消息协议。它的定位非常特殊：虽然它直接跑在网络层、封装在 IP 数据报内部，但它不负责传输用户数据，而是负责传递"控制信息"和"差错报告"。比如目标不可达、TTL超时、重定向、参数错误、时间戳请求、回显请求等，这些都是 ICMP 的管辖范围。
这里有一个关键点需要理解：ICMP 消息虽然寄生在 IP 报文里，但它并不是 IP 报文的"有效载荷"——它更像是 IP 的副驾驶。IP 负责驾驶，ICMP 负责报告路况和故障。这也是为什么很多抓包软件里，ICMP 报文显示在 IP 协议的上层，但你在浏览器里发的应用流量永远不会直接使用 ICMP。
1.2 报文封装与头部结构：每个字段都在说什么
ICMP 报文在线上传输时，外层有一个 IP 头，IP 头的 Protocol 字段值为 1，表示内层承载的是 ICMP 报文。ICMP 本身有 4 个字节的固定头部，后面跟着可变长的内容，具体格式取决于报文类型。
固定头部四个字节非常关键，干网络的人至少要能说出每个字段的含义：
- Type（类型，1 字节）：标识报文是请求还是应答，是差错报告还是信息查询。比如 Type=8 是 Echo Request，Type=0 是 Echo Reply，Type=3 是 Destination Unreachable。
- Code（代码，1 字节）：对 Type 做更细的分类。比如同样是 Type=3，Code=1 表示主机不可达，Code=3 表示端口不可达，Code=4 表示需要分片但 DF 位已置位。
- Checksum（校验和，2 字节）：覆盖整个 ICMP 报文（包括头部和数据区），用于检测报文在传输过程中是否被破坏。校验和计算的细节这里不展开，但一定要知道，抓包时如果看到 ICMP checksum 错误，很可能是有设备在干扰或者网卡收包异常。
固定头部后面是可变区，不同报文类型差异很大。比如 Echo 请求报文的可变区里有 Identifier 和 Sequence Number，用来让发送方对请求和应答做匹配；差错报文的可变区则会携带触发错误的 IP 报文头部及前 8 字节数据。
这里有个设计细节很耐人寻味：差错报告报文为什么只携带原始 IP 头和前 8 字节？因为这 8 个字节已经足以覆盖绝大多数传输层头部信息（源端口、目的端口等），接收方可以通过这些信息识别是哪个会话出了问题，同时又不会让差错报文本身过大，避免网络因反馈而进一步拥塞。这个"40 字节原则"——IP 头（通常是 20 字节）加 8 字节数据——是 ICMP 设计者当年考虑了报文膨胀风险后的折中方案。
2. 核心机制逐层拆解：ICMP 到底做了哪些事
2.1 Echo 请求与应答：ping 的灵魂机制
说到 ICMP，绕不开的就是 Echo。Echo 机制由一对报文组成：Type=8 的 Echo Request（回显请求）和 Type=0 的 Echo Reply（回显应答）。
当我们执行 ping 命令时，主机会向目标发送 Echo Request，目标如果收到并且允许响应，就会原样返回 Echo Reply。请求和应答报文里都包含 Identifier 和 Sequence Number 两个字段。Identifier 通常由发送进程的进程 ID 生成，用来区分不同 ping 实例；Sequence Number 则是递增的序号，用来统计丢包和乱序。
这个机制看起来简单，但它在排障中的价值超乎想象。ping 通不只能说明两端之间的 IP 连通性正常，还能借助应答延迟来评估链路质量。我平时会习惯性地观察 ping 的 RTT（往返时间）波动：如果 RTT 在 1ms 到 100ms 之间反复跳动，说明网络存在拥塞或链路质量波动，后续的诊断方向就得往带宽、队列、光模块误码率这些方向走。
还有一个实操技巧：ping 默认发的是普通的 Echo Request，但如果加上了正确参数，它可以变成 MTU 探测工具。在 Windows 上ping -f -l 1472就是发送一个不允许分片、载荷 1472 字节的报文。因为 IP 头加 ICMP 头本身是 28 字节（IPv4 通常情况），1472+28=1500，正好是标准以太网 MTU。如果这条命令能通，说明端到端至少支持 1500 字节的报文；如果返回"Packet needs to be fragmented but DF set."，说明路径上存在更小的 MTU。
2.2 差错报告家族：目的地不可达、超时、参数问题
Echo 是"查询型"的 ICMP，而 ICMP 的另一大半功能是"差错报告型"。这部分报文不是主动发起的，而是网络设备或目标主机在遇到无法转发的报文时，向源地址反馈的"坏消息"。理解这些报文，才算真正理解网络层出了问题之后，主机是怎么知道"出事了"的。
差错报告家族里最常用的几个成员：
Type=3 Destination Unreachable 是排障时最常碰到的差错类型。它的 Code 字段细分了多种不可达场景。Code=0 表示网络不可达，Code=1 表示主机不可达，Code=2 表示协议不可达，Code=3 表示端口不可达，Code=4 表示需要分片但 DF 位置位。其中 Code=3 有个很经典的用途：UDP 端口不可达。很多 traceroute 的 Linux 版本就是靠"发送 UDP 探测包，收到端口不可达"来判定已经到达目标的。
Type=11 Time Exceeded 包含两个主要场景。Code=0 表示 TTL 在转发过程中减到 0，报文被路由器丢弃。这是 traceroute 工作的基石——后面实操部分会细说。Code=1 表示分片重组超时。如果这个报文出现，通常是零散分片到达目的端的时间太长，目标主机缓存溢出无法完成重组，于是干脆把已收到的分片全部丢弃，并通知源端。
Type=12 Parameter Problem 表示 IP 头或参数有误，数据报无法被正确解析。正常情况下很少见到，但如果你在抓包时频繁看到，很可能是某台设备配置了奇怪的隧道封装或 TOE（TCP 卸载）功能导致报文头被改坏。
值得一提的是，源点抑制（Source Quench，Type=4）曾经被设计用于向发送方反馈"我快撑不住了，请你降低发送速率"，但在实际部署中效果很差，也容易引发拥塞恶化，所以早已被废弃。现在主流网络设备的实现基本都不再发送和响应这个报文。碰到相关老文档时别被误导。
2.3 差错报文中埋着的信息：为什么"不可达"能帮你定位故障
只看 Type=3 本身还不够，真正有价值的是它携带的原始报文信息。差错报文在被生成的瞬间，会把触发错误的那个 IP 报文头部和它的前 8 字节数据放在自己内部。这 8 字节到了 TCP/UDP 这层，刚好可以还原源端口和目的端口。收到 ICMP 差错报告的主机，靠这些信息就知道是哪一个 TCP 连接或 UDP 会话的哪一个报文出了问题。
这个设计在排查"连接超时但防火墙没有日志"这类疑难杂症时特别有用。有一次我排查某用户反馈到某服务器的数据库连接经常超时，服务器和防火墙的策略都翻了好几遍，最后抓包发现，中间的核心交换机在持续回 Type=3 Code=4 的 ICMP 报文，回看报文内嵌的原始数据，正是发往数据库 3306 端口、设置了 DF 位的 TCP SYN 包。链路 MTU 小于报文长度，又不允许分片，数据就一直发不出去。如果没有 ICMP 报错，这个问题几乎不可能快速定位。
2.4 重定向：路由方向的"智能纠偏"
Type=5 Redirect 是一个很有意思但容易被忽略的机制。当主机把报文发给路由器，路由器发现正确的下一跳其实应该是另一个设备时，它会向主机发送 ICMP 重定向消息，告诉它"你下次到那个网段别找我，直接发给旁边那台设备更近"。
这个机制在设计上是想让主机保持简单路由表，同时能适应网络拓扑变化。但它在安全性上是个软肋——攻击者可以伪造重定向消息，诱导主机把流量发给错误的下一跳，从而实现流量劫持。所以现在很多网络加固方案里都有一条：在主机侧禁用 ICMP 重定向响应，或者在路由器和交换机上关闭发送重定向的功能。实际生产环境中，我见到的大部分 Linux 服务器默认配置里，accept_redirects是全局开启的，如果这个服务器直接接在核心设备后面，网络环境又相对开放，建议评估是否需要关闭。
2.5 MTU 发现：绕过"分片黑洞"的关键
路径 MTU 发现（Path MTU Discovery，PMTUD）可能是 ICMP 在日常运维中最具实战价值的应用了。它解决的是一个不算罕见的问题：源主机按照自己的 MTU 发送满长度报文，但报文的传输路径上有些链路或设备的 MTU 更小。
PMTUD 的基本思路是：发送方发出的报文设置 DF 位，不允许中间路由器分片。如果某台设备发现报文长度超过出接口 MTU，它会直接丢弃报文，并向源地址回一个 Type=3 Code=4 的 ICMP 报文，告诉它"你的报文超过我能转发的尺寸了，我需要分片但不允许分片，所以我扔了"。发送方收到这个通知后，就把报文长度减小，再继续发，直到找到一条能通过整条路径的最大报文长度。
这套机制在正常情况下运转良好，但有个著名的坑：很多安全设备为了规避扫描和攻击，会悄无声息地把入方向的 ICMP 全部丢弃。一旦 PMTUD 用的 Type=3 Code=4 被防火墙吞掉，发送方永远不会收到"包太大了"的通知，就会一直用错误的大包重传，现象就是某些大包业务（例如带大缓存的上传、跨设备备份同步）间歇性卡顿甚至完全跑不通，而小包（如 SSH 登录、ping 小包）完全正常。这个问题在网络行话里叫 PMTUD 黑洞，后面我在排查部分会详细展开补救手段。
3. 实操：把 ICMP 用起来
3.1 ping 命令进阶：从"通不通"到"怎么看通不通"
ping 最基础的用法大家都知道，但很多人的使用方式还停留在ping IP这一层。真要拿 ping 当排障工具，有几个参数必须掌握。
Windows 上最常用的是-t持续 ping（Ctrl+Break 看统计，Ctrl+C 结束）、-n指定次数、-l指定载荷、-f设置 DF 位、-i设置 TTL。Linux 上则是-c指定次数、-s指定包大小、-M do设置 DF 位、-t是设置 TTL（注意 Windows 的-i和 Linux 的-t对应同一个功能）。跨平台容易混淆，建议在笔记本上记一份参数对照小抄。
更关键的是看懂输出。TTL 这个字段尤其重要。发送方设置初始 TTL，每经过一台路由器就减 1，目标主机返回 Echo Reply 时，TTL 已经是被减过之后的值。通过这个值可以粗略推断对方系统的默认初始值。Linux 默认 TTL 是 64，Windows 默认是 128，网络设备常见 255（老版本思科）或 64（部分新平台）。比如你 ping 一台服务器看到 TTL=57，那大概率是 Linux 系统，中间经过了 7 跳。如果不同时段 ping 同一个目标，TTL 出现明显变化，比如从 57 变成 113，那就要警惕路由路径是否发生了变化——可能流量被牵引到了另一台系统类型不同的设备上。
RTT 的观察也有门道。稳定的 RTT 说明路径上没有严重的拥塞和排队；RTT 忽高忽低，甚至出现长时间的间歇性延迟，往往指向链路中存在队列拥塞或无线重传；RTT 从某个跳开始突然增大，则可以考虑把排查重点放到这个跳的后续链路上。
3.2 traceroute 原理拆解：TTL 如何一步步画出网络路径
traceroute（Windows 上是 tracert）大概是 ICMP 最有创造性的应用。它利用 TTL 字段和 ICMP Time Exceeded 报文的配合，把一条数据报经过的每一跳都"逼"出来。
实现思路是这样的：发送方先发出一个 TTL=1 的探测报文。第一台路由器收到后，TTL 减 1 变成 0，按规则这个报文不能继续转发，于是路由器丢弃报文，同时回送一个 Type=11 Code=0 的 ICMP 超时报文给源地址。源地址一看这个报文的源 IP，就知道第一跳的设备地址。接着发送方发出 TTL=2 的探测报文，这次第一跳路由器把 TTL 改成 1 继续转发，第二跳路由器再把 TTL 减到 0，又超时回送报文。如此反复，每一跳设备都会在 TTL 归零时暴露自己的 IP，直到探测报文到达目标。
需要了解的是，探测报文的传输层协议在不同系统上不一样。Linux 的 traceroute 默认向目标端口发送 UDP 报文（常用 33434 起步的端口段），每跳发三次，最后一次到达目标后，通常会收到 Type=3 Code=3 的端口不可达应答，由此判断已经到终点。Windows 的 tracert 则默认用 ICMP Echo Request，目标主机收到后因为不知道是谁的请求，直接回 Echo Reply，到达判定方式不同。这两种模式在 Windows 平台以外的场景里差异很大，跨平台的工程师要特别留意。
实战中看 traceroute 输出有几句经验：如果某几跳显示星号，不一定是链路断，很可能是这几台设备不回应 ICMP 超时报文，比如某些运营商的路由器做了限速或过滤；如果到达某一跳后所有后续跳都超时，而最终目标又能通，那可能只是路径上有些设备对探测报文不敏感；如果目标都到达不了，而且中途某跳开始一直是星号，那就需要结合 ping 和抓包综合判断，不要急着下"链路中断"的结论。
3.3 抓包验证：用 Wireshark 看清 ICMP 的每一层
工具用得再熟，如果没见过 ICMP 报文在四层模型里的真实长相，理解始终是悬空的。建议每个学网络的人都亲手抓一次 ICMP 包，把结构看清楚。
使用 Wireshark 时，过滤条件可以直接写icmp。发起一次普通的 ping，就能在列表里看到成对出现的 Echo (ping) request 和 Echo (ping) reply。点开一个报文，从上到下逐层看：最外层是以太网帧，然后是 IP 层，IP 层里最显眼的是 Protocol 字段值为 1，表示上层是 ICMP。再展开 ICMP 层，Type、Code、Checksum、Identifier、Sequence 都在这里。
如果执行ping -f -l 1472这种方式触发大包，还可以观察 ICMP 数据区与以太网帧长度的对应关系，直观理解"IP 头 + ICMP 头 + 载荷"的整体开销。如果排查的是 PMTUD，记得把 Wireshark 挂在发送方侧，盯着有没有 Type=3 Code=4 的差错报文回来。
实际操作中抓包有个容易忽略的点：很多网卡的抓包工具默认在驱动层面开启了一些校验和卸载功能，这可能导致 Wireshark 显示 IP 或 ICMP 的 checksum 不正确，而事实上报文在线上是完好的。遇到校验和报错，先别着急怀疑报文被篡改，可以关掉网卡的 checksum offload 再抓一次。这也是很多初学抓包的人容易踩的坑。
3.4 利用 ICMP 时间戳与掩码请求的高级玩法
除了 Echo 和差错报告，ICMP 还有一些不那么常用但偶尔能派上用场的查询报文。
ICMP Timestamp（Type=13 请求，Type=14 应答）可以用来获取对端系统的时间。这在某些无法用 NTP 同步的环境里，可以用它粗略估算系统间的时间偏移。不过现代系统出于安全考虑，响应时间戳请求的设备越来越少，这个功能更多见于老设备的调试场景。
ICMP Address Mask Request（Type=17）用于询问子网掩码，但这个功能因为容易泄露网络规划信息，几乎所有现代操作系统和网络设备都默认不响应。见到这类报文，可以把它当作网络层扫描行为的一个信号，而不是真的指望它能告诉你掩码。
这些查询型 ICMP 虽然在常规排障中出场率不高，但攻击者往往会利用它们做网络侦察。作为防守方，了解它们存在本身就有价值——看到异常的时间戳请求或掩码请求时，至少要知道这是一种信息收集手段，应该引起警觉。
4. 常见坑和排查技巧
4.1 "ping 不通"不等于"业务不通"
做网络排障，最忌讳的就是把 ping 结果当成唯一的判断标准。ICMP Echo 请求被防火墙壁垒拦截的场景太常见了，很多网络设备、安全设备默认策略就对 ICMP 做丢弃处理，业务流量反而畅通无阻。所以"ping 不通"这件事，只能当作一个线索，不能直接推演出"链路故障或对端宕机"的结论。
反过来也要注意：业务不通但 ping 通，也是常有的情况。如果 TCP 端口没监听、服务进程挂了、负载均衡策略指向了错误的后端，ping 照样通，但业务就是连不上。所以我在排障时始终遵守一个流程：先 ping 看网络层连通性，再用telnet IP 端口或nc -vz IP 端口看应用端口是否可达，然后才根据业务协议本身的反馈做判断。拿 ICMP 的结果去否定应用层的问题，方向就是错的。
4.2 大包通、小包不通：PMTUD 黑洞的排查思路
PMTUD 黑洞是那种"症状明显但原因隐蔽"的典型故障。表象是：SSH、网页这种小流量正常，但只要涉及大消息块（比如大文件上传、跨节点数据库备份）就卡顿甚至断流。
排查思路可以这样推进。第一步，用不同载荷长度的 ping 做对照：ping -f -l 1472和ping -f -l 1200都试一遍。如果 1200 字节通而 1472 字节不通，基本能确定路径上有小于 1500 字节的 MTU 限制，且 TCP 会话遭遇了 PMTUD 黑洞。第二步，如果大包 ping 显示 "Packet needs to be fragmented but DF set"，说明中间设备在正常回 ICMP 差错报文，问题只是 MTU 小于发送方预期；如果 ping 大包直接超时，没有任何 ICMP 反馈，那就确认了黑洞口。第三步，找出小 MTU 的位置。最典型的场景是 PPPoE 拨号链路（MTU 通常只有 1492，因为要扣掉 PPPoE 头的开销），或者某些隧道/MPLS 环境下额外封装导致的 MTU 缩水。可以在发送方侧改小 MTU 做验证，比如 Linux 上ip link set dev eth0 mtu 1400，如果业务立即恢复，那基本就是 MTU 配置的问题。
还有一种被动规避方案是调整 TCP MSS。MSS 协商发生在 TCP 三次握手里，如果让两端协商出一个足够小的 MSS（比如 1360），那么即使中间链路 MTU 较小，TCP 分段后的报文也不会超过链路允许值，从而绕开 PMTUD 黑洞。很多企业出口都会在边界防火墙上配置 TCP MSS Clamping，原理就是在报文穿越时改写 MSS 字段。这是目前应对 PMTUD 黑洞最通用、最有效的方式。
4.3 防火墙限制 ICMP：怎么限才不给自己挖坑
最近几年到客户现场，遇到"防火墙把所有 ICMP 都禁掉"的情况仍然不少。这种配置的初衷通常是防 ping 扫描，但代价非常大：除了排障困难（ping 不通、traceroute 看不到路径），更重要的是会直接破坏 PMTUD，引发上面说的黑洞问题。所以我的建议从来不是"禁掉所有 ICMP"，而是精细化管控。
制定策略的时候，可以按照方向和行为来区分。对外方向（入站），一般不建议对完整的 Echo 请求做全放行，可以只对特定管理网段的源地址放行 Echo Request，其他源地址一律限制；对内方向（出站），则建议放行所有外出流量的对应差错报文——Echo Reply 和期望中的差错报告（如 Type=3、Type=11、Type=12）应该允许回来。换句话说，防火墙应该允许"本地会话触发后的对应 ICMP 应答"，而不是一刀切全部禁止。
实际配置里，很多主流防火墙会有"允许相关 ICMP 错误信息通过"的选项，勾选它通常就足够了。如果用的设备不支持这种会话关联功能，再考虑按类型放行。宁可多放行几种差错报文，也不要全禁。
4.4 应对 ICMP 洪泛：限速是最有效的手段
ICMP 被滥用的问题始终存在，最常见的就是 ping flood。有人以为禁掉所有 ICMP 就能防住，但这回避不了"你需要 ICMP 来排障"的需求，而且攻击者如果目的就是消耗你的链路带宽，禁掉 ICMP 并不会阻止流量被打满。正确的做法是限制速率。
主流交换机、路由器普遍支持对 ICMP 报文做限速。具体可以针对入接口的 ICMP 流量设置 pps（包每秒）限制，超过速率的部分直接丢弃。做这一步的时候，记得把限速值设得高于日常监控所需——比如你想要 10 个 ping 包就够诊断了，限速值可以设成几百 pps，既能应对日常排障，又不至于被一个小脚本轻松打满。
还有一个实用的配置方向是限制 ICMP 报文的速率时区分类型。Echo 请求可以相对收紧，差错报文则建议宽松一些，因为差错报文本身就是网络异常的信号，你把它们限得太死，会让自己在真正出问题时失去诊断依据。
4.5 为什么 traceroute 某些跳是星号：三种可能
traceroute 打星号这件事让很多人焦虑过。其实按经验看，星号不按链路中断处理的日子占大多数。可能的原因有三个。
第一，中间设备配置了"不回应 ICMP TTL 超时报文"，这类设备会把 TTL 到 0 的探测报文静默丢弃。常见于某些运营商的核心路由器、出口安全设备。第二，探测报文被路径上的安全设备过滤，导致后续报文无法到达目标。第三，如果只有个别中间跳显示星号，但最终目标能通，那基本是第一类原因，链路本身没问题。只有当你看到"从某一跳开始所有后续跳+最终目标全部超时"，才应该考虑路径或目标设备真的有问题。
掌握这个判断逻辑，能少走很多弯路。我见过有人盯着 traceroute 里的几个星号，硬是把链路排查了个遍，最后才发现只是目标路由器默认不回超时报文。
5. 扩展：ICMPv6 与 ICMP 的安全边界
5.1 ICMPv6：改头换面的下一代版本
IPv6 时代，ICMP 不仅没有消失，反而承担了更多职责。ICMPv6 的报文类型继承了 IPv4 时代的分类思路，但新增了针对 IPv6 特性的机制。
ICMPv6 最核心的新增功能是邻居发现（Neighbor Discovery Protocol，NDP）。它用 Type=135（邻居请求）和 Type=136（邻居通告）替代了 IPv4 里的 ARP，负责解析链路层地址、检测地址冲突、维护邻居可达性。另外，无状态地址自动配置（SLAAC）依赖 Type=134 的路由通告和 Type=133 的路由请求——主机通过接收路由通告来拿到前缀和默认网关信息。
这意味着在 IPv6 环境里，ICMPv6 的报文不再只是辅助，而是地址配置和邻居解析的基础设施。如果 IPv6 网络中误将 ICMPv6 全部禁掉，设备之间连基本通信都无法建立。很多从 IPv4 平移过来的防火墙策略，在这里就是重灾区。所以在做 IPv6 安全策略时，至少要对 ICMPv6 类型保持谨慎：135/136（邻居发现）必须放行，133/134（路由通告）要看网络设计，差错报文和其他必要类型同样不能一刀切丢弃。
5.2 ICMP 的安全使用边界：该开哪些、该禁哪些
给 ICMP 做安全策略，我习惯按"必需、可选、不建议"分层来决策。
必需的 ICMP 类型包括：Echo Request/Echo Reply（Type=0/8）用于连通性检验和部分监控；Destination Unreachable（Type=3）和 Time Exceeded（Type=11）用于 PMTUD 和 traceroute 诊断；Parameter Problem（Type=12）用于识别协议异常；ICMPv6 场景下还要额外放行邻居发现相关的 135/136。
可选的通常是 Redirect（Type=5）、Timestamp（Type=13/14）、Address Mask（Type=17/18）。这些要么有安全风险，要么在正常业务里很少用，一般建议关闭或在主机层禁用响应。
不建议开放但也不建议直接静默丢弃的，是那些 UDP 端口不可达引发的差错报文。如果在端口扫描防御场景下不想暴露过多信息，可以对局域网内部客户端的差错报告正常应答，对外部来源则做限速或限制特定来源。
说到底，ICMP 是网络层自带的反馈机制，把它理解成网络的三反馈系统，排障和安全策略的很多疑问就迎刃而解了。
我自己在实际排障里的习惯是：拿到一个"业务异常"的反馈，先不急着看业务协议本身，而是先抓一轮 ICMP 和传输层的包，把网络层的异常证据收集齐了，再往上层分析。很多复杂问题最终都指向中间链路对大包或特定类型报文的静默丢弃——而这些信号，恰恰只有 ICMP 能给你。如果你看完这篇，能顺手检查一下自己负责的网络里有没有"一刀切禁 ICMP"的策略，或者下一次 ping 大包不通时，能第一时间想到 MTU 黑洞而不是怀疑设备故障，那这篇文章就没白写。
