思科交换机排障命令手册：关键时刻救命命令

网络故障发生的那一刻，能记住几条靠谱的排障命令，往往比翻手册快得多。这篇文章汇总了思科交换机排障的实战命令手册：从show version、show module、show processes cpu等基础系统诊断开始，到接口与链路诊断、二层交换排障、三层路由与转发、QoS性能与丢包分析、DHCP安全防护，再到多播与堆叠监控，覆盖了网络工程师日常排障的绝大多数场景，每条命令都配有超简解释，建议收藏备用。

基础系统诊断

接口与链路诊断

接口类命令是排障的重中之重：show interface status查看接口状态，show interface查看详细计数（CRC错误、input errors、output drops），show interfaces trunk查看trunk放行情况，show etherchannel summary查看端口通道状态，show logging | include按关键字过滤日志。

二层交换与三层路由排障

二层：show mac address-table查看MAC表，show spanning-tree查看生成树状态，show vlan查看VLAN。三层：show ip route查看路由表，show ip arp查看ARP表，show ip interface brief查看接口IP。定位转发问题时按"接口-二层-MAC-ARP-路由"的顺序逐层检查。

性能与QoS丢包分析

show policy-map interface              # QoS队列/丢包，VoIP优先诊断
show platform hardware qfp active statistics drop   # 硬件丢包统计
show mls qos interface                  # QoS接口映射
show queueing interface                 # 队列深度/阈值，拥塞优化
show netflow                            # NetFlow流量统计，异常流捕获

安全与DHCP排障

show ip dhcp snooping                  # DHCP绑定/端口，地址冲突隔离
show ip dhcp binding                   # DHCP表详情，防伪服务器
show ip verify source                  # IP源守卫，ARP欺骗检查
show aaa servers                       # AAA认证服务器，登录失败诊断
show storm-control                     # 风暴控制阈值，广播抑制调整

监控、多播与堆叠

show ip igmp groups                    # IGMP组/端口，多播加入验证
show ip pim neighbor                   # PIM邻居，多播路由状态
show switch                             # 堆叠成员/角色，链路故障定位
show stack-ports                        # 堆叠端口状态，冗余切换诊断
show system uptime                      # 运行时间/重启原因，稳定性基线
show snmp                               # SNMP配置/社区，监控告警验证

掌握这些命令，关键时刻就能快速缩小故障范围，把问题定位从"猜"变成"查"。

排障前的三条纪律

命令背得再熟，也架不住乱敲。真正高效的排障都遵守同样的三条纪律：先确认现象，再看数据，最后才改配置。任何一次改动之前，先执行 show tech-support 存档并记录当前时间，这样即使改错也能对比前后差异；打开 terminal length 0 避免输出被分页截断；用 show clock detail 确认设备时间与日志时间是否一致，否则跨设备对齐事件时间会非常痛苦。

show tech-support | redirect flash:tech-baseline.txt   # 改动前存档基线
terminal length 0                                      # 关闭分页，完整输出
show clock detail                                      # 时间/时区/NTP同步状态
show logging | include %LINK-3-UPDOWN                  # 只看接口起落的日志
show inventory                                         # 序列号与硬件清单，报障用

还有一条老工程师的经验：改之前先想清楚怎么回退。绝大多数现场事故不是故障本身，而是排障过程中的二次操作。备份配置用 copy running-config flash:backup.cfg 一分钟，恢复时能省一小时。

分层定位法：把问题关进一个盒子

Cisco 交换机的排障顺序基本固定：物理层 → 接口层 → 二层 → 三层 → 应用层。每跨过一层，可能的故障范围就缩小一半。下面这张表给出了每一层最该先看的那条命令。

关键技巧是“看计数是否增长”而不是“看计数是否为零”：接口有几个 CRC 错误并不可怕，可怕的是它在持续增长。执行两次同样的 show interfaces counters errors、中间间隔 30 秒做差，比单次快照有价值得多。同理，show processes cpu sorted 5sec 看的是最近 5 秒的瞬时占用，静态快照往往什么都看不出来。

命令输出怎么读：三个真实片段

会敲命令只是入门，会读输出才是本事。下面三段输出是现场最常遇到的形态。

Switch# show interfaces GigabitEthernet1/0/24
GigabitEthernet1/0/24 is up, line protocol is down (notconnect)
  Hardware is Gigabit Ethernet, address is 0011.2233.4455
     1478 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 output errors, 0 collisions, 2 interface resets

up/down 且括号里是 notconnect，说明本端电气层活着但对端没有信号——优先查对端设备是否开机、网线水晶头、光模块方向是否反了。line protocol is down (err-disabled) 则是被保护机制关掉了，要配合 show interfaces status err-disabled 找原因。

Switch# show interfaces counters errors
Port        Align-Err    FCS-Err   Xmit-Err    Rcv-Err  UnderSize  OutDiscards
Gi1/0/23            0       4821          0       4821          0            0
Fa0/12              0          0          0          0          0         1342

