📚 课程目录第3章网络故障分类

3. 网络故障分类：物理层、数据链路层、网络层、传输层、应用层故障的典型表现

TCP/IP网络故障排查的第一步，不是急着抓包或ping，而是先回答一个根本问题：故障发生在哪一层？网络通信是一个分层协作的过程，每一层都有明确的职责边界。当故障发生时，不同层的异常会呈现出截然不同的外在表现。如果能在排查初期就根据症状快速定位到对应层次，就能大幅缩小排查范围，避免在错误的方向上浪费时间。

本章将按照TCP/IP五层模型（物理层、数据链路层、网络层、传输层、应用层）逐一剖析各层故障的典型表现、常见原因和判别方法。需要特别强调的是：实际故障往往是跨层的，例如光纤被挖断（物理层）会导致路由协议邻居震荡（网络层），最终表现为应用超时（应用层）。因此，掌握各层故障的“指纹特征”，是建立分层排查思维的基础。

3.1 物理层故障：一切问题的根源

物理层负责比特流的透明传输，是所有上层通信的物理基础。物理层故障的特征是“链路起不来”或“链路不稳定”，其表现往往最直接，但也最容易被忽视。

典型表现清单：

接口Down：路由器/交换机端口状态显示administratively down或notconnect，链路指示灯不亮或为红色/橙色。
大量CRC错误：接口计数器中input errors、CRC errors持续增长，通常由线缆质量差、接头氧化或电磁干扰引起。
间歇性断连：链路时而Up时而Down，常见于光纤弯曲半径过小、RJ45接头接触不良或光模块老化。
信号衰减：光模块接收功率低于阈值（如Rx Power < -25dBm），导致误码率升高。

物理层故障的判别方法非常直接：使用display interface（华为）或show interface（Cisco）查看端口状态和错误计数。如果发现物理层Down，优先检查线缆连接、光模块和两端设备供电。

# 以Cisco为例，物理层故障时的典型输出
Router# show interface GigabitEthernet0/0
GigabitEthernet0/0 is down, line protocol is down   <-- 物理层Down
  Hardware is Giga Ethernet, address is 0011.2233.4455
  MTU 1500 bytes, BW 1000000 Kbit/sec
  ...
  Input errors: 1523, CRC errors: 1523, Frame: 0, Overrun: 0
  Last input never, output never, output hang never

3.2 数据链路层故障：通信的“最后一公里”

数据链路层负责在相邻节点之间可靠地传输帧。该层故障的典型特征是“物理层Up，但协议层Down”，或者二层转发异常。与物理层不同，数据链路层故障往往更隐蔽，需要借助协议状态和MAC地址表来诊断。

故障现象	可能原因	判别命令/方法
接口Up但line protocol Down	封装不匹配（如HDLC vs PPP）、Keepalive未收到	`show interface` 查看协议状态
二层环路导致广播风暴	STP未启用或配置错误，形成环路	`show spanning-tree`，CPU占用率飙升
MAC地址漂移	两台交换机同时学习到同一MAC，通常由环路或非法设备接入	`show mac address-table` 观察端口变化
VLAN不匹配	Trunk链路允许的VLAN列表不一致，或Access端口VLAN配置错误	`show vlan`、`show interfaces trunk`

常见误区：很多工程师看到接口物理状态Up就认为二层没问题，忽略了line protocol状态。实际上，line protocol Down通常意味着数据链路层的封装协商失败或Keepalive机制检测到对端不可达。此时应重点检查两端接口的封装类型是否一致（如一方是PPP另一方是HDLC），以及二层Keepalive配置是否匹配。

3.3 网络层故障：路由与寻址的迷宫

网络层故障是日常运维中最常遇到的一类，其核心特征是“接口Up、协议Up，但数据包无法到达目的地”。网络层故障的排查需要系统性地检查IP地址规划、路由表、ARP缓存等要素。

网络层故障的判别逻辑遵循一个清晰的路径：

检查本机IP配置：确认IP地址、子网掩码、网关是否正确。使用ipconfig（Windows）或ifconfig/ip addr（Linux）。
验证直连连通性：先ping网关，再ping远端地址。如果网关不通，问题在本机到网关的二层/三层链路；如果网关通而远端不通，问题在路由路径上。
检查路由表：使用show ip route（Cisco）或ip route（Linux）确认是否存在到达目标网段的路由条目，以及下一跳是否正确。
验证ARP解析：使用show arp或arp -a检查网关MAC地址是否被正确解析。ARP表项不完整或错误会导致“能ping通网关IP但无法上网”的怪现象。

# Linux下网络层故障排查示例
$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
    inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0

$ ip route show
default via 192.168.1.1 dev eth0    <-- 默认路由存在
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100

