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
网友评论