外观
面对毫无头绪的复杂网络断网，高手如何像侦探破案一样层层抽丝剥茧？
在很多初学者眼里，网络故障似乎充满了“神秘学”： 一会儿觉得是网线接触不良，一会儿怀疑是防火墙策略挡了，一会儿又怀疑是 DNS 解析挂了，在完全不同的层级之间毫无章法地胡乱修改配置。 结果往往是：旧问题不但没查出来，反而因为胡乱改配置引入了三四个全新的网络故障！
优秀的网络工程师与医学专家极其相似——拥有极其严密、不可动摇的 “临床系统化排查方法论”。
学完本课后，你将能够：
- 精通 三大经典排障方法论：自底向上法（Bottom-Up）、自顶向下法（Top-Down）与对分查找法（Divide-and-Conquer） 的适用场景。
- 完整推演 自底向上从物理层到应用层的五步排查标准作业程序（SOP）。
- 识别 ARP 表项异常（如 Incomplete）背后的二层/物理层致命阻断根因。
- 形成 “提出假设
收集证据（抓包/命令） 验证假设 闭环解决”的职业工程师排障素养。
1. 三大经典网络排障方法论对比
在排查故障时，选择合适的思维模型能够将解决时间从数小时骤降至数分钟：
| 排障方法论 | 排查次序与核心逻辑 | 最佳适用场景 | 华为大赛考点 |
|---|---|---|---|
| 自底向上法 (Bottom-Up) | 从物理层（L1）逐层向上推进至应用层（L7）。 底层不稳，绝不上移！确保线缆和端口通畅后才查二层/三层。 | 新机房上架、新工程割接、搬迁施工或大面积整网断网时。 | 必须先确认物理层 UP！ |
| 自顶向下法 (Top-Down) | 从应用层（L7）向下回溯到物理层（L1）。 先查应用日志、DNS 解析和 HTTP 状态码，确认不是软件报错再往下查。 | 仅某个特定应用异常（如只有百度能开，某个特定网站打不开；或是出现 HTTP 502/404 明确报错）。 | 快速排除端侧软件配置失误。 |
| 对分查找法 (Divide-and-Conquer) | 在网络通信链路的中央中介节点（如核心交换机/网关）切一刀，先 ping 中间节点。若通则排查后半段，若不通则排查前半段。 | 跨越多个机房、路由器跳数较多的复杂广域网长路径排查。 | 效率极高，步步二分减半排查范围。 |
2. 自底向上（Bottom-Up）五步实战标准作业流
第一步：物理层（Layer 1）——见光不死
- 看灯：网卡和交换机端口指示灯是否亮起？常亮还是闪烁？
- 看线：双绞线水晶头是否卡紧？光纤收发光功率是否在正常门限内（使用
display transceiver查看 Rx Power 是否过低）？ - 协商状态：速率（100M/1000M）与双工模式（Full/Half）是否两端匹配？CRC 校验错误是否一直在飙升？
第二步：数据链路层（Layer 2）——寻址与隔离
- VLAN 审查：接口 Access/Trunk 配置是否正确？Trunk 是否遗漏了
port trunk allow-pass vlan？ - STP 状态：生成树协议是否把当前端口错误判定位 Blocking 阻塞状态？
- ARP 真实性：
- 执行
display arp或arp -a； - 关键警示：如果网关 IP 对应的 MAC 显示为
Incomplete，代表发了 ARP 广播根本没人理，二层通信完全阻断，绝不能跳去查三层路由！
- 执行
第三步：网络层（Layer 3）——路由与下一跳
- 本机三要素：IP 地址、子网掩码、默认网关是否在同一个子网？
- 路由表完整性：
- 核心交换机/路由器上是否存在到达目标网段的路由？
- 最长前缀匹配（LPM） 选中的下一跳 IP 是否可达？
- 动态路由协议（OSPF/IS-IS/BGP）的邻居关系是否稳定处于
Full或Established？
第四步：传输层（Layer 4）——端口与握手
- 端口状态：目标服务器端程序是否在监听目标端口（
ss -tulnp）？ - 三次握手：Wireshark 抓包看
SYN报文是否收到了SYN+ACK？还是直接被对端回复了RST强行重置？ - MTU 匹配：是否因为链路上封装了 IPsec/VXLAN 导致大包超长被丢？
第五步：应用与安全层（Layer 5~7）——策略与证书
- 防火墙策略：安全区域间的安全策略是否放行了该业务？
- NAT 状态：源 NAT 地址池端口是否已经耗尽？NAT Server 映射端口是否正确？
- 域名与证书：DNS 能否将域名正确解析为 IP？HTTPS 的 TLS 数字证书是否已过期？
3. 课堂小结与真题实战
- 网络排障三大方法论：自底向上适合新环境与全断故障；自顶向下适合单一软件报错；对分法适合长路径二分定位。
- 自底向上严守铁律：物理层不通，绝不上移诊断！
- ARP 表项如果显示
Incomplete，代表二层 ARP 解析超时失败，应在局域网链路层与物理层深入排查。