3、网络层故障排查：IP地址冲突、子网掩码配置错误、默认网关丢失、路由表异常

网络层出问题，说白了就是数据包找不到路，或者找错了路。工业环境里，这类故障往往不是一下子全断网，而是“时好时坏”、“这台能通那台不通”，排查起来特别磨人。我个人的习惯是，先看现象，再定方向——是局部冲突，还是全局失联？

下面我把四个最常见的网络层故障拆开来讲。每个我都踩过坑，有些坑现在想起来还觉得冤。

3.1 IP地址冲突：两台设备抢一个身份

IP地址冲突，就是局域网里有两台设备用了同一个IP。交换机不认这个，它只认MAC，但上层应用和网关会乱套。数据包发出去，谁响应算谁的？结果就是两台设备轮流掉线，或者都掉线。

排查步骤：

1. 确认冲突： 在网关或核心交换机上执行 arp -a | grep <可疑IP>，看MAC是否频繁变化。
2. 定位设备： 拔掉疑似冲突设备的网线，再ping这个IP。如果不再通，说明拔对了。然后顺着交换机端口指示灯找到物理位置。
3. 静态绑定： 在网关或汇聚交换机上做IP+MAC绑定。工业环境我建议直接做，省得以后扯皮。

3.2 子网掩码配置错误：能通不能全通

子网掩码错了，设备能ping通网关，但ping不通同网段的其他设备。或者反过来，能ping通跨网段的服务器，但ping不通隔壁工位的PLC。原因很简单——掩码决定了“网络号”的范围，掩码一错，设备判断对方是否在同一个广播域就错了。

常见错误类型：

排查方法：

• 在设备上执行 ipconfig /all（Windows）或 ifconfig（Linux），核对掩码是否与规划一致。
• 用 ping -b <广播地址> 测试广播域范围。能收到回应的设备，才在同一个子网内。
• 我习惯在规划阶段就画好子网划分表，贴到机柜门上。现场改配置时，直接对照表格，不容易出错。

3.3 默认网关丢失：能内通不能外通

默认网关丢了，设备只能和同网段通信，跨网段一律超时。工业环境里，如果上位机、数据库服务器和PLC不在同一个网段，网关一丢，上位机就收不到数据了。

为什么会丢？

• 设备重启后配置未保存（很多工业设备默认DHCP，但现场没DHCP服务器）。
• 人为误操作，清空了网关字段。
• 网关设备（路由器/防火墙）故障，导致设备认为网关不可达。

排查步骤：

1. 在设备上执行 route print（Windows）或 ip route（Linux），看默认路由是否存在。
2. 如果默认路由缺失，手动添加：route add 0.0.0.0 mask 0.0.0.0 <网关IP>。
3. 检查网关设备本身是否正常工作。ping一下网关IP，如果不通，问题可能在网关设备上。

3.4 路由表异常：数据包走了冤枉路

路由表异常，比前面几个都隐蔽。设备能ping通网关，也能ping通部分远程设备，但就是访问不了特定服务器。或者，数据包绕了一大圈才到目的地，延迟高得离谱。

常见路由表问题：

• 路由缺失： 没有到目标网段的路由条目，数据包被丢弃。
• 路由黑洞： 有路由条目，但下一跳设备不可达，数据包被“吃掉”。
• 路由环路： 两个路由器互相指向对方，数据包来回跳，直到TTL耗尽。
• 静态路由错误： 下一跳IP写错，或者出接口配错。

排查工具：

• tracert（Windows）或 traceroute（Linux）：看数据包经过的每一跳。如果某跳之后没反应，问题就在那附近。
• show ip route（交换机/路由器）：查看路由表条目，确认是否有目标网段的路由。
• ping -R（部分设备支持）：记录路由选项，看回包路径。

3.5 网络层故障排查流程图

下面这张图，是我自己总结的排查思路。遇到网络层故障，按这个流程走一遍，基本能定位到根因。

3.6 实战排查清单

最后，我整理了一份快速排查清单。现场遇到网络层故障，按这个顺序来，效率最高。