网络拓扑结构优化的后果有哪些？
基准测试会给出一个正常工作的网络的各个链路和通道的流量规律和时间特征，比如一个税务征管系统，每月的10号左右就是纳税数据流量的最高峰，其余时间均在高峰期流量的50%以下。依据这些规律和特征，网管人员可以了解网络的变化规律，以此预估网络流量的变化趋势，为升级网络设备和网上设备收集准确数据，也可为新的网络应用提供安装依据，还可以为网络成员的数量增删、结构调整提供精确的参考数据。 最重要的一点是，可以为早期发现部分严重的网络问题提供诊断依据，从而避免造成不必要的严重损失。
由于局域网中的网络拓扑结构是相对稳定的，一般不会每天都去改动，这一点与路由节点的动态变化是不同的，因为路由器会根据选用的路...全部
基准测试会给出一个正常工作的网络的各个链路和通道的流量规律和时间特征，比如一个税务征管系统，每月的10号左右就是纳税数据流量的最高峰，其余时间均在高峰期流量的50%以下。依据这些规律和特征，网管人员可以了解网络的变化规律，以此预估网络流量的变化趋势，为升级网络设备和网上设备收集准确数据，也可为新的网络应用提供安装依据，还可以为网络成员的数量增删、结构调整提供精确的参考数据。
最重要的一点是，可以为早期发现部分严重的网络问题提供诊断依据，从而避免造成不必要的严重损失。
由于局域网中的网络拓扑结构是相对稳定的，一般不会每天都去改动，这一点与路由节点的动态变化是不同的，因为路由器会根据选用的路由协议、网络互联的流量状况、网络设备及信道的工作质量动态地改变路由表和路由通道的实际方向。
这种调整经常是依据选用的路由协议和设定的条件自动进行的。而局域网内由交换机构成的网络路径通常没有这样大的灵活性，一个原因是它们的功能主要还是用来提供低延迟的数据传输的快速通道，虽然建立局域网内的动态链路带宽分配一直是交换机试图完成的主要功能。
另一个原因就是设备成本，如果所有交换机都具备带宽组合分配、交换节点选择和流量均衡的功能，那么整个网络的成本将会上升许多。第三个原因是虽然已经提出了不少带宽组合分配的协议，但还没有一个功能完备和完全标准的协议能实现这些功能。
目前我们常用网管系统监测、设置端口Trunk、启动STP/HSRP协议、启动端口保护功能等初级手段来应付网络流量的变化、交换节点中断和异常流量的冲击。
最初在进行交换机、路由器的设计时为了降低成本，其设计体系中一般没有像传统的通信传输产品那样设计独立的管理通道，而是利用承载数据业务的通道兼作管理通道来传递网络管理和监测信息。
这种体系的缺点很明显：一旦业务通道出现堵塞或中断，管理信息的获取通道也会随之中断，网管系统用来判断故障准确位置和程度的有效性及其真实性将大打折扣。遗憾的是这种状况在现在所谓的高档交换机中仍然没有改观。
“网管网”的概念始终没有随着设备成本的大幅下降而得以实现，所以，高效的网络拓扑结构优化和流量均衡的问题没有顺利进入实用阶段。网管员们面临的仍然是需要人工参与网络状态的检测和网络拓扑结构的调整。
由于获取的信息有限，即时性不高，加之没有很好的优化原则和算法，所以目前采用的方法主要是根据高峰期的发生时间和持续时间作为人工分析和调整拓扑结构的依据。
典型案例
这是一个拥有500台左右机器的公司办公和业务混合网，网络规模属于中等。
网络中有三个路由器与其他异地制造部门实现广域连接，一台路由器与公网相连。本地有约300台机器，用三台核心交换机依线型结构构成三组楼群的用户本地网。分别是楼群A、楼群B和楼群C。楼群A居线型结构的中间，并设有信息中心和网管中心。
三台核心业务服务器和与异地部门连接的路由器以及公网路由器都安装在此。楼群B和楼群C内分别安装有多台部门级服务器，服务器的内容管理由各部门负责，维护和故障诊断则由信息中心负责。各楼群下设工作组交换机和桌面交换机组成三级交换局域网，与各部分的终端用户相连，网管中心负责全面的网络规划和管理维护。
终端用户基本上用的是台式机，少数用户使用笔记本电脑。
本示例所讲述的故障发生在位于A楼群中的几个部门之间。
公司办公网和业务网没有分离，共同使用以前设计的以五类线铺设的以太网。原来安装的生产、采购、物料、库存、财务等软件模块已经使用近一年，效果还不错。
最近两周新增加了销售软件模块，在软件单独调试时感觉软件表现也不错，决定正式切换到网络化的销售平台上来。销售部人员已经全部经过培训，在平台切换并接入的那天，全体销售人员扔掉了手工记录，做好了准备，以便正式进入网络化销售流程重组的实施进程。
那天网络启动后一开始还正常，不久就出现问题，并网联调时销售模块的工作速度很慢，并且影响到财务模块、采购模块的工作速度，三个模块好像不能同时协调快速工作。
显然，新安装的销售模块有问题，它运行时速度比较慢，同时似乎也会影响采购模块、财务模块的正常工作。
为了验证是否是服务器或软件本身的问题，调试时软件安装人员建议暂时停止公司各项业务两小时，重新检查了服务器和各种流程响应，没有发现明显的问题征兆。只好备份数据，重新安装服务器和软件模块。按先后顺序分别将销售模块、采购模块、财务结算模块安装并启动入网调试，观察各工作站和服务器的工作状态，一切正常。
两小时后调试程序结束，一切过程均显示软件工作正常，遂决定重新启动整个系统进入日常工作状态。在开始后的前20分钟看起来还算不错，大家不由得都松了一口气。但20分钟后销售部首先报告业务响应又出现问题，速度变慢。
几乎同时采购部和财务部也报告速度变慢。调试人员观察到速度降低的同时网络响应的速度也有所下降，不如先前Ping服务器响应均在1ms以内，此时部分Ping响应变成2ms～18ms，100组Ping测试丢失率在约30%左右，不知是何种原因。
为什么单个模块调试都没有问题而全部模块工作起来以后就会出现问题？临近中午十分，正在大家疑惑不解之际，销售部报告软件工作速度恢复正常，不久财务部和采购部也报告业务流程恢复正常速度。虽然不知道具体原因，但业务能恢复正常工作总是件好事，折腾了一上午，也该补充点能量了。
大家随即变得“欢欣鼓舞起来”，纷纷结伴向附近的餐馆走去。
软件调试工程师心里一直在打鼓，午休时间他一个人又对服务器和工作站的软件设置进行了一番仔细检查，确认没有任何问题，随后将所有相关的服务器和工作站进行了重启。
要知道，这套软件他已经成功安装近百套了，从来没有出现过处理不了的问题，对此他一直是信心十足的。上午虽然软件工作后期趋于正常，但由于没有最终查明引起故障的原因，此时心中只好暗暗“祈祷”了，希望将此好景保持下去——因为在以前的软件调试安装过程也遇到过类似的问题。
然而好景实在不长，下午工作时间开始后约半个小时，故障又重新出现，症状跟上午的一模一样。收起
