用Sniffer和ARP分析網絡問題

用Sniffer和ARP分析網絡問題

電信網絡內部一套112測試系統，涉及到一系列服務器和測試頭（具備TCP/IP三層功能的終端），原有的拓撲在電信內網（DCN）中。因爲測試範圍的擴大，有些機房沒有內網接入點，變通的方案是在城域網上創建一個×××，將那些沒有DCN接入點的測試頭設備接在此×××上，而後此×××經過一個防火牆（PIX）與DCN作接口。能夠將這些測試頭看做一些提供測試服務的服務器，使用NAT靜態轉換將這些測試頭映射爲DCN內網網段上的IP地址，內網的一些客戶端使用這些映射後的地址訪問測試頭。
　　方案實施後，用DCN內網設備訪問有些測試頭，時通時不通，對這些局點的112測試工做帶來了極大的困擾。經過使用Sniffer抓包工具，結合對ARP協議的理解，逐步分析出了故障的真正緣由，解決了問題。這個分析解決問題的思路本人本身以爲有概括總結的必要，因此成文推薦給你們，共同窗習。

　　故障現象說明

　　112系統的部分網絡拓撲圖如圖1所示。




故障現象

　　1.DCN中的112CLIENT有時訪問不到測試頭A。112CLIENT ping 不通測試頭A，網關F上也ping 不通測試頭A。
　　2. F上始終有ARP記錄：例如嘉興某NPORT測試頭A
　　Internet 10.0.2.70 118 0090.e809.b82f ARPA FastEthernet0/1
　　3. 若是F上clear arp，則112CLIENT再ping，能夠ping通。
　　4. 若是不採起步驟3，用DCN內機器telnet 134.100.200.10（測試頭B），再用B來ping 10.0.2.70(測試頭A)，能ping通。再用112CLIENT ping A，能ping通。
　　5. 將測試頭換下，換上同IP地址筆記本電腦，沒有任何問題。
　　對問題的預先判斷中，有兩種傾向性猜想，以下：
　　◆ A：NPORT測試頭的TCP/IP實現不規範。測試頭是廠家應局方要求加工組裝的，其TCP/IP協議簇的實現是創建在NPORT MOXA卡上的，主要是爲了實現TCP/IP與SERIAL協議之間的轉換。而這種實現的可靠性並無100%的把握。若是是這個緣由，需廠家解決。
　　◆ B：寬帶交換機的設置不科學。交換機的ARP條目失效時間對其ARP對照表有很大影響，設的過短，很快就失效，包過來後就會不知道流向哪一個端口，會被交換機丟棄。寬帶交換機屬於數據部門維護，通常狀況下不會提供給咱們口令，沒有確實的判斷，他們通常不肯意改交換機設置。
　　因此確實的定位問題的所在，是咱們解決故障的先決條件。
　
　　查找故障源

　　在不能肯定故障源的狀況下，咱們同時從以上兩種傾向性猜想的角度出發，力圖從兩個方向作出解釋，最後找出符合實際的故障點。
　　首先，改變拓撲結構如圖2所示，網關接口之一鏈接一臺共享帶寬的HUB，HUB上的兩個端口分別鏈接寬帶部分和一臺運行Sniffer的電腦。這樣，Sniffer能「抓」到全部寬帶與網關F之間的包。




針對現象一：IDSCLIENT ping不通測試頭A

　　測試動做一：
　　1）網關F上有A的ARP記錄。
　　112_edge#sh arp | include 10.0.2.70
　　Internet 10.0.2.70 3 0090.e809.b82f ARPA FastEthernet0/1
　　2）用內網的IDSCLIENT來ping A，結果ping不通。
　　用Sniffer抓包，從圖3中能夠清楚地看出，ICMP探測包從網關F準確地向目的A 10.0.2.70（09B82F）發送,但A沒有迴響應包。因此結果爲ping不通。

