トラフィックポリシングとトラフィックシェーピングを比較して帯域幅を制限する
はじめに
このドキュメントでは、どちらも出力レートを制限する、トラフィックシェーピングとトラフィックポリシングの機能的な違いを説明します。
前提条件
要件
このドキュメントに関する固有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
バックグラウンド情報
このドキュメントでは、トラフィックシェーピングとトラフィックポリシングの機能的な違いを明確にします。どちらも機能的にトラフィックの出力レートを制限します。どちらのメカニズムも、パケットレートを測定するためのトラフィックメーターとしてトークンバケットを使用します。トークンバケットの詳細については、「What Is a Token Bucket」を参照してください。
このドキュメントの概念は、Cisco QoS設計の理解に役立ちます。トラフィックシェーピングとトラフィックポリシングは、最大トラフィックレートを適用し、輻輳を管理するために引き続き使用されます。新規の導入では、プラットフォームでサポートされている場合は、モジュラQoSコマンドライン(MQC)クラスベースシェーピングとクラスベースポリシングを使用することをお勧めします。Generic Traffic Shaping（GTS；ジェネリックトラフィックシェーピング）、Frame Relay Traffic Shaping（FRTS；フレームリレートラフィックシェーピング）、Committed Access Rate（CAR；専用アクセスレート）、およびrate-limitコマンドなどのレガシーメカニズムは、履歴に基づくため、またはプラットフォーム固有の説明をサポートするために組み込まれています。
ポリシングとシェーピング
トラフィック ポリシングはバーストを伝搬します。トラフィック レートが最大レートの設定値に達すると、超過トラフィックが廃棄（またはマーキング）されます。 その結果、出力レートは頂上と谷間のある鋸歯状になります。ポリシングと異なり、トラフィック シェーピングでは、超過パケットはキューまたは漏出バケットに保持され、一定の時間間隔でスケジュールされてから遅れて伝送されます。トラフィック シェーピングの結果、パケットの出力レートは平滑化されます。
次の図は、2 つのトラフィックオプションの主な違いを示しています。
ポリシングとシェーピングの比較
シェーピングでは遅延パケットをバッファリングするためのキューと十分なメモリが存在する必要がありますが、ポリシングではそれらは必要ありません。キューはアウトバウンドの概念です。インターフェイスを離れるパケットはキューイングされ、シェーピングを適用できます。インターフェイスでは着信トラフィックに対してポリシングだけを適用できます。シェーピングを有効にする場合は十分なメモリがあることを確認してください。また、シェーピングには遅延パケットを後で伝送するスケジュールを設定する機能が必要です。このスケジュール機能を使用すると、シェーピングキューを別々のキューに編成できます。この機能の例としては、Class Based Weighted Fair Queuing(CBWFQ)やLow Latency Queuing(LLQ)があります。
注：トラフィックシェーピングとトラフィックポリシングはどちらも、設定されたトラフィックレートを適用します。シェーピングは出力キューイングメカニズムです。ポリシングは、プラットフォームおよび機能のサポートに応じて、着信または発信に適用できます。
選択基準
次の表に、適切なトラフィックソリューションの選択に役立つ、シェーピングとポリシングの違いを示します。
| トラフィック シェーピング | トラフィック ポリシング | |
|---|---|---|
| 主な動作 | 認定レートを超える超過パケットをバッファおよびキューイングします。 | 認定レートを超える超過パケットをドロップ（または再マーキング）します。バッファリングしない。* |
| トークンのリフレッシュ レート | トークンは、Tc間隔ごとに定期的に補充されます。各インターバルの開始時に、シェーパは設定されたバケット制限を上限としてBcトークンを追加します。Tcはプラットフォーム固有の制限によって制限されます。 | トークンは、パケット到着間の経過時間に基づいて補充されます。ポリサーは追加するトークンの数を((t - t1) * policer_rate_bps) / 8で計算します。ここでt - t1は前のパケットからの時間です。 |
| トークン値 | ビット/秒(bps)で設定されます。 | バイトで設定する。 |
| 設定オプション |
|
|
| 標準的な方向 | Outbound | 着信または発信、プラットフォーム依存 |
| バースト | バーストを制御し、少なくとも 8 つの時間間隔で出力レートを平滑化します。トークンバケットメータリングを使用し、超過パケットをキューイングするキューに入れられたパケットは時間の経過とともに解放され、漏出バケットと同様のスムージング効果が生じます。 | 設定されたバースト制限内でバーストを許可します。転送レートを平滑化するためにパケットをバッファリングすることはありません。 |
| 長所 | 超過パケットがバッファリングされるため、超過パケットが廃棄される可能性は少ない（パケットは最大でキューの長さまでバッファリングされる。過剰なトラフィックが高いレートで維持されると、ドロップが発生する可能性があります）。 一般に、パケットの廃棄による再転送が起こらなくなる。 | パケットの廃棄によって出力レートを制御する。キューイングによる遅延が起こらなくなる。 |
| 短所 | キューイングによる遅延が発生するおそれがある（特にキューが深い場合）。 | 超過パケットをドロップし（設定されている場合）、TCP ウィンドウサイズを抑制し、影響を受けるトラフィックストリームの全体的な出力レートを削減します。過度にアグレッシブなバーストサイズは、特に TCP ベースのフローで、超過パケットのドロップを引き起こし、全体的な出力レートを抑制する可能性があります。 |
| オプションのパケット マーキング | いいえ | はい。設定されたMQCポリサーアクションおよびプラットフォームサポートに応じて、IP precedenceアクションまたはDSCPアクションを含むパケットの送信、ドロップ、またはマーキングをオプションで実行できます。 |
注：ポリシングではバッファは適用されませんが、設定済みのキューイングメカニズムは、物理インターフェイスでのシリアル化を待機する間にキューイングされる必要がある適合パケットに適用されます。
トークンのリフレッシュ レート
シェーピングとポリシングの主な違いはトークンが補充される速度にあります。 シェーピングとポリシングのどちらも、トークンバケットメタファを使用します。トークン バケット自体には、廃棄ポリシーまたは優先順位ポリシーはありません。
トークンバケット機能を使用する場合：
-
トークンはある一定のレートでバケットに入れられます。
-
各トークンは、送信元が一定数のビットをネットワークに送信する許可を与えます。
-
パケットを送信するには、トラフィック調整機能によって、パケット サイズと表現上等しい数のトークンをバケットから削除できる必要があります。
-
パケットを送信するのに十分なトークンがバケット内にない場合、パケットはバケットに十分なトークンが溜まるまで待機するか（シェーパーの場合）、または廃棄されるかダウンとマークされます（ポリサーの場合）。
-
バケット自体には指定された容量があります。バケットの容量がいっぱいになると、着信した新しいトークンは廃棄されて、今後のパケットには使用できなくなります。したがって、発信元がネットワークに送信できる最大のバーストは常にバケットのサイズにほぼ比例します。トークンバケットではバーストが許可されますが、制限があります。
シェーピングは、ビット/秒（bps）値を使用する時間間隔でトークンバケットを増やします。シェイパーは次の式を使用します。
Tc = Bc/CIR (in seconds)
この式では、次のようになります。
-
Bc：認定バースト。1つのタイミングインターバルの間に送信が許可されたトラフィックの量。
-
CIR：認定情報レート。シェーパーまたはポリサーが実行する平均トラフィックレート。
-
Tc：コミットされた時間間隔。設定されたCIRを秒単位で維持しながら、認定バーストを送信するためにシェーパーが使用する時間間隔。
Tc の範囲は、10 ミリ秒から 125 ミリ秒の間です。分散型トラフィックシェーピング(DTS)を使用する一部のレガシープラットフォームでは、最小Tcは4ミリ秒です。ルータは、CIR 値と Bc 値に基づいて、この値を内部で計算します。Bc/CIR が 125 ミリ秒よりも小さい場合は、この式から算出された Tc が使用されます。Bc/CIRが125ミリ秒以上の場合、トラフィックフローがより短い時間間隔で安定するとCisco IOSが判断すると、内部のTc値が使用されます。show traffic-shape コマンドを使用して、ルータが Tc の内部値を使用するか、コマンドラインで設定した値を使用するかを確認します。
show traffic の出力
Excess Burst（Be；超過バースト）が0以外の値に設定されている場合、シェーパはBc + Beまでのトークンをバケットに格納できます。トークン バケットの上限値は Bc + Be であり、オーバーフローしたトークンは廃棄されます。Bc を超えるトークンをバケットに保持する唯一の方法は、1 回または複数回の Tc の間にすべての Bc トークンを使用しないようにすることです。トークン バケットには Bc のトークンが Tc ごとに補充されるため、未使用のトークンを Bc + Be まで蓄積して後で使用できます。
これに対して、クラスベースのポリシングとレート制限では、パケット到着間の経過時間に基づいてトークンが補充されます。パケットが到着すると、ポリサーは前のパケットからの時間と設定されたポリサーレートから追加するトークンの数を計算します。具体的には、トークン到達レートは次のようにして計算されます。
Tokens added = ((t - t1) * policer_rate_bps) / 8 bytes
つまり、前のパケットが到達した時間を t1、現在の時間を t とした場合、トークン到達レートに基づいて t-t1 に相当するバイト数だけバケットが更新されます。
注：トラフィックポリサーはバイト単位で指定されたバースト値を使用するため、前述の式ではビットをバイトに変換します。
次に、8000 bps の CIR（またはポリサーレート）と 1000 バイトの通常バーストを使用する例を示します。
Router(config)#policy-map police-setting Router(config-pmap)#class access-match Router(config-pmap-c)#police 8000 1000 conform-action transmit exceed-action drop
トークンバケットは 1000 バイトでいっぱいになります。450 バイトのパケットが到達した場合、トークン バケットには十分なバイト数があるため、パケットは適合します。パケットにより準拠処理（伝送）が実行され、450 バイトがトークンバケットから削除されます（残りは 550 バイト）。 次のパケットが 0.25 秒後に到達した場合、次の式にしたがってトークンバケットに 250 バイトが追加されます。
(0.25 * 8000)/8
-
バケットが満杯の状態で始まる：
- 通常のバースト= 1000バイト
- 初期トークン=1000バイト
-
最初のパケットが到着します。
- パケットサイズ= 450バイト
- バケットに十分な数のトークンがあるため、パケットは適合します。
- ポリサーは450バイトに相当するトークンをバケットから削除します。
計算：1000 - 450 =残り550バイト
-
次のパケットは0.25秒後に到着します。
- ポリサーレート=8000 bps
- 0.25秒の間に追加されたトークン：
(0.25 × 8000) / 8 = 250バイト
-
更新後のバケット：
- 既存のトークンの残り=550バイト
- 追加された新しいトークン=250バイト
計算：550 + 250 = 800バイト
この計算では、トークンバケットに800バイトが残されます(ポリサーバケットに残っているトークン)。 次のパケットが 900 バイトであれば、パケットは超過し、超過アクション（廃棄）が実行されます。トークン バケットからは 1 バイトも削除されません。
トラフィック シェーピング
Cisco IOS®は、次のトラフィックシェーピング方式をサポートしています。
どのトラフィック シェーピング方式も実装の点ではよく似ていますが、それぞれの Command Line Interface（CLI; コマンド行インターフェイス）は若干異なります。各方式は遅延されるトラフィックを格納およびシェーピングするために異なるタイプのキューを使用します。シスコでは、クラスベースのシェーピングと分散シェーピングを推奨します。これらは、モジュラ QoS CLI で設定します。
次の図は、QoS ポリシーがトラフィックをクラスに配置し、設定されたシェーピングレートを超えるパケットをキューイングする方法を示しています。
トラフィック ポリシング
Cisco IOS は、次のトラフィック ポリシング メソッドをサポートしています。
「クラスベースポリシングの設定方法」で説明されているように、この2つのメカニズムには、機能面で重要な違いがあります。シスコでは、QoS ポリシーを適用する場合は、クラスベースのポリシングおよびモジュラ QoS CLI のその他の機能を推奨します。
police コマンドを使用して、トラフィックのクラスは課される最大レートを有する必要があり、そのレートを超過した場合はただちに対策を取る必要があることを指定します。つまり、police コマンドには、shape コマンドとは異なり、パケットをバッファリングして後で送出するためのオプションはありません。
また、ポリシングでは、パケットが適用レートを超えているか、または適用レートに適合しているかは、トークン バケットによって決まります。いずれの場合も、ポリシングは、IP プレシデンスまたは Differentiated Services Code Point（DSCP; DiffServ コードポイント）を含む設定可能なアクションを実装します。
次の図は、QoS 機能が一般的に適用される場合の、輻輳ポイントでのトラフィックポリシングの一般的な適用を示しています。
最小帯域幅制御と最大帯域幅制御
shapeコマンドおよびpoliceコマンドは、トラフィックを設定された最大レートに制限します。MQCでは、プラットフォーム固有の構文で特に指定されていない限り、shape averageおよびpoliceの設定レートはbpsで指定されます。重要なのは、どちらのメカニズムも輻輳時に最小帯域幅を保証しない点です。このような最小帯域幅の保証を提供するには、bandwith または priority コマンドを使用します。
階層型ポリシーは 2 つのサービスポリシーを使用します。1 つはトラフィックの集約に QoS メカニズムを適用する親ポリシー、もう 1 つは集約のフローまたはサブセットに QoS メカニズムを適用する子ポリシーです。サブインターフェイスやトンネルインターフェイスなどの論理インターフェイスには、親レベルでのトラフィック制限機能とそれよりも低いレベルでのキューイングを備えた階層ポリシーが必要です。トラフィック制限機能を使用すると、超過パケットをキューイングしたときに見られるように、出力レートが低下し、（おそらく）輻輳が発生します。
次の設定は最適ではありませんが、トラフィック集約（このケースではclass-default）を最大レートに制限する際の、police コマンドとshape コマンドの違いを示すために記載しています。この設定では、police コマンドは、パケットのサイズと準拠および超過トークンバケットに残っているバイト数に基づいて、子クラスからパケットを送信します。（「トラフィック ポリシング」を参照してください）。 その結果、ポリシング機能がプライオリティ機能による保証を上書きするため、Voice over IP（VoIP）および Internet Protocol（IP）クラスに指定されたレートは保証できません。
しかし、shape コマンドを使用すると、階層的キューイング システムが実現され、すべてが保証されます。つまり、シェープ レートを超える負荷が発生すると、VoIP および IP クラスはそれぞれのレートが保証され、class-default トラフィックが（子レベルで）廃棄されます。
class-map match-all IP
match ip precedence 3
class-map match-all VoIP
match ip precedence 5
!
policy-map child
class VoIP
priority 128
class IP
priority 1000
!
policy-map parent
class class-default
police 3300000 103000 103000 conform-action transmit exceed-action drop
service-policy child
前の設定を有効にするには、ポリシングをシェーピングに置き換える必要があります。例：
policy-map parent
class class-default
shape average 3300000 103000 0
service-policy child
show policy-map interface <interface>を使用して、設定されているポリシー、クラスカウンタ、提供レート、廃棄カウンタ、シェーピングレート、キュー項目数、およびポリサー適合/超過/違反カウンタを確認します。
Router#show policy-map interface gigabitEthernet 0/0/2
GigabitEthernet0/0/2
Service-policy output: parent
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
shape (average) cir 3300000, bc 103000, be 0 target shape rate 3300000
Service-policy : child
queue stats for all priority classes:
Queueing
queue limit 512 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Class-map: VoIP (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: ip precedence 5
Priority: 128 kbps, burst bytes 3200, b/w exceed drops: 0
Class-map: IP (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: ip precedence 3
Priority: 1000 kbps, burst bytes 25000, b/w exceed drops: 0
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0前述の例は意図的に最適ではありませんが、階層型QoSポリシーにおけるポリシングとシェーピングの違いを説明するためにのみ提供されています。推奨されるQoS設計では、通常、priorityコマンドは、音声など、遅延の影響を受けやすいリアルタイムのトラフィック用に予約されています。最小帯域幅の保証が必要な非リアルタイムクラスの場合、通常はbandwidthコマンドをCBWFQで使用します。
このアプローチは、LLQおよびCBWFQに関するシスコQoS設計ガイダンスに沿っています。LLQは遅延の影響を受けやすいトラフィックに対して厳密な優先処理を行い、CBWFQは輻輳時に他のトラフィッククラスに対して帯域幅保証を行います。したがって、この例のIPクラスは、厳密な優先処理を明示的に必要とするトラフィックを伝送しない限り、プライオリティではなく帯域幅で表した方が適切です。
policy-map child
class VoIP
priority 128
class IP
bandwidth 1000関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
6.0 |
21-Jul-2026
|
再認定 |
4.0 |
07-Sep-2023
|
ブランディング要件、SEO、文法、フォーマットを更新。 |
1.0 |
15-Feb-2002
|
初版 |
フィードバック