流量监管同样使用令牌桶（单桶或者双桶）算法，现在来介绍一个典型的流量监管工具CAR（committed access rate）承诺访问速率，CAR的工作目标是判断数据流量是否匹配或者超过认购流量（合同流量也叫CIR），能对匹配认购流量的数据包或者超过认购流量的数据包执行转发、丢弃、或重标记（一般是降低优先级）。需要注意的是CAR填充令牌桶中的令牌，一个令牌代表可以接收或者发送一个字节（byte）的数据或不是位（bit）。
注意：通过前面对令牌桶的描述，大家应该清晰这个算法了，下面的描述将基于CAR在单桶（只有Bc）和双桶（Bc和Be同时存）在的情况进行讨论。
CAR使用单桶算法（只有Bc）
CAR会在一个时间间隔Tc往桶1（Bc）中填充令牌，注意这里一个令牌代表一个字节，所以Bc的单位是字节，这和流量整形中Bc使用比特为单位不同，可以通过公式Bc=监管速率*Tc，一般监管速率都被配置成CIR，Tc默认为125ms。由于使用目前不存在Be所示CAR的判断非常简单，只有两种情况：
如果数据包的字节数小于或者等于（<=）桶1（Bc）的容量，也就是<=桶1的字节数那么该数据包被视为能匹配认购流量的数据包。CAR会移除和该数据包大小相同的令牌数，这个行为叫做conform 。
如果数据包的字节数大于（>）桶1（Bc）的容量，那么该数据包被视为超过认购流量的数据包，CAR不会移除令牌，这个行为叫做exceed。
必须注意的一件事情：在理解令牌桶算法的时候（无论是单桶或者双桶），实际上这都是一种形象的比喻，并不是路由器内部真正存在两个桶。笔者将单桶和双桶分开描述是为了让读者能使用渐进式的方法来理解。所以在这里为了给后面配置CAR的时候打下基础，需要特别的说明，CAR是必须去明确的逐项申明监管速率（一般为CIR）、持续突发Bc、最大突发（Bc+Be）分别是多少，不能只配置CIR然后，让系统自行计算Bc和Be，这与流量整形不同，而且配置是否使用第2个桶（Be）的方式和流量整形不同，这将在12.7.4部署CAR行为时作更多的描述。
CAR使用双桶算法（同时有Bc和Be）
CAR使用双桶算法时，将使用一个更复杂的算法来决定数据包是匹配还是超过认购流量，CAR将在耗尽Be（事实上此时Bc肯定耗尽了）之前来确认，那些超过的包，哪些属于conform，哪些属于exceed。但是这个决定没有像单桶那么简单，它关系到一个“debt（欠偿）”机制和欠偿变量（compounded debt Dc）的计算。这切的原因都来自于CAR使用了双桶，它的过程是这样的：
当CAR同时使用Bc和Be时：
1如果数据包的字节数小于或者等于（<=）桶1（Bc）的容量，也就是<=桶1的字节数那么该数据包被视为能匹配认购流量的数据包。CAR会移除和该数据包大小相同的令牌数，这个行为叫做conform 。
2 如果数据包的字节数大于（>）桶1（Bc）的容量，但是小于桶2（Be），那么该数据包将被CAR使用debt（欠偿）机制来决定，该数据包是conform或者exceed，因为你现在使用了两个桶，所以这一切将和桶2（Be）有关，那么什么是debt（欠偿）机制（很多也叫欠偿算法）
理解debt（欠偿）机制
因为使用双桶算法，所谓debt（欠偿）的意思就是，如果一个新到来的数据包尺寸（事实上就是字节）大于了桶1（Bc）中的令牌数，这个时候CAR将向桶2（Be）借令牌，然后一个Tc时间间隔后，如果桶1中的令牌不被彻底用完，比如用户低于监管速率发送数据，或者有一段间没有发送数据，那么桶1的令牌将被充满，然后此时桶1用溢出的令牌来偿还先前向桶2（Be）借的令牌。
假设此时，桶1(Bc)的令牌已经耗完，等于0，而桶2（Be）还有8000个字节的令牌，此时刚好有一个1000字节的数据包到达，CAR发现桶1没有可用令牌了，它就去向桶2借，因为目前桶2有8000个令牌，所以它可以借出1000字节的令牌，此时这个1000字节的数据包将被认为是一个conform的数据包，因为它虽然大于Bc但是它小于Be，然后桶2的令牌就会从8000减少到7000，这个向桶2(Be)借的1000个字节的令牌数量叫做“实际欠偿”（actual debt Da)，如果此时还有数据继续被发送，当然假设此时的Bc还是等于0，这个时候就牵涉到一个“欠偿变量”（compounded debt Dc）也叫累计欠偿的关键组件，而这个累计欠偿Dc将关系到如何决定当前数据是是conform或者exceed，在说明决定原则前必须前理解累计欠偿的计算公式，具体如下表所示：
注意：欠偿变量Dc的计算只会在桶1（Bc）被耗尽之后才会开始，此时才会向桶2借令牌。
累计Dc的增长会比Da更快，可以通过下表的一个到达的数据包、Da和累计Dc的关联来看出它的计算方式。现在假设是为CAR的Be配置为8000字节。当累计的Dc超出Be时，CAR将这个包确定为超过认购流量的数据包，也就是exceed，然后将当前的Dc值减至0.这时候CAR将做出如下原则：
如果Dc的累计增长超过了Be，当前的数据包就超出了认购流量，CAR将无法再从Be借到令牌，事实上这个时候Bc是肯定在耗尽Be之前就没有了可用的令牌，CAR将这个包确定为超过认购流量的数据包，也就是exceed，然后可以针对这个的数据包执行相应的exceed-action监控行为，可以是丢弃，也可以是降级标记后转发。
但是，如果借偿算法中的累计Dc小于Be，也就是Be还有可用的令牌借出，那么这个数据包被视为conforms，就能匹配到认购流量，然后桶2（Be）将移除与数据包字节数相同的令牌，然后执行一个conforms的行为，一般而言就是转发。
注意：在流量监管的双桶算法中，引入这个复杂的欠偿算法其实只有一个简单的目标就是在能监管的范围内缓解包的丢弃，这与流量监管的初衷并不矛盾。请永远不要认为丢弃数据包只是一个很小的事情，甚至会认为有TCP来确定可靠性，有重传机制的存在，可以调整滑动窗口来解决，关于这些问题将会在拥塞避免时做解释。
部署CAR行为
现在假设需对进入路由器E2/0接口的用户流量执行监管，将其监管到64K，然后通过公式Bc=监管速率*Tc来确认Bc的大小，及配置最大突发（Bc+Be）的示例如下：
配置CAR：
指令解析：
rate-limit：指示在某个接口下启动CAR限速机制也就监管功能
input[output]:指示确定CAR的限速方向，入和出方向都可以，但是建议在入向上做限速。
监管速率:指示CAR对用户流量的监管速率，一般建议监管到与认购流量或者叫CIR相同的速率，该实例中是64K，监管速率的单位是每秒多少比特（bits）。
可持续的突发Bc：配置可持续的突发量也就是桶1的容量，注意单位是字节(byte)，可以通过公式Bc=监管速率*Tc来确定，在该实例中就是64000*0.125(默认的Tc为125ms)等于8000位,在配置时需要将这个8000bit换算成字节，一个字节等于8个位，所以8000除以8等1000byts（字节）这就是Bc的大小。或者使用12.7.6如果存在多种方案来确定Bc和Be大小，应该选择哪一种最合适部分中的方案二或者方案三来确定。
Maximum burst（最大突发=Bc+Be）：注意该选项并不仅仅指示桶2（Be）的大小，不能仅将该选项当作Be的配置处理，事实上最大突发是指Be+Bc，如该实例所示的配置最大突发为2000字节，此时真实的Be只有1000字节，因为其中有1000字节是属于Bc。
Conform-action(匹配行为)：在现在这个Conform-action就必须先理解前面所描述的令牌桶算法，如果是单桶（只有Bc）,那么只要小于或者等于Bc大小的数据都将会是Conform；如果是双桶，这将根据双桶的借偿算法来决定，如果借偿算法中的累计Dc大于Bc但是小于Be，那么当前的数据包还是属于Conform，此时对Conform的数据包，执行一个action（行为），可以是转发、重标记、丢弃等，一般对匹配的数据包都执行transmit（转发或叫传输）。
exceed-action（超额行为）：该行为仍然是根据令牌桶算法来做出决定：如果是单桶（只有Bc）那么只要大于Bc的数据都会被视为exceed，如果是双桶（有Bc同时也有Be）这将根据双桶的借偿算法来决定，如果借偿算法中的累计Dc大于Be，那么当前的数据包就被视为exceed，此时需要对exceed的数据包执行一个action（行为），可以是转发、重标记、丢弃弃等，在该实例配置中执行的是drop（丢弃）。但是请注意，并不是绝对的说：对exceed的数据包执行的动作就一定是丢弃，也可能是降级标记后再转发，因为过多的丢包对网络并没有任何好处。关于这一点在12.7.8在一些情况下为什么CAR将不能匹配认购流量（CIR）的数据包还要做转发，会作更详细的说明。
在配置Maximum burst（最大突发）的注意事项：
在配置CAR的Maximum burst（最大突发）需要注意，如果如图所示，将正常的突发Bc和最大突发配置成相同的值，比如：Bc=2000字节，最大突发（Bc+Be）=2000字节，那么此时，相当于没有配置Be值，更直白的讲此时的CAR将使用单桶算法。这和配置GTS（通用流量整形时是有差异的，在配置GTS时如果需要申明不使用Be，那么会明确的将Be值配置为０，关于这一点请参看流量整形部分的描述，而CAR则是将最大突发配置为等于正常突发。
关于CAR使用Bc=监管速率*Tc来确认Bc时的小故障
在很多情况下，当用户在某个网络设备的接口上配置：rate-limit input64000 1000 2000 conform-action transmit exceed-action drop后，系统报告如下信息,根据Bc=监管速率*Tc的公式，目前监管速率是64K，而Tc默认是125ms，所以Bc应该就是64000*0.125=8000(bits)然后再换算成字节就是8000/8=1000字节，Bc就应该是1000字节，而如图所示，该实例中通过公式计算出来的Bc=1000字节，也是Bc有效范围内的值，那么在配置时系统为什么会报告错误？
执行上述指令后系统会报错：
Illegalnormal burst size * 违返规则的持续突发值（Bc）
Increasingnormal burst size to 1500 * 请增加Bc值到1500
上述通过公式计算出来Bc=1000字节是没有错误的，只是通常在做CAR时会忽略一件事情，为了考虑更好传输性能，CAR的Bc值（也就是令牌桶1）的大小，是不应该低于物理接口的MTU值的大小的，比如：该实例中通过公式计算出来的Be为1000字节，而如图所示，这是一个以太网接口(E2/0)，MTU=1500，所以系统才提示“Increasing normal burst size to 1500”请增加Bc值到1500。
当然，在该实例中如果用户不想调整CAR的Bc值到1500，那么可以通过更改网络设备的MTU在大小去吻合Bc值的大小，比如使用如下指令把MTU改为1000。但是笔者强烈建议不要修改设备默认的MTU值，因为这可能会引发其它更多问题，而且这种通过更改MTU的方式来适应Bc值只能在非以太网接口，比如串口上执行，在以太网接口上是不支持更改MTU值的。
改变MTU去适应CAR的最小Bc值
R1(config)#intes1/0
R1(config-if)#mtu1000 * 将接口MTU调整为1000字节
如果存在多种方案来确定Bc和Be大小，应该选择哪一种最合适
首先说明一下，因为CAR必须要逐项申明监管速率、Bc、最大突发值（实际上是Bc+Be）分别是多少，用户不能像基于流量整形和类别的监管那样仅配置监管速率，后面的Bc和Be都交给系统自己去计算出一个默认值，这是不可以的，所以Bc和Be值的确定和配置将不被“回避”，那么将如何来确定Bc和Be，在众多文档中一般会出现3种确定Bc和Be的方案：
第一种方案：Bc=监管速率*Tc
假设监管速率为64Kbit/s，而通过思科推荐的Tc都是125ms，64000*0.125=8000bits，然后再将8000bits换算成字节即1000byts，所以Bc为1000byts，如果再将Be也配置成1000字节，那么执行的指令如图所示：
为什么Be是1000字节，在配置时输入的却是2000字节？原因很简单，因为CAR的Maximum burst bytes（最大突发字节），并不仅是Be的值，而是Bc+Be的值，所以应该将最大突量配置为2000（1000字节的Bc+1000字节的Be）。
注意这里需要说明的是：这是一个实验室计划的公式，或者是为了帮助大家理解流量控制（包括整形和监管）去发现速率、持续突发、时间间隔三者之间的关系，事实上Tc值是不可以被管理员手工配置的，它只能被速率和持续突发（Bc）去决定，而大家常用的Tc=125ms，它也只不过是一个推荐的最合适的假定值，因为本身这个假定值的范围就是在10-125ms之间，只是取用了最高上线的假定值，所以基于这个默认Tc=125ms，使用Bc=监管速率*Tc的公式去计算得到Bc值也是一个“Ideal value”也就是理想值。这意味着如果在实战的工程项目中使用这个默认的125ms算出来的Bc值，如果过低，会造成用户实际的数据到达速率，低于甚至于有时候是远低于监管所配置的速率。所以一般使用第一种方案确定的Bc都是用在理解和分析相关知识点和技术问题上，并不是一个最佳的实践行为，但是这种计算公式是正确的，是正确的，不代表它是最推荐的实践方案，一般在理解了流量整形和监管后，自己在实验室要需要搭建并做出流量监管和整形的效果时，通常会使用上述公式去计算Bc值，而且通常算出的这个值都比较小，所以容易看到过载和丢弃的现象，再同时使用该公式的Tc(默认125ms)去计算流量整形，就可以看到整形的实际效果，具体的在本章的演示： GTS流量整形和CAR流量监管的效果部分会有详细描述。
第二种方案：将1秒钟可传输的监管值转换为字节作为Bc，然后附加0.5秒的值作为Be，假设现在的监管速率是每秒64Kbit／s,现在根据上述原则来确主Bc和Be，那么就将64000*1字节然后再除以8等于8000字节来作为Bc，然后以0.5秒的4000字节来作为Be，但是请注意在配置时用户应该使用如图输写方式：在Bc后面的那个12000个字节，叫Maximumburst，它是由Bc+Be得到，所以真实的Be值只有4000个字节。
第三种方案：只要知道被监管的目标速率是多少，就将依据如下所示的公式来得到Bc及最大突发值是多少，通过和第二种方案的对比，不难看出其实方案三和方案二的实质是一样的，只是方案上中方案三中多配置了0.5秒的Bc字节量，在方案二是以每秒而得到的Bc量，方案三中是以1.5秒所得到的Bc量，然后整个最大突发建议的是2倍Bc。这里的这个1.5秒可以被理解成是一个数据的平均往返时间。所谓平均往返时间就是来准确体现路由的途径时间，最理想的就是以1秒为单位来考虑，但是考虑到各种阻尼效应，所以多加了0.5秒，如果往返时间少于1.5秒，就必须更改该值来确保更准确的往返时间，那用户怎么才能知道最合理的往返时间，一种很科学的方案就是通过SLA来测量，当然这以超出本章的描述范围。
normal burst（BC）= configuredrate * (1 byte)/(8 bits) * 1.5 seconds
最大突发（Bc+Be）= 2 * normal burst
注意：在确定Bc和最大突发值时上述的方案2和3是具备良好实战意义的，正如思科官方文档所提示的这两个方案是“extensivetest results”（广泛测量的结果）。至于方案2和3在往返时间上的差异（哪0.5秒），可以针对具体工程项目中链路的情况来做调整。
