網絡管理員六類常見錯誤

協議分析器是網絡管理員庫中最強有力的工具之一。它能將難處理、耗時長、讓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，正確地址才配置上。

基於這一點可得出這樣一個結論：用過濾器看似很有道理，但很多時候問題的根源往往以假象出現在過濾器之外，如果跟蹤器沒有表明問題的起因，過濾器應當關閉，或至少應當擴展一下，直至跟蹤器確實查出原因。僅當所有過濾器都關閉後跟蹤器仍無法查出問題起因，纔可以得出結論——對網絡已無計可施了。

錯誤3

俘獲時幀太短

前面例子中表明，站點操作員使用過濾器是因爲網絡中數據量過大。分析器僅能俘獲大約3分鐘時間的數據，這使得站點操作員幾乎不可能發現問題的發生並使分析器及時加以阻止以真正找到問題的起因。分析器能夠俘獲數據幀而沒有將它們填入俘獲緩衝區的時間長短取決於網絡的速度、網絡中幀的數量、幀的大小以及俘獲緩衝區的大小。

幾乎所有分析器都能控制俘獲數據幀的大小，這在處理連接問題和不太高協議層問題時顯得很有用。在通常情況下，只要俘獲數據的第一個64字節也就足夠了。因此，如果網絡中所有幀都是1024字節而僅有3分鐘俘獲時間，那麼僅俘獲64字節將允許有超過30分鐘的俘獲時間。

錯誤4

觸發器安裝不正確

觸發器告訴分析器執行某項操作，比如終止俘獲。當等待問題發生而又不知道將何時發生時，觸發器顯得很有用。

安裝觸發器意味着沒有必要隨時以手動方式來控制分析器。觸發器安裝的最大問題往往是沒有正確定義，這會大大延長解決問題的時間。

當然，應該詳細知道怎樣安裝觸發器，並且，若有可能，在使用之前進行測試。有時可以安裝另一臺分析器來發送觸發數據幀，以確認俘獲分析觸發器已正確安裝。

使用觸發器帶來的另一問題是，許多分析器允許設置將被預觸發的俘獲緩衝區的百分比。舉例來說，可以指定50%的緩衝區在觸發之前俘獲，而另外50%的緩衝區在觸發之後俘獲。預觸發的百分比通常是0、25、50、75或100。

如果預觸發值設置不當，就有可能俘獲不到足夠的相關數據幀來診斷問題所在。預觸發值有可能被錯誤設置是因爲其默認設置對現行問題往往不適用：也許是因爲未將針對前一問題的設置升級，也許是因爲粗心的鼠標操作或錯誤按鍵。無論何種原因，一定要確認觸發器已正確安裝。

那麼怎樣來設置呢？通常是將預觸發百分比設爲100%，以知道是什麼原因導致觸發器關閉。

當然，只有當觸發器在觸發某事件時，它才處於關閉狀態。過去使用過特殊的觸發程序，它能測試狀態，然後發送信息包，分析器可將此信息包用作觸發器。測試狀態可以是日誌文件中的錯誤信息，或是上例中無法創建連接的情況。一般整個程序也就一百多行或稍長一些。

錯誤5

日期/時間設置不正確

沒有正確設置分析器上的日期/時間看似一件小事，很多時候可能也確實是這樣。然而，當處理廣域網絡中的問題時，有時同時運行兩臺分析器，網絡每端一臺，則正確設置日期/時間是相當有用的。

如果將兩臺分析器時鐘設置相同，調整跟蹤會變得更爲容易。假定在一個例子中，通過發現通用幀並比較時間，會發現其中一臺用了4小時37分，比另一臺提前了15.7891秒，如果時鐘設置同步誤差在1到2秒，時間差距計算也就容易多了。

另外，如果需要費勁地隨主機中的事件調整跟蹤，由於基於時間包的同步是不可選的，則設置相同的日期/時間絕對具有實質意義。

錯誤6 不理解協議

很多分析器具有“專家分析”功能，指的是它們能保持對信息的追蹤，像序列號、時間信息、顯示重傳信息、凍結窗口、無應答狀態等等。這類分析相當有用，但也有可能造成誤導，尤其在分析器沒有正確報錯時。

舉個例子，有一種情況：從一遠程位置發來的遠程登錄會話無法建立，而發自局域工作站的遠程登錄會話卻沒有問題。於是站點操作人員在遠程登錄服務器所在的局域網掛一分析器，跟蹤器表明從遠程主機到遠程登錄服務器的數據幀沒有報錯；於是他們得出結論是操作系統故障。

另一位操作人員查看跟蹤器發現，局域端遠程登錄會話連接到端口2323，而遠程會話連接到端口23。另外，遠程登錄服務器響應遠程連接請求的信息包包含了RST標誌設置。

在這裏，站點操作人員沒有仔細查看TCP細節，因此沒有意識到不同端口號和RST包的重要性，他們依賴來源於分析器的診斷信息，既然遠程登錄服務器的端口23沒有安裝，憑感覺猜想也認爲是操作系統出了問題。然而，若站點工作人員瞭解TCP和遠程登錄，他們就會立即發現問題所在並能在5分鐘內找到一個好的解決辦法。