业务有问题吗，或者配置本地转发

AC 侧大量 ARP 广播风暴问题定位分析

现象：Wireshark 抓包看到大量 ARP 请求，源 MAC 为 AC 的聚合口 MAC 00be‑d560‑6c01，大量 Who‑has 广播报文从 AC 发往核心方向；链路聚合、trunk 允许 VLAN 配置两边看上去完全一致。 组网：AC ↔ 核心交换机，静态链路聚合 BAGG1 (AC) ↔ BAGG10 (核心 YT‑CORE)，透传 VLAN 2600、2603‑2604、2624。

关键现象解读

1. 抓包 ARP 源 MAC 是 AC 设备 MAC，不是无线终端 MAC，ARP 报文是 AC 本身在向外发 ARP 请求，不是终端泛洪上来。
2. 两边聚合：静态聚合，成员口都 Selected，Trunk 放行 VLAN 完全一致。
3. 核心聚合接口配置了 undo stp enable（关闭 STP），AC 侧 BAGG1 没有关闭 STP。

根因分析（2 个最高概率）

原因 1：STP 在聚合两端配置不一致，产生二层环路风险（重点）

• 核心侧 Bridge‑Aggregation10：undo stp enable，该聚合口 STP 关闭，不参与生成树计算。
• AC 侧 Bridge‑Aggregation1：没有关闭 STP，该聚合口参与 STP 计算。

两端 STP 状态不一致，二层 VLAN 环境下，一旦存在其他迂回路径，会产生 MAC 来回漂移，AC 会不断 ARP 泛洪探测 IP 对应的 MAC 地址，表现为大量 Who‑has ARP 广播。

为什么大量 ARP：当 AC 的 MAC 地址表抖动、MAC 反复漂移消失，AC 需要频繁发送 ARP 广播，去探测各个网段网关 / 终端 IP 对应的 MAC，抓包就看到源源不断 ARP who‑has。

原因 2：AC 上开启了 ARP 代理 / ARP 扫描、网关 ARP 探测

AC 作为无线控制器，VLANIF 三层接口（VLAN2600/2603 等），开启arp‑scan、或者开启大量网关探测，会周期性对本网段所有 IP 发送 Who‑has ARP，这个行为是 AC 三层接口主动发出。

抓包特征：源 MAC 固定 AC 的设备 MAC，目标是各个网段 IP，循环扫描整个网段 IP 列表，和你截图现象完全匹配。

原因 3：MAC 地址漂移

查看 AC 上display mac‑address flapping record，确认是否 MAC 漂移。

• 如果 MAC 漂移记录频繁，说明二层网络存在环路，导致 MAC 表项反复删除，AC 只能依靠 ARP 广播重新学习 MAC。

分步排查命令（AC 设备执行）

修复操作步骤

步骤 1：STP 两端配置保持统一（必做）

核心侧 BAGG10 配置了undo stp enable，AC 侧 BAGG1 也要同步关闭 STP。 AC 上配置：

注意：只有 AC‑核心这一条聚合链路、无其他二层迂回链路，关闭该端口 STP 才安全；如果网络还有其他二层冗余链路，不能直接关闭 STP，需要统一规划 STP 根桥。

步骤 2：关闭不必要的 ARP‑scan

如果查到开启arp‑scan，会周期性扫描整个网段产生大量 ARP 广播，关闭：

步骤 3：确认网关部署位置

• 如果网关在核心交换机，AC 只做二层透传，那么 AC 上不要配置 VLANIF 三层 IP；AC 配置了 VLANIF IP 会触发本机 ARP 探测，大量向外发送 ARP 广播。

很多现场坑：网关在核心，AC 还配置了 VLANIF 三层 IP，AC 三层模块不停发送 ARP 扫描，形成广播风暴。

步骤 4：验证

修改配置后，持续抓包观察，确认 AC 不再周期性发出大量 Who‑has ARP 广播。

不再输出漂移记录，MAC 地址表稳定，ARP 广播恢复正常水平。

补充区分两种 ARP 风暴

