记一次网络故障排查
(所有图片信息均脱敏)
快下班收到客户保障网络不稳定,缩小故障范围后发现还是条跨运营商的线路问题,随即喊上对方运营商一同排查
排查记录
问题情况
简单查看后发现两个运营商之间主线路互ping均大量丢包,两者中间使用OSPF作为线路自动备份。
排查记录
- 先对主备线路的光衰进行检查比较,发现都在正常收光范围内,暂时排除线路本身问题;
- 主备线路中,双线共同运行条件下,主线路质量差,备线则无问题,两条线路和核心之间运行OSPF,因此则关闭主线,尝试全部在备线的情况线路质量,后发现备线质量也快速变差,因此缩小范围是在下联接入设备中;
- 查看流量和资源占用情况,发现虽然流量不大但是包的数量特别多,结合ping包丢包的情况,仅能收到部分包,推断是由于过多的包冲垮接收端,超过滑动窗口接收限制,正常的请求包无法被正常拼接;
- 再次由对端按此方法查询下联发现有接入用户包数量异常,down该用户端口后恢复正常。
所用到指令(新华三)
- 查看接口光衰:
dis transceiver diagnosis interface
- 查看模块信息:
dis transceiver interface
- 快速查看所有端口实时包转发率pps:
dis counters rate inbound/outbound interface
总结
这次的问题也是一种很常见且典型的客户网络问题场景,按下面总结的步骤可以快速的排查出问题的范围再确定到设备。
- 长ping正常大小包但是一直丢包的情况,优先考虑物理线路本身情况。
- 物理线路无问题情况下,可以查看该端口资源占用,包括:包转发、包的数量、流量大小等
- 根据资源占用的情况分开判断:
- 包收发数量明显差异较大的情况下,较大的方向有很多无效的请求/应答,
- 包数量正常但是流量较大情况下,则可能有很多畸形包
- 对于端口不同类型的包也可以简单判断来排除,如:单播多广播正常环节,则可以排除环路,因为环路会在短时间内造成大量的组播和广播包
- 分端口排查:
- 这步主要也是缩小范围,其实在每一个环节都会有用到;
- 对于核心和汇聚层面的设备可以通过端口数据和业务比对看到端口流量的异常情况
- 接入层面设备则是可以缩小到具体设备
- 日志、CPU、内存等占用情况算是巡检和排障必查的内容了。
记一次网络故障排查
https://www.xuchang.dev/post/78662e9