sniffer简明教程
sniffer是由NAI公司提供的强大的协议分析仪，完整的sniffer系统，除了我们经常使用的以太网模块外，还具有广域网模块，广域网模块需要专用的硬件支持。比如E1/FR/POS/ATM等，均需要硬件模块配合。这里再强调一点，以太网模块的sniffer，NAI也提供了专用的网卡，专用网卡是针对sniffer软件做了优化，在捕获报文的性能上要强于普通网卡。我们通过sniffer捕获报文做故障分析时，千万要记住，大流量的链路假如用普通网卡捕获报文可能出现部分报文漏捕获情况，这对分析丢包问题是极为不利的，所以往往我们多捕获几份报文作为分析的可靠依据来拟补工具的不足。
接下来，我们对sniffer的使用做简单的介绍。Sniffer的具体运用请大家研读ftp服务器上的sniffer课程。
一、捕获数据包前的准备工作
在默认情况下，sniffer将捕获其接入碰撞域中流经的所有数据包，但在某些场景下，有些数据包可能不是我们所需要的，为了快速定位网络问题所在，有必要对所要捕获的数据包作过滤。Sniffer提供了捕获数据包前的过滤规则的定义，过滤规则包括2、3层地址的定义和几百种协议的定义。定义过滤规则的做法一般如下：
1、在主界面选择capturedefine filter选项。
2、define filteraddress，这是最常用的定义。其中包括MAC地址、ip地址和ipx地址的定义。以定义IP地址过滤为例，见图1。
 
 

比如，现在要捕获地址为10.1.30.100的主机与其他主机通信的信息，在Mode选项卡中，选Include(选Exclude选项，是表示捕获除此地址外所有的数据包)；在station选项中，在任意一栏填上10.1.30.100,另外一栏填上any（any表示所有的IP地址）。这样就完成了地址的定义。
注意到Dir.栏的图标：
表示，捕获station1收发的数据包；

表示，捕获station1发送的数据包；

表示，捕获station1收到的数据包。
最后，选取 ，将定义的规则保存下来，供以后使用。
3、define filteradvanced，定义希望捕获的相关协议的数据包。如图2。
 

比如，想捕获FTP、NETBIOS、DNS、HTTP的数据包，那么说首先打开TCP选项卡，再进一步选协议；还要明确DNS、NETBIOS的数据包有些是属于UDP协议，故需在UDP选项卡做类似TCP选项卡的工作，否则捕获的数据包将不全。
如果不选任何协议，则捕获所有协议的数据包。
Packet Size选项中，可以定义捕获的包大小，图3，是定义捕获包大小界于64至128bytes的数据包。
4、define filterbuffer,定义捕获数据包的缓冲区。如图4：
 
Buffer size选项卡，将其设为最大40M。
Capture buffer选项卡，将设置缓冲区文件存放的位置。
5、最后，需将定义的过滤规则应用于捕获中。如图5：
 
点选Select FilterCapture中选取定义的捕获规则。
 
二、捕获数据包时观察到的信息
CaptureStart,启动捕获引擎。
sniffer可以实时监控主机、协议、应用程序、不同包类型等的分布情况。如图6：
Dashboard:可以实时统计每秒钟接收到的包的数量、出错包的数量、丢弃包的数量、广播包的数量、多播包的数量以及带宽的利用率等。
Host Table：可以查看通信量最大的前10位主机。
Matrix:通过连线，可以形象的看到不同主机之间的通信。
Application Response Time:可以了解到不同主机通信的最小、最大、平均响应时间方面的信息。
History Samples:可以看到历史数据抽样出来的统计值。
Protocol distribution:可以实时观察到数据流中不同协议的分布情况。
Switch:可以获取cisco交换机的状态信息。
在捕获过程中，同样可以对想观察的信息定义过滤规则，操作方式类似捕获前的过滤规则。
 
三、捕获数据包后的分析工作
要停止sniffer捕获包时，点选CaptureStop或者CaptureStop and Display,前者停止捕获包，后者停止捕获包并把捕获的数据包进行解码和显示。如图7：

Decode:对每个数据包进行解码，可以看到整个包的结构及从链路层到应用层的信息，事实上，sniffer的使用中大部分的时间都花费在这上面的分析，同时也对使用者在网络的理论及实践经验上提出较高的要求。素质较高的使用者借此工具便可看穿网络问题的结症所在。
Expert:这是sniffer提供的专家模式，系统自身根据捕获的数据包从链路层到应用层进行分类并作出诊断。其中diagnoses提出非常有价值的诊断信息。图8，是sniffer侦查到IP地址重叠的例子及相关的解析。
sniffer同样提供解码后的数据包过滤显示。
要对包进行显示过滤需切换到Decode模式。
Displaydefine filter，定义过滤规则。
Displayselect filter,应用过滤规则。
显示过滤的使用基本上跟捕获过滤的使用相同。

