|
sniffer簡明教程
sniffer是由NAI公司提供的強大的協議分析儀，完整的sniffer系統，除了我們經常使用的以太網模塊外，還具有廣域網模塊，廣域網模塊需要專用的硬件支持。比如E1/FR/POS/ATM等，均需要硬件模塊配合。這裏再強調一點，以太網模塊的sniffer，NAI也提供了專用的網卡，專用網卡是針對sniffer軟件做了優化，在捕獲報文的性能上要強於普通網卡。我們通過sniffer捕獲報文做故障分析時，千萬要記住，大流量的鏈路假如用普通網卡捕獲報文可能出現部分報文漏捕獲情況，這對分析丟包問題是極爲不利的，所以往往我們多捕獲幾份報文作爲分析的可靠依據來擬補工具的不足。
接下來，我們對sniffer的使用做簡單的介紹。Sniffer的具體運用請大家研讀ftp服務器上的sniffer課程。
一、捕獲數據包前的準備工作
在默認情況下，sniffer將捕獲其接入碰撞域中流經的所有數據包，但在某些場景下，有些數據包可能不是我們所需要的，爲了快速定位網絡問題所在，有必要對所要捕獲的數據包作過濾。Sniffer提供了捕獲數據包前的過濾規則的定義，過濾規則包括2、3層地址的定義和幾百種協議的定義。定義過濾規則的做法一般如下：
1、在主界面選擇capturedefine filter選項。
2、define filteraddress，這是最常用的定義。其中包括MAC地址、ip地址和ipx地址的定義。以定義IP地址過濾爲例，見圖1。 xiong2127 51cto技術博客 比如，現在要捕獲地址爲10.1.30.100的主機與其他主機通信的信息，在Mode選項卡中，選Include(選Exclude選項，是表示捕獲除此地址外所有的數據包)；在station選項中，在任意一欄填上10.1.30.100,另外一欄填上any（any表示所有的IP地址）。這樣就完成了地址的定義。 注意到Dir.欄的圖標：
 表示，捕獲station1收發的數據包；
 表示，捕獲station1發送的數據包；
 表示，捕獲station1收到的數據包。
