演示目标：
1 理解clock rate(时钟频率)和bandwidth（带宽）与接入速率的关系
2 在模拟运营商的接入路由器ISP上配置CAR监管用户流量到认购速率64K
3 取证模拟的企业网络以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/0
ISP(config-if)#ipaddress 192.168.1.2 255.255.255.252
ISP(config-if)#clockrate 128000*配置时钟频率为128000
ISP(config-if)#bandwidth 128 *配置带宽为128K
ISP(config-if)#noshutdown
ISP(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 1
ISP(config-if)#ipaddress 192.168.4.1 255.255.255.0
ISP(config-if)#noshutdown
ISP(config-if)#exit
ISP(config)#router rip * 在ISP的网络设备上公告路由
ISP(config-router)#noauto-summary
ISP(config-router)#version2
ISP(config-router)#network192.168.4.0
ISP(config-router)#network192.168.1.0
ISP(config-router)#exit
路由器R1的基础配置：
R1(config)#intes1/0
R1(config-if)#ipaddress 192.168.1.1 255.255.255.252
R1(config-if)#bandwidth128 * 为路由器R1配置物理链路的接入带宽
R1(config-if)#noshutdown
R1(config-if)#exit
注意在配置R1的S1/0接口的接入带宽时，请将其配置为与DCE端（ISP路由器）的时钟频率相同，如图所示，因为时钟频率是128000，所以请将R1的带宽也配置成128K。
R1(config)#intee2/0
R1(config-if)#ipaddress 192.168.2.1 255.255.255.0
R1(config-if)#noshutdown
R1(config-if)#exit
R1(config)#routerrip * 在R1上启动并公告路由
R1(config-router)#noauto-summary
R1(config-router)#version2
R1(config-router)#network192.168.1.0
R1(config-router)#network192.168.2.0
R1(config-router)#exit
路由器R2的基础配置：
R2(config)#intee2/0
R2(config-if)#ipaddress 192.168.2.2 255.255.255.0
R2(config-if)#noshutdown
R2(config-if)#exit
R2(config)#routerrip * R2上启动并公告路由
R2(config-router)#version2
R2(config-router)#network192.168.2.0
R2(config-router)#noauto-summary
R2(config-router)#exit
第二步：ISP路由器的S1/0接口上，也就是允许企业接入ISP的接入端口配置基于CAR的流量监管，监管的具体内容如下所示：将流量监管到每秒64K，监管到该速率的原因可能是企业用户只向ISP运营商支付了64K速率的流量费用，然后配置持续突发Bc为1500个字节，而最大突发（Bc+Be）=2000个字节，事实上，真正的Be只有500个字节。如果满足CAR语句所定义的监管范围，数据将被转发，如果超过了监管范围，那么这些数据包将被丢弃。
在ISP上配置基于CAR的流量监管：
ISP(config)#interfaceSerial1/0
ISP(config-if)#rate-limitinput 64000 1500 2000 conform-action transmit exceed-action drop
注意这里的Bc=1500个字节，并没有使用公式Bc=Tc*CIR也就是Bc=0.125*64000=8000bits，再将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/0
R1(config-if)#traffic-shaperate 64000 * 使用GTS配置流量整形的速率为64K
R1(config-if)#exit
在配置流量整形后，首先来观察没有大量数据发送时的各项状态，可以看到如图所示的各个流量整形选项，整形的目标速率为64000、Bc为8000位（1000字节）、Be为8000位、Tc是125ms、Bc+Be为2000字节，关于各个选项的参数都是根据Bc=CIR*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机制后，再去购买更高的认购速率将会使企业的资源使用更充分，过渡更平稳，通常管这种行为叫做可持续的增长。
本文转自 kingsir827 51CTO博客，原文链接：http://blog.51cto.com/7658423/1577240，如需转载请自行联系原作者
