IP通了业务却不通？从数据链路层到IP协议的排错实战

1. 一次业务响不上的故障为什么IP能通、服务就是不通1.1 故障场景还原很多年前调试一个办公局域网的时候遇到过一桩非常典型的故障同一层楼的两台电脑A去ping B的IP地址每个包都正常返回延迟也很漂亮。但A要访问B上的共享文件夹反复提示连接不上。关防火墙、开共享、重启网卡能试的日常操作都试了个遍问题纹丝不动。后来在接入交换机上做了端口镜像抓包才发现根源不在操作系统也不在共享配置而是后台还有一台电脑不知什么时候被人手动填了和B一模一样的静态IP地址。这个现象放在只看IP层的人眼里非常怪异既然IP通了为什么上层业务就不通但如果你把IP协议和数据链路层分开理解就会发现这个逻辑一点都不矛盾——“IP能通”只说明网络层和数据链路层的通路基本正常并不保证“传输层连接与具体服务可用”。那台抢占IP的电脑既抢走了ARP请求的应答权也干扰了交换机的MAC地址表导致发往B的数据帧要么送到了第三者手里要么被直接丢弃。从应用层的视角看就像目标服务永远存在但永远连不上。1.2 为什么这件事必须回到IP层和链路层来解释在写代码或者日常运维的时候大部分人习惯把网络问题一刀切地称作“网断了”。实际上“连不上”是一个笼统的结果背后可能是网卡驱动异常可能是IP地址配置错误或冲突也可能是端口没监听甚至是对面的防火墙把包丢了。如果把问题不分层直接开始猜很容易在应用层绕了半天才发现错在二层。这也是我遇到网络故障时永远先固定两个层面的原因IP协议负责跨网络的寻址和转发数据链路层负责在每一条物理链路上完成相邻节点间的帧传递。这两层的关系可以简单理解成一个接力赛——IP地址负责确定终点MAC地址和帧负责把每一棒送到下一个接力点。回到刚才的故障ping包能通只能证明“从A到B中间每一段链路都能跑”但应用进程是否正常收包端口是否响应根本不是IP协议与数据链路层的职责范围。理解了边界你才能判断“下一步该查哪一层”而不是原地打转。2. IP协议到底做了哪几件事2.1 IP的服务模型不可靠、无连接、尽力而为IP协议是网络层的核心它要解决的是“把数据报从源端一路运到目的端”。操作方式说起来很朴素给上层交来的数据加上一个头部头部里写清楚源IP和目的IP然后交给下一跳的接口由沿途的路由器根据路由表一级一级转发。整个过程中IP不维护连接状态不保证报文一定到也不保证到达顺序与发送顺序一致。这种“不可靠”听起来很弱但恰恰是互联网能大一统的关键——如果每一层都去做可靠性那么每一台路由器都得为每一条会话维护状态规模一大必然撑不住。正确的设计思想是把可靠性留在TCPIP专心做“尽力而为的送达”。理解这句话你就理解了很多网络问题为什么表现为“底层不背锅、上层来兜底”。2.2 IP报头里需要记住的字段IP报头看起来不长但每个字段都可以在抓包时告诉你一条线索。整理成一张速查表会更直观字段长度/作用实际使用中要注意的点版本4位标识IPv4或IPv6抓包第一眼确认协议栈是否正确IHL/首部长度4位通常为5存在选项时会变大报文偏移跟着变化总长度16位是整个IP数据报长度不是载荷长度标识16位分片重组时靠它判断是否同属于一个数据报标志DF/MFDF置1表示禁止分片MTU不足会触发ICMP错误分片偏移13位以8字节为单位重组时决定分片在大包里的位置TTL8位每过一跳减1减到0直接丢弃用于防环路协议号8位6是TCP17是UDP1是ICMP首部校验和16位TTL每跳会变因此每跳都要重新计算源/目的IP32位整个转发过程中一般不变NAT场景除外其中分片偏移是最容易被误解的字段。它不按字节计数而是以8字节为单位所以一个偏移值乘以8才是真实的字节偏移位置。接收端做重组时依赖的是“标识 MF标志 分片偏移”这三个字段的组合任何一个错了重组就会乱套。2.3 分片、重组与MTUMTU叫最大传输单元不同链路层协议可以各自定义自己的值。以太网的默认MTU是1500字节。一个IP数据报如果大于出接口的MTU就需要被切分成多个更小的分片。IPv4允许中间路由器参与分片IPv6则相反——只有源节点能分片中间路由器遇到超过MTU的包直接回一个ICMPv6“数据报太长”的报文让源端自己调整。IPv6这样设计是为了让转发路径上的设备保持无状态性能更稳。排错中碰到最多的问题是MTU与上层TCP的配合失调。典型场景是某些拨号链路的MTU只有1492隧道场景还会扣掉更多字节。如果主机TCP MSS没有跟着调整就会出现网页打不开、但ping网关畅通的现象。一条命令可以快速判断在Windows上执行ping -f -l 1472 目标IP1472字节加上IP头和ICMP头恰好等于1500。如果这条命令成功说明路径支持1500的包如果提示“需要拆分数据包但是设置DF”说明路径上存在MTU限制把数值往下调再测找到临界点。2.4 TTL、协议号与ICMPIP协议的“左膀右臂”TTL的全称是Time To Live虽然叫“生存时间”但在IPv4实际实现里就是“最大跳数”。每经过一台路由器TTL减1减到0路由器把包丢弃并回一个ICMP超时报文。这个机制解救了一个被反复提起的实际问题——环路。没有TTL的话两个路由器之间的一条错误路由就可能让数据报无限循环耗尽链路有效带宽。traceroute工具就是利用TTL的这个特性设计出来的。它发送TTL从1开始递增的探测包让每一跳路由器都“强制丢弃”一次并在ICMP报文里留名这样一来整条路径就被拼出来了。我拿到一个应用的traceroute结果通常先看每一跳的延迟分布再从延迟突起的那一跳入手排查。协议号的作用很多人会忽略。IP层不关心数据报里封装的是TCP还是UDP它只知道要把载荷交给某个上层协议协议号就是那个“投递标签”。如果抓包时看到IP层下面不是预期的协议号载荷那多半是封装方式变了需要往隧道或封装方向查。2.5 从IP地址到路由决策IP通信的另一个基础是网段与路由。一台主机收到包后会先用自己的子网掩码跟目的IP做与运算判断对方在不在本地网段。在本地就直接在二层找目标设备的MAC不在本地就把包扔给默认网关。路由器转发时会在路由表里找“最长匹配”的项目——前缀越长、越精确的越优先。IPv6也应该顺手提一句地址长度变成128位写成十六进制外观就很好认。另外IPv6里彻底取消了ARP改由邻居发现协议NDP完成三层地址到二层地址的映射探测方式也从广播改为组播。在纯IPv6环境里排错时不要再去查ARP缓存改查邻居缓存就对了。3. 数据链路层的真实分工3.1 以太网帧IP数据报在这里被装进“信封”数据链路层解决的是“相邻节点间怎么把数据送过去”的问题。物理线缆上不认IP地址只认电信号的时序和帧边界因此以太网必须把上层数据装进一个结构明确的帧里。一个最典型的以太网帧是这样的字段长度说明前导码 起始符8字节物理层同步用不算帧本体目的MAC6字节本帧要交给的下一跳设备源MAC6字节发出本帧的网卡地址类型/长度2字节0x0800表示上层是IPv40x0806表示ARP数据区46~1500字节装载IP数据报等内容帧校验序列FCS4字节用CRC算法检验整帧是否损坏这里有一个非常重要的认知MAC地址是一个“本地有效”的地址只在局域网范围内有意义。可以把IP地址想成快递单上的最终收件地址MAC地址则是某个外卖驿站的门牌号。IP数据报从源到目的每经过一跳路由器源MAC和目的MAC都会被重新封装一次但IP地址从头到尾不变NAT场景除外。这就是两层各司其职的具体体现。3.2 从共享介质到全双工冲突域如何被消灭老式以太网使用同轴线缆时所有设备共享同一条线路谁发数据前都得先听一下信道是否空闲两台设备同时发送就会产生冲突靠CSMA/CD机制来退避重发。后来交换机普及每个端口都是独立的接入通道全双工模式允许设备同时收发冲突域被缩小到了端口与对端设备之间的那一截链路上碰撞问题基本消失。今天看到网卡和交换机协商出的速率比如1Gbps/Full Duplex就是这个演进的产物。但这个演进也带来了一种隐蔽故障如果某一边因为手动指定或硬件问题锁成了半双工另一边是全双工两台设备之间不会立即断开而会在流量增大时出现大量CRC错误、重传和诡异的高延迟。这种问题光看IP层完全看不出端倪必须低头去查链路层的协商状态。3.3 交换机是怎么学习转发的交换机做的事可以归结为一句话记录每个端口后面有什么MAC地址。收到一个数据帧交换机会把源MAC和接收端口记进MAC地址表发往某个已知MAC时直接单播到对应端口查不到记录的MAC就把帧向除接收端口以外的所有端口泛洪让目的设备自己回包再用回包更新地址表。广播和组播帧天然就是要泛洪的。排查交换机问题时我现在习惯先看端口错误计数和丢包计数而不是一上来就抓IP层。错误计数持续增长紧接着去查对端设备的协商状态、网线质量、光模块光功率能比翻上层配置快得多。这是很多人容易忽略的视角二层的“状态信息”全在端口计数里三层的“状态信息”才在路由表里。3.4 数据链路层的可靠性只做“检错”不做“纠错”很多人误以为链路层有重传机制其实没有。以太网帧尾部的FCS是做CRC校验的接收方也重新算一遍CRC对不上就把这一帧当坏帧悄悄丢掉。重传是TCP等上层协议的事数据链路层只是不把坏数据直接向上提交。这也解释了为什么二层链路上会有一个合理的错误计数基线。二层计数有少量错误不代表一定有问题但长期快速上涨就值得警惕了接下来要检查的通常是线缆质量、电磁干扰、配对线序和光电转换器件。这些都属于典型的“网络层看起来正常、二层已经悄悄丢包”的场景。4. ARP两层之间最重要的“翻译”通道4.1 为什么需要ARPIP数据报要想被送达第一步必须封进以太网帧而帧里必须写目的MAC地址。但在一个局域网里我们往往只知道对方的IP不知道对方的MAC。ARP就是负责做“IP地址到MAC地址”翻译的协议。严格来说ARP是网络层与链路层之间的一项辅助协议它自己不完全是二层协议却总是封装在以太网帧里传输。4.2 一个完整的ARP解析流程假设主机A的IP是192.168.1.10要ping同网段的192.168.1.20。整个过程大概是这样的A先查自己的ARP缓存看有没有192.168.1.20对应的MAC地址。没有就发送一个广播ARP请求源IP是A目标IP是192.168.1.20目标MAC填FF:FF:FF:FF:FF:FF。同网段所有设备都收到广播并解开帧看目标IP只有192.168.1.20的网卡认领并单播响应自己的MAC。A把结果写进缓存之后发IPv4数据报时直接用学到的MAC地址封帧。ARP缓存里的条目不会立刻消失操作系统会按设定时间保留并不断刷新。排错时我经常在Windows上执行arp -a看缓存如果某个IP对应的MAC和实际设备对不上几乎可以肯定有人在二层动了手脚。4.3 免费ARP、缓存老化与ARP安全除了请求和应答还有一类ARP叫“免费ARP”或“无故ARP”。它不等别人问主机在开机或配置好IP后主动广播一句“这个IP是我的对应这些MAC”目的是提前刷新全网络的缓存并顺带探测IP地址冲突。如果网里另一台机器也配了一样的IP免费ARP会收到冲突证据系统就会弹出地址冲突提示。ARP安全老生常谈但必须说ARP不带身份认证任何设备都能回应“这个IP是我的”。一台机器可以在同一个广播域里冒充网关把出网流量都导到自己这边这就是ARP欺骗的基本原理。防御手段通常是接入层交换机上的动态ARP检测和端口安全。普通办公网最有效的办法反而简单——把访客设备和办公设备隔离严格控制手动静态IP的使用范围。4.4 二层寻址的三点常见误解第一以为MAC地址是设备唯一的“身份证”。其实MAC地址只需要在局域网内唯一即可一台电脑上多个网卡多个MAC是常态而且跨网段时MAC会被改写。第二以为跨网段通信也要做ARP查询实际上此时ARP查询的目标是网关的MAC不是对端服务器的MAC因为下一跳就是网关。第三以为ARP在所有网络里都存在IPv4是IPv6已经改用邻居发现协议完成同样的映射不再使用广播性质的ARP报文。5. 抓包实践把IP和以太网帧放到同一个屏幕上看5.1 准备一个最简环境用一台装了Wireshark之类抓包工具的电脑就能把IP和链路层这两层的协作看得明明白白。启动抓包前确保网卡开启混杂模式过滤栏里写ip.addr目标IP就能扫出和某台设备相关的所有IP报文。如果想同时观察ARP可以再叠加arp过滤条件。很多抽象概念比如分片重组、MAC地址更换看书容易头晕抓到包以后一眼就懂了。5.2 观察IP分片到底怎么拼先用一台Windows机器去ping局域网内另一台设备发一个默认大小之外的包ping -l 3000 目标IP不加-f源主机会发现本机的MUT为1500于是把3000字节的数据报切分成多片分片都带相同的标识字段除了最后一帧其余分片的MF标志都置1。抓包软件会把分片重新拼成一个整体展示而IP头里的分片偏移字段会显示每片在原数据报里的位置。如果换成ping -f -l 3000 目标IP就会故意触发“禁止分片”的ICMP错误返回“需要拆分数据包但设置DF”的提示。这一来一回IP分片和路径MTU发现机制就全部理解了比对着书看半天印象深刻得多。5.3 看二层帧的源、目的MAC如何在跨网段变化先抓一个同网段内的ping包会发现源MAC是本机网卡目的MAC是目标设备的MAC。再跳出本网段ping一个公网地址同样看一眼去程包目的MAC已经变成网关接口的MAC源MAC还是本机而IP头的目的IP不变。网关转发回来的响应又会把MAC换一次。这个细节最能说明IP层和数据链路层的分工。IP地址是全程不变的“收件单”MAC地址则是每一段接力中“当下这一棒的门牌号”。很多人书读了不少却对“下一跳”没有画面感抓一次包就全明白了。5.4 抓一个ARP请求看看清空ARP缓存后去ping同网段的机器抓包列表里会出现一条ARP请求。打开这条帧可以看到以太网类型字段是0x0806目标MAC是全F的广播地址。目标机器收到后回单播的ARP应答类型同样是0x0806。一个ARP请求就把二层帧结构、广播域范围、三层地址到二层地址的解析、帧类型字段如何指引上层协议这几件事全部串起来了。如果你以前没抓过包强烈建议今晚找个局域网设备试一次。6. 故障排查从二层开始再往三层收网6.1 推荐的排查顺序面对任何“连不上了”的故障我建议按自下而上的顺序排查先看网卡指示灯和协商状态确认链路是否建立、速率和双工是否正常。查本机IP配置用ipconfig或图形界面确认有没有拿到地址、掩码网关对不对。ping 127.0.0.1验证本机协议栈再ping同网段的另一台机器验证二层加三层的基本连通性。ping网关验证能不能出本网段最后ping公网IP和域名依次验证路由、NAT和DNS。如果第3步失败问题基本就锁定在网卡、交换机端口、网线或者VLAN划分类别不用去应用层折腾。如果第4步失败则说明IP配置、ARP缓存或路由表里有一环不对。按这个顺序走下来方向跑偏的可能性极低。6.2 常见问题定位速查表故障现象优先怀疑层级主要排查手段链路不亮、协商速率低物理层/数据链路层查网线、端口协商、驱动能ping通本网段但出不了网网络层查网关配置、路由表、ARP缓存偶发高延迟、大量TCP重传数据链路层查双工协商、CRC错误计数、光功率小包正常、大包不通网络层查MTU做路径MTU发现IP时通时不通ARP/地址冲突执行arp -a对比抓包看接入端口域名解析不出但IP能通应用层/DNS查DNS配置和解析服务器6.3 一个典型的MTU排查案例调试某家企业出口网络时遇到的现象是浏览网页经常卡在半路刷新几次能出来下载大文件偶尔报错。一开始怀疑DNS或代理换了几个思路都没解决。后来抓包发现TCP会话里出现大量“需要分片”的ICMP报文但同时还有超过链路承载能力的大包在持续发送。逐跳ping测MTU后定位到出口设备默认MTU被人改成了1450但终端并不知道TCP MSS也没同步调整。把链路各方MTU恢复标准值并让客户端重连后问题再没出现过。这类问题最麻烦的地方在于它既不是IP地址问题也不是链路断开而是“IP数据报大小超过下一跳承载能力中间节点又不能分片”表现就是大部分时候正常、文件一大就出事。6.4 两个容易想歪的点第一个误区是“ping通了就说明网络没问题”。ping只能确认ICMP的这条路径能走通不能证明某个高端口的服务、大数据包传输和特定应用链路也都正常。网络诊断中得到“通”这个结果不等于拿到了“畅通无阻”的保证书。第二个误区是以为IP协议“大于”数据链路层。这两层不是上下的管理关系而是封装关系——链路层帧把IP数据报当作自己的载荷往上送。想明白这个再看到奇怪的网络表现就问自己这一跳的MAC写对了吗这个包拆得开吗这个IP头里的字段是我预期的吗这三问基本能覆盖大多数疑难杂症。最后分享一个我自己长期用的思考习惯把IP地址当成快递单号把MAC地址当成派件节点的门牌号。数据报从A寄到B单号一路上不变但每一站派件员看的都是本站门牌。排错时随时想清楚自己正站在哪一段链路应当看的是IP、MAC还是端口速率。把这个问题想明白大部分网络故障的排查思路就自己长出来了。