4. 网络层诊断（上）：IP地址冲突、子网掩码配置错误、默认网关不可达问题定位
网络层出问题，往往是最让人头疼的。应用层报错五花八门，传输层连接超时，但根子可能就在网络层。这一章我们聚焦三个最常见的坑：IP地址冲突、子网掩码配错、默认网关不可达。这三个问题我几乎每次项目部署都会遇到，尤其是新环境上线的时候。
核心思路：网络层诊断的关键是验证“我能不能找到对方”。IP地址冲突让你找不到自己，子网掩码错误让你找不到邻居，网关不可达让你找不到外界。先定位是哪一类，再动手。
4.1 IP地址冲突：你和你自己打架
IP地址冲突，说白了就是局域网里有两台设备用了同一个IP。网络通信靠的是MAC地址寻址，但IP是门牌号。门牌号重复了，数据包就不知道该送给谁。
我记得有一次在数据中心做扩容，新上架的服务器怎么都ping不通网关。检查配置，IP、掩码、网关都对着呢。后来用arping扫了一下，发现网关的ARP表里，这个IP对应的MAC地址一直在跳变。嗯，这就是典型的IP冲突。
4.1.1 现象与影响
- 间歇性断连：设备能通一会儿，然后突然掉线，过一会儿又恢复。因为ARP表在两端设备之间反复覆盖。
- ping延迟抖动：第一次ping通，第二次超时，第三次又通。这是冲突最典型的特征。
- 无法获取IP：DHCP环境下，客户端请求地址时，服务器发现地址已被占用，分配失败。
4.1.2 诊断工具与方法
我个人习惯用下面这套组合拳，效率很高：
- arping：这是我最先用的工具。在冲突设备上执行
arping -D -I eth0 192.168.1.100，如果收到多个MAC地址的回复，基本实锤。 - 查看ARP表：在网关或交换机上执行
arp -a，看目标IP对应的MAC地址是否频繁变化。 - 抓包分析：用tcpdump抓取ARP报文。冲突时你会看到同一个IP的ARP请求和应答来自不同的MAC地址。
小技巧：Windows下可以用 arp -a 查看缓存，但清理缓存需要管理员权限执行 netsh interface ip delete arpcache。Linux下用 ip neigh flush dev eth0。
4.1.3 避坑指南
我曾经遇到过一个坑：虚拟化环境里，虚拟机克隆后忘记重新生成MAC地址，导致新虚拟机与模板机IP冲突。更隐蔽的是，有些虚拟交换机开启了MAC地址伪装，arping都查不出来。后来我强制在克隆后执行 ip link set eth0 address $(openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//') 重新生成MAC，问题解决。
4.2 子网掩码配置错误：你以为的邻居不是邻居
子网掩码决定了网络范围。掩码配错了，设备会错误地判断目标IP是在本地网络还是需要走网关。这个问题在手动配置IP时特别常见。
举个例子，IP是192.168.1.10，掩码应该是255.255.255.0，结果配成了255.255.0.0。这时候设备认为192.168.2.10是自己的直连邻居，不会发ARP请求去问网关，而是直接发ARP广播。对方不在同一个广播域，自然收不到回复，通信就断了。
4.2.1 诊断方法
怎么快速判断是掩码问题？我一般看两点：
- 能ping通网关，但ping不通同网段的其他主机？ 大概率不是掩码问题，可能是防火墙或ARP问题。
- 能ping通部分主机，但ping不通另一部分？ 检查掩码。用
ipcalc或ip addr确认当前掩码，然后手动计算网络地址。
关键命令：Linux下用 ip route show 查看路由表。如果目标IP应该走网关，但路由表显示走eth0直连，那掩码一定有问题。
4.2.2 实战案例
有一次，一个同事反馈新部署的服务器无法访问公司内网的OA系统。我登上去一看，IP是10.10.20.50，掩码是255.255.255.0，网关是10.10.0.1。问题很明显：掩码255.255.255.0意味着网络地址是10.10.20.0/24，而网关10.10.0.1不在这个网段内。设备认为网关是远程主机，需要走默认路由，但默认路由又指向这个网关，死循环了。
修正掩码为255.255.0.0后，通信恢复正常。
4.3 默认网关不可达：出不去的大门
默认网关是设备访问外部网络的出口。网关不可达，意味着你只能和同网段的主机通信，出不了局域网。
4.3.1 常见原因
| 原因 | 说明 | 典型现象 |
|---|---|---|
| 网关设备宕机 | 路由器或三层交换机挂了 | 所有跨网段通信全部超时 |
| 网关IP配置错误 | 写错了网关地址，或者网关IP不在本网段内 | ping网关不通，但同网段通信正常 |
| ARP解析失败 | 设备无法获取网关的MAC地址 | ping网关显示“Destination Host Unreachable” |
| VLAN/ACL限制 | 交换机端口或防火墙策略阻止了流量 | ping网关超时，但ARP能解析到MAC |
4.3.2 诊断步骤
我的诊断流程是这样的：
- 第一步：ping网关IP。 如果通，说明链路层没问题，问题可能在路由或上层。
- 第二步：检查ARP表。 执行
arp -n | grep 网关IP，看有没有对应的MAC地址。如果没有，说明ARP请求没收到回复。 - 第三步：抓ARP包。 用tcpdump抓取
arp and host 网关IP，看设备是否发出了ARP请求，网关是否回复了。 - 第四步：检查路由表。 执行
ip route show default，确认默认路由指向正确的网关IP和出接口。
注意：有时候ping网关显示“Destination Net Unreachable”，这不是网关本身的问题，而是本地路由表里没有匹配的路由。检查一下是不是默认路由被删了或者被覆盖了。
4.4 知识体系：网络层诊断逻辑
下面这张图梳理了本章三个问题的诊断逻辑，你可以把它当作排查时的路线图。
4.5 综合排查清单
最后，我整理了一份排查清单。遇到网络层问题，按这个顺序过一遍，大部分问题都能定位到。
- 确认IP配置：
ip addr show或ifconfig，检查IP、掩码、网关是否与规划一致。 - 测试同网段通信： ping一个同网段的已知IP，确认二层通信正常。
- 测试网关通信： ping网关IP，确认三层出口可用。
- 检查ARP表： 确认网关的MAC地址已正确解析。
- 检查路由表：
ip route show，确认默认路由存在且指向正确。 - 抓包验证： 如果以上都正常，用tcpdump抓取目标IP的流量，看数据包是否发出、是否有ICMP错误回复。
个人习惯：我每次部署新设备，都会先写一个脚本，自动执行上面这6步，并把结果输出到日志文件。这样出了问题，直接翻日志就能看到当时的网络状态，省去了复现的麻烦。