没有服务器建网站,wordpress 豆瓣,微信里的商家链接网站怎么做的,网站排名关键词演示#xff1a; GTS流量和CAR流量监管的效果及相关实践计划演示目标#xff1a;1 理解clock rate(时钟频率)和bandwidth#xff08;带宽#xff09;与接入速率的关系2 在模拟运营商的接入路由器ISP上配置CAR监管用户流量到认购速率64K3 取证模拟的企业网络以128K的接入速率… 演示 GTS流量×××和CAR流量监管的效果及相关实践计划演示目标1 理解clock rate(时钟频率)和bandwidth带宽与接入速率的关系2 在模拟运营商的接入路由器ISP上配置CAR监管用户流量到认购速率64K3 取证模拟的企业网络以128K的接入速率冲击64K的认购监管速率出现数据丢包现象4 通过在企业边界R1上作流量×××将128K×××为64K的速率看到延迟增大缓解丢包5 企业发送同样大小的包将接入速率AR改变成与认购速率相同此时会发生什么情况演示背景R1和R2的10MB以太网部分模拟企业的内部高速网络R1和ISP路由器的串口链路部分模拟企业到运营商的WAN链路接入将ISP的时间频率配置为128000那么此时整个链路的接入速率AR就是128K也就是说R1将以128K的速率发送数据到ISP但是由于企业只支付了64K认购速率的费用所以运营商会使用监管工具将用户的发送速率监管在64K范围内如果有超过的数据包那么这些超过的数据包将被丢弃为了避免过量的数据包被丢弃所以在路由器R1上部署流量×××以牺牲更大的延迟来缓解丢包。演示环境如图所示演示步骤第一步配置路由器R1和ISP之间的串口链路让ISP提供时钟并将时钟配置为128000带宽配置为128K注意在这个环境中完成这样的配置其主要的目标是让链路的接入速率为128K要将链路的接入速率仿真为128K必须将时钟频率配置为128000因为决定速率的关键因素是时钟频率关于这一点后面有详细描述。注意这样这样配置才能让整个实验最大程度接近真实读者才能看到监管和×××的不同效果。 ISP路由器的配置ISP(config)#inte s1/0ISP(config-if)#ipaddress 192.168.1.2 255.255.255.252ISP(config-if)#clockrate 128000*配置时钟频率为128000ISP(config-if)#bandwidth 128 *配置带宽为128KISP(config-if)#noshutdownISP(config-if)#exit 请严格区别clock rate和bandwidth的不同意义 Clock rate是定义了真实的物理层转输的bit比特率这被路由器应用到需要提供时钟频率的接口上比如某台路由器的同步串口上(S1/0)所以链路真正的传输速率是由Clock rate来决定而bandwidth是通过申明带宽来告之路由器的一些其它应用当前的带宽是多少这种典型的应用包据OSPF或者EIGRP再计算路由度量值的时候使用。在计算度量值是使用的是bandwidth而不是依据Clock rate但是bandwidth是不应响真实的发送率的最后建议将bandwidth与clock rate进行对应配置比如链路的时钟频率为128000那么建议将带宽配置为128K。 ISP(config)#inteloopback 1ISP(config-if)#ipaddress 192.168.4.1 255.255.255.0ISP(config-if)#noshutdownISP(config-if)#exit ISP(config)#router rip * 在ISP的网络设备上公告路由ISP(config-router)#noauto-summary ISP(config-router)#version2ISP(config-router)#network192.168.4.0ISP(config-router)#network192.168.1.0ISP(config-router)#exit 路由器R1的基础配置R1(config)#intes1/0R1(config-if)#ipaddress 192.168.1.1 255.255.255.252R1(config-if)#bandwidth128 * 为路由器R1配置物理链路的接入带宽R1(config-if)#noshutdownR1(config-if)#exit 注意在配置R1的S1/0接口的接入带宽时请将其配置为与DCE端ISP路由器的时钟频率相同如图所示因为时钟频率是128000所以请将R1的带宽也配置成128K。R1(config)#intee2/0R1(config-if)#ipaddress 192.168.2.1 255.255.255.0R1(config-if)#noshutdownR1(config-if)#exit R1(config)#routerrip * 在R1上启动并公告路由R1(config-router)#noauto-summaryR1(config-router)#version2R1(config-router)#network192.168.1.0R1(config-router)#network192.168.2.0R1(config-router)#exit 路由器R2的基础配置R2(config)#intee2/0R2(config-if)#ipaddress 192.168.2.2 255.255.255.0R2(config-if)#noshutdownR2(config-if)#exit R2(config)#routerrip * R2上启动并公告路由R2(config-router)#version2R2(config-router)#network192.168.2.0R2(config-router)#noauto-summaryR2(config-router)#exit 第二步ISP路由器的S1/0接口上也就是允许企业接入ISP的接入端口配置基于CAR的流量监管监管的具体内容如下所示将流量监管到每秒64K监管到该速率的原因可能是企业用户只向ISP运营商支付了64K速率的流量费用然后配置持续突发Bc为1500个字节而最大突发BcBe2000个字节事实上真正的Be只有500个字节。如果满足CAR语句所定义的监管范围数据将被转发如果超过了监管范围那么这些数据包将被丢弃。 在ISP上配置基于CAR的流量监管ISP(config)#interfaceSerial1/0ISP(config-if)#rate-limitinput 64000 1500 2000 conform-action transmit exceed-action drop 注意这里的Bc1500个字节并没有使用公式BcTc*CIR也就是Bc0.125*640008000bits再将8000个位除以8得到1000个字节的原因是因为Bc大小不能低于接口的MTU值关于这一点在12.7.5关于CAR使用Bc监管速率*Tc来确认Bc时的小故障中已经作了详细描述因为目前ISP的S1/0的接口使用的是1500个字节作为MTU所以将Bc配置为了1500字节。 第三步在该实验环境中模拟的企业内部路由器R2上发起对192.168.4.1的ping连续发50个ping包每个ping包的大小为2000字节以192.168.2.2作为源地址ping192.168.4.1。具体的显示结果如图所示可以看出在带上如图所示的各项参数完成ping时192.168.2.2到192.168.4.1的流量有严重的丢包现象。数据的成功率只有66%,50个包通了33个丢弃了17个包平均延迟为91ms。然后可以通过show interfaces s1/0rate-limit指令查看到超过CAR定义监管范围的17个包被丢弃如图所示分析为什么现在会存在严重的丢包现象 在一个网络中存在丢包的原因有很多种目前这种严重丢包的现象主要是因为用户网络以接入速率(AR)128K来发送数据而ISP路由器的监管器将限制进入的流量为64K所以就产生了如图示的“瓶颈效应”由于没有使用流量×××并且配置CAR将超过认购流量的数据包执行丢弃注意确认超过认购流量的算法是令牌桶算法而不是简单的对流速的加减法所以才会出现严重的丢包。那么此时需要对用户网络的路由器R1配置流量×××将接入速率128K×××为认购速率也就是CIR速率64K然后缓存超额的包等到下一个周期再发送超额的包来尽量避免丢弃这样做的目标是使用流量×××去匹配ISP运营商的流量监管所以在实践的环境中流量×××一般会和流量监管配合使用。第四步在R1上配置流量×××将128K的接入速率×××为64K的认购速率而在配置流量×××时流量×××中的Bc和Be参数让IOS系统根据配置的×××速率64K去自行计算无需管理员手工配置这也是思科的建议的思想具体配置如下所示 在路由器R1的S1/0接口上执行流量×××的配置R1(config)#inte s1/0R1(config-if)#traffic-shaperate 64000 * 使用GTS配置流量×××的速率为64KR1(config-if)#exit 在配置流量×××后首先来观察没有大量数据发送时的各项状态可以看到如图所示的各个流量×××选项×××的目标速率为64000、Bc为8000位1000字节、Be为8000位、Tc是125ms、BcBe为2000字节关于各个选项的参数都是根据BcCIR*Tc的公式计算而来而关于这个公式的计算在前面的小节有更详细的描述。然后可以通过show traffic-shape statistics指令来查看流量×××的状态如图所示目前的流量×××为非激活状态因为此时暂无任何大量的数据发送流量×××只在用户发送的数据超过拟订的×××速率根据令牌桶的算法决定后才会被激活如果无数据发送或者发送的数据根据令牌桶的算法后低于×××速率那么流量×××将永远不会被激活。注意如果用户发送的流量没有超过×××条件那么流量×××将不被激活 现在在路由器R2上使用与先前相同的Ping参数及携带数据包的大小来ping192.168.4.1,具体配置如图所示可以看到在相同的流量监管条件下因为用户配置了流量×××功能并将128K的接入速率×××为64K的认购速率也就是去匹配了ISP运营的监管速率所以此时的流量没有任何丢包现象为什么不发生丢包原为流量×××缓存了数据包它以牺牲更大的延迟作为代价来换回数据包不被丢弃所以它的平均延迟将增大如图所示平均延迟为249ms而在没有执行流量×××之前的平均延迟是91ms。 在流量持续的发送周期中可以来到路由器R1上通过show traffic-shape statistics来查看对流量×××的统计数据如图所示下面显示了流量×××队列的深度没有被×××的数据包以及被×××延迟的数据包以及目前的流量×××状态为激活状态。根据上面的实验可以得到一个关于流量管理的经验应该尽量让用户接入速率AR去匹配在ISP运营商处所购买的认购速率也叫CIR通过上面的实验取证了一个道理接入速率AR并不是越高越好而应该是让接入速率AR越匹配认购速率越好。如果无法更改接入速率AR,那么就需要使用流量×××将接入速率AR×××为与认购速率相匹配让网络中的数据包平滑过渡避免过大的抖动和丢弃。注意很多时候把接入速率也叫做用户的物理速率。同时还可以看出在很多时候流量×××是伴随流量监管在使用为什么这样讲呢很简单通常管理员对某个用户正在执行流量监管或者叫限速这大抵意味着用户的接入速率正高于管理员不希望的速率所以才来限制用户而正是因为这种限制可能会导致用户丢包从而引发用户要使用流量×××来放慢和平滑发送速率。 在实践中工程人员可能提出的问题 提问1:前面的描述一直在强调一个问题就是让用户接入速率AR去匹配在ISP运营商处所购买的认购速率也叫CIR那么在这个实验环境中如果现在将用户的接入链路AR的时钟频率及带宽都改成64K这样就可以与认购速率64K相匹配了同时不再使用流量×××会发生丢包吗将接入速率AR更改为与认购速率相匹配的64K而不再使用流量×××如果仍然是ping50个包然后每个包带2000字节的重量会明显发现处于64K的接入速率时丢包没有先前接入速率处于128K时那么严重会有明显好转但是可能仍然会存在丢包此时丢包的原因就不是接入速率AR高于认购速率所产生的问题了因为接入速率AR高于认购速率是造成丢包的一个重要原因但是不是唯一的原因比如虽然接入速率与监管速率匹配了但是由于产生的高额流量是持续不间断的发送超过了链路本身能承受的压力此时尽管用户的接入速率与监管速率相匹配但是它仍然会丢包。而这种高额流量的产生来源取决于应用程序本身比如该实例中笔者正使用一个持续的带大型数据的ping来制造高额流量在实际的环境中可能是视屏系统或者其它的软件。 提问2如果出现了提问1中所描述的虽然接入速率与监管速率匹配了但是由于产生的高额流量是持续不间断的发送超过了链路本身能承受的压力造成丢包该怎么办 第一步首先通过统计分析流量并计算后然后在用户的边界设备上执行流量×××这就是所谓当接入速率与监管速率匹配了但是为更好的平滑流量作为最大的目标来作的流量×××处理。如果在这种情况下被丢弃的程度得以缓解那么请感觉上帝启法您的这个决定。但是此时请谨慎的考虑IP语音流量如果还是出现丢弃。第二步请联系运营商并申请运营商在不违反你的认购速率的前提条件下适当加大对你监管的持续突发和最大突发当然这种增加是适当的适当的前提条件不违反你的认购这样可以让用户的网络流量性能得到最大的价值如果用户以一种更专业的眼光来看认购速率请您一定记住在签订那一张纸流量认购合同时您有权力要求运营商出了申明认购的承诺速率CIR是多少的同时要求对持续突发和最大突发进行说明或者书面承诺即便是你会让他很不开心。通常这种方案能缓解你丢弃的现象。如果这样做还不能达到用户的目标。第三步如果完成了前面两个步骤并确定不是由于用户内部网络的某个故障所导致的那么此时用户需要做的就是向运营商申明和购买更高的认购速率了。但是用户所在的企业高层不愿意为购买更高的认购速率而支付更多的费用。第四步此时用户唯一的办法就是限制内部用户对一些非重要数据的访问速率避免这种不重要的访问和下载来占用宝贵的WAN带宽然后在现有的已经出现匮乏的带宽资源条件下采取本章后面描述的各种队列调度机制和拥塞避免机制去更合理的执行队列调度比如将非常重要的数据流量放入低延迟队列或者优先级队列中执行调度其实这也是充分使用QOS技术来保证服务质量的核心所在但是这种做法并不能从根本上解问题也是一种“割股充腹”的行为因为随着用户企业内部网络的不断扩展对流量的需求不断提高最终用户还是需要通地购买更高的认购速率来缓解流量需求但是通过在部署QOS机制后再去购买更高的认购速率将会使企业的资源使用更充分过渡更平稳通常管这种行为叫做可持续的增长。 转载于:https://blog.51cto.com/7658423/1577240
