本文將描述一種對TCP/IP網絡進行故障診斷的結構化方法。此篇可以作爲引子，後面的文章我們將討論本文所涉及到的一些關鍵問題。
那麼，在你聽到“TCP/IP網絡故障診斷”這個詞的時候，你想到了什麼?許多人可能會看到一張流程圖。或者說想到了操作步驟有幾步的問題。還有許多人可能會感到茫然，無從下手。
TCP/IP的故障診斷似乎看起來簡單，畢竟，這僅僅是一個擁有四層協議的體系結構，每一層有多種協議。不過，表面的簡單並不意味着故障能夠輕鬆解決。下面我們先看看：
傳統的故障診斷方法
幾年前，在筆者第一次學習TCP/IP的網絡組建時，理解了幾個簡單的故障診斷的流程，這個流程大體涉及到如下的幾個方面：
鍵入ipconfig，用以檢查IP地址、子網掩碼、默認網關是否正確。
1. 運行ping 127.0.0.1,查看網絡適配器是否正在工作。
2. 運行ping 探測本機的IP地址是否正確或合法。
3. 試着ping同一子網內的任何一臺計算機的IP地址，看是否ping通。
4. 試着ping一下默認網關(即路由器上將你的子網連接到網絡其餘部分的接口)，看是否ping通。
5. 試着ping不同子網的一臺計算機的IP地址
6. 試着ping外網的一臺計算機的IP地址。
筆者覺得這種方法有點兒僵化，因爲我們幾乎可以不用動腦子就可以遵循這些步驟。而且還有點兒效率低下，因爲從其過程來看，它先假定你自己的計算機最可能有問題，而且問題極可能離你很近(你的網卡、計算機的IP地址配置、本地子網)，然後纔是遠程計算機的問題。在互聯網還沒有真正快速發展之前，這個方法也許不錯,也就是說，在DNS成爲被廣泛採用的域名解析系統之前，在防火牆和***等成爲多數企業的網絡部分之前，這個方案也許不錯。
筆者的意思是：如果你的一個用戶說：“我現在不能連接到服務器上。”那麼問題會出在哪裏呢?我們有必要將用戶的這句話分解爲幾部分，以便於進一步理解問題。
第一部分-“我不能…”：
那麼，我們應該問一下，是否只有一個用戶報告網絡問題呢?如果還有其他人，他們出現的問題類似嗎?如果是這樣的，那麼問題很清除了，你不需要採用上述的僵化方法，直接開始對用戶的計算機開始故障診斷即可以。否則，問題極有可能出現在其它地方，這可能意味着你的DNS服務器離線了或你的DNS供應商服務出現了問題。或者內部網絡上的某個路由器出了問題，出現丟包現象。或許你的用戶正試圖連接的服務器已經崩潰。
或許你應該停下來，想一想這些出現故障的用戶可能存在的共同問題。例如，這些機器都位於相同的子網上嗎?如果是這樣的話，那麼有可能那個子網的默認網關配置錯誤或者路由器癱瘓。或許是某個工作人員將連接子網的工作組交換機到骨幹交換機的網絡電纜切斷了。或許是某個惡意用戶將一個欺詐性的DHCP服務器安裝到那個子網上了，這個惡意用戶正竊取機器的IP地址，而將一些不可路由的地址分配給那些計算機，從而形成拒絕服務的故障。
當然，如果只是一個用戶存在着這種問題，那麼就需要我們問這樣一些問題，如“計算機開機了嗎?網絡電纜安全地安裝到了計算機的後部了嗎?”
“…連接到…”
可以問這位用戶這樣一個問題“你所說的連接是什麼意思?”這是因爲“連接”是一個技術性很強的詞語，許多用戶其實並不真正理解所談論的東西。爲什麼呢?因爲存在着不同種類的連接，包括MAC級的通信、TCP會話、口令驗證、訪問權限和特權、跨NAT的連接、防火牆的通過、應用層的會話等等。作爲網管員需要知道用戶的問題是什麼。當這些用戶說不能“連接到”服務器時，他們正在做什麼?是在訪問此服務器上的一個共享嗎?在訪問時是否收到了一個“拒絕訪問”的消息呢?這些用戶是否收到一個登錄窗口，提示其輸入相關憑證呢?(如賬戶名、口令等)服務器拒絕其憑證了嗎?這些用戶在找到或使用活動目錄中的共享時發生了問題了嗎?他們發現問題的是一個映射驅動器嗎?他們是不是正通過瀏覽網上鄰居來查找服務器呢?等等。
這些用戶僅在連接某臺服務器時纔出現故障嗎?或者，這些用戶是不是在連接到任何網絡節點時都出現故障?在這裏，決定問題或故障的範圍是很重要的：連接是一個方面或多個方面呢?
“…服務器…”
你搞定了這個用戶，而且搞定了那臺服務器，也搞定了其間的網絡。它們仍不能連接?爲什麼呢?需要注意的是那臺服務器到底在什麼地方呢?它在用戶的子網上嗎?在一個相鄰的子網上嗎?在一個不同的部門上嗎?在一個不同的樓層上嗎?在一個不同的大樓上嗎?是哪種網絡將用戶與特定的服務器連接起來?是無線以太網嗎?是無線局域網嗎?是互聯網上的***通道嗎?是撥號的modem連接嗎?是線纜modem還是DSL modem?首先決定用戶和服務器之間的連接類型(有可能是幾種)，然後思考哪個地方有可能出現故障?有可能是CSU/DSU出了故障，可以試着給它重新加電或與應該監視CSU/DSU的供應商聯繫。也有可能是某人在打掃衛生時碰到了電源開關，導致某個以太網交換機離線。如果你用的是可網管型交換機，也可以檢查網絡管理軟件的警告信息。也有可能是遠程服務器所在的辦公室發生了電源中斷。可以試着電話諮詢一下。
用戶是僅與一臺服務器無法連接，還是無法與多臺服務器不能連接?其他人也不能連接到那些服務器上嗎?在受影響的服務器之間有什麼共同的東西嗎?(問題有可能與用戶的計算機有關，更有可能與網絡架構自身有關)
“…現在”
時間因素在故障診斷中是至關重要的。應該問一下：問題是剛剛發生嗎?上次成功連接到服務器是在什麼時候?這種現象持續了多長時間?是連續性的還是間斷的?斷斷續續的網絡問題涉及到不可靠的WAN鏈接以及其它一些難於解決的問題，特別是這些問題持續很短暫時間或偶爾出現時更是這樣。
時間因素還有可能將問題與可能影響網絡的其它情況聯繫起來。問題是出現在今天上午10點20分嗎?彼時你的網絡還出現了哪些問題?WSUS服務器上打補丁了嗎?域服務器上的預定維護實現了嗎?
結構化的方法
筆者自己的TCP/IP網絡的結構化故障診斷的方法由三個關鍵部分組成：
1. 決定問題的因素。也就是說要考慮如下方面：
· 客戶端：即出現問題的客戶端
· 服務器端：客戶無法訪問的服務器、打印機或其它的網絡資源(如互聯網)等。
· 其間的網絡：線纜(如果不是無線的話)、集線器、交換機、路由器、防火牆、代理服務器，以及客戶端和服務器之間的其它網絡架構。
· 環境：可能會影響你的網絡的外部情況，如電源的波動、建築物的維護等等。
· 範圍：一個或多個有關的客戶端/服務器端。
· 期間：連續的、間斷的，還是偶爾的，何時開始等。
· 出現問題的連接類型：物理層、網絡層、傳輸層還是應用層?身份驗證還是訪問控制?等等。
· 標誌性信息：客戶端機器上的出錯消息，登錄對話框等等。
2. 在考慮到以上問題因素時，決定需要應用哪些故障診斷措施，這些措施包括：
驗證有關客戶端、服務器和網絡架構硬件的物理媒體。也就是說檢查電纜，確保網絡適配器正確安裝，並進一步查找、驗證可以顯示媒體斷開狀態的網絡連接。
驗證有關客戶端、服務器、網絡架構硬件的TCP/IP配置。在客戶端上這意味着檢查IP地址、子網掩碼、默認網關、DNS設置等等。對於網絡架構硬件而言，也就是指路由器上的路由表和Internet網關。
驗證有關客戶端和服務器端的路由選擇的連通性。也就是說要使用ping，pathping，tracert，或其它類似的工具，便於在網絡層上驗證端到端的TCP/IP的連接性;採用數據包嗅探以監視傳輸層會話;使用nslookup，telnet和其它的工具來診斷包括域名解析問題、身份驗證等應用層問題。
3.理解之、詢問之、測試之:
理解協議如何工作，數據包如何由路由錶轉發，netdiag.exe等工具能夠告訴你什麼是非常關鍵的。成功的TCP/IP故障診斷是建立在理解TCP/IP如何工作和有關測試工具的基礎之上的。如果你從來沒有努力理解網絡監視器的跟蹤模式，那麼你在診斷某些問題時就會遇到困難。
問一些恰當的問題對於成功的故障診斷也很關鍵。要學會何時按部就班，何時以跳躍性思維直奔主題是故障診斷藝術的本質所在，這還括充分使用你的左右腦，即要有充分的想象和縝密的思維。
最後，踏踏實實地測試，並隔離問題是很關鍵的，爲此你需要故障診斷的工具箱。而且沒有什麼比豐富的經驗更能幫助你解決複雜問題了。
小結
診斷TCP/IP網絡的故障時可能會使人灰心喪氣，不過也充滿樂趣。在未來的文章中，我們將祥細闡述故障診斷的措施和工具，以幫助你成功地解決網絡中出現的問題。