用Sniffer和ARP分析网络问题
添加时间: 2007-4-12 6:05:42 作者: 网络工程师认证参考 阅读次数:41 来源: http://www.d9soft.com
电信 网络 内部一套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失效时间。经过一段时间的检验，系统运行良好，原有故障消失。
本次排障工作中，我们坚持理论指导实践，对每种可能的故障原因进行不偏不倚的分析，在客观公正不带主观臆想的前提下，对每种观点进行逐步考察，终于确定故障点，解决了问题。
上一篇文章: 网络程序员复习一 下一篇文章: IT信息：五步成为网络专家
相关文章: