网络丢包诊断与分析的现实与理想

内容简介：网络丢包诊断与分析的现实与理想

自从有了网络便有了网络故障，网络故障的最大体现是丢包。如何对丢包进行诊断一直是一个令工程师头疼的问题，可关注丢包原因分析的人却非常的少。

现实

目前对于网络中出现丢包的传统处理步骤如下：

• 首先，确定丢包的设备。

• 然后，确定报文在该设备的处理流程。

• 最后，一一核对对应处理流程的转发表项（从软件表项到硬件表项）。

也许你会觉得一一核对转发流程表项太慢太麻烦，熟悉芯片的处理流程和功能之后你会找到如下一种处理方式：

• 首先，还是要确定丢包的设备。

• 然后，利用芯片提供的一些diagnosis功能进行确认，例如Broadcom的Flexible Counter，Mediatek的drop statitics等。

• 最后，根据硬件的丢包原因去确认丢包的真实原因。

虽然看起来步骤很明确，但是执行这些步骤需要对其中的流程以及机制了解的非常清楚，才能准确的诊断出丢包的原因。目前各个厂商对于丢包的诊断没有更进一步的手段和方案。

为什么会这样

是什么导致了网络诊断的手段在长时间都没有什么实质性的发展呢？主要是因为以下几个方面：

• NOS本身的封闭性

• NOS厂商不愿暴露更多的细节给客户

• NOS以前都是一些专用的系统，无法提供像服务器上一些便捷的手段如tcpdump

• NOS架构通常都是mips/ppc架构，其计算能力无法与x86相比

• 芯片厂商提供的diagnosis具有相当的局限性。

• Flexible counter提供一个基于丢包原因的统计，可以基于端口统计多个丢包原因的报文个数。但是如果你想知道具体的丢包原因需要调整reason bitmap，需要对照手册进行调整bitmap。

• Drop statics提供了端口丢包的统计，同时提供了丢包的reason status bitmap（即发生的丢包原因）。但是可惜的这个reason status bitmap是全局的，不是基于端口的，存在一定的干扰性。

理想

想象一下当你发现网络不通的时候，你打开一个应用程序，这个程序告诉你，你的某个报文在网络中的某一台设备的某个口上因为某种原因丢弃了，然后你核对对应配置，发现配置被人修改了，然后修改配置后就通了。前后用不上几分钟就能解决问题。相比传统的两种方式，是不是要简便的多了？

为什么这么做

看到这里人们不禁要问了，为什么传统的网络厂商都没有这么做，应该是没有办法做到这样的吧？

而今是一个开放网络操作系统盛行的时代，随之一起而来的是白盒交换机，白盒交换机的控制面CPU不再是局限在传统的mips/ppc的架构，支持x86、ARM的有，而交换机服务器化的趋势也在酝酿，可以预计将来x86的交换机将会大行其道。

总的来看这个时代有两个重要的趋势：

• 开放性，用户将会越来越注重系统的开发以及开发性。

• x86释放了强大的计算能力，如何利用？

诊断与分析的难度和开放网络的趋势使得开发便利的诊断分析成为了一种必要，同时这也是一个机会。

怎么做

理想是一步步实现的，要实现这个理想需按如下几步走：

• 能够在控制台上通过show命令看到最近一段时间内的丢包的基本信息，并能够将这些基本信息导出。

• 在控制台上通过show命令看到最近一段时间内丢包的详细信息，并支持导出的基本信息的解析（wireshark插件）。

• 部署应用程序收集并按照规则统计丢包的信息。

一小步

接下来就是如何获取这些丢包的信息，针对数据中心场景下20多种丢包原因进行分析，首先将其分为两类：

• 情况一：丢包，cpu可以获取原始报文的

• 情况二：丢包，cpu无法获取原始报文的

情况一

通常转发流水线中的大部分的丢包都可以获取到其丢弃的原始报文，对应的有：

• 报文携带的VLAN未创建

• 端口不在对应的VLAN中

• 路由查找失败

• l3 mtu检查失败

• stp 状态

• 其他等

对于这些的丢包情况，可以从芯片获取其原始的报文进行分析然后归类统计。

情况二

在整个转发流水线中也存在部分的丢包是无法提供原始报文的，对应的有：

• 超过buffer水线丢包

• 解析错误丢包

• 包校验错误丢包

• ingress mtu丢包(看mtu检查实现的方式而定)

对于这些丢包情况，可以从芯片的状态信息中获取对应的状态，然后进行归类统计。

进一步

完成第一步之后，对于部分场景依然只能得到一个模糊的丢包的原因，只能对应上直接原因，对于找到根本原因还差一步，例如l3 lookup miss，如果无法知道报文的目的口ip，那么就无法继续分析下去，因此，用户查看对应的报文的详细信息的需要在此时变的非常重要。

同样我们需要分析报文信息哪些在这种场景下对用户是必要的，分析的结果如下：

• 二层头信息，smac、dmac、etype、length。

• 802.1q tag信息，tpid、VLAN id。

• 三层头信息，sip、dip、tos、ip length、ttl、ip protocol。

• arp头信息，smac、tmac、sip、tip、op_code。

• 四层头信息，source port、dest port。

一大步

将全网的丢包信息全部汇集到一个collector上进行统计分析，然后提供以下方式的统计显示，并可尽量还原其对应的流量大小。

• 基于物理设备统计。

• 基于源目的ip的统计。

• 基于源目的端口的统计。

• 基于丢包原因的统计。

通过这些统计的方式可以发现网络中存在的危险和配置问题（like kill all possible warning in coding），整个网络尽在掌握。
拥有了这个网络诊断分析功能之后，我们只需要简单的两步就可以确定丢包的原因：

• show sdrop查看丢包的基本信息。

• 如果第一步还是没有提供足够的信息，那么show sdrop detail中的包含的报文的相关信息将会准确提示其原因。

以上所述就是小编给大家介绍的《网络丢包诊断与分析的现实与理想》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• 同态加密的现实与虚幻
• 现实世界的模型与理论
• 前端八大灵感设计，代码变为现实
• RealityKit 增强现实应用开发
• 揭穿AI的神话与现实
• 150行JavaScript代码实现增强现实

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。