论文部分内容阅读
者所在单位是某政府机关下属单位,主要担负着政府大楼内部各单位行政权力网上公开透明运行系统的日常运行、管理与维护工作。最近一段时间,大楼内的用户不断电话反映上网速度非常缓慢,针对这种现象,单位领导要求笔者等一千技术人员迅速采取措施,解决上网速度缓慢故障。
网络现状
大楼网络接入层全部采用H3C公司的Quidway S3050系列交换机,核心层采用Quidway S8512系列交换机;为了保证网络连接的稳定性,核心层采用双机热备份,各个楼层采用双链路连接。大楼各楼层交换机到核心交换机之间全部使用千兆多模光纤线路,楼层到桌面采用超五类非屏蔽双绞线。大楼网络中的服务器群,主要包括一台Web服务器,该服务器主要提供政府内部的Web访问,一台AD服务器集成了DNS服务,主要为大楼上网电脑提供域名解析服务,四台OA服务器,专门用于行政权力网上公开透明运行系统;为了保证这些服务器的安全、高效运行,它们都直接连接到大楼网络的核心交换机上,并通过硬件防火墙连接到Internet网络,整个大楼网络的结构拓扑图见下图。
故障现象
大楼网络中的本地DNS服务器是集成在活动目录服务器中的,以前该服务器的工作状态一切正常,最近不知道什么原因,网管员发现该服务器不能成功解析大楼外网地址的情况,具体现象为:
大楼网络中的终端系统无法成功解析外网地址,使用IE浏览器尝试访问域名解析失败的网站时,对应网站页面将无法打开,不过在终端系统中重复刷新网页若干次,有可能打开网页内容。登录进入DNS服务器所在主机系统,借助“nslookup”命令测试内部地址查询时,发现该操作是正常的,可是使用相同的命令测试外网地址时,发现有的网站域名可以被正常解析,有的不能被解析,不过不能被解析的域名在反复多次解析后,往往能够获得成功。那么为什么大楼外部的网站域名有时能够被解析成功,有时又会被解析失败呢?
故障排查
为了弄清楚故障原因,网管员进行了如下尝试排查操作:查配置参数
由于问题只是域名解析失败,网管员怀疑DNS服务器的自身配置出现了问题,迅速登录进入该服务器所在主机系统,依次单击“开始”|“设置”|“网络连接”,右击本地连接图标,展开该连接的属性设置框,选中TCP/IP协议选项,弹出对应选项的属性设置对话框,在其中检查它的IP地址、网关地址、掩码地址等参数时,发现一切正常。之后,网管员在DNS转发器上进行了转发测试,发现转发到本地电信部门提供的DNS地址202.102.24.35上时,一切正常,这说明DNS月&务器的配置参数是正确的。
查系统缓存
大家知道,DNS服务器工作时间一长之后,其系统缓存容易出现问题,为此网管员在DNS服务器所在主机系统中,依次单击“开始”|“运行”命令,在弹出的系统运行框中执行字符串命令“ipconfig/flushdns”。来清除对应系统作为客户端身份的缓存内容,之后再执行“dnscmd/clearcache”命令,将DNS服务器本地缓存的内容也清除了干净。为了保证系统缓存内容得到彻底清除,网管员最后还重新启动了一下DNS服务器主机系统,然而上面的努力一点效果也没有。打开DNS服务器的日志记录时,网管员也没有找到任何与外部网站有关的解析记录,这就意味着上面的问题与系统缓存无关。
查速度匹配
在排查过程中,网管员发现DNS服务器所在主机系统的网卡,使用的是千兆级别的自适应网卡,而楼层交换机、核心交换机使用的端口也是千兆自适应级别的,唯有网络线缆是100M级别的,会不会是网络线缆在连接这两种千兆级别设备出现了速度不匹配现象,从而引起了网站域名有时能够解析成功,有时解析失败现象?为了排除这种嫌疑,网管员特地在交换机以及服务器主机中,分别修改交换端口以及网卡设备的速度到100M状态,再进行域名解析测试时,发现上面的故障现象仍然存在。
查网络延迟
为了判断网络传输过程中是否出现延迟现象,网管员利用nslookup命令重新设置了默认查询响应时间。结果发现将默认响应时间变成20秒钟,反馈后的结果竟然还是超时。既然存在网络延迟现象,网管员决定找出引起该故障的原因:
首先考虑到DNS服务器的网卡接口与核心交换机的接口速度都是1000M,而网络线缆的传输速度只有100M,为了排除由于线缆因素引起的DNS查询延迟现象,网管员特地购买了一根1000M级别的六类网络线缆,进行连接测试,发现故障现象依旧,这就意味着域名解析失败故障与物理线缆没有任何关系。
其次为了排除由广播风暴因素引起的网络延迟,网管员特地登录进入核心交换机后台系统,使用display interface命令依次查看各个交换端口的数据流量状态,发现所有交换端口的广播流量大小正常,并没有异常流量出现,这说明上述现象不是由广播风暴因素引起的。
接着网管员检查了硬件防火墙的配置,因为DNS服务在正常工作时,需要用到硬件防火墙的TCP53端口、UDP53端口,要是这两个端口只有一个被启用的话,也可能引起域名解析延迟现象,不过经过检查之后,网管员发现硬件防火墙的端口配置是正确的,显然故障原因不在硬件防火墙上。
查系统日志
在上面的各项尝试操作都失败后,网管员只好将希望寄托于DNS服务器所在主机系统的日志上,想通过查看系统日志,特别是与DNS服务有关的日志信息,来寻找故障端倪。打开DNS服务器系统的日志后,网管员的确看到了一些错误或警报日志记录,可是经过仔细分析后,发现这些错误或警报基本与域名解析失败故障没有多大关系,因为本文中遇到的解析失败故障都是针对外部网站的,内部网站的名称解析是正常的,基于这一点,网管员忽略了日志中的警报和错误。
进行抓包分析
在万般无奈之下,网管员只好使用专业的数据抓包工具,分别在客户端系统和服务器系统中进行抓包测试,以便从中寻找故障缘由。在客户端系统中进行抓包分析时,网管员将DNS服务器指定为本地电信提供的202.102.24.35地址时,发现解析www.baidu.com、www.cctv.com、www.hsyf.gov.cn、www.yancheng.gov.cn等外部网站时,全部都能解析成功,同时在这个过程中没有看到 有任何错误出现;可是将客户端系统的DNS服务器地址指定为大楼内部的DNS服务器时,发现在解析上述几个相同的外部网站时,都出现了明显的超时现象。
例如,在客户端系统中抓包时,发现www.hsyf.gov.cn解析失败,而这个DNS请求的发送时间为Aug 18,201017:23:50,之后在同样的数据抓包中,看到来自指定DNS服务器的响应,结果是解析没有成功,返回的错误代码是Server failure,而客户端系统接收到这个反馈的时间为Aug 18,201017:24:01,这中间的延迟大约在10秒钟左右。在大楼网络的指定DNS服务器中进行数据抓包时,网管员尝试找到刚才客户端系统发来的解析请求,看看DNS服务器究竟是如何将指定解析任务转发到202.102.24.35服务器上的;然而让人感到十分意外的是,整个抓包中,竟然没有找到Aug 18,2010 17:23:50和Aug18,2010 17:24:01这个时段的DNS请求,这让人十分费解。再抓包分析其他的DNs解析请求时,这样的问题依然存在。
此外,在DNS服务器中进行操作时,网管员感觉到该服务器的负载比较大,操作起来不象以往那样顺畅,难道是该服务器太忙,而不能及时对客户端系统发送过来的解析请求进行响应?为了验证这种猜测,网管员立即重新启动了一下该服务器系统,并在刚刚启动成功的那一刻,再次进行数据抓包分析,结果发现在这一时刻,各种DNS请求都能被正常响应,看来问题的确是由DNS负载过重引起的。
解决故障
经过上述排查,终于找出DNS服务器负载过大隐患,从而引起DNS解析失败故障。为此,网管员立即对DNS服务器进行升级,同时将旧的服务器作为备份服务器。之后,经过一段时间的测试,发现DNS服务器解析失败问题终于得到了彻底解决。
反思总结
在实际维护网络的过程中,造成网站域名解析失败的原因有很多。依照网络故障现象,采取不同的解决办法,这本身就是一个解决故障的过程,具体的操作主要包括下面几个方面。
首先,重点检查指定DNS服务器的工作状态。DNS服务器出现网络连接错误,系统性能不稳定、响应迟钝的现象,在单位局域网网络中比较常见,这类现象表明DNS服务器自身工作状态不稳定;
其次,排查网络连接因素。当终端系统出现网络连接故障时,也容易造成域名解析有时成功、有时失败的现象,我们必须先依据一定的步骤检测网络故障原因,来排查是本地系统原因,还是外界连接原因,这样才能对故障排除做到有的放矢。
网络现状
大楼网络接入层全部采用H3C公司的Quidway S3050系列交换机,核心层采用Quidway S8512系列交换机;为了保证网络连接的稳定性,核心层采用双机热备份,各个楼层采用双链路连接。大楼各楼层交换机到核心交换机之间全部使用千兆多模光纤线路,楼层到桌面采用超五类非屏蔽双绞线。大楼网络中的服务器群,主要包括一台Web服务器,该服务器主要提供政府内部的Web访问,一台AD服务器集成了DNS服务,主要为大楼上网电脑提供域名解析服务,四台OA服务器,专门用于行政权力网上公开透明运行系统;为了保证这些服务器的安全、高效运行,它们都直接连接到大楼网络的核心交换机上,并通过硬件防火墙连接到Internet网络,整个大楼网络的结构拓扑图见下图。
故障现象
大楼网络中的本地DNS服务器是集成在活动目录服务器中的,以前该服务器的工作状态一切正常,最近不知道什么原因,网管员发现该服务器不能成功解析大楼外网地址的情况,具体现象为:
大楼网络中的终端系统无法成功解析外网地址,使用IE浏览器尝试访问域名解析失败的网站时,对应网站页面将无法打开,不过在终端系统中重复刷新网页若干次,有可能打开网页内容。登录进入DNS服务器所在主机系统,借助“nslookup”命令测试内部地址查询时,发现该操作是正常的,可是使用相同的命令测试外网地址时,发现有的网站域名可以被正常解析,有的不能被解析,不过不能被解析的域名在反复多次解析后,往往能够获得成功。那么为什么大楼外部的网站域名有时能够被解析成功,有时又会被解析失败呢?
故障排查
为了弄清楚故障原因,网管员进行了如下尝试排查操作:查配置参数
由于问题只是域名解析失败,网管员怀疑DNS服务器的自身配置出现了问题,迅速登录进入该服务器所在主机系统,依次单击“开始”|“设置”|“网络连接”,右击本地连接图标,展开该连接的属性设置框,选中TCP/IP协议选项,弹出对应选项的属性设置对话框,在其中检查它的IP地址、网关地址、掩码地址等参数时,发现一切正常。之后,网管员在DNS转发器上进行了转发测试,发现转发到本地电信部门提供的DNS地址202.102.24.35上时,一切正常,这说明DNS月&务器的配置参数是正确的。
查系统缓存
大家知道,DNS服务器工作时间一长之后,其系统缓存容易出现问题,为此网管员在DNS服务器所在主机系统中,依次单击“开始”|“运行”命令,在弹出的系统运行框中执行字符串命令“ipconfig/flushdns”。来清除对应系统作为客户端身份的缓存内容,之后再执行“dnscmd/clearcache”命令,将DNS服务器本地缓存的内容也清除了干净。为了保证系统缓存内容得到彻底清除,网管员最后还重新启动了一下DNS服务器主机系统,然而上面的努力一点效果也没有。打开DNS服务器的日志记录时,网管员也没有找到任何与外部网站有关的解析记录,这就意味着上面的问题与系统缓存无关。
查速度匹配
在排查过程中,网管员发现DNS服务器所在主机系统的网卡,使用的是千兆级别的自适应网卡,而楼层交换机、核心交换机使用的端口也是千兆自适应级别的,唯有网络线缆是100M级别的,会不会是网络线缆在连接这两种千兆级别设备出现了速度不匹配现象,从而引起了网站域名有时能够解析成功,有时解析失败现象?为了排除这种嫌疑,网管员特地在交换机以及服务器主机中,分别修改交换端口以及网卡设备的速度到100M状态,再进行域名解析测试时,发现上面的故障现象仍然存在。
查网络延迟
为了判断网络传输过程中是否出现延迟现象,网管员利用nslookup命令重新设置了默认查询响应时间。结果发现将默认响应时间变成20秒钟,反馈后的结果竟然还是超时。既然存在网络延迟现象,网管员决定找出引起该故障的原因:
首先考虑到DNS服务器的网卡接口与核心交换机的接口速度都是1000M,而网络线缆的传输速度只有100M,为了排除由于线缆因素引起的DNS查询延迟现象,网管员特地购买了一根1000M级别的六类网络线缆,进行连接测试,发现故障现象依旧,这就意味着域名解析失败故障与物理线缆没有任何关系。
其次为了排除由广播风暴因素引起的网络延迟,网管员特地登录进入核心交换机后台系统,使用display interface命令依次查看各个交换端口的数据流量状态,发现所有交换端口的广播流量大小正常,并没有异常流量出现,这说明上述现象不是由广播风暴因素引起的。
接着网管员检查了硬件防火墙的配置,因为DNS服务在正常工作时,需要用到硬件防火墙的TCP53端口、UDP53端口,要是这两个端口只有一个被启用的话,也可能引起域名解析延迟现象,不过经过检查之后,网管员发现硬件防火墙的端口配置是正确的,显然故障原因不在硬件防火墙上。
查系统日志
在上面的各项尝试操作都失败后,网管员只好将希望寄托于DNS服务器所在主机系统的日志上,想通过查看系统日志,特别是与DNS服务有关的日志信息,来寻找故障端倪。打开DNS服务器系统的日志后,网管员的确看到了一些错误或警报日志记录,可是经过仔细分析后,发现这些错误或警报基本与域名解析失败故障没有多大关系,因为本文中遇到的解析失败故障都是针对外部网站的,内部网站的名称解析是正常的,基于这一点,网管员忽略了日志中的警报和错误。
进行抓包分析
在万般无奈之下,网管员只好使用专业的数据抓包工具,分别在客户端系统和服务器系统中进行抓包测试,以便从中寻找故障缘由。在客户端系统中进行抓包分析时,网管员将DNS服务器指定为本地电信提供的202.102.24.35地址时,发现解析www.baidu.com、www.cctv.com、www.hsyf.gov.cn、www.yancheng.gov.cn等外部网站时,全部都能解析成功,同时在这个过程中没有看到 有任何错误出现;可是将客户端系统的DNS服务器地址指定为大楼内部的DNS服务器时,发现在解析上述几个相同的外部网站时,都出现了明显的超时现象。
例如,在客户端系统中抓包时,发现www.hsyf.gov.cn解析失败,而这个DNS请求的发送时间为Aug 18,201017:23:50,之后在同样的数据抓包中,看到来自指定DNS服务器的响应,结果是解析没有成功,返回的错误代码是Server failure,而客户端系统接收到这个反馈的时间为Aug 18,201017:24:01,这中间的延迟大约在10秒钟左右。在大楼网络的指定DNS服务器中进行数据抓包时,网管员尝试找到刚才客户端系统发来的解析请求,看看DNS服务器究竟是如何将指定解析任务转发到202.102.24.35服务器上的;然而让人感到十分意外的是,整个抓包中,竟然没有找到Aug 18,2010 17:23:50和Aug18,2010 17:24:01这个时段的DNS请求,这让人十分费解。再抓包分析其他的DNs解析请求时,这样的问题依然存在。
此外,在DNS服务器中进行操作时,网管员感觉到该服务器的负载比较大,操作起来不象以往那样顺畅,难道是该服务器太忙,而不能及时对客户端系统发送过来的解析请求进行响应?为了验证这种猜测,网管员立即重新启动了一下该服务器系统,并在刚刚启动成功的那一刻,再次进行数据抓包分析,结果发现在这一时刻,各种DNS请求都能被正常响应,看来问题的确是由DNS负载过重引起的。
解决故障
经过上述排查,终于找出DNS服务器负载过大隐患,从而引起DNS解析失败故障。为此,网管员立即对DNS服务器进行升级,同时将旧的服务器作为备份服务器。之后,经过一段时间的测试,发现DNS服务器解析失败问题终于得到了彻底解决。
反思总结
在实际维护网络的过程中,造成网站域名解析失败的原因有很多。依照网络故障现象,采取不同的解决办法,这本身就是一个解决故障的过程,具体的操作主要包括下面几个方面。
首先,重点检查指定DNS服务器的工作状态。DNS服务器出现网络连接错误,系统性能不稳定、响应迟钝的现象,在单位局域网网络中比较常见,这类现象表明DNS服务器自身工作状态不稳定;
其次,排查网络连接因素。当终端系统出现网络连接故障时,也容易造成域名解析有时成功、有时失败的现象,我们必须先依据一定的步骤检测网络故障原因,来排查是本地系统原因,还是外界连接原因,这样才能对故障排除做到有的放矢。