登录网关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失效时间。经过一段时间的检验，系统运行良好，原有故障消失。

　　本次排障工作中，我们坚持理论指导实践，对每种可能的故障原因进行不偏不倚的分析，在客观公正不带主观臆想的前提下，对每种观点进行逐步考察，终于确定故障点，解决了问题。