Network Troubleshooting Methodology - The Systematic Approach

其他语言版本：

网络解决问题的方法:系统性方法

方法为何重要

问题: 一个数据库应用程序是"慢". 网络团队指责服务器团队. 服务器团队指责网络. 同时,用户感到沮丧,时间被浪费在循环调试中.

解决方案: 一种系统,科学的解决问题的方法,它使用证据而不是假设来确定根源.

解决危险问题的代价: 浪费时间,错误的纠正方法掩盖了真正的问题,在团队之间指手划脚,用户体验退化.

导言:适用于联网的科学方法

网络故障排除基本上是科学方法中的一项练习:

观察症状和收集数据
形成假设 关于根源
测试假设 有诊断工具
分析结果 并且确认或拒绝该假设
执行固定 根据确认的根本原因
校验问题已经解决

这篇文章为网络故障排除提供了结构化的框架,可以防止常见的陷阱,如:

确认偏差( 仅寻找支持您初始猜测的证据)
没有诊断的随机变化("喷出和祈祷"方法)
纠正症状而不是根源
循环调试不记录已尝试的

五大关键问题

在进入技术诊断之前回答这五个关键问题缩小你的调查范围

问题1:最近有什么变化?

配置更改吗 ? 新硬件? 软件更新? 地形学改造?

检查更改管理日志
审查最近在配置管理系统中的承诺
问道:"昨日行得否?

↓

问题2:谁受到影响?

一个用户? 一栋楼? 每个人? 只有具体申请?

一个设备: 可能是本地问题(NIC,有线,配置)
一个子网: 网关、 DHCP 或切换发行
每个人: 核心基础设施(ISP)或广泛问题
特定应用程序 : 应用程序服务器、防火墙规则或 DNS

↓

问题3:它是恒定的还是断续的?

总是这样吗? 只在某个时候? 随机事件?

常数 : 硬故障( 电线切割、配置错误、服务下降)
时间: 办公时间、预定过程的拥挤
间歇/随机: 双相错配, 硬件失效, 间断链接

↓

问题4:你能重现它吗?

你能按要求引发问题吗?

对: 更容易诊断(可以测试假设)
没有 : 设置监控/ 博客并等待重现

↓

问题5:另一边看到什么?

检查连接的两端

客户端视角对服务器视角
源码对目的的包抓取
不对称的路线? 发送对接收的不同路径?

OSI模型诊断方法

OSI模型为排除故障提供了一个结构化的框架. 从第1层(物理)向上工作,或从第7层(应用)向下工作,视症状而定.

自下而上的方法(第1层)

何时使用 : 完全失去连通性,没有连通光线或物理层症状

第1层:物理

检查:电缆连接? 打开链接灯? 纤维干净吗?
图标 : show interfaces, (中文(简体) ). ethtool eth0
查找:CRC出错,相撞,后相撞,矮子,巨子

↓

第2层:数据链接

检查:正确的VLAN? 端口启用吗 ? STP封锁?
图标 : show mac address-table, (中文(简体) ). show spanning-tree
查找 : MAC 扇动, STP 地形变化, VLAN 不匹配

↓

第3层:网络

请检查date=中的日期值 (帮助) 。排队表对吗?
图标 : ping, (中文(简体) ). traceroute, (中文(简体) ). show ip route
查找: 缺少路径、错误的下一跳、路径循环

↓

第4层:运输

检查:能否建立 TCP 连接? 防火墙阻塞口?
图标 : telnet host port, (中文(简体) ). netstat -an,包抓取
查找: TCP 重传, 零窗口, RST 包

↓

第5-7层:会话/陈述/应用

检查: DNS 解析? 申请应答? 认证有效吗?
图标 : nslookup, (中文(简体) ). dig, (中文(简体) ). curl -v
查找: DNS 失败,应用程序错误,超时问题

从下到下的方法(第7层)

何时使用 : 存在基本连通性的具体应用问题.

示例 "我可以浏览互联网, 但我不能访问公司SharePoint网站".

从第7层开始( SharePoint 服务正在运行吗 ) ? DNS解析校正IP?),只有在需要时才能下架.

决定树:是1,2还是3层?

使用此快速诊断树来识别哪一层已失败 :

你能按一下本地主机(127.0.0.1)吗?

□没有

问题:操作系统/软件问题

TCP/IP 堆栈无法运行。检查OS服务,重新安装网络驱动程序.

对

你能按自己的IP地址吗?

↓ NO

问题: 第1/2层 - 本地网络接口

NIC 已禁用, 错误的驱动程序, 电缆未插接。检查 : ip link show 或设备管理器

↓ YES

你能打开默认的网关吗?

↓ NO

问题: 第1/2层 - 本地网络

请检查access-date=中的日期值 (帮助) 物理电缆开关端口状态 VLAN任务 ARP表

↓ YES

你能通过 IP 地址调用远程主机吗 ?

↓ NO

问题: 第3层 -- -- 运行

请检查access-date=中的日期值 (帮助) Routing table,防火墙规则,ACLs. 使用 traceroute 查找包到哪里

↓ YES

您能解析 DNS( 搜索主机名) 吗 ?

