这个站点安装了分析器，同时因为数据量大，配置了过滤器，只答应俘获两主机（基于MAC地址）之间的数据帧。前两天中没有发现问题，但在第三天问题出现了：跟踪表明服务器忽然停止了发送多路会话和最后一次会话。当从服务器端ping客户端时，跟踪器显示服务器没有发送任何数据帧。站点操作员得出的结论是：TCP栈或操作系统出了问题。
于是请求另一次跟踪，这次没有使用过滤器。一天半以后俘获了另一事件：跟踪清楚表明服务器持续发送数据，而与此同时却再也没有得到应答。经过更深层挖掘，发现服务器数据帧的目标MAC地址忽然改变了。
既然目标MAC地址不再与客户端的相匹配，那么第一次未使用过滤器的跟踪就不再俘获到MAC地址，同时表明服务器已停止了工作。另外发现就在地址改变之前，服务器无故收到带有为客户端IP地址配置的新MAC地址的ARP信息包，这导致服务器升级ARP缓存并向错误主机发送数据。
通过ARP数据帧的源MAC地址由无故发送ARP的主机向下跟踪，不知何故，主机居然同时配置了复用于客户端的静态IP地址和DHCP地址。当主机启动时，分配的是静态地址，这与服务器相冲突，于是调用DHCP，正确地址才配置上。
基于这一点可得出这样一个结论：用过滤器看似很有道理，但很多时候问题的根源往往以假象出现在过滤器之外，假如跟踪器没有表明问题的起因，过滤器应当关闭，或至少应当扩展一下，直至跟踪器确实查出原因。仅当所有过滤器都关闭后跟踪器仍无法查出问题起因，才可以得出结论——对网络已无计可施了。
错误3 俘获时帧太短
前面例子中表明，站点操作员使用过滤器是因为网络中数据量过大。分析器仅能俘获大约3分钟时间的数据，这使得站点操作员几乎不可能发现问题的发生并使分析器及时加以阻止以真正找到问题的起因。分析器能够俘获数据帧而没有将它们填入俘获缓冲区的时间长短取决于网络的速度、网络中帧的数量、帧的大小以及俘获缓冲区的大小。
几乎所有分析器都能控制俘获数据帧的大小，这在处理连接问题和不太高协议层问题时显得很有用。在通常情况下，只要俘获数据的第一个64字节也就足够了。因此，假如网络中所有帧都是1024字节而仅有3分钟俘获时间，那么仅俘获64字节将答应有超过30分钟的俘获时间。
