ルータ : Cisco 12000 シリーズ ルータ

ユニキャスト、マルチキャスト、および音声トラフィックが混在する Cisco 12000 シリーズ インターネット ルータでの WRED と MDRR の設定例

2011 年 10 月 21 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 7 月 7 日) | フィードバック

概要

このドキュメントでは、「RFC 2309leavingcisco.com で説明されている Weighted Random Early Detection(WRED; 重み付けランダム早期検出)用に、Cisco 12000 シリーズ ラインカードをマルチサービス環境で設定する方法を説明します。



前提条件

要件

このドキュメントの読者は次の項目に関する知識が必要です。



使用するコンポーネント

この文書の情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

  • Cisco 12000 シリーズ インターネット ルータをサポートするすべての Cisco IOS® ソフトウェア リリース。通常は、12.0S および 12.0ST リリースです。

  • この文書では Cisco 12000 プラットフォームのすべてを対象としています。それらのプラットフォームには 12008、12012、12016、12404、12406、12410、12416 が含まれます。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。



表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。



背景説明

Cisco 12000 シリーズは、広帯域 IP コア ネットワークを構築する最も一般的なプラットフォームです。このプラットフォームを使用すると、他にはない方法で Quality of Service(QoS)を設定できます。

さまざまな IP トラフィック(Voice over IP(VoIP)やマルチキャストなど)が同じネットワークに混在することがさらに一般的になってきているため、プライオリティ設定とドロップ動作の制御に対する要件が非常に重要になり、多くの場合、それらの要件は、VoIP などの新しいサービスを開始するときの成功と失敗を左右します。

さまざまなタイプの IP トラフィックのネットワーク要件は、このドキュメントの対象外です。このドキュメントでは、Cisco 12000 シリーズ、3 ポート ギガビット イーサネット(3 ポート GbE)ラインカードなど、異なるラインカードに適用可能な設定を調べるために行われたラボ テストに焦点を当てます。これらのテストによって、音声、データ、マルチキャスト トラフィックが混在するネットワーク環境には、3 ポート GbE エンジン 2 ラインカードが適切であるという結果が示されました。また、輻輳のあるネットワークでの QoS 設定の効果が証明されました。



テストで使用される優先クラス

異なるクラスに割り当てられている優先値は、ネットワーク全体で同じにする必要があります。全般的なポリシーを決定する必要があります。

クラス

優先度

トラフィック

悪意のあるトラフィック

 

身元が分からないすべてのオフ ネット トラフィック(オフ ネット)

オン ネット --- オン ネット

1

SP ネットワーク内でやり取りされるトラフィック(オン ネット)

インターネット サービス プロバイダー(ISP)サービス

2

ISP トラフィック、SMTP、POP、FTP、DNS、Telnet、SSH、www、https

中小規模のエンタープライズ(SME)

3

エンタープライズのお客様、ゴールド サービス

リアルタイム、音声以外

4

TV、リアルタイム ゲーム

音声

5

RTP VoIP トラフィック

ネットワーク制御メッセージ

6-7

ボーダーゲートウェイ プロトコル(BGP)およびその他の制御メッセージ



IP パケットのカラーリング

ネットワークのコアに QoS を実装する場合、ネットワーク内で転送されるすべての IP パケットの優先値をサービス プロバイダーが制御することが前提条件です。これを行う唯一の方法は、パケットがネットワークに送信されたときにすべてのパケットをマーキングして、お客様、エンド ユーザ、インターネットなど、そのパケットの送信元を区別しないようにすることです。コアでマーキングやカラーリングを行わないでください。



予想される結果

このテストでの目標は、0 〜 3 のクラスで true の WRED 動作を行うことです。つまり、輻輳中に優先度 0 のパケットのドロップを開始する状況を作ります。その後、輻輳が続く場合は優先度 1 のドロップを開始します。同様に優先度 2 と 3 を順にドロップしていきます。次のグラフは、この様子を表しています。

wred_behavior.gif

音声パケットの遅延は最も小さくなるようにし、すべての音声とマルチキャスト トラフィックではドロップが発生しないようにしてください。



ネットワーク セットアップ

