丢包问题是十分常见一类问题,下面总结的一个网络丢包问题的分析过程。

问题描述

组网:

TC-PORT1——-VSR-eth1

TC-PORT2——-VSR-eth2

打流:

报文从TC-Port1打入VSR-eth1,再从VSR-eth2出,到TC-Port2,打流的时候变换了源ip与源端口

问题:

测试同学在根据RFC2544打流测试转发性能中,发现报文有效转发性能总是小于40W pps,总是会出现丢包,而实际cpu利用率才20%左右

问题分析

丢包的原因很多,需要根据现场进行具体问题分析,下面就一个一个排查怀疑点,没有怀疑点再分析的过程:

  1. 昨天测试都ok的,检查一下测试打流报文,报文正确
  2. 查看报文处理过程中丢包计数,以确认丢包阶段,不幸地发现处理过程中无丢包统计
  3. 与打多条流有关?实测打一流问题同样存在,与多条流无关
  4. 再次回头检查报文是否有多种code path,导致第2步遗漏检查到丢包点,确认报文走一条code path
  5. 上面又被否认,继续分析怀疑点,没有分析出怀疑点,自已动手打流,观察TC收发包统计发现丢包有周斯性,大概周期是30s,这是一个重要信息
  6. 又回过头去确认一下丢包统计是否有漏统计,很欣慰又很失望的结果:丢包,错包统计没有遗漏统计
  7. 这时候收包处理过程丢包可能性已经排除
  8. 从上到下的报文流排查,报文丢在网卡上送cpu过程中?
  9. 内核采用epoll收包存在问题? 进程如果得到调度就没有问题
  10. top 查看进程调度,这时候有重大发现了: 看tc丢包统计与top的里面的进程natlog运行就同步了,但是看到natlog的线程状态为D状态,同时检查配置,开启nat log功能

natlog进程设置为D状态,导致不响应异步信号,在natlog释放cpu前,在转发线程与natlog运行在同一个cpu的情况下,转发线程得不到调度,导致报文接收缓冲区溢出,导致部分报文丢弃;

与natlog线程开发同学交流,natlog早期是基于多核开发,natlog根据运营商需求,每30s定时运行,natlog线程运行在控制核,转发线程运行在数据核,导致问题没有暴露出来

问题总结

  1. 定位问题,特别是未知的问题是一步步有依据推断与确认的过程
  2. 获取现场的全方位消息,同时要对信息进行去噪,避免关键信息遗漏与无关干扰