抓包的那些事

提到抓包，很多工程师都不陌生，但什么情况下需要抓包以及如何在现网中利用好抓包工具来帮助大家解决网络中莫名其妙的问题都是众说纷纭、不一而足。很多技术论坛、技术帖里说明的都是通过抓包解决网络问题，但是很少有提及抓包的方式方法、抓包过程、抓包范围以及抓包原因。本文中，将综合我在处理网络问题中的一些经验，从经验中简明扼要的说明抓包过程中的一些要点，给大家抛砖引玉，期待给大家在工作中能带来些许的帮助吧，文中有不足的地方，请大家不吝指正、共同进步！

工欲善其事必先利其器。首先要提到的就是抓包工具，我个人比较常用的是Wireshark,前身就是大名鼎鼎的Ethereal。这款抓包软件的特点就是便捷快速、资源消耗小、操作简单，兼容性高，除了更深层次和不具普遍性的细分协议外，能够满足大部分网络中的问题协议分析。另外还有，诸如Sniffer、WinNetCap、Spynet等，都是很不错的抓包工具。其中本人之前有用过的是Sniffer，和Ethereal比较下，功能细分更多、更强大，但对电脑的配置要求较高。个人认为更适合于研究协议和分析协议的专业人士使用，对于我们专注于解决日常网络问题的工程师来说有些高端了。

选好适合自己使用习惯的的抓包工具后，接下来就说一下什么情况下我们才需要抓包。简单的说就是当传输链路、配置软调、设备硬件、供电系统都确认没有问题，而网络问题（尤其是指网络延迟大、丢包率高）依旧存在的情况下，这时就需要利用到我们的抓包工具了。通常情况下，当客户向我报告网络延迟大或丢包率高的故障时，我第一件需要与客户确认的是近期网内是否有增加新设备或新业务；其次再确认网络问题的边界，是网内资源还是网外资源甚至全网资源访问异常；最后才确认设备的运行情况和配置增删情况。毕竟这些配置变更、设备故障、电源供电系统问题都是小概率事件，而且故障辨识度较高（除非设备厂商有一些不为人知的小bug，如果碰到了，那真的是中彩蛋了）。

在经过了故障筛选，对问题有了初步了解后，就需要进一步来确认问题范围了。少数情况下，这类延迟大、丢包率高等相关问题会发生在访问网外资源下，网外资源的访问需要经过第三方传输链路，第三方对于我们而言是未知的。从我们工程师的职责角度来说，未知往往意味着简单，我们在问题定位中也不需要操心太多，主要就是查看客户边界设备本端和对端WAN口下的输入/出统计参数是否有异常，诸如crc、error以及数据量统计等。crc、error等主要确认传输线路的物理介质可靠性，端口输入/出数据量统计主要用于确认租用带宽与应用带宽的匹配度，应用带宽大于租用带宽在内网没有数据量没有异常的情况下，通常也是造成丢包和延迟的问题之一。当然判断数据量有无异常仍需要综合考虑端口下的组播、单播、巨帧、MTU等数据予以评估确诊。另外针对现场传输线路模式的不同，方法也可以灵活多变，文中不再详述。本范围内，建议不要在跨边界的WAN口上做抓包工作，因为抓包后的信息量太大，会干扰我们对问题的判断定位。过多经过上一步的故障检查，基本上可以确认或排除广域网链路的问题。

以上说明的是少数情况，主要考虑到运营商作为基础网络的运营承载方，其网络质量在现实应用中还是相当过硬的。下面涉及的是多数情况下问题的处理，这类问题基本上发生在内网里。内网资源虽然可控性、识别度高，但常常因为网络管理人员监管不力，常有无厘头的问题发生，且集中是二层或客户端问题，诸如客户端乱装软件、病毒感染、乱接二层网络设备、乱插网线等现象屡见不鲜。经过多年网络监管规范度的发展提升后，对客户端问题都有了严格控制和监管，即使出现了类似的问题也容易解决，通常查一下STP、ARP、MAC等表项，逐层次逐网段的排查即可。此情况下可以适当利用抓包工具配合使用，直接监控选择问题网段涉及的trunk口，利用Ethreal里的排序功能，对数据信息量较大的地址做filter。在针对该地址下的报文信息做排序，再一次把异常应用filter出来，该客户端存在的问题就一目了然了。有可能发现的应用是我们不知道的，但通过查看底部的封包信息，每个七层协议中下三层的下拉菜单信息，尤其是物理层的数据包大小，慢的原因就彻底查明了。比较棘手的问题是，客户端内网访问没有问题，外网链路也没有问题，但偏偏内网访问外网突然就有问题的现象，这时候往往都会把问题第一定位在边界设备的硬件上，但前面已经提到硬件设备发生问题是小概率事件，当发生这类问题就只能通过抓包来发现解决问题了。以三层网络结构来举例，通常我们会监控边界设备与内网核心设备互联的边界设备的端口，这个端口可以理解成内网的WAN口，它的下一跳也就是上面提到的与第三方互联的端口了，选择这个接口做抓包的原因，就是因为内网访问外网所有的数据都需要经过该口出去，而我们需要解决的问题也正是内网访问外网异常。既然利用抓包工具搜集内网访问外网的所有数据，那么搜集到的数据量势必很大，这就更需要我们利用好抓包工具的排序和Filter功能。由于数据量太大，我一般会优先使用Filter功能，先将主流的IP、TCP等协议筛选出来，再针对具体的协议做排序功能，最后再对频度高信息做深入研究和逐一筛排，最终定位问题、解决问题。

信息的筛选和搜集是我们工程师这个层级需要把握住的，对于简单的、常用的诸如IP、ICMP、VRRP、TCP等协议我们可以通过自己去分析，对于非常见的、专业性的协议我们可以将问题升级，打包给研发或专业人士协助分析，但第一手的信息资料是需要工程师先行筛选和把握到位的，这也是我写此文的目的所在。

2017年03月