icg 3000自动重启

“晚上定时 OOM 重启 + 9119P16”这个组合，大概率是“内存缓慢泄漏/表项夜间堆积到阈值”触发的保护重启，不一定是硬件坏，但也不能排除版本已知缺陷。华三机制是：空闲内存跌破三级告警门限并持续/预测即将耗尽，系统会主动重启单板或整机防死机。
下面按“先定性 → 再定位 → 临时止血 → 找售后确认版本”四步给你落地动作。
一、为什么是“晚上”才炸
OOM 不是随机的，夜间复发表明有周期性触发源。ICG 这类网关夜间高发场景就这几类：
NAT 会话表堆积：白天短连接走完，但 TCP/UDP 老化时间设太长（尤其 P2P、视频会议、监控回传、BT/网盘），到夜里并发连接数叠加，会话表吃满内存
日志/审计写入高峰：行为管理、会话日志、流量统计、NAT 日志全开，白天产生、夜间刷写或外发，日志缓存占内存
SNMP 周期性轮询：网管平台夜间做全表 walk（interface、arp、session、bgp 表），某些版本 SNMP 子进程有泄漏
定时任务：配置备份、特征库更新、证书检查、NTP 重同步、云平台心跳上报
终端批量行为：夜间办公终端休眠前集中同步（OneDrive、微信、系统更新、杀毒库更新），瞬时新建连接暴涨
版本内存泄漏：9119P16 是 2022 年稳定基线，跑到现在若开了较多新特性（IPv6、安全策略、行为管理），可能存在未修复的慢泄漏
💡 关键区分：“内存慢慢涨、几天到阈值”= 泄漏/表项不释放；“每晚固定时间点突然涨”= 有定时任务或流量模型触发。
二、现场取证（下次重启前就把证据留好）
重启后内存就释放了，所以必须在故障前/故障时抓快照，别等重启完再登上去看“内存正常”。
1. 先存一份完整诊断（最重要）
display diagnostic-information
# 存到 flash，导出后发售后
2. 实时看内存趋势（白天就开始盯）
display memory-usage
display memory
display cpu-usage history
display memory-usage history # 有历史曲线更好
看两点：
内存是不是只涨不跌（泄漏特征）
每天晚上几点开始冲高
3. 看重启原因和日志
display logbuffer | include MEM
display logbuffer | include reboot
display reboot-history
dir flash:/core/ # 看有没有生成 core 文件
dir flash:/crash/ # 看有没有 crash 文件
OOM 前通常会先打：
DIAG/1/MEM_EXCEED_THRESHOLD
4. 定位是哪个进程/模块在吃内存
display process memory
display process memory heap job <pid> verbose
多次采样对比，看哪个进程的 Used 持续增加不回落。
进 probe 视图看内核内存池（更底层）：
probe
display system internal kernel memory pool
找“使用率不正常、且不断增加”的块。
5. 查会话/表项（夜间高负载时查）
display session statistics # 会话数
display nat session summary # NAT 会话
display arp count
display mac-address count
如果会话数上万且不释放，重点查老化时间：
display nat aging-time
6. 查定时任务和对外同步
display scheduled-task
display clock
display ntp-service status
顺便看有没有开：
info-center 本地日志没限额
SNMP 被网管全表轮询
云平台/APP 管理心跳
三、临时止血（先别再半夜重启）
按风险从低到高：
① 日志外发 + 限本地配额（立刻做）
info-center loghost 192.168.x.x # 外发到 syslog 服务器
info-center logfile size-quota 10
info-center logfile quantity 5
避免日志把 flash 和内存双向吃满。
② 缩短 NAT/会话老化时间
如果 TCP 老化被设成 86400 之类，改回合理值：
nat aging-time tcp 300
nat aging-time udp 120
（具体值按业务调，别一刀切把长连接业务砍了）
③ 关掉不必要的审计/行为管理
全流量审计 → 只开关键业务
应用识别特征库若设备内存小，换轻量版或延时更新
会话日志别存本地
④ SNMP 收敛
只允许指定网管 IP
别让网管平台每秒 walk 全表
临时关 SNMP v3 以外的版本
⑤ 开内存监控告警
snmp-agent trap enable
# 或配 memory-threshold 提前告警
让监控平台在内存到 80% 就报警，你能在重启前登上去抓现场。
⑥ 临时保底
业务低峰期计划内每周重启一次只是止血，不是根治，别把它当方案。
四、根治路径：找华三售后确认版本
9119P16 是老稳定版，但“稳定”不代表没已知缺陷。直接给 400 或代表处发工单，把下面信息给他们：
设备：ICG3000
版本：R9119P16
现象：连续多日晚间 OOM 自动重启，重启原因 out of memory
已采集：diagnostic-information、logbuffer、process memory 多次快照、session 统计、core 文件（如有）
请确认：
该版本是否有已知内存泄漏缺陷（NAT/SNMP/日志/行为管理相关）
是否有更高修复版本或补丁包（P17/P18 或 R914x 新线）
针对当前业务规模，推荐内存参数和会话老化配置
别自己盲升——ICG 是定制产品线，版本要售后确认适配再刷。
五、顺手排除硬件/环境
虽然概率低，但别漏：
display temperature all 看夜间温度，散热差会加剧泄漏触发
电源适配器是否原装，电压稳不稳
设备通风（别塞在弱电箱里）
六、一句话定性
你现在最该做的不是“重启试试”，而是今晚就开始采内存曲线 + 会话数 + 进程内存快照，连续采 2-3 天，拿到“内存爬升曲线”再给华三售后，他们才能给你准确定位版本补丁。盲目等下次重启，永远查不清。

