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

问题描述

组网：

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. 获取现场的全方位消息，同时要对信息进行去噪，避免关键信息遗漏与无关干扰