FCS-Err 持续增长属于链路质量问题：劣质光模块、脏污的跳线端面、超长的铜缆或双工不匹配都会造成。OutDiscards 则是出口拥塞，方向完全不同——前者换线换模块，后者要动 QoS 或扩容。详细排查思路见本站 Cisco IOS-XR 接口 CRC 错误排障。

Switch# show processes cpu sorted 5sec
CPU utilization for five seconds: 92%/0%; one minute: 88%; five minutes: 61%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
  78    12844120   9812233       1308  41.2%  39.8%  27.1%   0 ARP Input
 145     2219880    402113        552  22.7%  18.4%  11.3%   0 IP Input

92%/0% 里第二个数字是中断层占用，ARP Input 冲到 40% 通常意味着二层环路或某台设备在做 IP 扫描。CPU 类问题可以接着看 Cisco 交换机 CPU 占用过高排查：从 show processes 到 CoPP。

实战场景一：接口反复 up/down

接口每几秒翻转一次是接入层最常见的故障，通常有三类原因：物理层劣化、对端设备问题、以及生成树/UDLD 的保护性关闭。

show interfaces GigabitEthernet1/0/20 | include (up|down|resets|Last)
show interfaces counters errors | include Gi1/0/20
show logging | include GigabitEthernet1/0/20
show udld GigabitEthernet1/0/20
show spanning-tree detail | include Gi1/0/20

如果日志里出现 %PM-4-ERR_DISABLE，根据原因字段处理：psecure-violation 是端口安全触发，bpduguard 是收到了 BPDU，udld 是单向链路检测。用 shutdown / no shutdown 恢复后还要找到根因，否则十分钟后它会再次关闭。UDLD 的两种模式差别与配置见 Cisco UDLD 配置：Normal 与 Aggressive 模式。

实战场景二：某个 VLAN 内主机互相 ping 不通

先确认故障边界：同一个 VLAN、同一个交换机、还是跨设备。然后在接入交换机上按下面的顺序一条条过。

show vlan id 30                          # VLAN 是否存在、端口是否属于它
show interfaces GigabitEthernet1/0/5 switchport   # 端口模式与 VLAN 归属
show mac address-table vlan 30           # MAC 是否学到
show interfaces trunk                    # 上行是否为 trunk 且放行 VLAN 30
show spanning-tree vlan 30               # 是否被 STP 阻塞
show ip arp | include 30                 # 三层网关的 ARP 是否正常

实战中排名第一的原因是上行链路漏放行 VLAN，第二是接入端口被误配成 trunk，第三是STP 阻塞。逐一核对 show interfaces trunk 里的 Vlans allowed and active 一行，比凭记忆猜快得多。

实战场景三：二层环路与广播风暴

现象是全网变慢、CPU 飙高、show interfaces 里 output rate 拉满。定位口诀是看 MAC 漂移、看广播速率、看未知单播。

show mac address-table | include DYNAMIC        # 同一 MAC 在不同端口跳变即环路
show interfaces | include (rate|broadcast)      # 找广播包速率异常的端口
show controllers utilization                    # 端口利用率，排除正常大流量
show spanning-tree inconsistentports            # BPDU 保护/根保护导致的阻塞
show storm-control                              # 风暴控制阈值是否生效

临时止血可以 shutdown 可疑端口，长期方案是接入层统一开启 spanning-tree portfast + bpduguard default 与 storm-control broadcast level 5。另外建议同时检查 show vlan 与 show ip dhcp snooping binding，私接路由器往往同时带来环路和伪造 DHCP。

一次标准排障的七步流程

1. 收集现象：谁受影响、什么时候开始、能不能复现、之前有没有变更。
2. 确定边界：是单端口、单设备、单 VLAN，还是整个园区。
3. 建立基线：show tech-support 存档，记录时间与版本。
4. 分层定位：物理 → 接口 → 二层 → 三层 → 应用，逐层排除。
5. 提出假设并验证：一次只改一个变量，改动前记录回退方法。
6. 恢复业务：优先用回退或临时绕行方案恢复，再慢慢查根因。
7. 归档复盘：把命令输出、时间线、根因和长效措施写进工单，形成可复用的经验。

第 4 步和第 5 步是分水岭：新手习惯直接跳到第 5 步（改配置试试），这也是排障过程本身变成新故障的主要原因。

常用排障命令速查表

常见误区

• 把警告当故障：show processes cpu 里的 5 分钟均值比 5 秒值更能说明问题，瞬时峰值是正常的。
• 忽略 L2 而直奔 L3：三层不通的原因里，二层问题占了很大比例，先看 MAC 表再查路由。
• 重启万能论：重启会清掉所有计数和日志，等于消灭证据；确实无法远程登录时再考虑。
• 不做对比：和同型号同版本同业务的邻机对比 show interfaces、show processes cpu，差异点往往就是答案。
• 只看本端：链路类问题一定要两端同时看，单向故障（一个方向通一个方向不通）在光链路和双工不匹配上非常常见。

相关阅读

• Cisco VLAN Config and Verification: Repeatable Workflow
• Cisco BGP Troubleshooting: Common Issues and Fixes

原文链接：https://www.jb51.net/network/1006683.html