下载中心 | 网站地图 | 站内搜索 | 加入收藏

安恒公司 / 技术文章 / 网络管理与网络测试 / 网络测试 / 网络测试经验谈:DNS“堵死”局域网

2004-03-03 程振凯  阅:    下页:
网络测试经验谈:DNS“堵死”局域网

DNS“堵死”局域网


  “高速公路”不高速 马鞍山供电局于1998年初建成了基于Windows NT4.0的局域网,主要用于办公自动化系统(OA)和WWW信息发布。根据全省电力三*信息网络建设要求,供电局新增了*台Cisco 2621路由器,利用微波64K数字通道,于今年5月份以专线方式接入电力信息三*网,运行正常。但是,从7月中旬开始,发现整个网络运行变慢:运行办公自动化系统和访问局内WWW主页明显比以前慢,特别是访问省局主页,速度更是慢得难以忍受,近乎中断。刚开始还以为是网上用户多所致,可是发现连续几天,速度没有丝毫改善,这才怀疑网络可能“生病”了。

  多方检查,*筹莫展 供电局局域网的核心是3Com公司的3C16980 24口10/100M自适应交换机,OA服务器、WWW服务器和路由器均以100M的速度直接接入交换机,工作站通过3Com公司的双速Hub:superstackⅡDual Speed Hub500接入网络,OA服务器的IP地址为10.138.184.1,WWW服务器的IP地址为10.138.184.5,路由器局域网端口的IP地址为10.138.184.254,整个网络示意图如下图所示。

  由于与省局的通信故障*明显,所以我们决定**解决这个问题。我们检查了微波通道,未发现异常;检查了路由器的网络线,也没有发现问题。当时,有*个现象引起了我们的注意,我们利用PING命令来测试,发现不仅PING到省局时通时断,就是PING路由器的局域网端口(10.138.184.254),也是时通时断,我们第*感觉可能是路由器出故障了,可是路由器刚运行不到2个月,按理不应该出问题,所以我们没有轻易下结论,而是又作了*个试验:把路由器不连到网上,而是直接与*台微机相连(此时网络线是交叉连接,即1、2对与3、6线对相连,3、6线对与1、2线对相连),这时PING路由器,通信正常,访问省局主页,也正常,证明路由器本身无故障,问题肯定出在网络上,究竟是什么原因呢?

  流量分析,发现“元凶” 我们经常看到“广播风暴”、“网络堵塞”等*词,但真正的感性认识还没有。当时,我们就想,这是不是就是由过多的网络流量引起的网络堵塞呢?假如是,引起的原因又是什么呢?Cisco 2621是作为全省电力三*网的边缘路由器,由省局信息中心统*管理的,我们没有登录权限,无法利用路由器的内部命令来查看路由器收发数据帧的情况,我们也没有协议分析器等网络测试专用工具,所以我们决定利用Windows NT Server 4.0自身带的网络监视器,对网络的运行情况进行监视;对网络使用的带宽、高峰使用次数和正在传输的数据帧进行监视,通过监视的情况来分析是否引起了网络堵塞,以及导致网络堵塞的原因。

  Microsoft网络监视器,是*种基于软件的网络流量分析工具,它允许用户:
  1. 从网络上直接捕获帧(信息包);
  2. 在捕获以后立即或稍后进行显示或过滤所捕获的帧;
  3. 编辑所捕获的帧,并把它们发送到网上。

  网络监视器包含在Windows NT Server 4.0(简单版本)和Microsoft System Management Server(完全版本)中,由于我们手头没有Microsoft System Management Server,所以只好安装简单版本的网络监视器,其安装过程为:打开控制面版中的网络图标,选择服务页标,单击“增加”,而后选择网络监视器工具和代理,单击“确定”,而后输入Windows NT Server 4.0光盘的路径,单击“继续”,开始安装,安装完成后,重新启动,这样网络监视器就安装成功了。

  简单版本的网络监视器,只能捕获那些运行网络监视器的计算机进出的网络流量,而Cisco 2621路由器无法安装网络监视器,所以我们决定关闭路由器,把*台安装网络监视器的服务器的IP地址改为10.138.184.254(路由器局域网端口的IP地址),以观察由局域网发向路由器的网络流量。 

  运行网络监视器,按F10功能键开始捕获网络流量,通过捕获窗口的统计数据,我们发现网络利用率平均维持在50%以上(当时是星期二上午10点左右,网上用户较多),而且大多发向了路由器。按F11功能键停止捕获,而后按F12功能键显示所捕获的数据,发现超过90%以上的数据帧都是由DNS服务发出的。*个网络上出现那么多的DNS数据帧是不可想象的,所以基本上确定故障是由DNS引起的。

  DNS重配,恢复高速 我局的OA服务器(10.138.184.1)兼作域*系统服务器(DNS),所有局域网客户端的DNS都指向10.138.184.1,即当有客户端请求把主机*解析成IP地址时,都向10.138.184.1主机发出查询请求。我们仔细检查了DNS的配置,发现服务器属性中选定了使用转发器,列表中输入了主机10.138.184.5,即当服务器不能对客户端的域*请求进行解析时,其请求都传递给了另*个DNS服务器:10.138.184.5。

  主机10.138.184.5是*台运行Windows NT Server4.0的WWW服务器,兼作路由服务器,局域网中所有客户端的默认网关都指向该主机,通过该主机与网外主机(非本子网)进行通讯,它并不提供域*解析服务,DNS服务器怎么会转发到该主机呢?

  检查WWW服务器,发现确实装有DNS服务。我想起来了,原来为了测试*个在网内多DNS 协同工作的配置,在WWW服务器上临时安装了DNS服务,由于工作忙,安装后未测试完就放下了,也没有卸载。检查该DNS配置,发现该服务器属性中也选定了使用转发器,并把主机10.138.184.1输入到了列表,即当该服务器不能对客户端的域*请求进行解析时,其请求都传递给了另*个DNS服务器:

