電信網絡內部一套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通。”
　　測試動作四：
　　用內網機器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失效時間。經過一段時間的檢驗，系統運行良好，原有故障消失。
　　本次排障工作中，我們堅持理論指導實踐，對每種可能的故障原因進行不偏不倚的分析，在客觀公正不帶主觀臆想的前提下，對每種觀點進行逐步考察，終于確定故障點，解決了問題。