电信网络内部一套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失效时间。经过一段时间的检验,系统运行良好,原有故障消失。
  本次排障工作中,我们坚持理论指导实践,对每种可能的故障原因进行不偏不倚的分析,在客观公正不带主观臆想的前提下,对每种观点进行逐步考察,终于确定故障点,解决了问题。