4、网络层调试：IP报文分片与重组、路由表查找、TTL超时问题
网络层调试，说白了就是跟IP头打交道。很多链路问题表面看是物理层或数据链路层，追到根上其实是网络层的配置或行为异常。我个人习惯，排查链路问题时，先看一眼IP层的表现，往往能省下大量抓包分析的时间。
这一章我们聚焦三个核心点：IP分片与重组、路由表查找、TTL超时。这三个点几乎覆盖了90%的网络层故障场景。
核心观点：网络层调试的本质，是验证“源到目的”的IP包能否正确转发。分片、路由、TTL，是这条链路上的三个关键检查点。
4.1 IP分片与重组：MTU不匹配的典型场景
IP分片，说白了就是当数据包超过链路MTU时，路由器把它切成小块再发。重组则在接收端完成。听起来简单，但实际调试中，分片问题往往是“隐形杀手”。
为什么会分片？ 以太网标准MTU是1500字节，但IP包最大可以到65535字节。当一个大包（比如NFS、iSCSI流量）经过一个MTU较小的链路时，路由器就必须分片。
注意：分片会带来严重的性能问题。每分一次片，路由器就要多处理一个包头。更麻烦的是，只要有一个分片丢失，整个原始包都要重传。我在项目中遇到过，某视频监控平台频繁卡顿，最后发现是分片重组超时导致丢帧。
分片的关键字段
| 字段 | 作用 | 调试时怎么看 |
|---|---|---|
| Identification (ID) | 标识原始包，同一组片共享ID | 抓包时按ID排序，看哪些片属于同一个包 |
| Flags (DF/MF) | DF=1禁止分片；MF=1表示后面还有片 | DF置位但包超MTU → 路由器会丢包并回ICMP |
| Fragment Offset | 该片在原始包中的偏移量（8字节为单位） | 重组时按偏移量排序，偏移量必须是8的倍数 |
调试技巧：用tcpdump抓包时，加 -v 参数可以看到分片信息。比如 tcpdump -i eth0 -v 'ip[6:2] & 0x3fff != 0' 只抓分片包。
MTU探测与PMTUD
Path MTU Discovery (PMTUD) 是解决分片问题的标准方法。它的原理很简单：发送端先发一个DF置位的大包，如果中间链路MTU不够，路由器会回一个ICMP Fragmentation Needed报文，告诉发送端“这个包太大了，我的MTU是X”。
但PMTUD有个坑——很多网络设备会过滤ICMP报文。我曾经遇到一个案例：某数据中心跨地域传输大文件，速度奇慢。排查了三天，最后发现是中间防火墙把ICMP Type 3 Code 4（需要分片但DF置位）给丢了。发送端收不到反馈，就一直重传大包，形成死循环。
# 检查PMTUD是否正常工作
# 在Linux上手动探测路径MTU
ping -M do -s 1472 10.0.0.1 # -M do 表示DF置位，-s 1472 = 1500 - 28(IP+ICMP头)
# 如果收到 "Frag needed and DF set" 的ICMP错误
# 说明路径MTU小于1500，需要逐步减小包大小测试4.2 路由表查找：最长前缀匹配的实战
路由表查找，说白了就是路由器决定“这个包该往哪扔”。核心算法是最长前缀匹配——匹配到最精确的那条路由，就用它转发。
你想想看，路由器收到一个目的IP为192.168.1.100的包，路由表里有两条路由：192.168.1.0/24 和 0.0.0.0/0。它会选哪个？当然是/24那条，因为前缀更长，匹配更精确。
路由表结构
| 字段 | 含义 | 调试要点 |
|---|---|---|
| Destination | 目的网络/主机 | 注意区分网络地址和广播地址 |
| Next Hop | 下一跳IP | 必须是直连可达的地址 |
| Interface | 出接口 | 检查接口状态是否UP |
| Metric | 路由优先级（越小越优先） | 直连0，静态1，动态路由协议各有不同 |
常见问题：路由黑洞。我遇到过一台核心交换机上配置了静态默认路由指向一个不存在的下一跳，结果所有出站流量都丢了。排查时 show ip route 能看到路由，但下一跳ARP解析失败。记住：路由表里有条目 ≠ 能通。
路由查找的调试命令
# Linux
ip route get 8.8.8.8 # 查看去往8.8.8.8的实际路由
ip route show table all # 查看所有路由表（包括策略路由）
# Cisco
show ip route 192.168.1.100 # 查看特定目的的路由
show ip cef 192.168.1.100 # 查看CEF转发信息（硬件转发）
# 华为
display ip routing-table 192.168.1.100
display fib 192.168.1.100 # 查看FIB表个人经验：调试路由问题时，我习惯先查FIB（转发信息表）而不是路由表。因为路由表是控制平面，FIB才是数据平面真正用的。有时候路由表里有，但FIB里没有，说明路由没下发成功。
4.3 TTL超时：环路与路径探测
TTL（Time To Live）是IP头里的一个8位字段，每经过一个路由器减1。减到0时，路由器会丢弃这个包，并给源地址回一个ICMP Time Exceeded报文（Type 11 Code 0）。
TTL超时的两个典型场景：
- 路由环路：包在路由器之间来回转发，TTL不断递减直到0。这是网络故障中最常见的问题之一。
- 路径探测：traceroute就是利用TTL超时机制工作的。它先发TTL=1的包，第一个路由器回超时；再发TTL=2，第二个路由器回超时……以此类推，就能画出整条路径。
路由环路的调试方法
我曾经处理过一个经典环路案例：某园区网出口路由器上配了两条默认路由，一条指向ISP，一条指向内部核心交换机。结果内部核心交换机也配了默认路由指向出口路由器。你想想看，一个去往互联网的包到了核心交换机，查路由发现下一跳是出口路由器；出口路由器收到后，查路由发现下一跳又是核心交换机……死循环了。
# 检测路由环路
# 方法1：traceroute
traceroute -n 8.8.8.8
# 如果看到IP地址反复出现（比如 A → B → A → B），说明有环路
# 方法2：抓包看TTL
tcpdump -i any 'icmp[icmptype] == 11' # 抓ICMP超时报文
# 如果同一个源IP频繁发TTL超时，说明该路径上有环路注意：TTL超时不一定都是环路。也可能是路径太长（超过255跳），或者某个路由器配置了很低的TTL阈值。我见过有人把路由器的TTL阈值设成1，结果所有经过它的包都被丢弃了。
TTL与安全
TTL还可以用来做简单的OS指纹识别。不同操作系统发送的初始TTL不同：
| 操作系统 | 初始TTL |
|---|---|
| Linux | 64 |
| Windows | 128 |
| macOS | 64 |
| Cisco IOS | 255 |
嗯，这里要注意：如果抓包看到TTL是120，说明源端是Windows（初始128），经过了8跳。这个信息在排查跨域流量时很有用。
4.4 综合调试案例：一个典型的分片+路由问题
最后分享一个我实际处理过的案例，把这三个知识点串起来。
现象：某分支机构通过VPN访问总部文件服务器，大文件传输经常中断，小文件正常。
排查过程：
- 先ping大包（
ping -M do -s 1472），发现丢包。说明路径MTU有问题。 - traceroute查看路径，发现中间经过一个IPSec VPN网关。VPN网关的MTU通常比以太网小（因为要加IPSec头）。
- 检查VPN网关配置，发现MTU设为1400，但没开启PMTUD。导致大包被丢弃，且没有ICMP通知发送端。
- 同时发现路由表里有两条去往总部的路由，一条走VPN，一条走互联网出口。部分流量走了错误路径。
解决方案：在VPN网关上开启PMTUD，并调整路由优先级，确保VPN流量只走VPN隧道。同时在客户端设置TCP MSS为1360（1400 - 40字节IP+TCP头），避免分片。
总结：网络层调试，记住三个检查点——分片看MTU和DF标志，路由看FIB和下一跳可达性，TTL看是否超时和路径是否合理。这三个点查完，90%的网络层问题都能定位。