方案实施后，用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地址无对应端口，交换机丢掉此包。
转载地址：http://www.net130.com/CMS/Pub/network/network_manage/2006_03_13_11885.htm
