1,948
回編集
差分
ナビゲーションに移動
検索に移動
814行目:
814行目: − + − Example 1 shows a case that should never be configured, as it will cause a network outage. 849行目:
848行目: − + − Another important command shows in real time how the buffer utilization varies per port queue. This command reads the values from the ASIC: + + − もう一つ重要なコマンドとして、バッファ使用率がポート キューごとにどのように変化するか、リアルタイムで示します。このコマンドは、ASIC から値を読み取ります。 − [[ファイル:C90-QoS-0a.png|フレームなし]] − − ◦ Weighted Tail Drop (WTD) − − Port queue thresholds are used to drop traffic earlier than the queue end (tail drop). If the port queue has the ability to drop specific traffic before the queue end, the port queue will keep buffer space for certain types of packets over the rest of the traffic managed by the port queue, based on the user configuration. Figure 30 shows the queue thresholds, where the user has the flexibility to assign a different DSCP, CoS, IP precedence, or traffic class. 874行目:
868行目: − UADP ASICs offer up to three thresholds per port queue. The three thresholds on one queue need to use the same type of packet headers. For example, all three thresholds can use CoS within one queue, but other queues can use other packet headers such as DSCP. By default, TH0 is set to 80%, TH1 is set to 90%, and TH2 is set to 100% or the same as tail drop. All traffic is assigned to TH2 initially, but via MQC policy the threshold values can be changed. Another name for the threshold is Weighted Tail Drop (WTD), where every threshold is equal to a weight. − The following is a sample MQC policy to change WTD.+ 887行目:
880行目: − + − 917行目:
909行目: − + + − + − − − ● Weighted Random Early Discard (WRED) − − WRED is an algorithm for discarding frames in oversubscribed port queues randomly before the queue is full. WRED is based on the RED (random early discard) algorithm. − − Before we look at RED and WRED, let’s quickly revisit TCP flow management. Flow management ensures that the TCP sender does not overwhelm the network. The “TCP slow-start” algorithm (defined in <nowiki>RFC 2001</nowiki>) is part of the solution to address this. It dictates that when a flow starts, a single packet is sent, and then it waits for an Acknowledgment (ACK). When the ACK is received, the TCP endpoint will send two packets and wait for the next ACK before sending more data. The number of packets sent each time gradually increases. This will continue until the flow reaches a transmission level (that is, send x number of packets) that the network can handle without the load incurring congestion. Should congestion occur, the slow-start algorithm will throttle back the window size (that is, the number of packets sent before waiting for an ACK). This will normalize transmission to a set number of frames that the network can handle without dropping them. + +
Cisco Catalyst 9000 スイッチング プラットフォーム QoS and キューイング ホワイトペーパー (ソースを閲覧)
2021年3月28日 (日) 09:39時点における版
、 2021年3月28日 (日) 09:39→階層型 QoS
class class-default
class class-default
queue-buffers ratio <number>
queue-buffers ratio <number>
</syntaxhighlight>When the buffer units are modified manually, the user needs to ensure that every queue has a certain amount of buffer allocated. If no buffer units are allocated, the traffic on the queue will be dropped.
</syntaxhighlight>
バッファを手動で書き換えた時、ユーザは全ポートで一定量のバッファを確保して、割り当てる必要があります。もしバッファが割り当てられていなければ、トラフィックはキューでドロップするでしょう。
バッファを手動で書き換えた時、ユーザは全ポートで一定量のバッファを確保して、割り当てる必要があります。もしバッファが割り当てられていなければ、トラフィックはキューでドロップするでしょう。
class class-default
class class-default
queue-buffers ratio 45
queue-buffers ratio 45
</syntaxhighlight>As a result of the example 2 policy, every queue will have a buffer to enable it to transmit traffic.
</syntaxhighlight>
例 2. のポリシーの結果として、すべてのキューがトラフィックの送信を有効化するためのバッファを持ちます。
例 2. のポリシーの結果として、すべてのキューがトラフィックの送信を有効化するためのバッファを持ちます。
[[ファイル:C90-QoS-0a.png|代替文=|なし|フレーム]]
もう一つ重要なコマンドとして、バッファ使用率がポート キューごとにどのように変化するか、リアルタイムで示します。このコマンドは、ASIC から値を読み取ります。
Port queue thresholds
Port queue thresholds
* ポート キューしきい値
* ポート キューしきい値
UADP ASICs は、ポート キューごとに 3 つまでのしきい値を提供します。1 つのキューの 3 つのしきい値は、同じタイプのパケット ヘッダを使用する必要があります。例として、1 つのキューで 3 つのすべてのしきい値が CoS を使用する場合、他のキューは DSCP のように他のパケット ヘッダを使用することができません。デフォルトでは、TH0 を 80% に設定し、TH1 を 90% に、TH2 を 100% or テール ドロップと同じに設定されています。すべてのトラフィックは初期状態として TH2 に割り当てられておりますが、MQC ポリシー経由でしきい値を変更することができます。しきい値の別名は、ウェイテッド・テール・ドロップ (WTD) で、しきい値は重み付けと同じ意味になります。
UADP ASICs は、ポート キューごとに 3 つまでのしきい値を提供します。1 つのキューの 3 つのしきい値は、同じタイプのパケット ヘッダを使用する必要があります。例として、1 つのキューで 3 つのすべてのしきい値が CoS を使用する場合、他のキューは DSCP のように他のパケット ヘッダを使用することができません。デフォルトでは、TH0 を 80% に設定し、TH1 を 90% に、TH2 を 100% or テール ドロップと同じに設定されています。すべてのトラフィックは初期状態として TH2 に割り当てられておりますが、MQC ポリシー経由でしきい値を変更することができます。しきい値の別名は、ウェイテッド・テール・ドロップ (WTD) で、しきい値は重み付けと同じ意味になります。
queue-limit dscp values af11 percent 100
queue-limit dscp values af11 percent 100
</syntaxhighlight>ASIC で設定されたしきい値を見るためには、以下のコマンドを使用します。
</syntaxhighlight>ASIC で設定されたしきい値を見るためには、以下のコマンドを使用します。
[[ファイル:C90-QoS-0b.png|代替文=|なし|フレーム]]
[[ファイル:C90-QoS-0b.png|フレームなし]]
…..
…..
</syntaxhighlight>Step 2. Match the label value to the queue or threshold that it is associated with, using the following command.
</syntaxhighlight>
'''ステップ 2.''' ラベルの値がキューかしきい値に該当させるために、次のコマンドを使用します。
'''ステップ 2.''' ラベルの値がキューかしきい値に該当させるために、次のコマンドを使用します。
[[ファイル:C90-QoS-0c.png|代替文=|なし|フレーム]]
[[ファイル:C90-QoS-0c.png|フレームなし]]
* ウェイテッド・ランダム・アーリー・ディスカード (WRED)
* ウェイテッド・ランダム・アーリー・ディスカード (WRED)
WRED はキューがいっぱいになるために、帯域を超過したポートのキューで、ランダムにフレームを廃棄するためのアルゴリズムです。WRED はランダム・アーリー・ディスカード (RED) アルゴリズムがベースになっています。
WRED はキューがいっぱいになるために、帯域を超過したポートのキューで、ランダムにフレームを廃棄するためのアルゴリズムです。WRED はランダム・アーリー・ディスカード (RED) アルゴリズムがベースになっています。
RED と WRED を見る前に、TCP フロー管理を簡単に振り返ってみましょう。フロー管理は、TCP 送信側がネットワークを埋め尽くさないようにします。"TCP スロー スタート" アルゴリズム (RFC2001 で定義) はこれに対処するための解決策の一部です。それはフローを開始する時に指示し、1 つのパケットが送信されると、次に確認応答 (ACK) を待ちます。ACK が受信されると、TCP エンドポイントは 2 つのパケットを送信し、さらにデータを送る前に、次の ACK を待ちます。パケットの数を段々と増加させて送信します。これはフローが送信レベル (パケットを x 個送信) に達するまで継続し、ネットワークに混雑を伴う負荷を発生させないように、管理します。混雑が発生した場合、スロースタート アルゴリズムは、ウィンドウ サイズ (ACK を待つ前に送信したパケットの数) を抑制します。これによりネットワークがそれらをドロップせずに処理できる数に、送信が正規化されます。
=== 階層型 QoS ===
=== 階層型 QoS ===