↓ NO

问题: DNS 配置

检查: DNS 服务器设置, DNS 服务器可用性,防火墙屏蔽端口 53

↓ YES

您能否到达应用程序端口( telnet 主机端口 ) ?

↓ NO

问题:防火墙/港口封锁

请检查access-date=中的日期值 (帮助) 防火墙规则,安全小组,服务监听端口

↓ YES

网络是 OK - 应用程序层问题

问题在于应用程序本身、认证或应用程序配置

隔离技术

当对根源有一个假设时,使用这些隔离技术来确认或拒绝:

1. 系统替换组件

提示 : 一次改变一个变量。如果你把电缆和开关端口都换了, 你就不会知道是哪个修好的了.

用已知好电缆交换补丁电缆
测试不同的开关端口
尝试不同的NIC( 或 USB 网络适配器)
来自不同客户端设备的测试
移动到不同的 VLAN/ 子网

2. 多点包裹捕获

收集源头、中间点和目的地的流量,以确定投放或修改的包:

# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com

# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com

# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue

3. 循环测试

通过测试单个设备内的连通性消除外部变量:

# Test TCP stack without network
ping 127.0.0.1

# Test application listening locally
telnet localhost 80

# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing

4. 已知良好基线比较

对比一个工作系统的配置和行为 :

# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
     <(ssh broken-switch "show run int gi1/0/1")

# Compare routing tables
diff <(ssh router1 "show ip route") \
     <(ssh router2 "show ip route")

解决问题期间的文件

适当的文档可以防止循环调试, 当你多次尝试同样的事物而不意识到的时候.

解决问题模板

Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01

Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds

Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found

Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss

Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.

Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.

Time to Resolution: 25 minutes

为什么文件事项: 没有这个记录,下一次有人看到开关上的CRC错误,他们可能会浪费时间来更换电缆并测试端口,而不是立即检查纤维的清洁性.

现实世界案例研究

案例研究1:"网络缓慢"(实际:TCP窗口耗尽).

症状

数据库应用响应时间从小于100ms退化到5+秒. 应用团队指责"网络延迟".

初步假设( 错误)

网络拥堵
WAN 链接饱和
防火墙瓶颈

诊断过程

平试: RTT = 2ms(优秀,排除了第3层的延迟)
带宽测试( iperf) : 1 Gbps 链接上的950 Mbps( 无拥堵)
包抓取 : 从数据库服务器被披露的 TCP 零窗口包
服务器检查 : 数据库服务器接收缓冲 = 64KB (tiny!)

根原因

数据库服务器OS缓冲器太小,无法用于高频宽×延迟产品. TCP窗口会填满,迫使发送者等待.

决议

# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216

经验教训

不要假设: "慢"并不总是意为"网络延迟". 总是在跳跃到结论之前收集证据(等待时间,包抓行为).

案例研究2:互通互通(实际:双相错相)

Symptom

服务器连接会随机下降,特别是负载下. 有时效果很好,有时完全没有反应。

Initial Assumptions (Wrong)

NIC 失败
坏电缆
切换硬件问题

Diagnostic Process

接口检查 : 服务器 NIC = 1000/Full, 开关端口 = 1000/Half (mismatch!)
错误计数器 : 切换端口发生大规模相撞
后期相撞: 双相错配的指标

Root Cause

自动谈判失败。服务器商谈了"全双","开关"倒回"半双". 碰撞只在双方试图同时传输时在负载下发生.

Resolution

! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
 speed 1000
 duplex full

Lesson Learned

检查两端 : 界面状态显示已谈判的设置。不匹配意味着自动谈判失败。总是对服务器的硬码速度/ 复数。

案例研究3:“无法进入某些网站”(实际上:MTU/PMTUD 黑洞)

Symptom

用户可以浏览一些网站(Google,Yahoo),但不能浏览其他网站(银行网站,公司门户网站). 小型 HTTP 请求奏效, 页面超时。

Initial Assumptions (Wrong)

DNS问题
防火墙封锁特定地点
ISP 路由问题

Diagnostic Process

DNS 分辨率 : 所有场地的工程罚款
平试: 可以拨打"无法到达"网站
小的 HTTP 请求( curl) : 小页的作品
大型下载 : TCP 握手后 Stalls
MTU测试: ping -M do -s 1472 已经成功, ping -M do -s 1473 失败
ICMP 监测: 未收到"需要破碎"(第3版代码4)消息

Root Cause

VPN隧道将MTU减少到了1400个,但防火墙却屏蔽了ICMP"破碎需要"的消息. Path MTU Discovery (PMTUD) 无法工作,创建了MTU黑洞. 装有 DF 位元集的大包被悄悄扔下

Resolution

! Implemented TCP MSS clamping on router
interface Tunnel0
 ip tcp adjust-mss 1360

! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big

Lesson Learned

大小事项 : 如果小请求工作,但大额转移失败,则怀疑MTU/分解问题。使用有 DF 位的 ping来测试路径 MTU.

案例研究4:VoIP质量问题(实际:QoS错位)

Symptom

语音有粗糙的声音断断续续的辍学只在工作时间(9时至5时)进行。

