如何理解Cisco CAR中的“正常突发”和“最大突发”?


11

据我了解,Cisco IOS CAR(承诺访问速率)基于泄漏桶算法(思想与令牌桶算法完全相同),我配置为平均速率的位数为“水不断泄漏桶的数量” ”。例如,此处的平均输入速率限制速率为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的算法丢弃字节,直到丢弃所有新数据包?


您在我的答案中需要其他任何信息或解释,以赚取您设置的赏金吗?
凯勒G

请不要忘记您必须手动授予赏金 ; 如果您得到的答案不满意,请至少说明该答案缺少的内容。
Mike Pennington

Answers:


12

让我们计算一下我们正在处理的内容。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字节。突发桶为1,875,000字节。每187.5毫秒重新填充一次铲斗。

如您所述,IOS使用存储桶机制来限制可以通过的流量。 它不会在任意时间段内将流量平滑到接口带宽的X%! 取而代之的是,只要您有令牌可以支付,它就可以完全访问接口的带宽。

另外,由于这是治安,因此红色/白色不会起作用。RED仅在有队列要管理时发生。 管制中没有缓冲/排队,只有成形中。

让我们先处理提交桶(Bc)。假设目前没有多余的铲斗(Be)。

*仅提交存储桶(双色警察)*

这是一个非常严格的策略程序,只会让您准确地在CIR内发送;上面没有爆裂。Bc只有一个桶。流量有两种“颜色”,一致超出

时间= 0毫秒-存储桶开始时已满,其中装有937,500字节的令牌。假设您在整个接口上发送了7,500个字节。现在,IOS将存储桶减少了7,500个字节,并且该存储桶中现在具有价值930,000字节的令牌。发送的流量被视为“符合”,并且已应用“符合动作”。

时间= 187.5毫秒-我们现在击中Tc,然后重新填充Bc铲斗。添加了价值937,500字节的令牌。任何额外的令牌溢出并丢失。

时间= 190毫秒-提交存储桶中包含937,500个令牌。我们收到2,000,000字节的流量。前937,500个字节可以很好地传输,因为存储桶具有令牌。剩余流量被视为“超出”,并根据“超出行为”进行处理。记住,策略中没有缓冲(称为整形)-您可以传输,注释和传输,也可以丢弃。

时间= 375毫秒-我们再次击中Tc,Bc桶中重新装满937,500个令牌。

*用多余的桶提交桶(三色警察)*

您可以选择添加一个多余的存储桶(Be)。这样一来,流量便会暂时超过Bc存储桶。总体CIR应该保持不变。这是三个“颜色”策略:顺应,超出和违反

时间= 0毫秒-两个存储桶(Bc和Be)都开始充满。Bc有937,500个令牌,Be有1,875,000个令牌。

时间= 50毫秒 -2,000,000字节的流量到达。路由器首先递减Bc桶令牌。它将Bc桶减少到零。Bc覆盖的937,500字节流量被视为“符合”,并且对其应用了“符合动作”。

剩下的1,062,500字节的流量还没有令牌。现在,路由器进入Be桶,并减去1,062,500个令牌以覆盖其余流量。这些字节被视为“超出”,并将对其应用“超出动作”。在您的示例中,流量将被丢弃,但是您可能会备注或仅发送流量。

如果您要在家中保持分数,那么Bc现在有零个令牌,Be有812,500个令牌。

时间= 75毫秒-现在,路由器又接收了1,200,000字节的流量。Bc桶是空的,所以那里没有帮助。Be桶可以提供帮助,因此它使用令牌覆盖了前812,500字节的流量,现在为空。此流量被视为“超出”,并将对其应用“超出动作”。

现在,这些存储桶已经干dry了,但仍有387,500字节需要处理。该流量被认为是“违反”的,并且始终随CAR一起丢弃(您可以使用MQC和带有“ violate-action”的Police命令对其进行其他处理)。

时间= 187.5毫秒-现在我们到达第一个Tc间隔,这是充满水桶的时间。关键一点是,只有价值 Bc的代币才能重新填充!BC桶首先装满937,500。Be桶REMAINS EMPTY。

时间= 375毫秒-一直很安静,我们进入下一个Tc间隔。价值不列颠哥伦比亚省的令牌已添加到“不列颠哥伦比亚省”存储桶中。由于Bc存储桶已满,因此多余的令牌不会丢失-而是将它们“溢出”到Be存储桶。现在Bc存储桶已满937,500个令牌,Be存储桶已部分满937,500令牌。

时间= 562.5毫秒-保持安静,我们处于下一个Tc。价值不列颠哥伦比亚省的令牌已添加到已满的“不列颠哥伦比亚省”存储桶中。所有这些都溢出到Be桶(已经有937,500个令牌)中。Be一直填充到1,875,000个令牌。

*最后说明*

  • 您的配置没有使用Be存储桶。您仅使用Bc桶进行速率限制/管制,如果向您发送数据的策略器/ shaper配置不相同并且在Tc方向上不同步,则可能会产生意外的副作用。

  • CAR /速率限制非常旧并且已弃用。考虑切换到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
!

*来源*


答案很简单!但是我有一个关于单一速率(两种颜色)策略的问题。您提到了以下内容:流量有两种“颜色”,符合和违规。我认为应该是,符合并超过(而不是违反应该属于树色策略的方法)。
丹尼尔·布拉泽克

您说得没错,按照您的建议进行更新。
凯勒G
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.