网络设备静默丢包类问题
问题描述
1.业务报障A机房二期10.60段访问B机房非常慢。
ip: 10.60.12.228—>10.13.88.60（表现形式为wget下载数据异常）
2.A机房内部一期到二期好多机器互访都有超时的情况。
ip: 10.39.48.215 -> 10.60.11.147，10.60.12.171，10.60.11.164
3.A机房内部一期到二期有ping不通的情况。
ip: 10.39.48.217 —> 10.60.11.179
4.A机房二期到B机房有不通的情况。
ip: 10.60.12.230–> 10.13.88.60
拓扑环境
A机房 = yz
B机房 = bx
A机房一期server ip段 = 10.60.0.0/16
A机房二期server ip段 = 10.39.0.0/16
B机房server ip段 = 10.13.0.0/16
排查分析过程
从业务方报障来看，所有异常的现象都与A机房相关，故障大概率出在A机房网内。
从A机房二期到B机房这个故障例来分析，登陆两边的服务器进行排查。
1.首先从10.13.88.60上ping 10.60.12.230，发现确实不通。
再用10.60.12.230 ping 10.13.88.60，发现10.13.88.60能够收到icmp request并且正常回复了icmp reply，但10.60.12.230并没有收到reply。
再使用traceroute发现udp包能够到达10.60.12.230并且能够正常收到回包。
并且telnet 10.60.12.230 443或80有概率不通情况。
2.使用数据流探测工具找到指定不通的流，在通过traceroute判断断点在哪里。
通过traceroute显示最后一跳回显在亦庄br5，证明报文丢在了br5.yz至10.60.12.230这条路径上。
再通过逐个隔离问题路径上的设备来缩小问题范围，当隔离core2时故障恢复。
问题定位
通过如上排查步骤可知出现问题的两个最大可能性:
1.报文在br5.yz向core.yz转发时丢包。
2.core2.yz向spine.yz转发时丢包。
问题根因
通过如上问题定位，将故障可能范围缩小到最小，提供给厂商排查。
通过厂商排查，问题根因为：
br5.yz vxlan tunnel与underlay ecmp关联表项下发失败，导致ecmp下一跳未及时更新导致丢包。隔离core2后会触发刷新ecmp和vxlan tunnel表项，因此故障恢复。
触发该问题的动作是：
core4.yz shutdown一个与br5互联的端口触发，此bug的出现概率很低。
解决方案
厂商建议升级新软件版本解决。
故障处理思路及建议
这是一个典型的静默丢包问题，定位思路为:
1.先找到不通业务流的特征。
2.再通过traceroute、流统等工具发送具备该特征的流量确定转发断点位置范围。
3.再通过隔离设备等操作尝试绕过故障路径来快速恢复业务。
4.将上述排查过程描述以及现象提供给厂商排查，定位根因并提供解决方案。