====================================================================================== 本文轉自於我的個人博客：www.vants.org，該文鏈接爲：http://www.vants.org/?post=27，後續我的大部分文章將首先發布在我的個人博客，歡迎大家關注。 ======================================================================================
當我們在工作中遇到疑難雜症時，我們需要有一個明確的分析流程和清晰的分析思路，不能東一槍西一炮，上來就抓包。明確的流程和思路可以讓我們少走彎路，節省我們寶貴的時間，大大提高我們分析定位故障的效率。
下面我們將針對這個流程圖逐一進行擴展講解。
1 故障信息的收集
一般情況下，我們需要收集的故障信息主要包含故障相關的拓撲結構，路由設置，相關設備的地址信息等。
網絡拓撲
故障發生的網絡拓撲結構是我們首先需要搞清楚的信息。拓撲結構爲我們提供了故障環境下，從客戶端到服務器端大致的網絡連接情況，包含經過的各種網絡設備、網絡鏈路等。下圖爲一個網絡拓撲圖的例子：
拓撲圖的例子
路由情況主要指故障環境下，各個網絡層轉發設備處的路由設置情況，包括客戶端和服務器端網絡環境中的三層交換機、路由器、防火牆等路由表信息。
我們可以通過路由信息和拓撲結構，分析出數據包交互的來回路徑。
相關設備的地址信息
相關設備的地址信息主要指故障客戶端、服務器的IP地址、默認網關、路由設置等信息 。
2 驗證故障現象
我們需要在故障現場，通過與用戶的充分溝通和我們自己的親身體驗，確認具體的故障現象。
3 常規測試和分析
常規測試主要指利用ping、tracert、telnet、nslookup等常用工具，對故障進行常規性的測試，從而判斷包括網絡層的延時丟包情況、經過的路徑、服務開啓情況、DNS解析的情況等信息。我們在這些常規測試的基礎上，結合檢查相關設備的ARP表、路由表、訪問控制列表等配置信息，大致分析判斷出故障是否需要通過分析數據報文交互的方式來定位。
另一方面，在條件許可的情況下，常規測試還包含通過多次改變環境、置換相關關鍵設備觀察故障現象的有無來分析判斷故障產生的大致位置，排除跟故障無關的設備和環境，是爲後續的數據包分析提供思路依據，提高故障分析定位效率。
4 確認故障範圍
確認故障範圍主要是確認故障是屬於全局故障還是局部故障。
全局故障
全局故障主要指整個網絡都出現故障現象，如全網中斷、全網緩慢等。
全局故障一般多爲核心設備處理性能不足或核心鏈路利用率過高導致，較爲常見的原因遭受了來自內部病毒或外部的惡意***，一般具有較爲明顯的流量異常情況，我們需要在覈心交換機處部署網絡分析工具，捕獲核心交換機或者核心鏈路上的數據報文，查看是否存在流量過大（BT下載、DOS***）、TCP會話、UDP會話數過高等異常的主機、是否存在各種***（ARP、蠕蟲、DOS、掃描等）數據包，這些具有明顯異於正常水平的流量參數可以幫助我們快速定位異常的原因類型和源頭。
具體參數請大家參考《流量分析相關參數說明》一文，常見流量異常情況的分析定位請大家參考《常見流量異常分析》一文。
局部故障
局部故障主要指部分網段、部分主機、部分應用等出現故障，這些問題往往是個體現象，如VLAN2丟包嚴重、FTP服務登陸不上、部分地方***隧道建立異常等。
局部故障一般都具有一定的分析難度，我們一般需要通過數據交互的過程和數據報文的封裝來判斷定位。
5 確定數據報文交互路徑
有一些故障，特別是業務應用的故障，客戶端與服務器端在進行業務數據流交互時，中間會經過各種鏈路和中間設備。當客戶端反饋業務應用存在故障，我們僅僅在某一個點（客戶端、服務器端或者其他中間鏈路處）進行抓包，是無法真正反映故障真實面貌的，我們需要多點同步抓包，這樣才能完整的反饋業務數據流在網絡中交互的全部過程。在這個完整交互的過程中，我們通過對比分析，可以發現故障發生的位置和原因。
結合故障環境和路由情況，確認出現故障的業務系統的訪問路徑，需要重點了解清楚這個路徑中所要經過的網關型設備，同時需要了解清楚業務訪問數據流的來回路徑是否一至。
6 確認故障關鍵點
網絡數據報文在交互的過程中，其經過了客戶端、客戶內網、客戶內網網關、外網、服務器端網關、服務器內網、服務器的各種處理，這些點都會針對交互數據報文的相關情況進行相應的處理，包括請求、檢測、修改、轉發、丟棄、響應等。網絡數據報文交互的過程既然有這麼多的點參與處理，那麼當一個網絡數據報文交互出現故障時，任何一個點都有可能是導致故障的原因，爲了提高我們分析定位的效率，我們首先需要找出最有可能影響數據交互的關鍵點。
在瞭解清楚數據報文交互路徑的情況之下，我們就可以確認可能的故障關鍵點了。這裏面需要特別注意的是：關鍵點的選擇，一定要跟具體的數據報文交互路徑結合起來。
我們爲了簡化結構、突出重點，提高分析的效率，我們一般會將實際網絡環境進行抽象，將其劃分爲由端系統和中間系統組成的網絡，如下圖所示：
端系統、中間系統圖示
在這個結構中，我們需要分析的關鍵點只有兩個，那就是端系統和中間系統。
端系統關鍵點
客戶端
首先，客戶端是網絡交互數據的發起者，是整個數據交互過程的起點，也是數據交互過程中的，客戶端網絡行爲的基準點；另外，客戶端也可能需要對服務器的響應數據進行相應處理並作出迴應，在這些過程中，有可能存在客戶端本身處理的問題導致整個數據交互過程出現問題，因此，客戶端是一個非常重要的關鍵點。
服務器端
服務器端是服務器所有網絡行爲的基準點；同時，服務器端需要對客戶端的請求做出相應的處理和響應，這些處理過程本身可能導致網絡數據交互的故障，因此，服務器端跟客戶端一樣，是一個非常重要的關鍵點。
中間系統關鍵點
中間系統爲各種對網絡交互數據報文進行不同處理的設備，我們在做分析的時候，主要針對可能會對交互的數據進行檢測、修改、丟棄等處理的網關設備，包括路由器、防火牆、流量控制設備以及各種應用層檢測防護設備等。
由於這些設備的工作原理和特性以及可能存在的策略失誤、性能不足等原因，其在處理交互數據包的過程中，可能存在修改、丟棄數據的行爲，從而導致網絡交互故障的產生，因此，中間設備也是我們分析過程中的一個關鍵點。
7 確定故障類型
在離故障點最近的位置抓取故障時的數據交互報文，在此主要指故障客戶端主機報文和故障服務器端報文。
一般情況下，我們可以按照如下步驟確認故障的類型：
1，在故障客戶端機器上，部署網絡分析工具，開啓抓包；
2，在故障客戶端機器上，還原故障現象，也就是通過操作，讓故障現象發生，然後捕獲到這個故障現場的交互報文；
3，捕獲到故障現場的數據報文後，停止抓包；
4，通過網絡分析工具分析具體故障交互時的數據包；
5，通過分析，定位導致故障的類型。
故障類型主要分爲兩類，一類爲端系統問題導致的故障，如服務器端處理延時、業務系統本身BUG等，此類故障主要爲端系統本身問題；另一類爲中間系統原因導致的故障，如中間系統較大的轉發延時、中間系統策略誤報過濾等導致的丟包等。如果是中間系統導致的，那麼則需要結合故障環境和報文交互路徑設計需要捕包的具體位置。
8 架設捕包環境
在需要做數據包捕獲的位置，主要爲各個故障關鍵點前後，主要通過交換機的端口鏡像功能以及鏈路串接TAP等方式實現。
這些捕包環境全部部署完成後，就可以進行下一步的工作了。
9 全面測試，做數據包的捕獲
1，在各個重點位置，利用網絡分析工具進行同步捕包；
2，在故障客戶端主機上，進行相應操作，還原故障現象；
3，故障出現後，故障客戶端主機停止相應的操作，同時，停止運行各個捕包位置的網絡分析工具；
4，使用簡單明瞭的名字，保存各個捕包位置處捕獲到的數據包文件。
10 深入分析，定位故障
捕獲到全面的數據包之後，就可以利用關聯分析法、對比分析法，確認故障發生的真正原因和位置了，關於對比分析法和關聯分析法的詳細說明請參考《疑難網絡故障的分析方法和原理》。
11 故障解決
故障原因和位置確認了，那麼解決故障就是一件很簡單的事情了。如果故障原因涉及到第三方廠商的產品，則及時聯繫相應廠商配合解決即可。