网络丢包诊断分析的现实与理想如何诊断丢包一直是让工程师头疼的问题，但很少有人关注丢包原因的分析。现实目前，网络丢包的传统处理步骤如下：首先，确定丢包的设备。然后，确定消息在设备中的处理流程。***，逐一查看处理流程对应的转发表项（从软件表项到硬件表项）。您可能会觉得逐条查看转发流程条目太慢太麻烦。当你熟悉了芯片的处理流程和功能后，你会发现有以下处理方法：首先，你还需要确定丢包的设备。然后，利用芯片提供的一些诊断功能进行确认，如Broadcom的FlexibleCounter，Mediatek的dropstatistics等***，根据硬件丢包的原因，确认真正的丢包原因。虽然步骤看起来很清晰，但是执行这些步骤需要对流程和机制有非常清晰的了解，才能准确诊断丢包的原因。目前各厂商对于丢包的诊断还没有进一步的手段和解决方案。为什么会这样？是什么原因导致网络诊断手段长期没有实质性发展？主要是因为以下几个方面：NOS本身是封闭的，NOS厂商不愿意向客户公开更多的细节。它是一个专用的系统，不能在服务器上提供一些像tcpdump这样方便的手段。NOS架构通常是mips/ppc架构，其计算能力无法与x86相提并论。芯片制造商提供的诊断具有相当大的局限性。灵活的计数器提供基于丢包原因的统计，可以基于端口统计多种丢包原因的报文数量。但是如果想知道丢包的具体原因，需要调整原因位图，就需要按照手册调整位图。Dropstatics提供了端口丢包的统计信息，同时也提供了丢包的原因状态位图（即丢包原因）。但遗憾的是，由于状态位图是全局的，而不是基于端口的，具有一定的干扰性。理想地想象一下，当你发现网络不可达时，你打开一个应用程序，它告诉你你的一个数据包由于某种原因在网络中某个设备的某个端口上被丢弃了，然后你查看对应的配置，发现修改了配置，修改配置后就可以运行了。解决问题前后不到几分钟。与传统的两种方法相比，是不是简单多了？你为什么这么做？人们不禁要问，为什么传统的网络厂商没有这样做呢？这应该不可能吧？现在是开放网络操作系统盛行的时代，白盒交换机也随之而来。白盒交换机的控制面CPU不再局限于传统的mips/ppc架构，支持x86和ARM，同时交换机服务器全球化的趋势也在酝酿，可以预见x86交换机将在未来。总的来说，这个时代有两个重要的趋势：开放性，用户会越来越重视系统的开发和发展。x86释放强大计算能力，如何使用？诊断分析的难度和开放网络化的趋势，使得开发便捷的诊断分析成为必然和机遇。理想怎么做，一步步实现。要实现这个理想，您需要按照以下步骤操作：您可以在控制台使用show命令查看最近一段时间丢包的基本信息，并可以导出这些基本信息。在控制台使用show命令查看近期丢包的详细信息，支持导出的基本信息分析（wireshark插件）。部署应用，根据规则收集丢包信息并统计。一小步对于丢包，我们首先想到的是用户关心的是哪个端口出现丢包，丢包的原因是什么。因此，show命令的内容定义如下。在设备上缓存这些丢包情况，并更新最后一次发现的时间。接下来就是如何获取这些丢包信息，分析数据中心场景下20多种丢包原因。首先分为两类：Case1：Packetloss，CPU可以获得原始数据包Case2：LostPacket，CPU无法获得原始消息——通常在转发管道中大部分丢失的数据包都可以得到原始数据包messagediscarded，对应：报文携带的未创建的VLAN端口在对应的VLAN中没有路由Lookupfailurel3mtucheckfailurestpstatusothers等对于这些丢包情况，可以从芯片中获取原始数据包进行分析然后分类计数。Case2：在整个转发流水线中，也有一些丢包无法提供原始消息。对应的有：packetlossbeyondthebufferpipelineanalysiserrorpacketlosspacketverificationerrorpacketlossingressmtupacketloss(mtucheckimplementation取决于方法)对于这些丢包情况，可以从状态信息中得到对应的状态的芯片，然后分类和计数。同时，为了支持信息的导出为后续分析提供支持，定义了agent导出丢包信息的格式，如下：上述结构包含了截断后的报文前128字节（如果有原帖），这里主要提供给应用分析。进一步完成第一步后，对于某些场景，仍然只能得到一个模糊的丢包原因，只能对应直接原因，离找到根源还有一步之遥，比如l3lookupmiss，如果无法获知数据包的目的端口ip，则无法继续分析。因此，此时用户查看相应消息的详细信息是非常重要的。同样的，我们需要分析一下在这个场景下用户需要哪些消息信息。分析结果如下：Layer2headerinformation,smac,dmac,etype,length。802.1q标记信息、tpid、VLANid。三层头信息，sip，dip，tos，ip长度，ttl，ip协议。arp头信息、smac、tmac、sip、tip、op_code。四层头信息，源端口，目的端口。因此，设备缓存的丢包案例不仅保存了丢包的元数据信息，还保存了该案例对应的最后一条丢包报文的解析结果。在cli上，可以使用命令以如下格式显示相应的信息。上面给出了三个示例，其中两个可以获取原始丢弃消息信息，另一个无法获取。同样，导出的信息也需要支持解析，通过wireshark的lua插件显示，显示结果如下。将全网所有的丢包信息收集到一个收集器中进行统计分析是一大步，然后提供如下统计展示方式，尽可能还原出对应的流量大小。基于物理设备统计。基于源和目标IP的统计信息。基于源端口和目标端口的统计信息。根据丢包原因统计。通过这些统计方法，可以发现网络中存在的危险和配置问题（如killallpossiblewarningincoding），从而控制整个网络。有了这个网络诊断分析功能，我们只需要两个简单的步骤就可以确定丢包的原因：showsdrop查看丢包的基本信息。如果第一步仍然没有提供足够的信息，showsdropdetail中包含的相关信息会准确提示原因。云启科技的ConnetOS已完成前两期，第三期正在规划中。wireshark插件已经开放到github了，大家可以去了解一下。作者简介：陈虎，云启科技高级系统工程师，参与过多款高端交换机的研发，熟悉Broadcom、Dune、Mediatek系列芯片的架构和转发流水线。
