各位做维护的同事经常会听到用户对网速太慢的抱怨，但是网速慢的原因有很多，比如软件设置不当，网络设备故障，物理链路问题，感染病毒等，而单单从用户的故障描述里面很难有进一步的发现，所以也许大家一时也不知道从何下手。

　　Sniffer是一个非常好的流量分析工具，利用它我们可以实际了解到当前网络中正在发生的具体流量，并且通过Sniffer的专家系统以及进一步对数据包的解码分析，我们可以很快的定位网络故障，确认网络带宽的瓶颈，在故障发生前及时消除网络隐患，这样能给我们日常的维护工作带来很大的方便，也使得我们的维护工作处于主动地位，不会再只有接到用户故障投诉后才能处理故障，在时间和效率上都不能很好的让用户满意。

    对出口流量进行分析

　　下面是借助Sniffer对我某地市分公司出口流量做的一个简单的流量分析，没有什么很深的技术含量，也并不需要太深的专业知识，希望能对大家日常的维护工作有一定启发。 分析目标：了解目前带宽实际利用率，检查有无网络隐患。

　　分析方法：
　　在核心交换机上做端口镜像，利用sniffer抓包。 
　　测试地点：中心机房
　　抓包开始时间：5.17 10:20
　　抓包持续时间：16s
　　数据包个数：88865
　　平均带宽利用率：7％

　　1、首先我们了解一下网络中协议的分布情况，通过sniffer的Protocol Distribution功能可以直观的看到当前网络流量中协议分布图：

　　从上面可以很明显看出，HTTP应用流量最大占63％，其次就是NetBios流量占35％。

　　了解协议分布情况以后，我们再找到网络中流量最大的主机，因为流量越大也就意味着对网络的影响也就越大，如下图所示：

　　
    可以看到219.72.238.88，219.72.237.201这两台主机在目前我们网络内部流量较大，分别占16.52%和15.97％。进一步利用HostTable功能的Outline视图，可以发现这两个地址流量的90％都是HTTP流量，如下图所示：

    锁定：90％都是HTTP流量
　　
　　我们可以从上图注意到，219.73.238.88这个主机上行流量要明显小于下行的流量，而219.72.237.201这个主机则是上行流量明显大于下行流量，通过确认219.72.238.88为一台Web服务器，219,72,237,201则是其他公司托管我在我公司的一台服务器，所以到这一步我们就可以大致知道这两个主机当前正在进行的网络活动。
　　
　　同时我们要注意的就是每个地址的收发包数量是否正常，即是否收发之间存在较大差异，如果只收不发或者只发不收，那很可能就意味着这个主机的当前流量有异常（例如受到SYN攻击），我们可以进一步通过sniffer提供的Decode功能对捕获的数据包进行解码，来分析具体的数据包内容。比如我们通过定义一个过滤器来查看上面两个地址的具体数据流量,如下图所示：

　　我们可以看到在这些HTTP应用里面，TCP的三次握手都很完整，排除了恶意的SYN攻击行为，都是正常的HTTP流量。附:也许从这次的例子看不出有什么异常，实际上在大部分的情况下一旦网络出现异常，可以在第一时间直观的通过HostTable功能找到问题的根源。

　　2、查看sniffer的专家系统，发现存在大量的Local Routing（本地路由）告警，sniffer中对此告警的解释为：Two DLC stations on the same segment are communicating via a router. Packets are being transmitted via the router rather than directly from one DLC station to the other（大致意思是两个属于同一网段的主机之间通过路由器通信，数据包通过路由器发送而不是直接在两主机间转发）。并提示可能原因为路由表设置不当。(如下图所示)

    警告：流量来自私网139端口
　　
　　通过查看告警来源，发现流量均为来自私网地址的139端口连接，通过sniffer的Protocol Distribution的Packet排序可以看出Netbios协议流量占所有流量的80％，即当前网络中80％的数据包都是Netbios协议数据包。如下图所示：

    很明显出现这种现象是不正常的，我们可以在所捕获的数据包里定义过滤器，选择只查看Netbios协议，进一步了解具体的数据包内容（如下图所示）：

　　发现存在大量网内的私网地址发起的139端口连接请求，而且全都是TCP的SYN请求，TCP的三次握手只有一次，很可能受到了SYN攻击。数据包大小都是62字节，而且每个数据包之间发送间隔都在1ms内，排除人为发起TCP请求的可能。通过观察数据包的源，目的IP地址，发现源地址很分散，目的地址均为实际并不存在的IP地址，但根据我公司IP地址规划都属于某地市分公司私网地址段。根据流量的特征，初步判断为私网用户感染蠕虫病毒，病毒通过139端口与大量虚假IP地址建立连接，造成网络中存在大量短数据包，严重降低网络运行效率。

    问题：TCP连接请求进行不断的循环重传

　　同时我们还发现当前网络对每一个TCP连接请求进行不断的重传，直到TTL值过期之后才被丢弃。通过跟踪查看某个地址的重传数据包，发现一个奇怪的现象：

　　上面两幅截图是Sniffer捕获的172.17.60.126对172.17.46.14发起TCP连接请求的两个数据包，可以看到在数据包的网络层里面有两个选项：Identification，Time to live（TTL）。Identification是用来唯一标识主机发出的每个数据包的，正常情况下每个数据包的ID都不一样，而TTL是用来限制数据包在网络中经过的跳数的，每经过一跳TTL值就减1，直到TTL值为0的时候数据包就被丢弃，主要是防止当网络中出现环路时数据包的循环传送。而在上图可以看到，这两个数据包的Identification是一样，只是TTL值相差1。这就表示这两个数据包实际上是同一个数据包（因为ID一样），只不过被发出去以后又被送回来了。到了这里，我们可以初步怀疑是否出现了路由环路。

    总结：路由环路、中毒机器

　　进一步在中心机房尝试tracert172.17.46.14这个IP地址跟踪路由，发现路由在中心机房交换机和地市交换机之间形成环路，数据包在环路不断往返，直到TTL值过期才被丢弃。

　　通过查看中心机房交换机路由表，发现配置了静态路由，将172.17.44.0/22这段地址指向了地市分公司交换机，而在分公司交换机配置的私网地址池里面只配置了172.17.44.0/23，并没有包括172.17.46.0这段地址，所以在里面找不到对应的路由，故将流量通过默认路由又传回至中心机房，从而形成环路。检查针对其他网段的异常流量时同样出现这种情况。所以，当感染蠕虫病毒的机器与大量实际并不存在的地址建立139连接时，借助静态路由设置不当的漏洞，这些数据包在网络中循环传送，消耗了大量网络带宽，降低了网络的运行效率。所以针对以上流量分析，我们可以得出以下结论：

    ⑴目前网络中存在大量中毒机器，并且正在试图通过局域网感染其他主机，最好能及时通知客户做杀毒处理，消除网络隐患。

    ⑵出于安全方面的考虑，建议拒绝基于139端口的流量。

    ⑶中心机房交换机上需要更改静态路由，取消路由环路。

　　上面的文章只是一个抛砖引玉，其实Sniffer还有很多强大的功能，希望大家能在平时多多使用，互相交流经验，进一步提高我们的日常维护工作效率。