据我了解，Cisco IOS CAR（Committed Access Rate）是基于漏桶算法（想法与令牌桶算法完全相同），我配置为平均速率的位数，是“不断漏桶的水”的量”。例如这里的平均输入速率限制速率是 5Mbps：
interface FastEthernet0/0
ip address 10.10.10.2 255.255.255.0
rate-limit input 5000000 937500 1875000 conform-action transmit exceed-action drop
现在如果流量率低于平均率，那么它总是符合的。“正常突发”决定了在应用超出操作之前流量突发有多大，我是否正确？因此，在上面的示例中，如果流量恒定为 5Mbps（存储桶中的 625000 字节），那么我可以发送一秒钟 7.5Mbps（向存储桶添加额外的 312500 字节）的流量，并且不会丢失一个比特? 如果桶中的字节在正常突发和最大突发之间，那么如果最大突发也已满，则基于类似 RED 的算法丢弃字节，直到所有新数据包都被丢弃？
让我们计算一下我们在这里处理的内容。CAR 基本上是 IOS 监管的旧版本，因此所有这些概念都适用于两者。
Committed Information Rate (CIR) = 5,000,000 (5Mbps)
Burst Commit Bucket (Bc) = 937,500
Burst Excess Bucket (Be) = 1,875,000
Time Interval (Tc) = Bc / CIR = 0.1875 s = 187.5 ms
我们希望将流量限制为 5Mbps。提交桶是 937,500 字节。Burst Bucket 是 1,875,000 字节。并且每 187.5 毫秒重新填充桶。
正如您提到的，IOS 使用桶机制来限制可以通过的流量。 它不会在任意时间段内将流量平滑到 X% 的接口带宽！ 相反，它允许完全访问接口的带宽，只要您有代币支付即可。
此外，由于这是警务，因此 RED/WRED 不起作用。RED 仅在需要管理队列时发生。 在监管中没有缓冲/排队，只有在整形中。
让我们先处理 Commit Bucket (Bc)。假设目前没有 Excess Bucket (Be)。
* 仅提交桶（双色监管器）*
这是一个非常严格的监管器，只会让您在 CIR 内准确发送；上面没有爆裂。只有一个桶，公元前。流量有两种“颜色”，符合和超过。
时间 = 0 ms --存储桶开始时已满，其中包含 937,500 字节的令牌。假设您通过接口发送 7,500 个字节。现在 IOS 将存储桶减少 7,500 字节，存储桶中现在有 930,000 字节的令牌。发送的流量被认为是“符合”的，并对其应用了“符合操作”。
时间 = 187.5 ms --我们现在达到了 Tc，并重新填充 Bc 桶。添加了 937,500 字节的令牌。任何额外的令牌溢出并丢失。
Time = 190 ms --提交桶中有 937,500 个令牌。我们收到 2,000,000 字节的流量。前 937,500 个字节被很好地传输，因为存储桶有令牌。剩余的流量被视为“超出”，并根据“超出动作”进行处理。请记住，监管中没有缓冲（这称为整形）——您要么传输、注释和传输，要么丢弃。
时间 = 375 毫秒——我们再次命中 Tc，Bc 桶重新填充了 937,500 个令牌。
* 提交带有过多存储桶的存储桶（三色监管器）*
您可以选择添加一个多余的存储桶 (Be)。这允许流量暂时超过 Bc 存储桶。整体 CIR 应保持不变。这是一个三“颜色”监管器：符合、超出和违反。
时间 = 0 ms --两个存储桶（Bc 和 Be）一开始都是满的。Bc 有 937,500 个代币，Be 有 1,875,000 个代币。
时间 = 50 ms -- 2,000,000 字节的流量到达。路由器首先递减 Bc 桶令牌。它将 Bc 桶减少到零。Bc 涵盖的 937,500 字节流量被视为“符合”，并对其应用了“符合操作”。
剩下 1,062,500 字节的流量还没有令牌。现在路由器进入 Be 桶，并减去 1,062,500 个令牌以覆盖其余的流量。这些字节被视为“超出”，并将对其应用“超出操作”。在您的示例中，流量将被丢弃，但您可能会备注或仅传输它。
如果你在家里记分，Bc 现在有 0 个令牌，Be 有 812,500 个令牌。
时间 = 75 ms --现在，路由器接收另外 1,200,000 字节的流量。Bc 桶是空的，所以没有帮助。Be 存储桶可以提供帮助，因此它用其令牌覆盖了前 812,500 字节的流量，现在是空的。此流量被视为“超出”，并将对其应用“超出操作”。
现在桶已经干了，但仍有 387,500 个字节需要处理。这种流量被认为是“违规”并且总是被 CAR 丢弃（您可以使用 MQC 和带有“violate-action”的警察命令用它做其他事情）。
时间 = 187.5 毫秒——现在我们到达第一个 Tc 间隔，是时候填满我们的桶了。一个关键点是，只有价值Bc的代币被重新填充！Bc 桶首先填充到 937,500。Be 桶仍然是空的。
时间 = 375 ms --一直很安静，我们进入下一个 Tc 间隔。Bc 价值的代币被添加到 Bc 桶中。由于 Bc 桶已经满了，多余的令牌不会丢失——而是“溢出”到 Be 桶。现在 Bc 桶装满了 937,500 个令牌，而 Be 桶装满了 937,500 个令牌。
时间 = 562.5 ms --安静，我们在下一个 Tc。Bc 价值的代币被添加到 Bc 桶中，该桶已经满了。所有这些都溢出到 Be 桶中（已经有 937,500 个令牌）。Be 一直填充到 1,875,000 个令牌。
* 最后说明 *
您的配置没有使用 Be 存储桶。您仅使用 Bc 存储桶进行速率限制/监管，如果向您发送数据的监管器/整形器配置不同且 Tc 不同步，则可能会产生意想不到的副作用。
CAR/rate-limit 非常旧且已弃用。考虑切换到 MQC 和现代 QoS 来实现这一点，因为它将为您提供更多信息和选项。
我完全忽略了上面的序列化延迟（在线路上传输数据所需的时间），而且我很确定数学在真实场景中是行不通的。但是无论使用的确切数字如何，这些概念都是可靠的。
* MQC 示例 *
policy-map PM-FA0/0-IN
class class-default
police cir 5000000 bc 937500 be 1875000
!
interface Fa0/0
service-policy input PM-FA0/0-IN
!
* 来源 *