内存泄漏特征：设备刚重启后内存空闲充足，运行若干小时后空闲内存持续下降，到临界阈值触发 OOM 重启；用户反馈晚上发生，一般是夜间定时业务（NAT 会话、VPN、日志、SNMP 采集、定时脚本 / 物联网业务）触发内存缓慢泄漏。
2、ICG3000 为物联网网关，常见会加剧内存占用的业务：大量 NAT 会话、IPsec VPN 隧道、流量统计、syslog 海量日志输出、SNMP 高频轮询、物联网协议处理。
3、R9119P16 版本存在若干内存泄漏相关问题单，如果配置简单仍然持续内存上涨，优先怀疑版本缺陷。

## 排查步骤（按现场执行顺序）

### 步骤 1：确认重启历史、OOM 记录

```
#查看设备重启历史，确认重启原因为MemoryexhaustReboot（内存耗尽重启）
display reboot‑history
#查看硬件故障检测日志
display hardware‑failure‑detection
#查看系统日志，查找内存告警、OOM相关记录
display logbuffer | include memory
```

>
> `MemoryexhaustReboot`就是内存耗尽 OOM 重启记录H3C。

### 步骤 2：监控内存变化，定位是否内存泄漏

**设备正常运行状态，多次间隔采集，观察 Free 空闲内存是否持续走低**

```
#查看整机内存
display memory summary
#查看每个进程内存占用，观察哪一个进程内存持续上涨
display process memory
```

>
> 操作建议：设备重启完成记录一次内存，之后每隔 2‑4 小时采集输出；如果空闲内存随时间不断变小，确认存在内存泄漏。

### 步骤 3：重点排查业务配置（优先排除配置侧因素）

1. **NAT 会话**：查看 NAT 会话数，夜间业务是否会话数暴涨

```
display nat session summary
```

- 如果会话数量巨大，检查 NAT 老化时间是否配置过长；调整 nat aging‑time。

2. **IPSec VPN**：大量隧道、频繁隧道重建会引发内存泄漏，查看隧道状态。

```
display ipsec sa summary
```

3. **日志输出**：syslog 输出到外部日志服务器，流量巨大会持续消耗内存；关闭不必要的 debug 调试开关。

```
display info‑center
undo info‑center enable debug
```

4. **SNMP**：确认网管是否高频 walk 轮询；如果不需要可以临时关闭 snmp 测试复现情况。
5. 物联网业务：Modbus、DNP3 等物联网协议，如果点位数量巨大，会消耗大量内存。

### 步骤 4：探针视图进一步定位泄漏模块（需要 network‑admin 权限）

```
system‑view
probe
#查看内核内存池，定位哪个模块内存持续增长
display system internal kernel memory pool slot 1
#查看进程堆内存，定位用户态进程泄漏
display process memory heap job <进程ID>
```

>
> ⚠️probe 视图属于内部维测视图，不要随意修改参数，仅做查看。

### 步骤 5：临时规避与版本处理

1、临时应急：配置定时任务，夜间业务高峰前定时重启设备，临时规避业务中断，不解决根本问题。
2、R9119P16 版本，查阅版本说明书，优先升级到 R9119 分支后续稳定补丁版本修复内存泄漏 BUG。

>
> ⚠️升级前完整备份配置；升级之后持续观测内存曲线。

### 步骤 6：收集信息提交 400 定位

如果配置排查完毕仍然复现，需要收集以下诊断信息给到 400 技术支持：
1、`display reboot‑history`、`display memory`多组时间点对比输出；
2、诊断信息：`diagnostic‑collect`导出 diag 压缩包；
3、复现时间点，夜间哪些业务在运行；
4、配置文件。

升级下最新版本再观察

内存超了，对于硬件设备，大概率是版本问题

不确定可以直接升级版本到最新再观察

要确定原因可以收集diag诊断日志分析