奇怪的拓扑，奇怪的ping小概率10-15分钟长时间丢包的问题

image.png

结合拓扑分析，control01 下的交换机访问所有同一交换机下的管理ip根本没有丢包，

但是 跨交换机访问： 其实一共只有两个千兆交换机：

命名描述：

control01接的交换机是 S1

control03， control02 接的交换机是S2

当然，主要问题是，S2下的机器互相访问也会100%丢包，
次要问题，当S1下的机器管理ip访问 S2的管理ip的时候，就会出现间歇性100%丢包，

所以问题排查的第一步应该排查S2交换机。

image.png

目前猜测：

可能跟周期性的arp广播风暴有关系，目前已经排除了物理机的arp相关的产生源问题，可能是交换机配置不当，而且这个拓扑比较奇葩。

arp广播风暴，一般会导致交换机cpu使用率飙高，同时网络是完全无法响应的情况，参考: https://icode.best/i/81958445268565。

而华为交换机是可以查询到cpu使用率信息的：参考: https://support.huawei.com/enterprise/zh/doc/EDOC1100004340/818b7da7

但不确定能否基于snmp-exporter暴露出来metric，这样可以基于交换机使用率的dashboard直接对照host-pinger的dashboard。

那么分析下snmp-exporter是否有cpu usage的collector。

// /root/github/snmp_exporter/snmp.yml

grep -i cpu -r * /root/github/snmp_exporter/snmp.yml


...

snmp.yml:  - name: ssCpuSystem
snmp.yml:    help: The percentage of CPU time spent processing system-level code, calculated

...

# 可以看到snmp exporter 应该是可以从交换机收集到cpu的系统，用户（态）使用率

而且华为交换机基于snmpwalk 也可以获取cpu的使用率。

基于交换机 S2 snmp的cpu使用率dashboard结合host-pinger 的dashboard对照，即可确认是交换机的arp间歇性广播风暴导致的。

image.png

广播风暴主要原因以及解决方案参考： https://icode.best/i/81958445268565

实际原因：千兆交换机上行到万兆的光纤跳线（光模）没有接紧有关系，导致端口功能不稳定。

由于有两个上行口，而其中一个有主的逻辑，这里应该是基于类似vrrp的逻辑（类似vip 可漂移），有一个虚拟mac（类似vmac）绑定在上行口，由于端口接线不稳定，导致vmac不间断发生漂移，导致该交换机下的所有交换机重新建立arp记录，产生大量的arp广播风暴，造成10-15分钟的集群管理网口断网。

image.png

观察一晚 确认未复现

交换机监控项需要包括：
cpu 内存 arp 请求数，丢包数

物理机监控host-pinger ping 丢包率即可

image.png