能不能期望我們每一位網管員都能夠解決網絡運行中出現的所有問題呢?通過多年網絡管理的總結認為，如果預先采取一定的措施，并且使用正確的故障診斷方法，那么回答是肯定的。下面給出了一個較為完整的過程，敬請各位同行批評指正。
及時更新網絡圖
首先應該繪制一個網絡方框圖。這個文檔的作用是為從事故障診斷的人員提供一個關于網絡布局和配置的全部信息的單一來源。網絡圖上包含的主要內容有：
●路由器的連接圖;
●設備的序號、型號及端口情況;
●使用的路由協議(如RIP、OSPF等);
●IOS版本(用于具有何種性能查找和判別);
●已安裝的模塊;
●訪問控制列表;
●地址(網絡地址和序號，MAC地址更好);
●交換機(型號);
●集線器(Hub型號);
●所有配置的拷貝。
當網絡使用發生變化時，要及時更新網絡圖。如果沒有更新網絡圖，那么您的網絡圖的用處就要大打折扣，這將是非常危險的。如果出現這種情況，您必須馬上繪制一幅新的網絡圖，而不是依賴那個不能反映實際情況的老的網絡圖。
當網絡以通常方式運行時，必須符合網絡性能的基線。基線用來記錄網絡在低、中和高使用量時的信息量。它建立了一個網絡運行性能的記錄，該記錄可以用來進行比較，以確定是否出現問題。網絡運行性能基線中包含以下主要內容：
●網絡上運行了哪些協議;
●每個協議使用的帶寬百分比;
●每個協議的峰值使用量和平均使用量;
●數據包的大小以及每種大小數據包的百分比;
●循環冗余校驗(Cyclical Redundancy Check，CRC)發現的錯誤的峰值和平均值;
●網段每秒鐘傳輸的信息幀的峰值和平均值;
●是否存在超長的數據包;
●沖突域每秒產生的沖突的峰值和平均值;
●網段運行的峰值和平均值。
故障診斷方法與步驟
正確地確定問題是解決問題的關鍵。下面我們按照順序介紹故障診斷方法、步驟。應該注意的是這些步驟往往是相互重疊的，而且解決問題的方法實質上是循環式的。
⑴確定網絡問題的性質;
⑵收集有關的情況并對問題進行分析;
⑶分析問題產生的原因;
⑷設計一個解決問題計劃;
⑸實現這個解決問題計劃;
⑹評估該解決問題計劃產生的結果;
⑺重復上面的操作，直到問題得到解決;
⑻將解決方案記入文檔資料。
確定網絡問題的性質實際上就是要提出問題。即“誰出了問題，是什么問題，何時產生和出現在何處”這樣的形式。這些問題可能會多次出現，您可以向用戶、網管員、以及遇到或者了解問題的其他人詳細提問：誰受到了問題的影響?是單個用戶還是存在共性的一組用戶，甚至是整個網絡中的所有用戶呢?
若是單個用戶可能出現下列若干問題中之一
●物理層問題，包括發生故障的網絡電纜。可用Ping來測試;
●在特定主機上的硬件故障。用Ping 127.0.0.1或Ping本機地址來檢測;
●軟件加載不正確或者崩潰了，尤其是網絡協議出了問題。可重裝軟件或刪除網絡協議后重新加載網絡協議;
●主機地址或者子網掩碼設置不正確。可修正主機地址和子網掩碼;
●默認網關配置不正確。可用Tracert檢測，重新修正默認網關。
擁有公共屬性或者遇到問題的一組用戶可能出現下列若干問題
●網絡設備(比如集線器或者交換機)發生了故障;
●路由器接口發生故障;
●服務器發生故障;
●訪問列表設置錯誤;
●VLAN配置錯誤。
在我們知道“誰出了問題”后，就要集中精力解決：這個問題有何表現?是沒有連接還是只有部分連接的問題，或者是根本沒有連接的問題呢?如果是沒有連接的問題，那它就屬于：
●硬件故障;
●遠程通信服務故障;
●路由協議故障。
如果是部分連接的問題，那它屬于
●訪問列表問題;
●子網掩碼不正確;
●路由協議不兼容。
這個問題何時發生呢?是間歇性出現還是經常發生的問題，或者是剛剛發生的問題呢?
如是間歇性發生的問題，其原因可能是
●遠程通信服務故障;
●信息擁擠;
●路由循環。
如是經常發生的問題，那么原因是信息擁擠。出現新問題的原因是
●訪問列表發生變化;
●新的硬件故障;
●路由協議發生變化;
●新增加的路由。
正確確定網絡問題的性質，是我們判斷是廣域線路問題還是局域網中的問題的基礎。
解決故障步驟
收集有關的情況并對問題進行分析
主要包括對設備進行觀察，設法了解問題究竟存在什么位置。可以通過查看路由器的接口和進程命令，查看內存、緩存和CPU的使用情況等等。在查看過程中，應記錄發現的情況，以便評估存在問題的原因。如遇到間歇性失去連接的問題，注意查看該接口復位了多少次。如果問題與訪問列表相關，就需要查看訪問列表是如何設置的，與現有文檔的注釋進行比較，判斷是否一致。如現有的設置與文檔不一致，應審查更新文檔的策略。在盡可能收集到各種情況后，即可轉入對問題原因的分析工作。
分析產生問題的原因
就是要確定這個問題本身有什么表現，誰受到了這個問題的影響。如果我們不知道這個情況，就需要倒退一個或兩個步驟，重新思考這個問題。如果收集到正確的信息，那么在解決問題模型中，這是最容易執行的步驟之一。知道誰受到了問題的影響，這個問題有何表現，問題在何時發生，以及問題發生在何處。剩下的唯一問題就是這個問題為何會發生。當我們對OSI模型有一個透徹的了解時，解決這個問題對故障診斷者來說就變得易如反掌了。因此要求我們對OSI模型的每一層協議功能要非常熟悉，才能從中獲得重要的線索，以確定問題為何會發生。
當您認為問題的原因已經找到后，應該再花一點時間來確定其他還有什么原因導致問題的產生。您應該避免只找出單個原因。只有找到確定的原因越多，您解決問題的可能性就越大。因此要盡量找出可能的故障原因，按降序列出導致故障的可能原因，并從中找出最有可能的故障原因。
設計解決問題計劃
只有當確定了導致問題產生的最有可能的原因時，才能制定一個操作計劃。包括為了解決問題而計劃使用的操作步驟。在確定操作步驟時。應盡量做到詳細;這個計劃越詳細，按照這個計劃執行的可能性就越大。一旦制定好計劃，就要按步驟實施這個計劃。
實施解決問題計劃
當在實施操作計劃時，以特別注意，每次只能作一個修改。如果修改后問題解決，那么應該將修改的結果進行分析并記入文檔。如果修改沒有成功，應該立即撤消這個修改。重要的是要按照制定的計劃來進行操作。因為在實施計劃中，有時由于某一步不行，很容易嘗試新的方法。這樣做的危害是很快就失去對原計劃的跟蹤線索，結果往往使情況變得更加槽糕。一旦發現原計劃不可行，正確的方法是應該重新設計計劃，然后實施新的計劃。
另外，在實施操作計劃時，應特別注意安全程序的執行。安全性是我們最擔心的事情。不要或者盡量少開放網絡，在解決問題時，也應該盡可能縮短放松安全性的時間。前者可以阻止不太精明黑客突破網絡的企圖，后者可以減少黑客在在網絡安全性放松時攻擊網絡的可能性。
評估操作計劃產生的結果
觀察結果最簡單的方法是用第一步中獲得的數據來測試。問題的表現或者某些表現是否仍然存在呢?如在第一步中簡明說明了存在的問題，那么就可以較容易地測定問題地表現是否存在。如果問題的某些表現已經解決，但其他的表現仍然存在，那么將解決方案記入文檔，然后轉入下一個操作步驟。
間歇性問題的測試并不是那么容易進行。有時要等到發生另一個故障時才能進行測試。在這種情況時，在最終確定問題之前，必須把對系統的修改記入文檔，這是非常重要的。
重復操作過程
在完美無缺的環境中，根本不需要重復上面的操作過程，因為我們對問題的分析肯定能夠指明存在的一個問題，也是唯一的問題。但在實際工作中我們很少能夠做到完美無缺。當操作計劃不能產生預期的結果時，首先應該撤消試圖解決問題時所做的所有修改。如果保留這些修改，可能導致出現一些遺留問題。
下一步是搞清什么地方分析失敗了。通過確定問題的性質來重新啟動這個操作過程，這是非常重要的。對問題進行分析時，要對自己提出的所有假設多問幾個為什么。重新確定問題的性質，當第二次設法解決問題時，要花費更多的時間去考察問題的細節，深入到問題的內部去看一看。如第一次解決問題時有些情況沒有注意到，應該確保第二次解決問題時不要犯與第一次同樣的錯誤。
