這個(gè)站點(diǎn)安裝了分析器，同時(shí)因?yàn)閿?shù)據(jù)量大，配置了過濾器，只答應(yīng)俘獲兩主機(jī)（基于MAC地址）之間的數(shù)據(jù)幀。前兩天中沒有發(fā)現(xiàn)問題，但在第三天問題出現(xiàn)了：跟蹤表明服務(wù)器忽然停止了發(fā)送多路會話和最后一次會話。當(dāng)從服務(wù)器端ping客戶端時(shí)，跟蹤器顯示服務(wù)器沒有發(fā)送任何數(shù)據(jù)幀。站點(diǎn)操作員得出的結(jié)論是：TCP棧或操作系統(tǒng)出了問題。

　　于是請求另一次跟蹤，這次沒有使用過濾器。一天半以后俘獲了另一事件：跟蹤清楚表明服務(wù)器持續(xù)發(fā)送數(shù)據(jù)，而與此同時(shí)卻再也沒有得到應(yīng)答。經(jīng)過更深層挖掘，發(fā)現(xiàn)服務(wù)器數(shù)據(jù)幀的目標(biāo)MAC地址忽然改變了。

　　既然目標(biāo)MAC地址不再與客戶端的相匹配，那么第一次未使用過濾器的跟蹤就不再俘獲到MAC地址，同時(shí)表明服務(wù)器已停止了工作。另外發(fā)現(xiàn)就在地址改變之前，服務(wù)器無故收到帶有為客戶端ip地址配置的新MAC地址的ARP信息包，這導(dǎo)致服務(wù)器升級ARP緩存并向錯誤主機(jī)發(fā)送數(shù)據(jù)。

　　通過ARP數(shù)據(jù)幀的源MAC地址由無故發(fā)送ARP的主機(jī)向下跟蹤，不知何故，主機(jī)居然同時(shí)配置了復(fù)用于客戶端的靜態(tài)IP地址和DHCP地址。當(dāng)主機(jī)啟動時(shí)，分配的是靜態(tài)地址，這與服務(wù)器相沖突，于是調(diào)用DHCP，正確地址才配置上。

　　基于這一點(diǎn)可得出這樣一個(gè)結(jié)論：用過濾器看似很有道理，但很多時(shí)候問題的根源往往以假象出現(xiàn)在過濾器之外，假如跟蹤器沒有表明問題的起因，過濾器應(yīng)當(dāng)關(guān)閉，或至少應(yīng)當(dāng)擴(kuò)展一下，直至跟蹤器確實(shí)查出原因。僅當(dāng)所有過濾器都關(guān)閉后跟蹤器仍無法查出問題起因，才可以得出結(jié)論——對網(wǎng)絡(luò)已無計(jì)可施了。

　　錯誤3 俘獲時(shí)幀太短

　　前面例子中表明，站點(diǎn)操作員使用過濾器是因?yàn)榫W(wǎng)絡(luò)中數(shù)據(jù)量過大。分析器僅能俘獲大約3分鐘時(shí)間的數(shù)據(jù)，這使得站點(diǎn)操作員幾乎不可能發(fā)現(xiàn)問題的發(fā)生并使分析器及時(shí)加以阻止以真正找到問題的起因。分析器能夠俘獲數(shù)據(jù)幀而沒有將它們填入俘獲緩沖區(qū)的時(shí)間長短取決于網(wǎng)絡(luò)的速度、網(wǎng)絡(luò)中幀的數(shù)量、幀的大小以及俘獲緩沖區(qū)的大小。

　　幾乎所有分析器都能控制俘獲數(shù)據(jù)幀的大小，這在處理連接問題和不太高協(xié)議層問題時(shí)顯得很有用。在通常情況下，只要俘獲數(shù)據(jù)的第一個(gè)64字節(jié)也就足夠了。因此，假如網(wǎng)絡(luò)中所有幀都是1024字節(jié)而僅有3分鐘俘獲時(shí)間，那么僅俘獲64字節(jié)將答應(yīng)有超過30分鐘的俘獲時(shí)間。