最後，選取  ，將定義的規則保存下來，供以後使用。
3、define filteradvanced，定義希望捕獲的相關協議的數據包。如圖2。
比如，想捕獲FTP、NETBIOS、DNS、HTTP的數據包，那麼說首先打開TCP選項卡，再進一步選協議；還要明確DNS、NETBIOS的數據包有些是屬於UDP協議，故需在UDP選項卡做類似TCP選項卡的工作，否則捕獲的數據包將不全。 如果不選任何協議，則捕獲所有協議的數據包。
Packet Size選項中，可以定義捕獲的包大小，圖3，是定義捕獲包大小界於64至128bytes的數據包。
4、define filterbuffer,定義捕獲數據包的緩衝區。如圖4： Buffer size選項卡，將其設爲最大40M。
Capture buffer選項卡，將設置緩衝區文件存放的位置。
5、最後，需將定義的過濾規則應用於捕獲中。如圖5： 點選Select FilterCapture中選取定義的捕獲規則。
二、捕獲數據包時觀察到的信息
CaptureStart,啓動捕獲引擎。
sniffer可以實時監控主機、協議、應用程序、不同包類型等的分佈情況。如圖6：
Dashboard:可以實時統計每秒鐘接收到的包的數量、出錯包的數量、丟棄包的數量、廣播包的數量、多播包的數量以及帶寬的利用率等。
Host Table：可以查看通信量最大的前10位主機。
Matrix:通過連線，可以形象的看到不同主機之間的通信。
Application Response Time:可以瞭解到不同主機通信的最小、最大、平均響應時間方面的信息。
History Samples:可以看到歷史數據抽樣出來的統計值。
Protocol distribution:可以實時觀察到數據流中不同協議的分佈情況。
Switch:可以獲取cisco交換機的狀態信息。
在捕獲過程中，同樣可以對想觀察的信息定義過濾規則，操作方式類似捕獲前的過濾規則。
三、捕獲數據包後的分析工作
要停止sniffer捕獲包時，點選CaptureStop或者CaptureStop and Display,前者停止捕獲包，後者停止捕獲包並把捕獲的數據包進行解碼和顯示。如圖7：
Decode:對每個數據包進行解碼，可以看到整個包的結構及從鏈路層到應用層的信息，事實上，sniffer的使用中大部分的時間都花費在這上面的分析，同時也對使用者在網絡的理論及實踐經驗上提出較高的要求。素質較高的使用者藉此工具便可看穿網絡問題的結症所在。 Expert:這是sniffer提供的專家模式，系統自身根據捕獲的數據包從鏈路層到應用層進行分類並作出診斷。其中diagnoses提出非常有價值的診斷信息。圖8，是sniffer偵查到IP地址重疊的例子及相關的解析。
sniffer同樣提供解碼後的數據包過濾顯示。
要對包進行顯示過濾需切換到Decode模式。
Displaydefine filter，定義過濾規則。
Displayselect filter,應用過濾規則。
顯示過濾的使用基本上跟捕獲過濾的使用相同。
四、sniffer提供的工具應用 sniffer除了提供數據包的捕獲、解碼及診斷外，還提供了一系列的工具，包括包發生器、ping、trace route、DNS lookup、finger、who is等工具。
其中，包發生器比較有特色，將做簡單介紹。其他工具在操作系統中也有提供，不做介紹。
包發生器提供三種生成數據包的方式：
點選  ，新構一個數據包，包頭、包內容及包長由用戶直接填寫。圖9，定義一個廣播包，使其連續發送，包的發送延遲位1ms點選
 ，發送在Decode中所定位的數據包，同時可以在此包的基礎上對數據包進行如前述的修改。xiong2127 51cto技術博客可以定義連續地發送buffer中地數據包或只發送一次buffer中地數據包。請特別注意，不要在運行的網絡中重放數據包，否則容易引起嚴重的網絡問題。數據包的重放經常用於實驗環境中。
