DNS故障引发子网流量异常
来源：不详 责任编辑：栏目编辑 发表时间:2013-07-02 05:15 点击:次
这是笔者最近亲历的一起网络故障，故障比较典型，排错思路比较可取。我把这个过程写下来和大家分享，希望能够帮助到你。
1、症状描述
客户来电报告中心主网络则基本正常，而一个子网突然变慢。这是本地铁通网络服务公司，该公司为普通用户提供Web服务和Internet接入服务。前几天其服务的一个片区的用户反映网络速度很慢，发Email也需要等待超过60秒以上的时间才能联通。这个片区被划分为一个子网，从主机房的网管系统上观察发现除了该片区(子网)路由器流量很高以外(测试为97%)，中心网络的路由器与其它子网的交互流量均为40%以下。此外，没有其它特别现象。
2、诊断过程
铁通的维护人员自行进行了网络排错可惜没有找到故障所在，由于不能断开网络停止用户服务来进行检查，于是求助于我们，本人被派出诊。应该说，从症状上看这个故障比较简单，只要查出子网的路由流量来源就可以很快确定故障方向，进一步则立即可以查出流量源。
从网络拓扑图上看，故障子网与中心网络为E1链路。故障子网下面有一个营业厅，一般只与中心网络交互一些业务数据应该不会有太大的流量。此外，该子网下的Web服务器数量为45台，中心的网管系统报告97%的流量肯定是过高的。
笔者考虑只有一种情况可以比较多地占用E1通道的有效流量，那就是故障子网下的网站与中心网络的网站或服务器之间有多媒体文档的传输或者下载业务才会造成这种情况。不过询问管理人员得知中心网络并不提供诸如多媒体视频的播放和下载服务，那只能借助工具进行检测了。
由于故障网络规模比较小，中心网络的网管系统只支持到路由器一级的管理，交换机和服务器等采用的是廉价的桌面交换机，所以无法支持网络管理。将网络测试仪接入交换机进行测试，启动便携网管功能，可以看到路由器的流量和网管系统观测的到的流量是相同的，均为97%左右。
查看中心网络处与此相连的路由器流量，也是997%左右，这说明路由器通道链路性能基本正常。不过这样高的通道流量必然导致路由器拥塞和丢包，所以从流量的角度看又是不正常的。现在需要了解的是，如此高的路由流量是从哪里来的，以及数据包到达路由器以后的去向等。这样就可以很快定位导致如此之高的通道流量的数据源和拥塞源。
将网络流量分析仪接入网络的路由器通道进行监测和分析，结果显示95%流量流向了业务数据服务器，且多数为HTTP和Email方面应用。其中，Internet访问流量占88%，本地流量占7%。查看流量分析仪指示的流量来源分布图，没有发现集中的流量应用，IP地址分布比较均衡，最高的流量只占0.5%。这些数据表明，用户的应用比例均衡，故障原因应该在应用过程中而不是某个集中的用户“轰击”比如黑客等。也就是说，应该是应用的过程和通道出了问题。其原因是这些流量按通道设计不应该到达营业厅网络的业务服务器，而是应该直接从中心网络的Internet主路由器进入互联网。那么，这些流量是如何被引导到营业厅服务器方向上来的呢?
下面我们进行进一步的分析，大家知道IP数据包在传输过程中会在路由器中作地址解析(ARP)，或是在本地DNS中进行域名分析。如果这些分析路径出问题，则IP数据包的传输和交换就会出问题。根据流量分析仪的指示，笔者任意选择了10个IP地址做路由追踪测试，用网络测试仪追踪的结果是，他们都要经过一个DNS服务器。而模仿营业厅网络成员分别对已知的本地和外地用户做ICMP监测和路由追踪测试，结果发现ICMP监测中重定向数据包占82%，目标不可达数据包数量占13%。这表明，只有约2%的用户能一次性出入正常路由到达目标站点，其余95%的IP数据包都要经过路由竞争或重新发送才能有部分机会到达目的地。
由此，可以重点检查主路由器的路由表和DNS的转换表。由于多数Internet访问流量被引导到了营业厅业务服务器，所以可以重点检查DNS服务器。用网络测试仪对DNS服务器做查询，观察查询结果，发现DNS转换表有相当大的比例指向了营业厅子网中的业务服务器。笔者怀疑是DNS服务器出了问题!
于是通知中心网络的网管人员将DNS服务器重新启动并快速设置一次，稍后网络管理人员报告网络业务恢复正常。用网络测试仪的Internet工具包查询DNS服务器，可以看到指向营业厅业务服务器的数据已经全部消失，这表明网络已经完全恢复了正常工作。但好景不长，约3分钟后，故障重新出现，仍有97%的通道流量被指向了子网。
由于DNS服务器只设置了一台，没有备份或备用服务器，于是不得不立即来到中心网络机房，对DNS服务器及其周围设备进行检查。测试服务器网卡和与路由器的电缆正常。为了不中断服务，笔者让网管人员在另一台备用服务器上临时安装设置了DNS服务器。经过短暂的业务中断后，更换上的新DNS服务器开始投入适用。只见子网路由器的流量立刻降低到了1.5%。经过30分钟的稳定工作后，所
1、症状描述
客户来电报告中心主网络则基本正常，而一个子网突然变慢。这是本地铁通网络服务公司，该公司为普通用户提供Web服务和Internet接入服务。前几天其服务的一个片区的用户反映网络速度很慢，发Email也需要等待超过60秒以上的时间才能联通。这个片区被划分为一个子网，从主机房的网管系统上观察发现除了该片区(子网)路由器流量很高以外(测试为97%)，中心网络的路由器与其它子网的交互流量均为40%以下。此外，没有其它特别现象。
2、诊断过程
铁通的维护人员自行进行了网络排错可惜没有找到故障所在，由于不能断开网络停止用户服务来进行检查，于是求助于我们，本人被派出诊。应该说，从症状上看这个故障比较简单，只要查出子网的路由流量来源就可以很快确定故障方向，进一步则立即可以查出流量源。
从网络拓扑图上看，故障子网与中心网络为E1链路。故障子网下面有一个营业厅，一般只与中心网络交互一些业务数据应该不会有太大的流量。此外，该子网下的Web服务器数量为45台，中心的网管系统报告97%的流量肯定是过高的。
笔者考虑只有一种情况可以比较多地占用E1通道的有效流量，那就是故障子网下的网站与中心网络的网站或服务器之间有多媒体文档的传输或者下载业务才会造成这种情况。不过询问管理人员得知中心网络并不提供诸如多媒体视频的播放和下载服务，那只能借助工具进行检测了。
由于故障网络规模比较小，中心网络的网管系统只支持到路由器一级的管理，交换机和服务器等采用的是廉价的桌面交换机，所以无法支持网络管理。将网络测试仪接入交换机进行测试，启动便携网管功能，可以看到路由器的流量和网管系统观测的到的流量是相同的，均为97%左右。
查看中心网络处与此相连的路由器流量，也是997%左右，这说明路由器通道链路性能基本正常。不过这样高的通道流量必然导致路由器拥塞和丢包，所以从流量的角度看又是不正常的。现在需要了解的是，如此高的路由流量是从哪里来的，以及数据包到达路由器以后的去向等。这样就可以很快定位导致如此之高的通道流量的数据源和拥塞源。
将网络流量分析仪接入网络的路由器通道进行监测和分析，结果显示95%流量流向了业务数据服务器，且多数为HTTP和Email方面应用。其中，Internet访问流量占88%，本地流量占7%。查看流量分析仪指示的流量来源分布图，没有发现集中的流量应用，IP地址分布比较均衡，最高的流量只占0.5%。这些数据表明，用户的应用比例均衡，故障原因应该在应用过程中而不是某个集中的用户“轰击”比如黑客等。也就是说，应该是应用的过程和通道出了问题。其原因是这些流量按通道设计不应该到达营业厅网络的业务服务器，而是应该直接从中心网络的Internet主路由器进入互联网。那么，这些流量是如何被引导到营业厅服务器方向上来的呢?
下面我们进行进一步的分析，大家知道IP数据包在传输过程中会在路由器中作地址解析(ARP)，或是在本地DNS中进行域名分析。如果这些分析路径出问题，则IP数据包的传输和交换就会出问题。根据流量分析仪的指示，笔者任意选择了10个IP地址做路由追踪测试，用网络测试仪追踪的结果是，他们都要经过一个DNS服务器。而模仿营业厅网络成员分别对已知的本地和外地用户做ICMP监测和路由追踪测试，结果发现ICMP监测中重定向数据包占82%，目标不可达数据包数量占13%。这表明，只有约2%的用户能一次性出入正常路由到达目标站点，其余95%的IP数据包都要经过路由竞争或重新发送才能有部分机会到达目的地。
由此，可以重点检查主路由器的路由表和DNS的转换表。由于多数Internet访问流量被引导到了营业厅业务服务器，所以可以重点检查DNS服务器。用网络测试仪对DNS服务器做查询，观察查询结果，发现DNS转换表有相当大的比例指向了营业厅子网中的业务服务器。笔者怀疑是DNS服务器出了问题!
于是通知中心网络的网管人员将DNS服务器重新启动并快速设置一次，稍后网络管理人员报告网络业务恢复正常。用网络测试仪的Internet工具包查询DNS服务器，可以看到指向营业厅业务服务器的数据已经全部消失，这表明网络已经完全恢复了正常工作。但好景不长，约3分钟后，故障重新出现，仍有97%的通道流量被指向了子网。
由于DNS服务器只设置了一台，没有备份或备用服务器，于是不得不立即来到中心网络机房，对DNS服务器及其周围设备进行检查。测试服务器网卡和与路由器的电缆正常。为了不中断服务，笔者让网管人员在另一台备用服务器上临时安装设置了DNS服务器。经过短暂的业务中断后，更换上的新DNS服务器开始投入适用。只见子网路由器的流量立刻降低到了1.5%。经过30分钟的稳定工作后，所
相关新闻>>
最新推荐更多>>>
- 发表评论
-
- 最新评论 更多>>