例如，一次故障中，一臺服務器忽然停止了工作。人們起初懷疑是站點人員對服務器實施了誤操作所致，實際上跟蹤器表明，是因為眾多主機向服務器發送連接請求信息的同時服務器卻沒有響應，致使服務器死鎖。

　　在花了幾天時間來判定到底服務器出了什么問題后，被告知觀察跟蹤器，于是請求站點操作員將跟蹤器從主機所在局域網（這里指設想B中第三種情況的網絡X）移到服務器所在局域網。結果發現訪問控制列表沒有被正確添加到服務器所在局域網的路由器上，這份錯誤的訪問控制列表過濾了所有來源于客戶端主機所在網絡的信息。假若當初多一些懷疑的話，就會發現在服務器所在局域網中根本就沒見到過連接請求信息。因為沒有同時查看網絡兩端的情況，致使站點很多天不能工作。

　　怎么知道跟蹤器在網絡的哪一端起作用呢？在跟蹤器中，發自客戶端主機的幀信息都具有實客戶端所有的源MAC地址，與此同時，目標MAC地址則存放在路由器中。

　　不幸的是，問題變得越來越復雜，僅僅知道分析器連接于哪個網絡還不夠。當將一個局域網分解成多個部分時，首要的是去找到空閑Hub端口或同軸電纜的分接頭，然而，在網絡交換環境下，并不是僅僅將分析器接入交換設備的空閑端口就萬事大吉了。

　　大多數交換設備都具備將特定端口指定為分接頭或映像端口的能力，只是所用術語因交換設備制造廠商不同而有別。假如所有來自或發往特定端口的通信同樣能發送到映像端口，這時只要將分析器連接到映像端口，所有設置即告完成。

　　但問題在于有些交換設備不能將兩端口之間的通信發送到映像端口。舉例說，在雙工環境下，作為監控的連接之一部分的兩臺主機能同時發送信息，交換機也能接收每幀數據并將其傳輸到鏈接中的另外端口。但對于映像端口，必須對某一數據幀進行緩沖，假如這樣處理了太多幀，緩沖區就會溢出，數據幀就會丟失，跟蹤因此變得不可靠。更糟的是，根本就不知道是在跟蹤不可靠的線索。

　　某些交換設備支持內部分析器功能，這類交換機本身能夠俘獲傳向被跟蹤對象的數據幀。這種功能部件的可靠性依靠于交換機的緩沖容量。在某些情況下，我們不得不選擇映像端口或是內部分析器方式。但只要有可能，最好是將主機之一和分析器連接到Hub，并將Hub掛到交換機上。