同城异地网络拥塞问题的分析与解决.docVIP

同城异地网络拥塞问题的分析与解决 王哲 马宏远 摘要：本文介绍了天津研发中心局域网拥塞问题的测试、分析与解决的过程。 关键词：子网 专线 数据包 端口 天津研发中心自成立以来，信息化建设倍受重视。目前，该研发中心已建立起一个中等规模的局域网。随着一重和天津研发中心的发展，该局域网的规模也在不断扩大，功能也在不断增加。 在扩建网络和完善功能的同时，也遇到了一些棘手的问题。下面介绍一个关键问题的解决过程。 1问题及初步分析 1.1 问题的反馈 近期，实验基地内部局域网用户反应OA系统及物流软件网速过慢，希望尽快得到解决。 1.2 初步分析 首先要确定该问题存在的范围，即该问题出现在哪些子网，或整个局域网。 经过调查，发现研发中心办公楼11层子网与10层子网中使用OA的传输速率明显高于实验基地子网。由此确定出现拥塞的仅为子网。 目前，研发中心办公楼与实验基地和一重局域网均通过2M带宽的专线相连，因此可以断定数据传输瓶颈出现在研发中心办公楼与实验基地的专线上。 2 软件测试与结果分析 2.1 流量测试 为此我们使用“基线”网管软件来监视专线的实时流量，从上午10:00点开始至下午16:00点结束，监视结果数据表明实验基地至研发中心流量为1.7M至2.1M，可以确定网络速度慢是由于两端大量不明数据所造成的拥堵。 2.2 流量分析 接下来对专线中的数据流量进行分析，来确定产生拥塞的数据及其源头。 2.2.1 核心交换机的配置 在核心交换机上设置端口镜像，截取所有实验基地到办公楼的数据包。对核心交换机进行如下操作： C4506(config)# monitor session 1 source interface Gi3/14 C4506(config)# monitor session 1 destination interface Gi3/23 其中Gi3/14为被监测端口，Gi3/23为监测数据输出端口。 2.2.2 拥塞数据源头的确定 在与Gi3/23端口相连接的服务器上安装WildPackets OmniPeek流量数据分析软件，并使用该软件对核心交换机端口流量进行分析，分析结果中主要节点流量数据如下： Node Total Bytes % Total Bytes Packets Sent PacketsReceived CE. 93.204 556,111,684 413882 291150 EGF. 5.746 34,282,931 15366 25210 4 5.542 33,066,262 14162 23906 GERC. 5.482 32,706,563 12270 22328 1 5.296 31,597,729 27908 22669 25 4.754 28,362,839 12449 20727 8 3.99 23,805,498 16588 20689 表1 节点流量数据表 可见CE.节点流量数据最大。 将该表中的数据流量进行统计，其结果如下图： 图1 各节点流量统计图 可见，CE.的这台主机占据2M带宽68%的比例。可以确认问题的源头为名字GC.这台主机。 2.3 服务功能的排查 CE.计算机在研发中心局域网中主要担任三大角色：主域控制、CAPP服务器、Lansecs服务器（监控服务器）。所以专线中的拥塞导致的网速过慢就只能是以上三种服务其中的某一种服务造成的。 2.3.1 CAPP服务可能性的排除 由于在实验基地主要是理化和生产人员，其电脑中并没有安装CAPP。CAPP主要用户为办公楼10层科研人员，该软件开启后，将通过CE.计算机与一重CAPP服务器接通。如果是该服务产生的数据流量过大，大量数据包将在研发中心与一重相连的专线中产生拥塞，该拥塞将降低全公司局域网中所有用户的OA传输速率。这与最初的调查结果不符，因此CAPP可以排除。则问题只能出现在域服务或监控软件服务上。 2.3.2 产生拥塞数据包端口的确认 既然是发送的数据量过大，而发送数据必然会使用TCP或UDP协议中某一个端口来实现。那么再次使用“WildPackets OmniPeek”分析CE.究竟使用了那些端口，结果如下： Indent Protocol Bytes Packets 1 IP-20009 94743 138,544,198 2 IP-4586 5295 353,550 3 IP-4577 8241 590,415 4 IP-4120 5243 350,319 5 IP-3209 3230 214,244 6 Xrl 5257 351,215 7 Netopia-vo3 5264 352,059 表2 端口流量数据表 可见，端口IP-20009发送的数据包和字节数均居首位。对表中数