設定のテストと検証には、Cisco 12410 および Agilant から生成されたパケットが使用されました。Cisco 12000 ルータは、Cisco IOS ソフトウェア リリース 12.0(21)S1 ベースのエンジニアリング リリースを実行しています。

network_setup.gif



3 ポート GbE エンジン 2 キューイングの実装

通常、エンジン 2 カードには、宛先スロットにつき 8 つの fromfab キューと 1 つの低遅延キュー、および 8 つの tofab キューがあります。また、個別の tofab マルチキャスト キューが 1 つあります。3 ポート GbE カードでは、物理ポートにつき fromfab キューが 1 つだけがあります。このテストに適用した設定では、これ以上のキューが指定されました。結果として、3 ポート GbE カードではこの設定を使用でき、キューは利用可能なキューに自動的にマッピングされました。



Cisco IOS ソフトウェアのエンジン 2 WRED アルゴリズム

キューの深さの最小値と最大値を設定するときには、エンジン 2 ラインカードの WRED に使用されるアルゴリズムを熟知している必要があります。設定されている最小値をコードが認識することはありません。その代わり、コードは(設定された最大値に基づく)独自の計算式を使用して、最小値を設定します。

計算式:

最小値 = 最大値 -(負の結果にならない 2 の最大出力)

このテストで使用された値は、Application-Specific Integrated Circuit(ASIC; 特定用途向け集積回路)にプログラムされている次の最小値になりました。

優先度

設定されている最小値

設定されている最大値

2 の最大出力

ASIC の最小値

0

50

5000

4096

5000-4096=904

1

60

6000

4096

6000-4096=1904

2

70

7000

4096

7000-4096=2904

3

80

8000

4096

8000-4096=3904

この計算式を使用して最小値を計算する場合、WRED パラメータを設定するときにこの点を考慮しないと、パケット処理動作が不正確になります。次の例を参照してください。

優先度

設定されている最小値

設定されている最大値

2 の最大出力

ASIC の最小値

0

50

150

128

150-128=22

1

75

225

128

225-128=97

2

100

300

256

300-256=44

3

125

375

256

375-256=119

これは、まず 0 から始まり 1、2 と続き、最後に 3 という規則(上記)に従ってドロップが開始されるように値が設定されていても、値が ASIC に書き込まれるとき、実際には優先度 0 をドロップした後に優先度 2 がドロップされ、次に優先度 1 と続き、最後に優先度 3 がドロップされる結果になります。エンジン 2 カードの ASIC に設定されている値を確認する方法はありません。エンジン 3 カードにこの設定を適用する場合、設定に表示される値は実際の値(再計算された最小値)です。



QoS 設定

QoS 設定の詳細は、『Cisco 12000 シリーズ インターネット ルータでの MDRR および WRED の理解と設定』を参照してください。



Rx CoS

rx-cos-slot 2 B2-Table
rx-cos-slot 3 B2-Table
rx-cos-slot 6 B2-Table

ほとんどの場合、rx-cos-slot all コマンドを使用できます。このテスト ケースでは、一部に tofab キューイングをサポートしないカードを使用したため、常に rx-cos-slot all コマンドを使用できたわけではありませんでした。その代わり、テストに使用されるラインカードにスロット テーブルを割り当てました。

!   
slot-table-cos B2-Table  
destination-slot all B2  
multicast B2  
!--- 上記の手順を実行していない場合、マルチキャスト トラフィックで 
0 ドロップの目標には達成できません。rx-cos が設定されていないと、
マルチキャストはデフォルト キューで処理され、輻輳があると 
すぐにドロップされます。

!


Tx QoS

tx-cos を設定できるようになりました。「cos-queue-group B2」など、tx qos の名前を選択します。

ドロップ動作を設定する各優先値は、個別の random-detect-label にマップする必要があります。

precedence 0 random-detect-label 0  

precedence 1 random-detect-label 1  

precedence 2 random-detect-label 2  

precedence 3 random-detect-label 3

Modified Deficit Round Robin(MDRR; 欠陥修正ラウンド ロビン)では、各優先度を MDRR キューにマップします。この例では、ビデオ(マルチキャスト トラフィック)の帯域を予約するために、優先度 0 〜 3 を同じ MDRR キューにマップしました。このマッピングにより、目的のとおりに動作するようになります。

