電信網路內部一套112測試系統，涉及到一系列伺服器和測試頭（具有tcp/ip三層功能的終端），原有的拓撲在電信內網（dcn）中。由於測試範圍的擴大，有些機房沒有內網接入點，變通的方案是在都會網路上建立乙個vpn，將那些沒有dcn接入點的測試頭裝置接在此vpn上，然後此vpn通過乙個防火牆（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通。」
用sniffer抓icmp包來分析
用sniffer抓icmp包來分析。1。ping 192.168.1.1 l 0 ping乙個ip，指定攜帶的資料長度為0 抓包分析如圖 從圖上的1處我們可以看到這個資料總大小是 60byte 從2處看到ip資料總長度 28byte ip資料為什麼是28byte？因為ip頭部是20個位元組 4處標記...
ARP協議格式和例項分析
arp協議是乙個網路層協議，它的出現是為了完成網路層的ip和資料鏈路層的mac位址之間的對應關係。一 arp協議的報文格式 arp的報文格式如下 1.硬體位址型別 該欄位表示物理網路型別，即標識資料鏈路層使用的是那一種協議，其中0x0001為乙太網。5.操作 記錄該報文的型別，其中1表示arp請求報...
資料鏈路層 乙太網和ARP協議
arp協議 乙太網 不是一種具體的網路，而是一種技術標準，既包含了資料鏈路層的內容，也包含了一些物理層的內容。例如 規定了網路拓撲結構，訪問控制方式，傳輸速率等 乙太網幀格式 mtu 最大傳輸單元，鏈路層限制的資料幀大小 由於資料鏈路層mtu的限制，對於較大的ip資料報要進行分包 將較大的ip包分成...