在网络运维现场，你一定遇到过这样的诡异现象：
SSH/Telnet 登录交换机非常卡、命令输入一顿一顿的，但设备互 Ping 却畅通无阻、不丢包。
看上去像是假卡，
又不是真的网络掉线，
命令敲半天才回显，
但链路却稳定如老狗。
交换机命令卡到爆、敲回车半天不显示，但 ping 却 0% 丢包、延迟正常。
很多人第一反应：
“是不是 CPU 100% 了？”
“是不是内存满了？”
“是不是交换机老化了？”
真相往往比你想象的更隐蔽。
其实背后隐藏着交换机最核心、最容易被误解的知识点：
👉 CPU 控制面 与 交换芯片转发面 的天然分工。
今天我们从底层原理 → 典型原因 → 排查思路 → 实战案例
一次性讲透。
一、先上结论：
你的“命令卡顿”，是 CPU 卡；你的“Ping 正常”，是 ASIC 正常。
交换机不是一块大脑，
而是：
控制面（CPU）做管理
转发面（ASIC 芯片）做数据转发。
二者彼此独立。
这是多数人误解的第一点。
Ping 测的是“数据平面（Data Plane）”
命令执行属于“控制平面（Control Plane）”
两者并不是同一个通道。
Data Plane（数据转发面）：
专门负责包的高速转发 → ASIC 芯片执行 → 确保网络不丢包Control Plane（控制面）：
CLI 命令、SSH、Telnet、Web、协议计算（OSPF/BGP）、日志、管理进程
→ 是 CPU 在执行
所以你看到的现象其实是：
数据面正常 → 转发正常 → ping 不丢包
控制面异常 → CPU 卡顿 → 命令半天不返回
这在多种设备（华为、H3C、Cisco、锐捷、迪普等）都十分常见。
控制面（CPU）
负责的是：
命令行操作
协议计算
管理进程
SSH/Telnet
SNMP
Web 管控
日志
ACL 编译
生成树/OSPF/BGP 协议逻辑
转发面（ASIC）
负责的是：
二三层转发
MAC 学习
ARP
VLAN
ACL 硬件匹配
Multicast
QoS
Line-rate 线速转发
Ping 不丢包 = 数据面（ASIC）全程 OK
命令卡 = 控制面（CPU）被压死了
这是区别一切现象的总钥匙。
二、为什么 CPU 会卡成 PPT？
下面逐条告诉你现实最常见的情况。
1. 某接口被刷广播/多播/未知单播风暴
大量广播 / 多播风暴为什么导致 CLI 卡？
因为：
广播帧需要 CPU 参与处理（如 ARP Request）
当某个端口被“风暴”淹没
CPU 会被大量异常帧打爆
导致命令操作非常卡
但——
数据转发面（ASIC）的单播转发仍然正常，
所以 Ping 一点问题没有。
📌 典型表现：
CPU 90%–100%
命令敲一个字要等一秒
但 ping 内网设备：0% 丢包
这类故障占比高达 40% 以上。
2. STP / RSTP / MSTP 拓扑不停震荡
生成树震荡会不断触发：
MAC 刷新
端口 up/down
大量协议事件
大量 BPDU 处理
链路不断加入/退出拓扑
所有这些都要 CPU 处理。
结果是：
SSH 登录卡
执行命令卡
show 命令卡
但只要数据平面稳定，
Ping 很可能依旧正常。
3. ARP 攻击 / ARP 表抖动
ARP 攻击会带来大量：
ARP Request
ARP Reply
GARP
ARP 冲突
ARP 解析属于 CPU 行为，而不是 ASIC。
CPU 一旦爆炸 → CLI 卡到怀疑人生。
但数据面依旧凭已有 FIB 表项高速转发，
所以 Ping 能走硬件路径，依旧通畅。
4. 管控协议被打满（SSH/Telnet/SNMP 被刷）
攻击者可能对交换机：
扫 SSH
扫 Telnet
扫 SNMP
尝试暴力破解
大量连接请求 (syn flood)
这些都是：
要由 CPU 消化的管理面流量。
CPU 很难受，但 ASIC 不受影响。
结果就是：
命令卡
配置慢
日志刷屏
Ping 却非常稳
5. 某设备疯狂上报日志/Traps/Syslog
比如：
AP/服务器一直发送 syslog
某个环路设备不断生成告警
大量 SNMP Trap
CPU 处理异常日志超多
CPU = 累惨
Ping = 依旧稳
6. 过大 ACL/策略路由表被编译
某些操作会触发 CPU 编译动作，例如：
新增/修改 ACL
修改策略路由
大量动态 ARP/MAC 学习
VRRP/OSPF/BGP 路由表更新
CPU 编译这些策略时
会卡住一段时间，
CLI 自然像 PPT 一样一页页刷。
Ping 仍然走硬件，不受影响。
7. 某端口 MTU 设置异常导致 CPU 频繁丢弃报文
某些不符合要求的长帧/错帧
会不断丢到 CPU 里检查，
再次把 CPU 送上天。
8. 环路导致 CPU 成吨处理控制帧
环路不是只会让网络抖动，
更会产生大量：
广播帧
BPDUs
MAC Flush
ARP 请求
这些都是 CPU 的灾难。
Ping 可能走的是另外几条路径，
也就完全不丢包。
三、那为什么 Ping 不丢包？
因为你 Ping 的是 “转发面”，不是 “控制面”。
Ping 通常走两种情况：
1. 设备之间互 Ping
走 ASIC 线速硬件转发
→ 与 CPU 无关
→ CPU 爆掉也能 Ping 通
2. Ping 交换机的网关 IP
如果该网关是 SVI（VLAN 接口）
那包进入 CPU
但大部分交换机都会优先为 ICMP Echo 分配资源
即以最低成本处理。
CPU 慢 ≠ CPU 不处理。
所以会：
延迟稍大
但不丢包
四、该怎么排查？
1. 看 CPU 使用率
display cpu
show cpu
top
#看CPU占用排行
display cpu-usage process
show processes cpu sorted≥ 80% 就说明是 CPU 造成的。
重点关注：
CPU 总利用率
mgmt 进程
sshd
snmp
紧急告警进程
arp/mac 处理进程
如果是 ARP/广播 → LAN 有设备异常
如果是 SSH/HTTP → 被暴力破解
如果是 OSPF/BGP/STP → 协议震荡
如果是 SNMP → 监控系统请求过多
如果是 日志进程 → 接口 flap 或 debug
2. 查看是否有环路 / 广播风暴
display mac-address flapping
show storm-control
show interface counters
display interface X statistics
display arp statistics有抖动、storm-control 告警，就是重点方向。
3. 看日志
display logbuffer
show logging关注：
端口 up/down
BPDU
ARP 冲突
CPU overload
登录爆破日志
4. 抓取 CPU 流量
display cpu-usage all
display cpu-defend statistics发现哪类报文被 CPU 吃满，一眼明了。
5. 看是否被扫描
display ssh server sessions
display users
display firewall session table
display trapbuffer暴力破解时 CLI 会明显卡顿。
6. 排查特定端口入流量
找出是否某端口流量巨大导致广播风暴。
五、如何彻底解决？（核心策略）
1. 开 storm-control（广播/多播/未知单播限制）
最有效的防风暴手段。
开启：
storm-control
广播抑制（bc-suppression）
组播抑制
未知单播抑制
2. 开流量防护（CPU-defend）
限制被投递到 CPU 的异常流量。
3. 开 DHCP Snooping、ARP Detection
避免 ARP 攻击。
4. 正确配置 STP，避免拓扑震荡
尤其是：
根桥唯一
关闭不必要的 STP
禁止私接环路
接入端口开 portfast
5. 关闭未使用的管理服务
如：
Telnet
Web
SNMP（无需就关）
FTP/TFTP
让 CPU 轻松点。
6. 更新交换机版本 / 优化 ACL / 减少策略复杂度
ACL 越多，编译时间越长。
7. 优化 SSH：禁用无用服务（很有效）
undo telnet server enable
undo http server enable
undo https server enable
只保留必要的 SSH。
8. 清理不必要的日志，关闭 DEBUG
undo debugging all
调试日志一定要关。
9. 升级设备/增加更高规格的 CPU
对于老设备：
控制面本身性能差
新协议+新功能一启用就卡
这种只能升级。
10. 规范网络架构，防止环路、风暴、抖动
关闭没用的端口
VLAN 规划合理
STP/MSTP 设计规范
关键设备上配置 BPDU guard、Root guard
六、总结：一句话解释你遇到的现象
命令行卡，是 CPU 出问题；
Ping 很稳，是 ASIC 很正常。
这是交换机架构决定的，也是 90% 网络工程师都必须掌握的运维底层逻辑。
你遇到的现象不是网络不通，
而是管理面被“打爆”了。
交换机不是网络卡了，而是“脑子（控制面）”忙不过来了。
数据面（ASIC）继续高速工作 → ping 不丢包
控制面（CPU）被打爆 → 命令卡顿
真正的网络工程师排障绝不会只看 ping。
更关键的是：
CPU 状态
控制面流量
管理会话
协议运行
广播/组播
日志
风暴抖动
这些才是设备是否健康的真正指标。