交换机bug类问题
问题描述
20191112凌晨1:33左右，手浪业务监控及LVS接连产生报警。
LVS同学反馈vip：221.179.175.159/116/221/57/207监控报警，并且从不同地点ping测试这几个vip有些通，有些不通，数量不等。
从Y机房工具机mtr测试这几个vip有大量丢包。
拓扑环境
D机房 = dbl
D机房出公网流量通过EBR转发到ISP。
EBR通过与BR的BGP-PEER学习LVS-SERVER VIP路由。
排查分析过程
1.首先在Y机房工具机ping测试221.179.175.207，发现丢包，mtr后发现丢包丢在D机房出口设备(EBR)与运营商互联接口（如拓扑图所示），查看接口流量及误码均无异常。同时给运营商报障，运营商反馈无异常。
2.查看网络监控中的设备接口信息发现故障发生时pps突增，但bps增幅不明显。这种情况一般有以下两种可能：
1）发生来自公网的syn flood攻击，由于lvs同学并未反馈有syn报文突增情况以及syn-flood不会影响icmp，因此排除。
2）发生路由问题产生环路，流量在ebr和局方直连设备之间不停的循环转发直至ttl超时。
3.LVS同学反馈直连接在D机房EBR下的SNAT-SERVER ping D机房LVS-SERVER不通。
sip:36.156.5.87,dip:221.179.175.207，但是从EBR上使用SNAT网关sip：36.156.5.1 ping dip:221.179.175.207通，证明来去路径可达。
4.由于SNAT server到LVS server全部路径都在IDC内部，沿途所有路径可控，相对于从公网故障例作为突破口，此故障例更合适，所以继续重点排查该问题。在SNAT server上ping 221.179.175.207会有偶发的ttl超时回显，并且来源ip为ISP直连我方IP，证明这个icmp request包在EBR与局方设备之间环了，此现象印证了第2部的猜想。
5.于是开始排查路由是否学习正常，查看到221.179.175.207的路由以及BGP邻居，路由学习正常，bgp邻居及bgp路由无抖动情况。
6.如上操作证明非交换机上层路由协议问题以及LVS故障，基本可以定位是EBR这台交换机的底层转发出了异常。 查看交换机底层ipv4硬转表
发现故障网段的硬转表在slot1中表项丢失。
查看此时IRF堆叠状态，堆叠状态无异常。
7.通过在ebr上reset bgp peer with br以强制刷新表项后恢复。
故障原因
厂商分析反馈交换机底层转发层面bug。
解决方案
升级软件版本后解决。