VRRP组网AC之间配置漫游组导致AC之间环路冲击有线网络问题

【组网】DT51-AC1和DT51-AC2旁挂核心交换机（核心只做二层透传），业务和管理vlan网关，以及dhcp地址池都在DT51-FW1000防火墙插卡上。

连接接口：主AC（BAGG2口，成员口XGE1/3/9 + XGE1/3/10）—— （BAGG133）核心交换机（BAGG134）——（BAGG2口，成员口XGE1/3/9 + XGE1/3/10）备AC；

核心交换机（BAGG1000）——FW1000（防火墙插卡）。

集中转发（未配置基于vlan的二层隔离）+ 本地转发（map文件配置了基于vlan的二层隔离）

AC上开启了全局stp (stp global enable)，且在与核心交换机互联的端口上默认开启了stp功能。

无

时间：故障共先后发生两次：2023-07-15 19:00~19:10左右；2023-07-17 11:40左右。

现象：据反馈已在线的无线终端使用卡顿，新终端无法接入。

现场处理方法：将所有AP从主AC切换到备AC后业务恢复正常。// 通过切断主AC和核心交换机的端口。

故障原因：有线网络中故障时间有广播/组播风暴，但引发原因未知。现场未找出有线物理环路。

故障时刻，核心交换机和主备AC互联的接口（BAGG133和134）以及和FW1000互联的口（BAGG1000）收到大量的广播/组播报文，其中个AC互联的口收到的广播/组播量较大，交换机接口Rx方向有大量arp和dhcp广播的超限速丢包记录。

此外，核心交换机上有mac漂移记录，记录了网关mac（在FW1000上）来回在交换机连接FW1000的口（BAGG1000）和连接主备AC的接口（BAGG133和134）之间漂移。

故障时刻AC的CPU总利用率不算高，但是部分转发核的利用率很高【两次发生故障时现象一致】，应该与大量广播和组播冲击AC转发核有关。

对此，收集了故障时刻AC上的cplog和dplog，收集方法是：

AC Probe视图：

fpl-diag slot 1 savelogall 0xffff

fpl-diag slot 2 savelogall 0xffff

通过作图发现，故障时刻AC和核心交换机连接端口的单播/广播/组播流量陡增：

通过上图可以看出，故障时刻，主AC和核心交换机连接聚合端口下两个成员口的广播/组播/单播流量陡增，但是入方向和出方向的广播/组播/单播流量的数量基本是相等的，无法比较准确地分析出故障时刻广播/组播泛洪的源头。

备AC和核心交换机端口的报文量级及特征与与主AC的非常接近。

而且从核心交换机侧端口的流量分析，故障时刻防火墙与核心交换机侧端口的流量交互量级要远低于核心交换机与主备AC之间的端口。

虽然从核心交换机侧的arp debug分析出故障时刻的广播泛洪主要由arp泛洪引起，且arp的源地址是网关，但按照上述情况来分析，并不是由于网关（防火墙）发送大量arp引起的泛洪，而是arp广播报文被下方的设备大量复制导致的。

## 值得注意的是，如果arp广播报文泛洪是因AC的大量复制引起，那么无法以下三种可能：

1. 两台AC和核心交换机之间或者下行链路之间产生了某种环路；        // AC上除了和核心交换机的聚合口，没有其它接口，且已排查下行链路无环路

2. 网关侧发来的arp广播请求，被AC大量复制后发给无线终端；         // 这种情况的发生需要两个条件：① 网关侧发来大量广播报文【不太符合】，② AC上有大量集中转发的终端，且AC下AP数量及绑定的服务模板较多，AC上会进行大量复制网关侧发来的广播报文，然后进行CAPWAP封装后发送给各个AP Radio下的终端，这种情况会导致故障时刻AC的转发CPU利用率上升甚至被打满，但是这种情况有一个显著的特征，就是AC端口入方向的广播量远大于出方向的广播量，而AC端口入方向的单播量远远低于出方向的单播量。

【这是因为，网关发来的广播到达AC被复制后，封装了CAPWAP报文，此时由广播变为单播，再由AC端口发出】

但局方反馈该AC下只有几十个集中转发的终端，且防火墙网关发送的报文量并不算大，结合这些特征，故障也不符合这种情况。

3. AC下有大量集中转发的终端，AC上未配置基于vlan的二层隔离，终端发送的大量arp请求被AC大量复制后导致广播泛洪。     // 这种情况也需要两个条件：① AC下有大量的集中转发终端【不符合】，且AP数量及绑定的服务模板数量较多【不符合】；② AC上没有配置基于vlan的二层隔离【符合】；

这种情况的特征也是AC端口出方向单播量远远高于AC端口入方向的单播量，同时从核心交换机侧的arp debug来看，泛洪的arp广播源地址是防火墙网关，因此这种情况也能被排除掉。

## 此外，如果是2和3两种情况导致的故障，那么由于终端主要是接入在主AC上的，因此大量流量的交互应该是集中在主AC和核心交换机之间，也不会出现备AC和核心交换机之间同样存在大量报文交互且与主AC量级接近的情况。

那么情况只能回到环路这种情况引发的广播泛洪，那么环路究竟来自于哪里？

在主AC---核心---备AC上再次排查后仍然没有发现其它物理环路的可能。

不经意之间，查看了AC的display interface brief，发现了一个奇怪的端口：WLAN-Tunnel1/0/1

查询后发现这个口是漫游组隧道的入口

查看AC上的stp记录发现，两次故障时刻均有WLAN-Tunnel的stp状态改变的记录。

此外，对于的业务vlan下也有WLAN-Tunnel1/0/1口和AC和核心交换机之间的物理成员口的添加记录，说明存在环路的可能

而根据故障时刻AC上的display mac-address记录，发现主AC会从WLAN-Tunnel1/0/1学到对应业务vlan的mac地址，同时也能从AC和核心交换机的聚合口学到，这说明VRRP主、备AC和核心交换机聚合口以及主、备AC之间的WLAN-Tunnel1/0/1虚拟口构成了环路，导致了故障时刻arp广播报文的大量复制。

WLAN-Tunnel1/0/1的产生与VRRP主、备AC配置了如下命令有关，删除后WLAN-Tunnel1/0/1隧道消失，问题解决。