precedence 0 queue 0  

precedence 1 queue 0  

precedence 2 queue 0  

precedence 3 queue 0  

precedence 4 queue 4 

音声は優先度 5 とマークされます。そのため、優先度 5 は低遅延キューにマップされています。

precedence 5 queue low-latency  

precedence 6 queue 6  

precedence 7 queue 6  

次に、各 random-detect-label のドロップ動作を設定する必要があります。テスト中、目的のドロップ パターンを実行する値が見つかるまで、これらの数字を変更していきました。詳細は、「予想される結果」のセクションを参照してください。キューの深さは、物理キューで計測され、MDRR や RED-Label キューでは計測されません。

random-detect-label 0 50 5000 1  

random-detect-label 1 60 6000 1  

random-detect-label 2 70 7000 1  

random-detect-label 3 80 8000 1 

Cisco 12000 では、作成する Class-Based, Weighted Fair Queuing(CBWFQ; クラスベース重み付け均等化キューイング)の動作の MDRR キューに異なる重み付けを設定できます。デフォルトの重み付けは、キューにつき 10 です。MDRR サイクルごとに送信されるバイト数は、重み値の関数です。1 の値は各サイクル 1500 バイトを表します。10 の値は各サイクル 1500+(9*512) バイトを表します。

queue 0 20  

queue 4 20  

queue 6 20  

!  


インターフェイス マッピング

WRED には各インターフェイスを設定する必要があります。設定するには、次のコマンドを使用します。

  • configure terminal

  • interface gig 6/0

  • tx-cos B2



ドロップなしの開始

生成されたストリームでは、他の値が示されない限り、次の値が使用されます。

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb voip

これにより、バックグラウンド ストリームは 240 Mb(VoIP とマルチキャスト)になります。

次に、同じサイズのデータ ストリームを 4 つ追加し、優先度 0 〜 3(ストリームにつき 1 つの優先値)を設定します。



1 つあたり 151 Mb のデータ ストリームが 4 つ

この設定の合計帯域幅は 844 Mb になります。次のグラフには、パケット ドロップが 0 であり、超低遅延(音声を含む各ストリームで約 50 マイクロ秒)であることが示されています。

151mb.gif



1 つあたり 160 Mb のデータ ストリームが 4 つ

この設定の合計帯域幅は 880 Mb になります。次のグラフには、優先度 0 クラスからパケットのドロップが始まり、音声の遅延は 6 ミリ秒に増加していることが示されています。

160mb.gif



1 つあたり 167 Mb のデータ ストリームが 4 つ

この設定の合計帯域幅は 908 Mb になります。優先度 1 のクラスでもドロップが開始しています。音声トラフィックの遅延は依然として同じです。

注:ストリームは増加するまで停止されなかったため、ストリーム 0 と 1 のドロップ数の差は累積です。

167mb.gif



1 つあたり 191 Mb のデータ ストリームが 4 つ

合計帯域幅が増加すると、優先度 2 のキューからもパケットがドロップされ始めます。このとき、ギガビット イーサネット インターフェイスが到達しようとしている合計帯域幅は 1004 Mb です。これは、次のグラフのシーケンス エラー カウンタに示されています。

191mb.gif



1 つあたり 244 Mb のデータ ストリームが 4 つ

優先度 3 のシーケンス エラーも増加し始めています。これは、そのキューからドロップが開始する最初のサインです。このとき、GbE インターフェイスを送信しようとしている合計帯域幅は 1216 Mb です。Multicast(MC; マルチキャスト)と音声キューのドロップが引き続きゼロであり、音声キューの遅延が増加していないことに注目してください。

244mb.gif

停止と開始

カウンタをクリアしたグラフを作成するために、すべてのストリームを停止して開始しました。次に、高い輻輳での表示を示します。次の図では、目的のとおりに動作していることが分かります。

stop_start.gif



すべての QoS の削除

輻輳中に QoS によってパフォーマンスが実際に向上していることを証明するために、QoS を削除して、インターフェイスが輻輳するようにしています。その結果を次に示します(生成されたストリームでは、他の値が示されない限り、次の値が使用されます)。

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb VoIP

