华三SDN网络，网关丢包

**大概率就是控制网段单独配置了针对控制网网关 IP 的 ICMP 防护 / 控制平面 CAR/SDN 安全策略，导致周期性丢包；生产网关没有绑定该策略，ping 正常。**
现象特征：**控制网网关做源 ping 终端，25~30s 丢 1 个包；生产网关同测试完全正常**。说明**数据平面转发没问题，是【网关本身 CPU 处理 ICMP 应答报文被限流】**，不是转发面丢包。

>
> 组网要点回顾：SDN，核心作为无线网关；控制汇聚、生产汇聚；控制器旁挂核心。
> 控制网网关 IP 是核心上三层接口 IP；ping 报文源 IP = 网关 IP，报文**上送到核心 CPU 处理（控制平面）**；生产网关的 ping 报文，直接硬件转发，不上 CPU。

## 原理区分（为什么两个网关行为不一样）

1. **控制网网关 ping（源 IP = 控制网关 IP）**
ping 应答报文是**核心交换机 CPU 生成并发出**，属于**控制平面报文**。
如果控制平面 QoS /attack-defense 里针对控制网段 / 控制网关 IP 做了 ICMP flood 防护、CAR 限速，令牌桶耗尽就会周期性丢弃 ICMP 应答包，表现为**每隔 25~30s 丢 1 个 ping 包**。
2. **生产网关 ping（源 IP = 生产网关 IP）**
生产网关的 ICMP 应答，**直接硬件转发，不上核心 CPU**，不受控制平面 CAR/anti-attack 限制，所以 ping 零丢包。

>
> 这就是最典型的现象差异：**同一个核心，不同源 IP ping，一个丢包一个正常**。

## 4 个最可能根因，按优先级排序

### ① 核心交换机控制平面 QoS 预定义 / 自定义策略（最高概率）

H3C Comware V7 核心默认自带**control-plane 预定义 QoS 策略**，对所有上送 CPU 的 ICMP 做 CAR 限速。
现场大概率额外**针对控制网段做了细化策略**，控制网关 IP 的 ICMP 应答命中这个 CAR，令牌桶周期性耗尽，丢包。

```
#查看控制平面QoS策略
display qos policy control-plane pre-defined
display qos policy control-plane applied
```

>
> 控制平面 CAR 只对**上送 CPU 的报文生效**；硬件转发报文不受影响，完美匹配你现场现象。

### ② attack-defense 攻击防范：针对控制网关 IP 开启 ICMP-flood 检测

单独针对**控制网网关 IP 配置了 icmp-flood detect ip**，阈值设置偏高，长时间 ping 时，计数器缓慢累积，**每 25~30s 触发一次丢弃，然后计数器重置，恢复 ping**，形成周期性丢包。生产网关没有配置这条检测，无丢包。

```
display attack-defense policy
display icmp-flood detect
```

>
> 典型特征：**仅针对指定 IP 做 ICMP flood 检测，不是全局**，正好解释生产网关正常。

### ③ SDN 控制器下发的安全策略 / 流表，针对控制网段的 ICMP 限流

SDN 控制器（VNF/ACG/ 安全策略）旁挂核心，控制器下发流规则：

- 控制网段的 ICMP 报文做限流；
- 生产网段没有这条限流策略。

>
> 注意：SDN 策略一般是**针对穿越设备的数据平面**；但如果是**目的 / 源是网关本机 IP**，报文上 CPU，容易被控制器下发的 ACL / 安全策略拦截。
> 排查：登录 SDN 控制器，查看安全策略、QoS 策略，区分控制网段 / 生产网段的 ICMP 动作。

### ④ ip icmp error-interval ICMP 差错报文令牌桶（次概率）

`ip icmp error-interval`是 ICMP 差错报文令牌桶；如果控制网网关触发大量 ICMP 应答，令牌桶每 25~30s 耗尽，丢弃应答包。

```
display current-configuration | include ip icmp error-interval
```

## 快速定位验证方法（核心上执行）

1. **区分丢包位置：debug 查看被丢弃的报文原因**

```
debugging packet-filter cpu
terminal debugging
terminal monitor
```

持续 ping 控制网关，抓到丢包时刻，看日志提示：`drop by control-plane car` / `drop by icmp-flood`。

2. 验证是否是控制平面问题：
- 从终端 ping 控制网关（报文上 CPU）：周期性丢包；
- 在核心上用**生产网关 IP 作为源 ping 终端**：无丢包；
- 在核心上**控制网关 IP 作为源 ping 终端**：周期性丢包。
✅ 只要满足这个现象，100% 是**控制平面 CPU 侧对控制网关 IP 的 ICMP 报文限流**，不是转发面。
3. 检查是否 SDN 控制器下发 ACL / 安全策略
在核心查看 ACL、流表：

```
display acl all
display openflow flow-table
```

## 临时验证手段（快速确认是不是策略导致）

>
> 窗口业务低峰操作：

1. 临时移除 control-plane 上自定义的 qos policy，再测试 ping；丢包消失 → 控制平面 CAR 问题。
2. 临时删除针对控制网关 IP 的`icmp-flood detect ip`，测试 ping；丢包消失 → ICMP flood 防护问题。

>
> ⚠️不要直接关闭全局 attack-defense，会降低安全防护。

## 容易踩坑的误区

1. ❌不是链路 / 光模块错包：如果是链路错包，**生产网关 ping 也会丢包**，不会只控制网网关丢。
2. ❌不是 VLAN 三层转发、ARP 问题：ARP 问题不会出现**均匀 25~30 秒丢一个包**，一般是批量丢包。
3. ❌不是无线侧问题：测试是**核心上直接用控制网关源 IP 去 ping 终端**，流量不经过无线 AP，直接排除无线侧。

## 排查顺序建议

1. 先查核心`control-plane qos policy`；
2. 再查`attack-defense icmp-flood`是否针对控制网关 IP 单独配置；
3. 然后去 SDN 控制器，核对控制网段的安全策略、QoS；
4. 最后核对`ip icmp error-interval`。

现在就才想这个问题是不是就刻意给控制网络配置了策略才出现这样的情况呢

你可以去掉策略后，再测试下不就知道了吗？

优化下无线的业务VLAN就能解决