协议分析器是网络管理员库中最强有力的工具之一。它能将难处理、耗时长、让CEO们感到恼火甚至不得不重启所有机器的问题转变为能短时处理、易于在每周例行状态报告中反映的问题，为公司省下大量的时间与金钱。
然而，就像其它任何复杂工具一样，它必须被适当运用才能获得最大的效益。在使用协议分析器诊断网络故障时，应当尽量避免……
错误1 分析器误置
正确放置分析器对快速诊断故障具有决定性作用。设想分析器是置于网络中的窗口，犹如建筑物窗口一般，视野的改变依赖于从哪个窗口看出去。从南面窗口望去是看不到建筑物北面高速公路上交通的拥挤状况的。在分析置于网络不当位置的分析器时，跟踪往往要花很长时间。那么，怎样正确放置分析器呢？我们可以举例说明。
以下为几个可能出现的问题及原因分析：
设想A：一台主机，服务器A，主机不能与其它任何主机通信。可能的原因：
1） 服务器A没有正确配置；
2） 服务器A配置的网卡出错；
3） 服务器A所在局域网出了问题；
4） 服务器A所在局域网段出错。
设想B：一台主机，服务器B，主机不能与远程网X中的任何一台主机通信；且局域网或其它远程网中的主机无任何故障（这就意味着问题不可能出现在服务器B或服务器B所在局域网段上）。
可能原因：
1） 服务器B有关网络X的部分配置错误；
2） 服务器B用于连接到网络X的路由器所在网段的连接出了问题；
3） 服务器B所在局域网与网络X的一处或多处链接出了问题；
4） 网络X用于连接到服务器B所在网络的路由器所在网段出了问题；
5） 网络X出了问题。
设想C：一台主机，服务器C，主机不能与局域网中另一主机通信，但与网络中其它主机通信正常（这意味着问题不可能出现在服务器C或服务器C所在局域网段）。
可能的原因：
1） 主机C错误配置；
2） 主机C网卡出现故障；
3） 主机C所在局域网段出了问题。
设想D：一台主机，服务器D，主机不能与一远程主机通信，但与服务器D所在局域网段的其它主机通信正常，到远程网或远程网自身的连接亦无故障。
可能原因：
1） 主机D错误配置；
2） 主机D网卡出错；
3） 主机D所在局域网段出了问题。
这些问题当中个别的不用分析器也可诊断或排除。例如：设想A中的第三种情况，就能通过检查服务器A所在局域网的其它主机决定故障所在；设想D中的第二和第三种情况亦能通过这种方法确定（假设主机D能与局域网中其它主机通信）。
一台服务器或主机的错误配置通过检测很容易被发现。但另外一些问题，像网络或网段中的故障，就需要分析器来诊断。
在以上所有可能的设想中，一开始或许会将分析器置于离最有可能出现问题的主机或是怀疑有问题的网络、网段尽可能近的地方，但是如果未发现有意义的问题，得准备好移动分析器，要知道，在出现故障的位置被确定以前，所做的一切都是建立在猜想基础上的。在以上设想B的第三种情况中，服务器B所在局域网和网络X中都应该有分析器，至少分析器应该能够从一端被移动到另一端。
例如，一次故障中，一台服务器突然停止了工作。人们起初怀疑是站点人员对服务器实施了误操作所致，实际上跟踪器表明，是因为众多主机向服务器发送连接请求信息的同时服务器却没有响应，致使服务器死锁。
在花了几天时间来判断到底服务器出了什么问题后，被告知观察跟踪器，于是请求站点操作员将跟踪器从主机所在局域网（这里指设想B中第三种情况的网络X）移到服务器所在局域网。结果发现访问控制列表没有被正确添加到服务器所在局域网的路由器上，这份错误的访问控制列表过滤了所有来源于客户端主机所在网络的信息。假若当初多一些怀疑的话，就会发现在服务器所在局域网中根本就没见到过连接请求信息。因为没有同时查看网络两端的情况，致使站点很多天不能工作。
怎么知道跟踪器在网络的哪一端起作用呢？在跟踪器中，发自客户端主机的帧信息都具有实客户端所有的源MAC地址，与此同时，目标MAC地址则存放在路由器中。
不幸的是，问题变得越来越复杂，仅仅知道分析器连接于哪个网络还不够。当将一个局域网分解成多个部分时，首要的是去找到空闲Hub端口或同轴电缆的分接头，然而，在网络交换环境下，并不是仅仅将分析器接入交换设备的空闲端口就万事大吉了。
大多数交换设备都具备将特定端口指定为分接头或映像端口的能力，只是所用术语因交换设备制造厂商不同而有别。如果所有来自或发往特定端口的通信同样能发送到映像端口，这时只要将分析器连接到映像端口，所有设置即告完成。
但问题在于有些交换设备不能将两端口之间的通信发送到映像端口。举例说，在双工环境下，作为监控的连接之一部分的两台主机能同时发送信息，交换机也能接收每帧数据并将其传输到链接中的另外端口。但对于映像端口，必须对某一数据帧进行缓冲，如果这样处理了太多帧，缓冲区就会溢出，数据帧就会丢失，跟踪因此变得不可靠。更糟的是，根本就不知道是在跟踪不可靠的线索。
某些交换设备支持内部分析器功能，这类交换机本身能够俘获传向被跟踪对象的数据帧。这种功能部件的可靠性依赖于交换机的缓冲容量。在某些情况下，我们不得不选择映像端口或是内部分析器方式。但只要有可能，最好是将主机之一和分析器连接到Hub，并将Hub挂到交换机上。
为什么这么做呢？这是因为即使确信交换机有足够容量缓存所有数据帧，以至于映像端口或内部分析器不可能丢数据，跟踪仍然是不可靠的。例如，标准以太网中，一个处于交换机有故障端口的RJ45连接器每当交换机向服务器传输数据帧时都会创建交互式会话，交换机将此解释成为一次冲突并停止工作，当尝试16次之后数据帧就会撤消，但数据帧仍被发送到映像端口，因此跟踪器发现了数据帧并显示服务器响应失败。另一种情况是：不合规格的配线导致1%的数据帧破坏。如果将分析器与第一种情况（任何位置的数据帧都能传送）中提到的的主机一起挂到Hub，或者与第二种情况（网络中有被破坏的数据帧）中主机一起挂到Hub，接收交换机的端口会在未将数据帧发往映像端口之前就将它们撤消，跟踪器没有任何错误指示。当然，每当改变一种方式，都得冒一定风险来纠正可能出现的意外问题。如果RJ45连接器出现故障仅仅是因为没有在交换机端口将其固定好，那么只要将连接器重新插入Hub，故障或许也就不存在了，至少问题是得到了解决。
另外需要记住的是，对于交换设备，在其网段内每个端口都是有效的，因此当连接到服务器的交换端口未发现问题时，应将Hub（或分析器）移动到主机或路由器交换端口。
还有，注意不能将Hub挂到双工环境。有些分析器能以双工方式工作，这类分析器有两个以太网口和一个功能模块，功能模块将通信对分为两部分，并分别发送到每一以太网口，之后软件把从每个以太网口接收来的数据结合成单一的跟踪链。如果网络是双工环境，就需要这种分析器。
错误2 过多的过滤
过滤功能允许协议分析器忽略某些数据帧，从而为感兴趣的帧腾出更多的俘获缓冲空间。如果能过滤来源于较高协议层的数据，如IP地址和端口号以至更高层数据，则分析器几乎很少需要基于源或目标MAC地址的过滤。然而，实际跟踪中通常出现的问题是过滤太多。
有一个站点出现过这样的故障：服务器与一特定客户端之间的连接出了问题，莫名其妙地断开了，其它客户端都没有任何问题。由于客户端与服务器处在同一子网，一旦发生断开现象，使客户端与服务器恢复连接的唯一办法是重新启动服务器。
这个站点安装了分析器，同时因为数据量大，配置了过滤器，只允许俘获两主机（基于MAC地址）之间的数据帧。前两天中没有发现问题，但在第三天问题出现了：跟踪表明服务器突然停止了发送多路会话和最后一次会话。当从服务器端ping客户端时，跟踪器显示服务器没有发送任何数据帧。站点操作员得出的结论是：TCP栈或操作系统出了问题。
于是请求另一次跟踪，这次没有使用过滤器。一天半以后俘获了另一事件：跟踪清楚表明服务器持续发送数据，而与此同时却再也没有得到应答。经过更深层挖掘，发现服务器数据帧的目标MAC地址突然改变了。
既然目标MAC地址不再与客户端的相匹配，那么第一次未使用过滤器的跟踪就不再俘获到MAC地址，同时表明服务器已停止了工作。另外发现就在地址改变之前，服务器无故收到带有为客户端IP地址配置的新MAC地址的ARP信息包，这导致服务器升级ARP缓存并向错误主机发送数据。
通过ARP数据帧的源MAC地址由无故发送ARP的主机向下跟踪，不知何故，主机居然同时配置了复用于客户端的静态IP地址和DHCP地址。当主机启动时，分配的是静态地址，这与服务器相冲突，于是调用DHCP，正确地址才配置上。
基于这一点可得出这样一个结论：用过滤器看似很有道理，但很多时候问题的根源往往以假象出现在过滤器之外，如果跟踪器没有表明问题的起因，过滤器应当关闭，或至少应当扩展一下，直至跟踪器确实查出原因。仅当所有过滤器都关闭后跟踪器仍无法查出问题起因，才可以得出结论――对网络已无计可施