$ ping -c 3 192.168.1.1    <-- 网关可达
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.5 ms

$ ping -c 3 8.8.8.8    <-- 公网不可达，问题在出口路由或NAT

3.4 传输层故障：端口与连接的隐形杀手

传输层故障的特征是“网络层通，但应用连不上”。TCP/UDP端口的状态、连接建立过程、流量控制机制是排查的核心。传输层故障往往表现为连接超时、连接被拒绝或连接建立后立即断开。

典型传输层故障场景：

TCP连接超时：客户端执行telnet server_ip 8080无响应，最终超时。可能原因：防火墙丢弃SYN包、服务器负载过高、半连接队列溢出。
TCP连接被拒绝（RST）：服务器主动返回RST标志。可能原因：端口未监听、iptables/ACL明确拒绝、应用程序崩溃后端口释放。
TCP三次握手延迟：SYN-ACK响应慢，可能由服务器accept队列满或网络路径MTU问题导致。
UDP丢包严重：网络层正常但应用层数据不完整，常见于视频会议、DNS查询等UDP应用。

传输层排查的核心工具是netstat、ss和telnet。使用ss -tunap可以快速查看本机所有TCP/UDP端口的监听状态和连接状态。当发现大量TIME_WAIT或SYN_RECV状态的连接时，往往预示着传输层异常。

# 查看TCP连接状态统计
$ ss -s
Total: 256 (kernel 312)
TCP:   42 (estab 8, closed 20, orphaned 0, synrecv 0, timewait 14)

# 查看特定端口的监听状态
$ ss -tlnp | grep 8080
LISTEN   0    128    0.0.0.0:8080    0.0.0.0:*    users:(("java",pid=1234,fd=13))

3.5 应用层故障：表象背后的多层博弈

应用层故障是用户最容易感知的故障类型，但也是最容易误判的层次。应用层故障的典型特征是“网络连通性完全正常，但应用功能异常”。例如：浏览器能打开百度，但无法打开公司内部OA系统；微信能收发消息，但无法发送图片。

应用层故障的排查需要区分三种情况：

应用本身故障：代码Bug、数据库连接池耗尽、中间件线程阻塞。此时应查看应用日志，如tail -f /var/log/app/error.log。
协议交互故障：HTTP状态码异常（如500、502、503）、SSL/TLS握手失败、DNS解析错误。使用curl -v查看详细交互过程。
依赖服务故障：应用依赖的数据库、缓存、认证服务不可用。例如Nginx返回502 Bad Gateway，通常意味着后端Tomcat已宕机。

实战技巧：当应用层出现故障时，不要急于登录服务器查看代码。先用curl -v或浏览器开发者工具（F12）观察HTTP请求的完整链路——DNS解析耗时、TCP连接耗时、TLS握手耗时、首字节时间。这些数据能帮你快速判断问题出在DNS、网络、Web服务器还是应用代码。例如，如果DNS解析耗时超过1秒，优先排查DNS服务器；如果TTFB（首字节时间）很长，则问题大概率在后端应用。

3.6 分层排查复盘：一个真实案例

某公司员工反馈无法访问部署在数据中心的ERP系统，但可以正常访问互联网。以下是分层排查的完整过程：

排查步骤	操作命令	结果分析	结论
1. 物理层检查	`show interface`	本机网卡状态Up，无CRC错误	物理层正常
2. 数据链路层检查	`show vlan`	接入交换机VLAN 10正常，Trunk允许列表包含VLAN 10	二层正常
3. 网络层检查	`ping 10.1.1.1`（网关） `ping 10.2.1.10`（ERP服务器）	网关通，ERP服务器不通；`traceroute`显示在核心路由器第3跳后无响应	网络层路由存在问题
4. 传输层检查	`telnet 10.2.1.10 443`	连接超时	传输层不可达
5. 最终定位	登录核心路由器查看路由表	发现到10.2.1.0/24网段的路由下一跳指向了已宕机的旧防火墙	路由指向错误，修正下一跳后恢复

重要复盘：本次故障的根因是网络层路由配置错误，但排查过程中最容易误导人的是“能上互联网”这一现象。实际上，互联网流量走的是默认路由（指向另一台出口设备），而ERP系统的流量走的是静态路由（指向已宕机的防火墙）。这提醒我们：“部分网络通”不等于“网络层正常”，必须针对目标地址做完整的连通性测试。

分层故障排查的核心价值在于：它提供了一条结构化的思维路径，避免在故障发生时东一榔头西一棒子。当遇到任何网络问题时，建议按照“物理层→数据链路层→网络层→传输层→应用层”的顺序逐层排查，每层使用对应的命令和工具验证，直到找到故障根源。这种系统化的方法，远比凭经验猜测要高效得多。