ここで何を扱っているか計算してみましょう。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 msごとに補充されます。
おっしゃったように、IOSはバケットメカニズムを使用して、通過できるトラフィックの量を制限します。 任意の期間にわたってインターフェース帯域幅のX％へのトラフィックを平滑化しません！ 代わりに、トークンの支払いがある限り、インターフェースの帯域幅へのフルアクセスが可能になります。
また、これはポリシングであるため、RED / WREDは機能しません。REDは、管理するキューがある場合にのみ発生します。 ポリシングにはバッファリング/キューイングはなく、シェーピングのみです。
最初にCommit Bucket（Bc）を扱いましょう。現時点では、過剰バケット（Be）がないものとします。
*バケットのみをコミット（2色ポリサー）*
これは非常に厳密なポリサーであり、CIR内でのみ正確に送信できます。上記の破裂はありません。バケットは1つだけです。トラフィック用の2つの「色」は、あります準拠して超過します。
時間= 0ミリ秒-バケットは最初からいっぱいで、937,500バイトのトークンが入っています。インターフェイスを介して7,500バイトを送信するとします。これで、IOSはバケットを7,500バイト減らし、バケットには930,000バイトのトークンが含まれるようになりました。送信されたトラフィックは「適合」と見なされ、「適合アクション」が適用されます。
時間= 187.5 ms- Tcに到達し、Bcバケットに補充します。937,500バイト相当のトークンが追加されます。余分なトークンはこぼれ、失われます。
時間= 190ミリ秒-コミットバケットには937,500トークンが含まれています。2,000,000バイトのトラフィックを受信します。バケットにトークンがあるため、最初の937,500バイトは問題なく転送されます。残りのトラフィックは「超過」と見なされ、「超過アクション」に従って処理されます。覚えておいてください、ポリシング（シェーピングと呼ばれます）にはバッファリングがありません-送信、リマークして送信、またはドロップします。
時間= 375ミリ秒 -Tcに再度ヒットし、Bcバケットに937,500トークンが補充されます。
*超過バケットを使用したバケットのコミット（3色ポリサー）*
オプションで、超過バケット（Be）を追加できます。これにより、トラフィックは一時的にBcバケットを超えることができます。全体的なCIRは変わらないはずです。これは、「適合」、「超過」、「違反」の3つの「カラー」ポリサーです。
時間= 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バイトをカバーし、現在は空です。このトラフィックは「超過」と見なされ、「超過アクション」が適用されます。
これでバケットは乾燥しましたが、処理する必要のある387,500バイトが残っています。このトラフィックは「違反」と見なされ、常にCARでドロップされます（MQCと「violate-action」を使用したpoliceコマンドを使用して、他のことを行うことができます）。
時間= 187.5ミリ秒-最初のTc間隔、つまりバケットを埋める時間に到達しました。重要な点は、 BC相当のトークンのみが補充されるということです。Bcバケットは最初に937,500まで満たされます。Beバケットは空のままです。
時間= 375 ms-静かで、次のTc間隔に到達します。Bc相当のトークンがBcバケットに追加されます。Bcバケットはすでにいっぱいなので、超過したトークンは失われません-代わりにBeバケットに「溢れ」ます。これで、Bcバケットは937,500トークンでいっぱいになり、Beバケットは部分的に937,500トークンでいっぱいになります。
時間= 562.5ミリ秒-静かで、次の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
!
*ソース*