1. 终端上来的 ARP：源 MAC 是无线终端 MAC，需要查无线侧，隔离广播域。
2. AC 设备自身发出 ARP（你的现场）：源 MAC 是 AC 设备 MAC，问题出在AC 三层模块、ARP 扫描、STP 环路 / MAC 漂移，不是无线用户报文。

极简小结

1. 现象中 ARP 源 MAC 是 AC 设备本身，不是无线终端上传流量。
2. 优先：AC 的 BAGG1 接口补上undo stp enable，和核心保持 STP 配置一致。
3. 检查 AC 是否配置多余 VLANIF 三层 IP；检查arp‑scan是否开启。
4. 看 MAC 漂移日志，如果持续漂移，网络实际存在二层环路，需要全网梳理拓扑。

从你描述的“AC链路聚合口发出大量ARP”以及“二层MAC学习”来看，这个问题很可能不是由典型的物理环路引起的，根源可能出在AC的无线功能特性或终端行为上。可以按照由简到繁的顺序来排查和解决。

 第一步：快速排查与临时缓解

首先，执行一些快速检查来确认问题范围，并进行临时抑制，避免影响业务。

1. 检查是否有环路

   • 分别在AC和核心交换机上执行 display mac-address mac-move（AC）和 display mac-address flapping（核心）。如果存在MAC地址漂移记录，说明网络中存在二层环路。

   • 同时检查STP状态：display stp brief，确认聚合口及成员端口状态正常，没有被异常阻塞的端口。

2. 检查是否为已知软件问题

   • 执行命令 display version 查看AC的软件版本。

   • 如果版本在 R2446P03 到 R2452P02 之间（不含两端），可能会受到“rrop anti-bmc network”功能的影响。

   • 临时解决方案：在AC的系统视图下执行 rrop anti-bmc network disable 命令。这个命令用于关闭无线广播组播控制功能，不会影响无线业务。

3. 临时抑制ARP广播

   • 在AC的聚合口（例如Bridge-Aggregation10）下执行：

     text

     broadcast-suppression arp pps 100

   • 该命令用于限制ARP广播包的速率（单位：包/秒）。100是一个建议起始值，需要根据实际业务调整。

 第二步：深入排查与根治

如果以上步骤没有效果或只缓解了症状，就需要深入排查了。

1. 检查终端行为

   • 重点观察发送ARP的源MAC地址。如果大量ARP请求来自少数几个终端，很可能是这些终端上安装了某些软件在进行网络扫描。

   • 解决方案：在终端侧排查并卸载或关闭这些异常软件。

2. 检查AC的无线优化功能

   • 如果问题与AP间的无线终端漫游相关，可能需要关注AC上一些特定的优化功能。除了之前提到的 rrop anti-bmc network，一些AC版本中默认启用的“广播ARP优化”或“ARP代理”等功能也可能在特定场景下引发问题。

   • 排查方法：登录AC的Web界面或命令行，检查与“ARP”、“广播优化”、“漫游”相关的配置项。如有疑问，可查阅对应软件版本的配置手册或咨询H3C技术支持。

3. 检查聚合链路配置

   • 确认聚合链路两端模式一致（均为静态聚合或动态LACP）。

   • 执行 display link-aggregation verbose 检查成员端口是否全部为Selected状态。

   • 检查负载分担模式是否合理。在纯二层环境中，可尝试调整为基于源和目的MAC的负载分担：

     text

     link-aggregation load-sharing mode destination-mac source-mac

4. 实施二层隔离（终极方案）

   • 如果确认是无线终端侧的广播问题，可以在AC或连接AP的交换机上启用基于VLAN的用户隔离。这能有效将广播域限制在最小范围，是根治此类问题的常用手段。

   • 配置命令（在AC系统视图下）：

     text

     user-isolation vlan 2600 enable # 为业务VLAN 2600启用二层隔离

   • 注意：启用此功能后，同VLAN内的无线终端将无法直接通信，可能会影响投屏、打印等功能。如果这些是刚需，需要谨慎评估。

优化无线的管理VLAN和业务VLAN就能解决。做三层旁挂组网

聚合口两边配置一致看看，是不是一边关闭了生成树导致一直发包协商啊。

还有两边配置动态聚合试一下