これにより、バックグラウンド ストリームは 240 Mb(VoIP とマルチキャスト)になります。

次に、同じサイズのデータ ストリームを 4 つ追加し、優先度 0 〜 3(ストリームにつき 1 つの優先値)を設定します。



1 つあたり 153 Mb のデータ ストリームが 4 つ

合計帯域幅は 852 Mb になります。ドロップは 0 であり、遅延は 50 マイクロ秒以下です。

153mb.gif



1 つあたり 158 Mb のデータ ストリームが 4 つ

WRED が適用されているときと同じ使用率でドロップを開始します(872 Mb)。今回の相違は、音声パケットの遅延が 14 ミリ秒(WRED テスト時よりも 2 倍以上)になり、VoIP およびマルチキャストを含むすべてのクラスで平等にドロップが発生している点です。

158mb.gif



入力ロードの追加

これまでのすべてのテストでは、ギガビット イーサネット インターフェイスからの送信のみを対象としていました。もう 1 つの方向のインターフェイスで輻輳が発生したときに、インターフェイスがどのように反応するかを確認するために、次のテストを行いました。

このテストでは、1056 Mb の合計帯域幅を持つギガビット イーサネット インターフェイスをロードしました。この結果、優先度 0 〜 2 のトラフィックではドロップが発生し、優先度 3 のトラフィックではドロップが発生しませんでした(MC と VoIP では同じ結果になり、ドロップは発生しませんでした)。次に、パケット ジェネレータが生成して、ギガビット イーサネット インターフェイスから送信できる限りのトラフィックをもう 1 つの方向に追加しました。その結果は非常に興味深いものになりました。受信側の輻輳はキューの送信にまったく影響を与えず、受信トラフィックの遅延は音声で 13 マイクロ秒未満という極端に小さいものでした。

ingress_load1.gif



12-RP#show interfaces g 6/0

show interfaces コマンドを使用して、ギガビット リンクの負荷を監視できます。

Router#show interfaces gig 6/0
GigabitEthernet6/0 is up, line protocol is up
  Hardware is GigMac 3 Port GigabitEthernet, address is 0004.de56.c264 
  (bia 0004.de56.c264)
  Internet address is 178.6.0.1/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 232/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex mode, link type is force-up, media type is SX 
  output flow-control is unsupported, input flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output 00:00:05, output hang never
  Last clearing of "show interface" counters 08:52:40
  Queueing strategy: random early detection (WRED)
  Output queue 0/40, 2174119522 drops; input queue 0/75, 0 drops
  30 second input rate 838969000 bits/sec, 792079 packets/sec
  30 second output rate 910819000 bits/sec, 464704 packets/sec
    7584351146 packets input, 1003461987270 bytes, 0 no buffer
	Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
	0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
	0 watchdog, 514 multicast, 0 pause input
	11167110605 packets output, 2241229569668 bytes, 0 underruns
	0 output errors, 0 collisions, 0 interface resets
	0 babbles, 0 late collision, 0 deferred
	0 lost carrier, 0 no carrier, 0 pause output
	0 output buffer failures, 0 output buffers swapped out


ストリーム サイズの変更

すべてのストリームが同じ帯域幅であるためにこのテスト結果が生じたわけではないことを検証するために、異なるデータ量を送信するようにストリームを変更しました。また、ストリームごとに Maximum Transmission Unit(MTU; 最大伝送ユニット)が異なるように変更しました。結果は引き続き同じであり、設定したキュー値では、優先度 0 が最初にドロップされ、優先度 1、2 と続き、最後に優先度 3 がドロップされました。

stream_size.gif



10 ポート ギガビット イーサネット エンジンの 4 ラインカードによる確認

テストでの VoIP キュー(低遅延キュー)の遅延はかなり高かったため、10 ポート ギガビット イーサネット エンジン 4 ラインカードでも同じテストを行いました。予測どおり、このラインカードでの結果は、Low Latency Queue(LLQ; 低遅延キュー)の遅延という点では、著しい向上が見られました。ドロップの発生方法については同じ結果でした。LLQ の遅延は約 10 マイクロ秒であり、3 ポート ギガビット イーサネット エンジン 2 ラインカードの遅延の 1:1000 です。



関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 22561