4、网络层故障诊断：IP地址冲突与子网掩码错误、路由协议故障（OSPF/BGP）、NAT与ACL配置问题、MTU与分片问题
网络层，说白了就是整个通信系统的「交通枢纽」。数据包能不能顺利到达目的地，全看这一层给不给力。我干通信这些年，碰到的网络层故障少说也有上百起，其中IP地址冲突、子网掩码配错、路由协议「抽风」、NAT/ACL配置翻车，还有MTU分片问题，这五类占了八成以上。今天咱们就一个一个捋清楚。
核心观点：网络层故障诊断，本质上就是「查路由、验地址、看策略」。别被花里胡哨的现象迷惑，抓住这三个点，问题就解决了一半。
4.1 IP地址冲突与子网掩码错误
IP地址冲突，这玩意儿太常见了。我记得有一次去某园区网排查，用户说「上不了网，但能ping通网关」。我过去一看，好家伙，两台电脑的IP一模一样。为什么会这样？说白了就是DHCP地址池不够用，或者有人手动配了静态IP。
诊断方法：
- Windows下用
arp -a查看MAC地址对应关系，如果同一个IP出现两个不同MAC，基本就是冲突了。 - Linux下用
ip neigh或者arping来验证。 - 我个人的习惯是，先抓个包看看有没有ARP应答异常。冲突时你会看到连续的ARP请求，但应答的MAC地址来回变。
避坑指南：我曾经遇到过一种情况——ping网关偶尔通偶尔不通。查了半天，发现是有人把打印机的IP配成了网关地址。嗯，这种「狸猫换太子」的故障，光靠ping是看不出来的，必须用arp表对比。
子网掩码错误，这问题更隐蔽。你想想看，掩码配错了，设备会认为目标地址不在同一个网段，于是把数据包扔给网关。但网关一看，这包不该找我啊，直接丢弃。结果就是「能ping通网关，但ping不通其他网段」。
我建议你遇到这种情况，先算一下IP和掩码的与运算结果。比如：
IP: 192.168.1.100
掩码: 255.255.255.0 → 网段 192.168.1.0
掩码: 255.255.0.0 → 网段 192.168.0.0
这两个结果不一样，通信肯定出问题。
4.2 路由协议故障：OSPF与BGP
路由协议这块，OSPF和BGP是两大主力。先说OSPF，它最常见的故障就是邻居起不来。
OSPF邻居故障排查：
- 先看
show ip ospf neighbor，如果状态卡在INIT或EXSTART，多半是Hello间隔或Dead间隔不匹配。 - 如果状态卡在2-WAY，说明DR/BDR选举有问题。我遇到过一台路由器优先级配了0，结果死活不参与选举。
- 还有一个坑——区域ID不匹配。两台路由器一个配area 0，一个配area 1，邻居永远起不来。
注意：OSPF的MTU不匹配也会导致邻居卡在EXSTART阶段。我曾经在项目里被这个问题坑了整整一个下午，最后发现是链路两端的MTU差了4个字节。
BGP故障：BGP的问题通常出在TCP连接上。你想想看，BGP是基于TCP的，如果TCP三次握手都完不成，那还谈什么路由交换？
排查步骤：
- 先确认
show ip bgp summary里邻居状态是不是Established。 - 如果不是，检查TCP 179端口是否可达。用telnet或者nc测一下。
- 再看update-source是不是配对了。我见过有人把loopback接口的IP写错了，结果BGP会话一直down。
- 最后检查路由策略——有没有deny掉对方的路由？
个人经验：BGP的next-hop问题也很常见。尤其是跨AS的时候，如果下一跳不可达，路由就不会被安装到路由表里。我建议你养成习惯，配完BGP后一定用 show ip route bgp 确认一下。
4.3 NAT与ACL配置问题
NAT配置问题，说白了就是「地址转换没转对」。最常见的现象是：内网能上网，但外网访问不了内网服务器。
NAT故障排查：
- 先看NAT转换表：
show ip nat translations。如果表里没有记录，说明流量根本没触发NAT。 - 检查ACL是否匹配了正确的源地址。我遇到过有人把ACL写反了，内网地址没匹配上，结果所有流量都走了outside接口。
- 还有一个坑——NAT overload（PAT）的端口耗尽。如果内网用户太多，端口号用完了，新连接就会失败。
ACL配置问题：ACL这东西，写错一个顺序就能让你抓狂。因为ACL是顺序匹配的，一旦匹配就停止检查。
我建议你记住三条原则：
- 精确的规则放在前面，宽泛的规则放在后面。
- 最后一定要加一条deny any，否则默认是permit any。
- 检查ACL时，用
show access-list看匹配计数。如果计数一直为0，说明流量没走到这条规则。
实战案例：我曾经帮一个客户排查「视频会议卡顿」的问题。查了半天，发现是ACL里有一条deny UDP的规则，把视频流的RTP包给拦了。嗯，这种「好心办坏事」的配置，在ACL里太常见了。
4.4 MTU与分片问题
MTU问题，说白了就是「包太大，链路装不下」。以太网默认MTU是1500字节，如果上层协议（比如IP）封装后的包超过这个值，就需要分片。
分片带来的问题：
- 分片会增加CPU开销，降低转发性能。
- 如果某个分片丢了，整个包都要重传。
- 有些防火墙会丢弃分片包，导致通信失败。
诊断方法：
- 用ping命令测试：
ping -l 1472 -f（Windows）或ping -M do -s 1472（Linux）。如果提示「需要分片但设置了DF标志」，说明MTU有问题。 - 我个人的习惯是从1500开始往下减，每次减100，直到ping通为止。这个值就是实际的MTU。
避坑指南：我曾经遇到过VPN隧道里丢包的问题。查了半天，发现是GRE隧道封装后，包大小超过了物理链路的MTU。解决方案是在隧道接口上配置 ip mtu 1400，强制分片。嗯，这种「隧道嵌套」的场景，MTU问题特别容易出。
MTU不匹配的典型场景：
| 场景 | 现象 | 解决方法 |
|---|---|---|
| PPPoE拨号 | 某些网页打不开，但能ping通 | 将MTU改为1492 |
| VPN隧道 | 大文件传输失败 | 隧道接口配置较小的MTU |
| MPLS网络 | ping通但TCP连接慢 | 启用PMTUD（路径MTU发现） |
最后说一句，MTU问题有个特点——它不会让你完全断网，但会让你「时好时坏」。你想想看，小包能通，大包就丢，这种故障最让人头疼。所以排查的时候，一定要用不同大小的包去测试。
总结一下：网络层故障诊断，我的套路是「先看连通性，再看路由表，最后查策略」。IP冲突和掩码错误属于基础问题，路由协议故障需要熟悉邻居状态机，NAT/ACL要关注配置顺序，MTU问题则要善用ping测试。嗯，把这些搞明白了，网络层故障基本难不倒你。
公众号:蓝海资料掘金营，微信deep3321