10.138.184.1。如此看来,10.138.184.1把不能解析的主机*传递给10.138.184.5,而10.138.184.5又把不能解析的主机*传递给10.138.184.1,这样,当两台DNS服务器都不能对请求主机*进行解析时,就形成了*个死循环,产生大量的网络流量,影响了整个网络的运行速度。由于WWW服务器10.138.184.5的默认网关是Cisco 2621路由器的局域网端口(10.138.184.254),所以大量的数据帧都转发到该路由器,引起网络堵塞。

  找出引起故障的原因,问题就好办了:卸掉临时安装在WWW服务器(10.138.184.5)上的DNS服务,关闭DNS服务器(10.138.184.1)的转发,这样网络速度明显提高了,与三*网的通信也恢复正常了。

https://anheng.com.cn/news/html/network_troubleshooting/128.html 

下页:   

相关文章
工业以太网WiFi测试经验分享 - 13-06-27 - 阅读: 185926
*次RAID5故障的恢复和经验教训 - 12-03-25 - 阅读: 279660
ERP项目为何总是与成功失之交臂-企业实施ERP的经验 - 07-03-22 - 阅读: 159834
如何查找网络中的BT流量,使用协议分析仪PE的经验 - 06-08-15 - 阅读: 260706
OptiView INA设置故障排除-网络综合测试仪使用经验 - 06-07-02 - 阅读: 248765
无线网络“实战”中的问题和经验 - 06-02-05 - 阅读: 202231
网络维护经验谈:广播风暴分析与排除 - 05-12-31 - 阅读: 238277
EtherScope网络通应用案例分析:Vigo国际学校使用ES的经验 - 04-11-30 - 阅读: 228954
布线设备和线缆的导购经验谈——识别真假双绞线和接插件 - 04-10-27 - 阅读: 202847
*网管的小经验——*个学校的网管老师 - 04-05-30 - 阅读: 143810
安恒公司——*个拥有十年测试经验的专业公司 - 03-10-29 - 阅读: 150810
网络维护经验交流会各地巡讲——10月新增 河北、山西站,欢迎注册! - 03-10-17 - 阅读: 235477
安恒-FLUKE网络维护经验交流会 - 03-10-12 - 阅读: 220448
双绞线的规范和制作经验谈 - 02-12-10 - 阅读: 147231
网络测试经验谈:传统而经典的技术 - 02-03-03 - 阅读: 133468
网络测试经验谈:局域网WEB服务故障* - 02-03-03 - 阅读: 135950
网络测试经验谈:局域网IP冲突问题的探讨 - 02-03-03 - 阅读: 148968
网络测试经验谈:网络故障排除六例 - 02-03-03 - 阅读: 135609

Email给朋友 打印本文
版权所有·安恒公司 Copyright © 2004   enterprise.anheng.com.cn   All Rights Reserved    
北京市海淀区*体南路9号 主语国际商务中心4号楼8层 (邮编100048) 电话:010-88018877