1. 课程导入与故障诊断方法论
复杂网络的故障诊断，难点往往不在“敲命令”，而在于面对一个已经出现业务受损的网络时，能否在有限时间内把问题范围从“整张网”收敛到“某个接口、某条表项、某个参数”。H3C Comware 平台提供了从物理层到应用层的大量观测手段，但工具越多，越需要一套稳定的方法论来约束排查路径，否则很容易在无关方向上反复试探。本课程后续 29 章会围绕具体协议、具体故障场景展开，本章先建立贯穿全课程的整体思路、分层模型、常用工具集与性能优化目标。
一、故障诊断的整体思路：先收敛，再定位，后验证
Comware 网络的故障诊断可以概括为三个动作：收敛范围、定位根因、验证恢复。收敛范围解决“问题出在哪一段”，定位根因解决“为什么这一段不工作”，验证恢复解决“改完之后是否真的好了、有没有引入新问题”。
收敛范围最有效的手段是分段与对比。例如一台终端无法访问服务器，不要一上来就抓包，而是先确认：同网段其他终端是否正常？同终端访问其他服务器是否正常？如果“同网段其他终端正常、只有这一台异常”，问题大概率在终端侧或接入端口；如果“同终端访问其他服务器正常、只有目标服务器异常”，问题大概率在路径或目标侧。这种“换一个变量看结果是否变化”的做法，就是二分法在故障诊断中的直接应用。
定位根因时，要遵循从下往上、从近到远的顺序。物理层与链路层的问题会掩盖上层所有现象，先确认接口 Up/Down、光功率、CRC 错包、双工速率，再去看 IP 可达性、路由表项、ARP/ND 表项，最后才分析 TCP 握手、应用响应。反过来做，很容易被上层超时误导。
二、分层诊断模型
把 OSI 与 TCP/IP 模型映射到 Comware 的实际观测点上，可以得到一张便于操作的诊断分层图。下图给出从物理层到应用层的诊断对象、典型命令与常见故障特征之间的对应关系，它是本课程后续所有章节的公共参照。
这张图的使用方式是：先确定业务受损的表现落在哪一层，再从该层向下逐层确认。例如“ping 通但网页打不开”，表现落在应用层，但根因可能在传输层（端口被 ACL 拦截）或网络层（策略路由把流量引到了错误出口）。因此分层不是只查一层，而是以表现层为起点，向下逐层排除。
三、常用工具与观测手段
Comware 的诊断工具可以按“是否影响转发”分为两类。第一类是非侵入式观测，包括各类 display 命令、日志 display logbuffer、告警 display alarm、接口计数 display counters。这类命令随时可用，是排障的主力。第二类是侵入式观测，主要是 debugging 系列和流镜像、抓包。debug 会消耗 CPU 并可能刷屏，必须在业务低峰期、配合 terminal monitor 与 terminal debugging 使用，并提前用 ACL 限定范围。
除设备自身命令外，还应善用外部手段：从客户端 ping、tracert 判断路径与丢包位置；用 telnet 或 ssh 测试目标端口连通性；在关键链路做端口镜像后用抓包工具分析交互过程。设备侧与终端侧的数据互相印证，才能避免“单侧视角”的误判。
undo debugging all）。在生产网中无过滤地开启 debug，本身就可能成为一次新的故障。四、性能优化目标
故障诊断解决“通不通”，性能优化解决“快不快、稳不稳”。Comware 网络的性能优化通常围绕四个可量化目标展开：
- 时延：关注转发路径跳数、队列调度、是否绕行。可用 ping 的 RTT 与 tracert 逐跳时延定位突增点。
- 丢包率：区分拥塞丢包与错误丢包。前者看队列丢弃计数，后者看接口 CRC、Alignment 错包。
- 吞吐与带宽利用率：通过
display interface的入/出速率与带宽占比判断是否存在瓶颈链路。 - 资源占用：CPU、内存、会话表、ARP 表、MAC 表的容量与增长趋势，决定设备能否长期稳定运行。
优化不是“把参数调到最大”。例如把 ARP 老化时间调得过短会增加广播与表项震荡，调得过长则会导致终端迁移后流量黑洞。合理的做法是先测量基线，再针对瓶颈调整，最后用同样的测量方法验证改善幅度。下表给出一组示例性的观测指标与判断方向，用于建立基线意识。
| 观测对象 | 典型命令 | 关注指标 | 异常方向 |
|---|---|---|---|
| 接口 | display interface | CRC 错包、丢包、速率 | 错包持续增长 |
| CPU | display cpu-usage | 5 秒/1 分钟占用率 | 持续高于 70% |
| 内存 | display memory | 已用比例、剩余量 | 持续下降不回收 |
| 会话表 | display session table | 当前会话数 / 规格 | 接近上限 |
| 路由表 | display ip routing-table | 表项数量、震荡日志 | 频繁增删 |
需要强调的是，表中数值属于示例性参考，实际阈值必须结合设备型号、业务模型与历史基线确定。课程后续章节在讨论具体协议优化时，会给出更贴近场景的参数与判断依据。
五、贯穿全课程的工作习惯
最后给出三条贯穿后续所有章节的习惯。第一，先记录再操作：变更前保存当前配置与关键表项输出，变更后对比差异，这是复盘与回退的基础。第二，一次只改一个变量：同时调整多个参数，即使问题消失也无法确认是哪一项起了作用。第三，用数据说话：判断“是否恢复”要有明确的观测点与前后对比，而不是凭感觉认为“好像好了”。