登錄網關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失效時間。經過一段時間的檢驗，系統運行良好，原有故障消失。

　　本次排障工作中，我們堅持理論指導實踐，對每種可能的故障原因進行不偏不倚的分析，在客觀公正不帶主觀臆想的前提下，對每種觀點進行逐步考察，終于確定故障點，解決了問題。