3. IOS-XE系统级诊断命令与日志分析
当接口状态、路由邻居、ACL 命中计数这些“局部证据”都正常，而业务仍然时断时续时，问题往往已经下沉到 IOS-XE 的控制平面或数据平面内部。此时继续在接口配置里打转收益很低，需要切换到系统级视角：用 show tech-support 抓取完整快照，用 show platform 观察硬件与转发引擎状态，用 show processes cpu/memory 判断控制平面是否被压垮，再结合日志分级与 syslog 时间线把零散现象串成因果链。本节围绕这四类手段展开，目标是让读者能独立完成一次系统级异常的定位。
一、show tech-support：先固化现场，再离线分析
show tech-support 不是一条“查看命令”，而是一次诊断数据采集动作。它会顺序执行数百条 show 命令，把接口、路由、平台、进程、日志、内存等输出汇总成一份大文本。它的价值在于时间一致性：所有输出来自同一时刻，避免了分多次敲命令时状态已经漂移的问题。
实际排障中不建议直接在终端刷屏，因为输出量常在数万行以上，滚动过程中容易丢关键段。更稳妥的做法是重定向到文件或闪存：
Terminal# show tech-support | redirect flash:tech_20240612.txt
Terminal# show tech-support routing | redirect flash:tech_routing.txt
Terminal# dir flash: | include tech_IOS-XE 还支持按模块裁剪，例如 show tech-support platform、show tech-support memory，在只怀疑某一子系统时能显著缩短采集时间。采集完成后应尽快导出，因为 flash 空间有限，且设备重启会丢失现场。分析时按“平台 → 进程 → 日志 → 接口/协议”的顺序阅读，先确认硬件与转发是否健康，再看控制平面负载，最后回到具体协议。
show version 中的 uptime），后续把日志时间戳与采集时刻对齐，是判断“异常发生在采集前多久”的关键参照。二、show platform：看清硬件与转发引擎的真实状态
show platform 面向的是“盒子内部”。在 Catalyst 9000 系列上，常用派生命令包括：
show platform software status control-processor：查看控制处理器负载与内存概况；show platform hardware fed switch active fwd-asic resource utilization：查看转发 ASIC 的 TCAM、表项等资源占用；show platform software fed switch active ifm mappings：确认接口与转发引擎的映射关系；show platform resources：汇总 CPU、内存、句柄等平台级资源。
判断要点是“资源是否接近上限”。例如 TCAM 利用率长期高于 90%，新增 ACL 或路由策略可能静默失败；某个 ASIC 的丢包计数持续增长，则说明问题可能出在硬件转发路径而非控制平面。这些信息在接口层是看不到的，必须靠 platform 命令暴露。
三、show processes cpu/memory：控制平面是否被压垮
控制平面过载是“业务抖动但接口不 down”的典型根因。核心命令是：
Terminal# show processes cpu sorted 5sec
Terminal# show processes cpu history
Terminal# show processes memory sorted
Terminal# show processes memory platform sortedsorted 5sec 按最近 5 秒 CPU 占用排序，能快速锁定突发占用进程；cpu history 用字符柱状图展示过去 60 秒、60 分钟、72 小时的趋势，用于区分“瞬时尖峰”和“持续高位”。经验上，控制平面 CPU 持续超过 70%～80% 就应警惕，若某个进程长期占据首位，需结合其功能判断：路由协议进程高可能意味着拓扑震荡，SNMP 或日志进程高可能意味着轮询过频或日志风暴。
内存方面要同时看“已用总量”和“增长趋势”。单次 show processes memory sorted 只能看到当前占用，真正有价值的是间隔采样对比：
Terminal# show processes memory sorted | include Processor
Terminal# show processes memory sorted | include IOSD若某进程内存每隔几分钟稳定增长且不回落，属于疑似泄漏；若内存总量接近平台上限并伴随分配失败日志，则可能触发进程重启甚至整机异常。此时应结合 show memory statistics 与平台内存告警日志一起判断。
四、日志分级与 syslog 分析：把时间线读成因果链
IOS-XE 日志按严重程度分为 0～7 级：0 emergency、1 alert、2 critical、3 error、4 warning、5 notification、6 informational、7 debugging。默认记录 0～6 级，debugging 需显式开启。级别数字越小越严重，因此排障时优先关注 0～3 级，但 5 级 notification 往往包含接口 up/down、邻居建立等关键状态变化，不能忽略。
常用配置与查看方式：
Terminal(config)# logging buffered 16384 informational
Terminal(config)# logging host 10.10.20.50
Terminal(config)# logging trap informational
Terminal(config)# service timestamps log datetime msec localtime show-timezone
Terminal# show logging | include %LINK|%ROUTING|%PLATFORM开启毫秒级时间戳是分析的前提，否则同一秒内的多条事件无法排序。分析时遵循“找首个异常事件”的原则：从业务报障时刻向前回溯，定位第一条非正常日志，它通常最接近根因；其后的 CPU 尖峰、邻居震荡、进程重启多是连锁反应。例如接口物理抖动会先产生 %LINK-3-UPDOWN，随后触发路由重算与 CPU 上升，若只盯着 CPU 就会误判方向。
logging rate-limit 或调整该模块日志级别抑制，再继续排障，否则采集与分析都会被噪声淹没。五、一次完整的系统级定位示例
假设某 Catalyst 9000 上业务间歇性丢包，接口无 down 记录。按以下顺序推进：
- 执行
show tech-support | redirect flash:tech_a.txt固化现场，同时记录当前时间； - 查看
show processes cpu history，若发现周期性尖峰，记录尖峰间隔； - 用
show processes cpu sorted 5sec确认尖峰时占用最高的进程； - 查看
show platform resources与 ASIC 资源利用率，排除硬件转发瓶颈； - 在
show logging中按时间戳定位尖峰前后的 0～5 级日志，寻找首个异常事件； - 若日志显示某协议邻居反复重建，回到协议层用
show ip ospf neighbor等命令验证，形成闭环。
整个过程的关键不是命令数量，而是分层判读：平台层回答“硬件是否健康”，进程层回答“控制平面是否过载”，日志层回答“谁先动的手”。三者交叉验证后，结论才可靠。若只凭单一命令下判断，很容易把连锁反应中的“结果”当成“原因”，导致优化方向错误。