四、sniffer提供的工具应用
sniffer除了提供数据包的捕获、解码及诊断外，还提供了一系列的工具，包括包发生器、ping、trace route、DNS lookup、finger、who is等工具。
其中，包发生器比较有特色，将做简单介绍。其他工具在操作系统中也有提供，不做介绍。
包发生器提供三种生成数据包的方式：
点选 ，新构一个数据包，包头、包内容及包长由用户直接填写。图9，定义一个广播包，使其连续发送，包的发送延迟位1ms
 
点选 ，发送在Decode中所定位的数据包，同时可以在此包的基础上对数据包进行如前述的修改。
点选 ，发送buffer中所有的数据包，实现数据流的重放。见图10：
 
可以定义连续地发送buffer中地数据包或只发送一次buffer中地数据包。请特别注意，不要在运行的网络中重放数据包，否则容易引起严重的网络问题。数据包的重放经常用于实验环境中。
交换机做镜像端口使用
从sniffer的工作原理我们知道，与其在一个冲突域的报文均能被尽收囊中，对于交换机来说，一个物理端口就是一个冲突域（不像Hub所有端口均出在一个冲突域），为此，大部分交换机均提供端口镜像功能，便于监控链路承载的报文情况。如下图：
 
这里需要说明的是，Hammer系列交换机中，mirror功能在不同产品线存在不同的问题，这些问题对于我们做报文分析是极为不利的。要求我们清楚了解各个产品的mirror特性。下面举两个例子说明：
比如G产品线的百兆电口在做端口镜像时，如果监控端口与被监控端口不在一个控制器（一组端口）中的话，只能抓到进端口的包，出端口的包抓不到。
µHammer3550-48交换机内部由两块芯片堆叠而成的硬件特点，其中芯片1包括端口1-12、25-36、50，芯片2包括端口13-24、37-48、49，由于mirror不能跨芯片建立，因此建立端口镜像时只能在端口1-12、25-36、50或端口13-24、37-48、49范围内建立。
Hub使用注意事项
某些交换机不提供端口镜像功能或者在路由式网络的情况下，需要在网络中加入Hub来扩大某个冲突域的端口数，便于sniffer接入其中。如图所示：
 
在原来的网络插入Hub时，要特别注意Hub端口的工作状态，保证设备双方互连端口状态完全一致，否则强引入新的丢包点。比如Hub不具有端口自协商能力，且只能工作在半双工状态，而交换机的端口原先被设置为全双工状态，显然，Hub加入链路，在大流量情况下，必然引起丢包。

XX电信网络故障分析报告
一、某运营商网络故障现象描述
该运营商城域网建设采用LAN、ADSL等多种接入技术。对于ADSL用户报文采用802.1Q封装，实现二层透传到达BAS，由BAS提供相应的服务；而LAN接入用户则由三层交换机来实现三层快速转发，市局和各县局网络形成辐射状星型结构。
安图、敦化方向的接入为城域网的重要组成部分，由于光纤资源的原因，敦化局通过安图局汇接到市局中心，具体见该运营商安图、敦化方向的网络拓扑图：
该方向由于接入用户多（特别是敦化MA5100下连用户），因此有网络流量大、汇接层交换机需要透传更多VLAN  ID等特点。在用户上网的高峰期（一般为中午1点至3点，晚上8点至12点），出现如下现象：
1、安图、敦化ADSL用户上网速度慢，ping BAS的IP或长春DNS地址出现严重丢包，丢包率达到10％左右。
2、安图、敦化ADSL用户pinge Alpine3808地址不出现丢包。
3、安图、敦化LAN接入用户上网没有出现异常现象，ping BAS的IP或长春DNS地址不出现丢包。
4、在安图、敦化Flex24上ping BAS的任一个IP或长春DNS地址均出现严重丢包，丢包率在10％左右。
5、在安图、敦化的Flex24上ping Alpine3808的IP地址不出现丢包。
二、网络故障分析及定位
从上面描述的故障现象看，问题似乎与BAS的相关性比较大。是否与BAS的处理能力有关呢？事实上，BAS还负担着市局、其他地市大量的用户，其他用户没有出现类似的网络故障。与BAS分布式的结构有关吗?从客户工程师了解到BAS关于安图、敦化用户配置部分与其他地方是一致的。
为了准确地定位问题所在，我们从下而上对安图、敦化方向的网络健康状况做了全面的检测。
1、首先在安图对MA5100报文转发情况进行检测
在安图MA5100下找一ADSL用户做测试机，测试示意图如下：