基於兩種猜想，故障的緣由可能解釋有： 　　解釋A：應該爲A的ARP緩存中沒有網關F的ARP記錄，因此A找不到網關的MAC地址，並且它對這種「找不到網關的MAC地址」不做爲（NPORT測試頭對ARP的實現不完善）。 　　解釋B：鏈接測試頭A的寬帶交換機中的MAC對端口的對應記錄過時，在MAC地址表中目的MAC地址無對應端口，交換機丟掉此包。 　　針對現象二：將測試頭換下，換上同IP地址筆記本電腦，沒有任何問題。 　　測試動做二： 　　1）A的位置換上一臺電腦hongjing（IP與A一致）,且讓網關F有hongjing的ARP記錄。 　　112_edge#sh arp | include 10.0.2.70 　　Internet 10.0.2.70 3 000b.dbe0.1de9 ARPA FastEthernet0/1 　　2）IDSCLIENT2(134.100.5.52) ping 10.0.2.70(HONGJING),能ping通。 　　基於兩種猜想，故障的緣由的解釋有： 　　解釋A：包從網關F中發過來，ICMP探測包準確的發送到目的A 10.0.2.70,hongjing一樣因爲本機ARP緩存中沒有網關F的記錄，不能當即發送ICMP迴應包。但hongjing沒有「不做爲」，而是根據ICMP包的源IP地址跟本身的掩碼判斷此ICMP查詢包發自廣播域外，因此hongjing當機立斷，向本廣播域發起ARP查詢，要查出網關10.0.0.1的MAC地址，查到後，將ICMP迴應包發送到10.0.0.1,因此網絡能通。 　　對比動做一，動做二的網絡包分析，不難發現問題所在。相同的條件與狀況下，產生「通」與「不通」的兩種結果，關鍵在於測試頭（A）與電腦（hongjing）對ICMP查詢包的「態度」不同所致。電腦hongjing的態度「積極」，當沒有該包的傳遞者F的MAC地址時，會千方百計找到「回答」的路徑，並「回答」。而測試頭A的態度「消極」，收到詢問包時，發現本身沒有該包傳遞者F的MAC地址時，沒有采起任何措施，保持「沉默」，因此沒回答。 　　解釋B：筆記本電腦hongjing一接上交換機後馬上發出廣播包，通知局域網內其餘機器，hongjing的MAC地址是多少。此時，交換機記下hongjing-MAC與端口的映射。因此包從網關F過來後，能到達測試頭A。 　　針對現象三：「若是F上clear arp，則112CLIENT再ping ，能夠ping通」 　　測試動做三： 　　登陸網關F,執行clear arp命令，而後在內網中，用IDSCLIENT ping A，結果能夠ping通。 　　基於兩種猜想的緣由解釋： 　　解釋A：原本因爲測試頭的「消極」，是不通的。但網關F上執行了clear arp命令後，網關F因爲ARP地址影射清空，F不知網關的MAC，會向廣播域發送ARP包，該包中包含了本身的MAC地址。根據RFC826，雖然廣播域中的機器不會迴應此包，但會將F的MAC地址記錄到ARP緩存中，因此能使得本不通的112CLIENT pingA能ping通。 　　解釋B：網關F上執行了clear arp命令後，網關F因爲ARP地址映射清空，F不知網關的MAC，會向廣播域發送ARP包，該包中包含了本身的MAC地址。測試頭A上連的交換機會將F的MAC地址和相關端口綁定；A迴應此ARP請求時，交換機又會將NPORT測試頭A的MAC地址與相關端口綁定。因此後續的鏈接能通。 　　針對現象四：「用DCN內機器telnet 134.100.200.10（測試頭B），再用B來ping 10.0.2.70(測試頭A)，能ping通。再用112CLIENT ping A，能ping通。」 　　測試動做四： 　　用內網機器IDSCLIENT telnet 到134.100.5.66，而後從134.100.5.66上ping 測試頭B，結果原本ping不通的，如今能夠ping通了。 　　基於兩種猜想的緣由解釋：　　 　　解釋A：此現象用猜想A解釋不了。 　　解釋B：測試頭B向測試頭A ping時，先會發ARP廣播，測試頭B迴應此ARP請求。這個過程當中，A上連的交換機會將A<->相應端口，B<->相應端口的記錄記在地址端口映射表。 　　因此F到A的包就能通了。 　　至此，能夠排除猜想A。同時，因爲同一批次的NPORT測試頭在其餘地區及內網用的比較正常，因此，傾向於猜想B。爲進一步證明猜想B，進一步作了如下測試。 　　作動做一的時候，在交換機與A間抓包。看是否有源地址爲F的物理地址，目的地址爲A的物理地址的包從交換機端口出來，結果確實無包被監聽到，因此，從理論上得出，猜想B是正確的。從理論上定位出正確的故障緣由後，咱們義正詞嚴的聯繫數據部門，請他們修改了部分交換機的ARP失效時間。通過一段時間的檢驗，系統運行良好，原有故障消失。 　　本次排障工做中，咱們堅持理論指導實踐，對每種可能的故障緣由進行不偏不倚的分析，在客觀公正不帶主觀臆想的前提下，對每種觀點進行逐步考察，終於肯定故障點，解決了問題。