Initial Assumptions (Wrong)

带宽不足
VoIP 服务器超载
ISP 连接质量

Diagnostic Process

带宽测试 : 工作繁忙时段仅连接40%
调查: 标有DSCP EF(46)的语音流量正确
队列检查 : 语音队列只有5%的带宽分配(应为33%)
包抓取 : 拥堵时语音包被丢弃

Root Cause

QoS政策存在,但带宽分配向后:最佳效果获得60%,声音获得5%. 在数据流量增加的工作时间,由于排队过多,语音包被丢掉。

Resolution

! Corrected QoS policy
policy-map WAN-QOS
 class VOICE
  priority percent 33
 class VIDEO
  bandwidth percent 25
 class CRITICAL-DATA
  bandwidth percent 20
 class class-default
  bandwidth percent 22

Lesson Learned

时间问题=能力: 如果问题只发生在繁忙的时段,那就不是困难的失败,而是容量/QoS问题. 检查队列统计, 而不仅仅是总带宽。

症状下的指令参考

症状	层	要运行的命令	寻找什么
无链接光	第1层	`show interfaces ethtool eth0`	状态: 下行, 无载体, 有线缆未插
包损失	第1/2层	`show interfaces show interfaces counters errors`	CRC 错误、矮子、巨子、碰撞、后期碰撞
不能打开网关	第2层	`arp -a show mac address-table show spanning-tree`	没有 ARP 条目, MAC 未学习, STP 屏蔽
无法到达远程子网	第3层	`traceroute show ip route show ip route summary`	缺少路径, 错误的下一跳, 路径循环
连接被拒绝	第4层	`telnet host port netstat -an tcpdump`	服务不听防火墙块 TCP RST
缓慢的性能	第4层+	`ping (RTT) iperf3 tcpdump show interfaces`	高纬度、带宽限制、TCP再传输、零窗口
无法解析主机名	第7层	`nslookup dig cat /etc/resolv.conf`	DNS 服务器无法访问, 错误的 DNS 配置, NXDOMAIN
间断滴出	Layer 1/2	`ping -f (flood) show logging show interfaces`	双相错配, 失败的电缆, STP 重组
有时候有用,不是别人	多个	`Extended ping Packet capture Interface statistics`	负载平衡问题, ECMP 不对称,状态表溢出

何时升级

知道何时升级为销售商TAC或高级工程师. 当 :

你已经用完了你知识库里所有障碍的解决步骤
问题需要访问/许可
问题涉及供应商软件错误或硬件缺陷
业务影响至关重要并具有时间敏感性
多个团队需要合作(应用程序+网络+服务器).

升级前 : 记录你尝试过的一切 TAC的工程师们需要这些信息来避免重复你的步骤. 包括:

完整的症状描述
开始发行的时间
诊断命令运行及其输出
配置备份
包抓取(如果相关)
你已经试过了

建立个人知识库

每一次解决问题都是学习的机会。建立个人知识库:

1. 创建解决问题的杂志

# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md  # Index of all issues

# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation

2. 构建一个命令夹克工作表

按情景组织常用命令,以便在排除故障时快速参考。

3. 记录您的网络

地貌图(第2层和第3层)
IP 地址方案文档
区域局任务
标准配置(平板)
已知良好基线(问题前的界面统计)

常用防盗剂

随机变化而不诊断

在不理解问题的情况下改变配置,往往使事情更糟糕,或者掩盖真正的问题.

假设网络总是有问题

"网络问题"往往是应用程序,服务器,或客户端的问题. 在接受指责之前收集证据

跳过记录您的故障清除步骤

你会浪费时间重复你已经做过的测试或者无法向同事解释你尝试过什么

忽略间歇性问题

间歇性的问题往往是即将失败的预警迹象. 在他们变得危急之前调查他们

解决症状而不是根源

重启一个设备可能会恢复服务,但如果你不知道为什么它需要重启,问题就会再起.

摘要:系统解决问题核对表

开始前

回答五个关键问题(有什么变化? 谁受到影响了? 不停还是断断续续? 可复制吗? 彼等何所见. )
收集初步症状和用户报告
检查最近的更改或维护

问题解决期间

通过OSI层(自下而上或自上而下)有条不紊地工作
测试时修改一个变量
记录每个测试及其结果
使用包抓取来查看实际的交通行为
与已知良好基线相比

在决议通过后

校对:Soup
文件根源和解决
更新您的知识库
如果配置发生变化, 则更新文档
考虑一下: 监测能早点发现吗?

结论

网络故障排除既是科学也是艺术. 该科学正在采用系统的方法,正确使用诊断工具,并理解协议。艺术是了解哪些测试是先根据症状进行的,从经验中识别出规律,并知道何时升级.

通过遵循本条概述的系统性方法——提出正确的问题,通过OSI模式有条不紊地工作,记录你的步骤,从每个问题上学习——你会在解决问题时提高效率,并避免导致浪费时间和错误纠正的常见陷阱。

记住: 目标不仅仅是要恢复服务,而是要理解它为什么失败,这样你才能防止它再次发生.

最后更新:2026年2月2日作者:鲍德9600 技术队