pc向202.98.0.68发300个ping报文，pc最终显示发送了300个包，接收225个报文，丢包率25％。
在Flex24上将21端口的报文镜像到19端口，在19端口通过sniffer捕获报文。
从19端口捕获到的报文看，217.62.100.11向202.98.0.68发送了300个icmp echo
request报文，202.98.0.68向217.62.100.11回了225个icmp echo reply报文。
从检测结果看，MA5100对报文的转发正常，丢包出现在上级网络。
 
2、对安图的Flex24报文转发情况进行检测
为了检测Flex24的报文转发情况，采用上述类似的测试手段。在Flex24上将Flex24的24端口镜像到19端口（关闭原先的镜像配置，启用新的镜像配置），pc再向202.98.0.68发300个ping报文，pc最终显示发送了300个包，接收224个报文，丢了76个报文，丢包率25％。
从Flex24的19端口捕获到的报文看，217.62.100.11向202.98.0.68发送了300个icmp echo equest报文，202.98.0.68向217.62.100.11回了224个icmp echo reply报文，丢弃了76个。
从检测结果看，76个报文显然在Flex24的上级网络被丢弃，问题出现在上级网络。
3、对Alpine3808的报文转发进行检测
原先计划对Alpine3808报文转发检测采用上述类似的手段，但由于现场的种种限制（Alpine3808的镜像端口上不能准确捕获到所需报文，怀疑Alpine3808镜像有问题；若采用HUB接入到链路中来捕获链路中报文，也可以达到目的，但HUB于链路中的光电收发器端口协商存在问题，一边端口工作在半双工、另一边端口工作在全双工，因此回导致网络工作异常，没有采用该方式），采用了另外一种手段。

由于在BAS上ping(源IP为218.27.194.2)218.27.194.9，在用户上网高峰期出现严重丢包，而ping 218.62.89.129不出现丢包；在安图Flex24上ping（源IP为218.27.194.9）218.62.100.1同样出现严重丢包。因此断定Alpine3808三层转发正常而二层转发异常！
218.27.194.2 ping 218.27.194.9之间的通信在Alpine上是实现二层透传；218.27.194.2  ping 218.62.89.129  之间的通信在Alpine上是实现三层转发。
218.27.194.9  ping 218.62.100.1之间的通信稍为复杂点，218.27.194.9向218.62.100.1发icmp echo request报文在Alpine3808上是通过三层转发，但218.62.100.1向218.27.194.9回icmp echo relpy报文时，在Alpine上是通过二层转发（这是因为218.62.100.1/24和218.27.194.2/192在 BAS上均为直连网段，218.62.100.1向218.27.194.9的报文只在BAS做三层转发，其他设备只需二层透传）。
种种迹象表明Alpine3808二层转发存在严重问题！
4、进一步确认故障点
从故障现象看，用户报文在Flex24、Alpine3808上通过三层转发的不会出现丢包现象；而通过二层转发的均有丢包想象。
再次检测Flex24的二层转发情况：
在用户上网的高峰期，Apline3808上ping（源IP为218.27.194.1）敦化Flex24的IP（218.27.194.10）,不会出现丢包，显然报文在安图Flex24上实现二层转发，再次证明Flex24的二层转发正常。
问题只能出现在Alpine3808的二层转发上。

 
三、对故障现象的一一解释
1、安图、敦化ADSL用户上网速度慢，ping BAS的IP或长春DNS地址出现严重丢包，丢包率达到10％左右。
现象解释：ADSL用户报文通过Alpine3808二层透传到达BAS，因此出现丢包。
2、安图、敦化ADSL用户ping  Alpine3808地址不出现丢包。
现象解释：ADSL用户和Alpine3808之间的通信，与Alpine3808二层透传无关。
3、安图、敦化LAN接入用户上网没有出现异常现象，ping BAS的IP或长春DNS地址不出现丢包。
现象解释：LAN接入用户上网报文在Alpine3808上通过三层转发，因此不丢包。
4、在安图、敦化Flex24上ping BAS的任一个IP或长春DNS地址均出现严重丢包，丢包率在10％左右。
现象解释：BAS向Flex24相应的报文，在Alpine3808上是实现二层透传，因此丢包。
5、在安图、敦化的Flex24上ping lpine3808的IP地址不出现丢包。
现象解释：Flex24与Alpine3808之间的通信，与Alpine3808的二层透传无关，因此不丢包。