1. Nexus故障诊断体系总览
在 Nexus 交换机上排查故障，最容易犯的错误是“看到现象就敲命令”。例如接口起不来就反复 shutdown/no shutdown，路由不通就不断改静态路由，却忽略了问题可能出在 vPC 域、FEX 上联、VLAN 数据库或控制平面策略。Nexus 运行的是 NX-OS，它和传统 IOS 在架构、进程模型、配置提交方式上都有明显差异，因此排障必须建立一套与 NX-OS 架构相匹配的体系化方法，而不是零散命令的堆砌。
NX-OS 架构：理解故障的“地层结构”
NX-OS 采用模块化、多进程的架构，可以粗略分为四层。最底层是硬件与转发芯片层，包括线卡、ASIC、FEX、光模块和背板；其上是内核与平台层，负责驱动、传感器、电源风扇管理和 ASIC 初始化；再往上是控制平面，运行 BGP、OSPF、EIGRP、HSRP/VRRP、STP、vPC、LACP 等协议进程；最上层是管理与策略层，包括 CLI、NX-API、SNMP、Syslog、RBAC、CoPP 等。
这个分层非常关键：不同层的故障，观察点和命令完全不同。硬件层看 show environment、show interface transceiver；平台层看 show module、show processes cpu；控制平面看 show ip route、show bgp summary、show vpc；管理策略层看 show logging logfile、show policy-map interface control-plane。如果层次判断错了，命令敲得再多也只是在错误的地层里打转。
诊断工具全景：按“观察对象”分类
Nexus 的诊断工具可以按观察对象分成五类，而不是按命令字母顺序记忆：
- 状态与清单类：
show version、show module、show inventory、show interface status，用于确认“设备现在长什么样”。 - 协议与邻居类：
show ip ospf neighbor、show bgp summary、show vpc brief、show lacp neighbor，用于确认“对端是否还在对话”。 - 转发与路径类：
show ip route、show forwarding route、traceroute、show system internal forwarding，用于确认“报文实际走哪条路”。 - 抓包与追踪类：
ethanalyzer local interface inband、SPAN/ERSPAN、show system internal access-list interface，用于确认“报文到底有没有到、被谁丢了”。 - 日志与事件类：
show logging logfile、show tech-support、show cores、Call Home，用于确认“什么时候发生了什么”。
工具本身没有优劣，关键是先确定观察对象，再选工具。例如“vPC 成员口流量不均”，观察对象是转发路径和哈希结果，就应该用 show port-channel load-balance 和 show vpc consistency-parameters，而不是先去看 BGP 邻居。
故障分层模型与排障流程
把架构分层和工具分类结合起来，就得到 Nexus 的故障分层模型：物理层 → 链路层 → 控制平面 → 转发平面 → 策略与管理平面。排障时自下而上逐层排除，每层都有明确的“通过条件”。
下面这张图展示了分层模型、每层的典型观察对象、常用工具以及层间判断关系，是本章的核心视图：
实际排障时，这个模型可以转化为一个可执行的判断顺序。以“两台 Nexus 之间业务不通”为例：先 show interface status 确认接口 up、VLAN 放通、MTU 一致；再 show ip route 和 show bgp summary 确认路由存在且邻居 Established；然后 show forwarding route 确认 FIB 已下发；最后用 ethanalyzer 或 SPAN 确认报文是否真的到达并转发。任何一层不通过，就停在该层深挖，而不是跳到上层改配置。
copy running-config startup-config 或是否处于 configure terminal 的未提交状态，避免把“未提交”误判为“配置无效”。把体系落到日常：三个习惯
第一，先分层再敲命令。每次排障前用一句话写下“当前怀疑在哪一层”，再选对应工具。第二，保留基线。在业务正常时保存 show tech-support 和关键接口、路由、vPC 状态，故障时才有对比依据。第三，记录时间线。把日志时间、配置变更时间、业务报障时间对齐，很多“莫名其妙”的故障其实是某次变更的延迟效应。
本章建立的“架构分层 + 工具分类 + 分层排障”框架，是后续所有章节的公共底座。无论是 vPC 不一致、FEX 离线、CoPP 丢包还是 BGP 震荡，都可以回到这张分层图上，先定位层，再选工具，最后验证通过条件。