msr3610设备cpu升高

可以看下进程，那些进程占用比较大，但是50%是正常范围的

可能性比较多，可以升级下最新版本再观察，

一般80以下没问题的

设备状态显示正常，但CPU利用率在55%-80%之间浮动，这种情况在MSR3610上确实可能发生。这通常不代表硬件故障，而更可能是软件版本、特定配置或特定进程导致的现象。客户要求CPU低于50%，我们需要找到具体原因并优化。

 首要排查方向：版本与“逐包转发”问题

这是H3C MSR3610一个已知的典型情况。

• 老版本软件Bug：部分早期软件版本在配置了 tcp mss 后，设备会错误地进入“逐包转发（per-packet）”模式，导致CPU占用异常升高。

• 如何排查：

  1. 检查配置：执行 display current-configuration | include per-packet，确认是否存在 forwarding policy per-packet 配置。

  2. 升级版本：建议将设备软件升级至CMW710-R0305或更高版本，该问题已在后续版本中修复。

 第二步：定位高占用进程

通过命令行定位具体是哪个进程占用了CPU。

• 关键命令：

  • display cpu-usage task：查看各任务（Task）的CPU占用率。

  • display process cpu：查看各进程的CPU占用率。

• 常见高占用进程分析：

• 针对stamgrd进程的解决方案：

  • 原因：网络中可能存在无线AP发送的CAPWAP报文上送到路由器，导致其无线功能进程异常处理。

  • 操作：如果确认路由器未充当无线AC，可执行 undo wlan enable 关闭其无线功能，以释放CPU资源。

 第三步：检查关键性能优化配置

确保设备已开启快速转发，避免数据包全部交由CPU处理。

• 检查快转是否开启：执行 display ip fast-forwarding cache。如果显示为空或未开启，大量数据包将由CPU软件转发，导致利用率高。

• 开启快转：

  text

  system-view ip fast-forwarding

  如果设备支持硬件快转，也可尝试 hardware-quic 命令。

📋 第四步：排查其他常见诱因

• NAT日志：大量NAT会话日志会严重消耗CPU。检查 nat log enable 是否开启，如非必需，建议关闭或仅保留 flow-end 记录。

• 路由振荡：检查路由表是否频繁变化，display ip routing-table protocol 可查看路由稳定性。

• 报文攻击或异常流量：内网是否存在广播风暴、ARP攻击等异常流量。可通过 display interface 检查接口是否有大量广播或错误包。

• 不必要的服务：如无需使用，可关闭 cwmp (TR069)、lldp、ndp 等协议以节省CPU。

• SNMP轮询频率：若网管系统频繁轮询设备，也可能导致CPU升高，可适当降低轮询频率

重要区分：MSR3610 数据报文硬件快速转发不占用主控 CPU；CPU 高指控制平面 CPU升高，业务转发不一定卡顿，但是协议、管理、隧道、NAT 会话处理会受影响H3C。现象：设备看接口、邻居、告警都正常，但 CPU 持续 55‑80% 波动。

第一步：采集基础定位信息（优先执行，确定哪个进程吃 CPU）

把display cpu‑usage sort输出保存，根据最高进程判断方向：

1. rout / ospf / bgp →路由协议方向
2. ipc / arp →ARP、广播报文上送
3. diag/log →海量日志输出
4. natd →NAT 会话处理重载
5. vty/ssh →大量管理登录访问
6. kernel 线程 →版本 BUG、中断异常

高频根因（按现场出现概率）

1、协议震荡（邻居表面看全 Full/Up，后台有闪断）

OSPF/BGP/ADVPN/GRE 隧道邻居短暂闪断后马上恢复，display ospf peer brief看是 Full，但是后台不停 LSA 刷新、路由计算，CPU 周期性冲高华为。 排查：

现象：邻居瞬间 down 又 up，日志大量邻居 down/up，肉眼看 display peer 是正常 Full，CPU 反复 55‑80%。

2、大量 ARP 广播、广播报文上送 CPU

内网存在环路、终端 ARP 风暴，大量 ARP 报文上送到主控 CPU，转发芯片处理不了的广播报文全部交给 CPU 处理。

看 ARP 报文计数持续快速增长。

3、海量日志持续输出占用 CPU

某些隐性报错，终端看不到，但设备内部疯狂写 logbuffer，CPU 消耗在日志打印，没有严重告警，只是大量重复 notice/warn 日志H3C。

打开终端监控，看是否屏幕疯狂滚动日志。

4、NAT 会话数量大、会话频繁新建销毁

MSR3610 做 NAT，内网大量终端频繁上下线，natd 进程 CPU 拉高。

观察会话总数、每秒新建速率。

5、特性重载：流采样 sflow、netstream、DPI、IPS

开启 netstream / 流采样，采样比过高，会把大量报文上送 CPU 分析，表面业务状态全部正常，但 CPU 持续高。

6、软件版本 BUG

MSR3610 部分老 R66 版本存在已知问题：空闲环境下控制平面 CPU 基线偏高，无明显异常业务进程，基线 CPU 就 50‑70%。

解决：升级到官方推荐稳定基线 R67 系列版本。

7、端口 / 光模块隐性震荡

接口display ip interface brief看物理是 Up，但是底层光模块异常，频繁短暂 flap，不会直接 down，但是产生大量中断，拉高 CPU。

排查处理步骤

1. 先确认 5 分钟平均 CPU，客户告警阈值建议以5 分钟平均为准，瞬时冲高不算故障H3C。
2. 根据display cpu‑usage sort定位高占用进程，对号入座上面根因。
3. 如果日志狂刷：关闭不必要日志输出，调整日志级别。 info‑center source default severity warning
4. 如果是 netstream/sflow：调低采样比率，业务不使用直接关闭。
5. 如果协议震荡：排查二层环路、链路质量，调整 hello/dead 定时器，CPCAR 保护控制平面。
6. 如果找不到业务原因，进程看不出明显异常，基线就高：优先升级 Comware V7 到稳定版本。

客户要求 CPU≤50% 的注意点

MSR3610 控制平面 CPU，部分版本空闲基线就 45‑55%，没有故障业务的情况下，很难强制压死在 50% 以下。

1. 区分瞬时值和 5 分钟平均值，监控告警建议用5 分钟平均作为阈值，不要拿 5 秒瞬时做告警；
2. 若 5 分钟平均持续 > 50%，且伴随进程高占用，才需要深度排查；
3. 升级版本是很多基线 CPU 偏高场景的最终解决手段。

收集信息提交 400CASE 需要输出清单

1. display version
2. display cpu‑usage history
3. display cpu‑usage sort
4. display cpu‑usage summary
5. display cpu‑defend statistics
6. display logbuffer