交換機做鏡像端口使用
從sniffer的工作原理我們知道，與其在一個衝突域的報文均能被盡收囊中，對於交換機來說，一個物理端口就是一個衝突域（不像Hub所有端口均出在一個衝突域），爲此，大部分交換機均提供端口鏡像功能，便於監控鏈路承載的報文情況。如下圖：
這裏需要說明的是，Hammer系列交換機中，mirror功能在不同產品線存在不同的問題，這些問題對於我們做報文分析是極爲不利的。要求我們清楚瞭解各個產品的mirror特性。下面舉兩個例子說明：
比如G產品線的百兆電口在做端口鏡像時，如果監控端口與被監控端口不在一個控制器（一組端口）中的話，只能抓到進端口的包，出端口的包抓不到。
µHammer3550-48交換機內部由兩塊芯片堆疊而成的硬件特點，其中芯片1包括端口1-12、25-36、50，芯片2包括端口13-24、37-48、49，由於mirror不能跨芯片建立，因此建立端口鏡像時只能在端口1-12、25-36、50或端口13-24、37-48、49範圍內建立。
Hub使用注意事項
某些交換機不提供端口鏡像功能或者在路由式網絡的情況下，需要在網絡中加入Hub來擴大某個衝突域的端口數，便於sniffer接入其中。如圖所示：
在原來的網絡插入Hub時，要特別注意Hub端口的工作狀態，保證設備雙方互連端口狀態完全一致，否則強引入新的丟包點。比如Hub不具有端口自協商能力，且只能工作在半雙工狀態，而交換機的端口原先被設置爲全雙工狀態，顯然，Hub加入鏈路，在大流量情況下，必然引起丟包。
出自 51CTO.COM博客 |
，發送buffer中所有的數據包，實現數據流的重放。見圖10：
XX電信網絡故障分析報告
一、某運營商網絡故障現象描述
該運營商城域網建設採用LAN、ADSL等多種接入技術。對於ADSL用戶報文采用802.1Q封裝，實現二層透傳到達BAS，由BAS提供相應的服務；而LAN接入用戶則由三層交換機來實現三層快速轉發，市局和各縣局網絡形成輻射狀星型結構。
安圖、敦化方向的接入爲城域網的重要組成部分，由於光纖資源的原因，敦化局通過安圖局匯接到市局中心，具體見該運營商安圖、敦化方向的網絡拓撲圖：
xiong2127 51cto技術博客
xiong2127 51cto技術博客
該方向由於接入用戶多（特別是敦化MA5100下連用戶），因此有網絡流量大、匯接層交換機需要透傳更多VLAN ID等特點。在用戶上網的高峯期（一般爲中午1點至3點，晚上8點至12點），出現如下現象：
1、安圖、敦化ADSL用戶上網速度慢，ping BAS的IP或長春DNS地址出現嚴重丟包，丟包率達到10％左右。
2、安圖、敦化ADSL用戶pinge Alpine3808地址不出現丟包。
3、安圖、敦化LAN接入用戶上網沒有出現異常現象，ping BAS的IP或長春DNS地址不出現丟包。
4、在安圖、敦化Flex24上ping BAS的任一個IP或長春DNS地址均出現嚴重丟包，丟包率在10％左右。
5、在安圖、敦化的Flex24上ping Alpine3808的IP地址不出現丟包。
2、安圖、敦化ADSL用戶pinge Alpine3808地址不出現丟包。
3、安圖、敦化LAN接入用戶上網沒有出現異常現象，ping BAS的IP或長春DNS地址不出現丟包。
4、在安圖、敦化Flex24上ping BAS的任一個IP或長春DNS地址均出現嚴重丟包，丟包率在10％左右。
5、在安圖、敦化的Flex24上ping Alpine3808的IP地址不出現丟包。
二、網絡故障分析及定位
從上面描述的故障現象看，問題似乎與BAS的相關性比較大。是否與BAS的處理能力有關呢？事實上，BAS還負擔着市局、其他地市大量的用戶，其他用戶沒有出現類似的網絡故障。與BAS分佈式的結構有關嗎?從客戶工程師瞭解到BAS關於安圖、敦化用戶配置部分與其他地方是一致的。
爲了準確地定位問題所在，我們從下而上對安圖、敦化方向的網絡健康狀況做了全面的檢測。
1、首先在安圖對MA5100報文轉發情況進行檢測
在安圖MA5100下找一ADSL用戶做測試機，測試示意圖如下：
pc向202.98.0.68發300個ping報文，pc最終顯示發送了300個包，接收225個報文，丟包率25％。
pc向202.98.0.68發300個ping報文，pc最終顯示發送了300個包，接收225個報文，丟包率25％。
在Flex24上將21端口的報文鏡像到19端口，在19端口通過sniffer捕獲報文。
從19端口捕獲到的報文看，217.62.100.11向202.98.0.68發送了300個icmp echo
request報文，202.98.0.68向217.62.100.11回了225個icmp echo reply報文。
request報文，202.98.0.68向217.62.100.11回了225個icmp echo reply報文。
從檢測結果看，MA5100對報文的轉發正常，丟包出現在上級網絡。
2、對安圖的Flex24報文轉發情況進行檢測
2、對安圖的Flex24報文轉發情況進行檢測
爲了檢測Flex24的報文轉發情況，採用上述類似的測試手段。在Flex24上將Flex24的24端口鏡像到19端口（關閉原先的鏡像配置，啓用新的鏡像配置），pc再向202.98.0.68發300個ping報文，pc最終顯示發送了300個包，接收224個報文，丟了76個報文，丟包率25％。
從Flex24的19端口捕獲到的報文看，217.62.100.11向202.98.0.68發送了300個icmp echo equest報文，202.98.0.68向217.62.100.11回了224個icmp echo reply報文，丟棄了76個。
從檢測結果看，76個報文顯然在Flex24的上級網絡被丟棄，問題出現在上級網絡。
3、對Alpine3808的報文轉發進行檢測
原先計劃對Alpine3808報文轉發檢測採用上述類似的手段，但由於現場的種種限制（Alpine3808的鏡像端口上不能準確捕獲到所需報文，懷疑Alpine3808鏡像有問題；若採用HUB接入到鏈路中來捕獲鏈路中報文，也可以達到目的，但HUB於鏈路中的光電收發器端口協商存在問題，一邊端口工作在半雙工、另一邊端口工作在全雙工，因此回導致網絡工作異常，沒有采用該方式），採用了另外一種手段。
由於在BAS上ping(源IP爲218.27.194.2)218.27.194.9，在用戶上網高峯期出現嚴重丟包，而ping 218.62.89.129不出現丟包；在安圖Flex24上ping（源IP爲218.27.194.9）218.62.100.1同樣出現嚴重丟包。因此斷定Alpine3808三層轉發正常而二層轉發異常！
由於在BAS上ping(源IP爲218.27.194.2)218.27.194.9，在用戶上網高峯期出現嚴重丟包，而ping 218.62.89.129不出現丟包；在安圖Flex24上ping（源IP爲218.27.194.9）218.62.100.1同樣出現嚴重丟包。因此斷定Alpine3808三層轉發正常而二層轉發異常！
218.27.194.2 ping 218.27.194.9之間的通信在Alpine上是實現二層透傳；218.27.194.2 ping 218.62.89.129 之間的通信在Alpine上是實現三層轉發。
218.27.194.9 ping 218.62.100.1之間的通信稍爲複雜點，218.27.194.9向218.62.100.1發icmp echo request報文在Alpine3808上是通過三層轉發，但218.62.100.1向218.27.194.9回icmp echo relpy報文時，在Alpine上是通過二層轉發（這是因爲218.62.100.1/24和218.27.194.2/192在 BAS上均爲直連網段，218.62.100.1向218.27.194.9的報文只在BAS做三層轉發，其他設備只需二層透傳）。
種種跡象表明Alpine3808二層轉發存在嚴重問題！
4、進一步確認故障點
從故障現象看，用戶報文在Flex24、Alpine3808上通過三層轉發的不會出現丟包現象；而通過二層轉發的均有丟包想象。
再次檢測Flex24的二層轉發情況：
再次檢測Flex24的二層轉發情況：
在用戶上網的高峯期，Apline3808上ping（源IP爲218.27.194.1）敦化Flex24的IP（218.27.194.10）,不會出現丟包，顯然報文在安圖Flex24上實現二層轉發，再次證明Flex24的二層轉發正常。
問題只能出現在Alpine3808的二層轉發上。
三、對故障現象的一一解釋
三、對故障現象的一一解釋
1、安圖、敦化ADSL用戶上網速度慢，ping BAS的IP或長春DNS地址出現嚴重丟包，丟包率達到10％左右。
現象解釋：ADSL用戶報文通過Alpine3808二層透傳到達BAS，因此出現丟包。
2、安圖、敦化ADSL用戶ping Alpine3808地址不出現丟包。
現象解釋：ADSL用戶和Alpine3808之間的通信，與Alpine3808二層透傳無關。
3、安圖、敦化LAN接入用戶上網沒有出現異常現象，ping BAS的IP或長春DNS地址不出現丟包。
3、安圖、敦化LAN接入用戶上網沒有出現異常現象，ping BAS的IP或長春DNS地址不出現丟包。
現象解釋：LAN接入用戶上網報文在Alpine3808上通過三層轉發，因此不丟包。
4、在安圖、敦化Flex24上ping BAS的任一個IP或長春DNS地址均出現嚴重丟包，丟包率在10％左右。
現象解釋：BAS向Flex24相應的報文，在Alpine3808上是實現二層透傳，因此丟包。
5、在安圖、敦化的Flex24上ping lpine3808的IP地址不出現丟包。
現象解釋：Flex24與Alpine3808之間的通信，與Alpine3808的二層透傳無關，因此不丟包。