サービス品質(QoS) : QoS パケット マーキング

QoS(Quality of Service)の実装

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

目次

概要
QoS を必要とするアプリケーション
      アプリケーション特性について
ネットワーク トポロジの確認
      リンク層のヘッダー サイズ
基準に基づいたクラスの作成
各クラスをマーキングするためのポリシーの作成
エッジからコアへの作業
トラフィックを処理するポリシーの構築
ポリシーの適用
ポリシーの効果を監視するための QoS Policy Manager(QPM)の使用
汎用 QoS における推奨事項
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書では、遅延や帯域幅の影響を受けやすいアプリケーションや、複数のアプリケーション間の転送を実行するネットワークに、Quality of Service(QoS)を実装するときに役立つ高レベルのガイドラインをいくつか説明します。これらのアプリケーションによって業務処理は改善しますが、ネットワーク リソースを酷使する可能性があります。QoS を実装することで、ネットワーク内の遅延、遅延変動(ジッタ)、帯域幅、およびパケットの損失が管理されます。その結果、セキュアで、計測可能な、かつ保証された品質のサービスを、アプリケーションに提供できます。

QoS を必要とするアプリケーション

まず、ビジネス上重要で保護する必要があるアプリケーションを決定します。これには、ネットワーク リソースの利用で競合しているすべてのアプリケーションを検討する必要がある場合があります。この場合、「Netflow Accounting」、「Network-based Application Recognition(NBAR)」、または「QoS Device Manager(QDM)」を使用して、ネットワーク内のトラフィック パターンを分析してください。

Netflow Accounting を使用すると、ネットワーク トラフィックの詳細が提供されるので、各フローに関連するトラフィックの分類や優先順位を知ることができます。

NBAR は、アプリケーション層までのトラフィックを識別するための分類ツールです。このツールを使用すると、インターフェイスを通過するトラフィック フローごとに、インターフェイス単位、プロトコル単位、および双方向の統計情報が提供されます。NBAR では、サブポートの分類も実行されます。つまり、アプリケーション ポートよりも詳細な検索と識別が行われます。

QDM は、Web ベースのネットワーク管理アプリケーションであり、ルータ上の IP ベースの拡張 QoS 機能の設定と監視を行うための操作性の優れたグラフィカル ユーザ インターフェイスを提供します。

アプリケーション特性について

保護を必要とするアプリケーションの特性を理解することが重要です。 遅延やパケット損失によって大きな影響を受けるアプリケーションもあれば、バースト性があったり使用する帯域幅が大きいために、「アグレッシブ」と見なされるアプリケーションもあります。 バースト性があるアプリケーションの場合、常にバーストがあるか、バーストは小規模かを判断します。このアプリケーションのパケット サイズは、大きいか、小さいか、このアプリケーションは、TCP ベースまたは UDP ベースのどちらなのかを判断してください。

特性

ガイドライン

遅延またはパケット損失の影響を受けやすいアプリケーション

(音声およびリアルタイム ビデオ)

weighted random early detection(WRED; 重み付けランダム早期検出)、トラフィック シェーピング、断片化(FRF-12)、またはポリシングは使用しないでください。この種のトラフィックには Low Latency Queuing(LLQ; 低遅延キューイング)を実装して、遅延の影響を受けやすいトラフィックにプライオリティ キューイングを使用する必要があります。

常にバースト性があるか、帯域幅を大量消費するようなアプリケーション

(FTP および HTTP)

帯域幅を確保するには、WRED、ポリシング、トラフィック シェーピング、または class-based weighted fair queueing(CBWFQ; クラスベース重み付け均等化キューイング)を使用します。

TCP ベースのアプリケーション

パケットの損失により TCP がスピードを落とした後、スロースタート アルゴリズムを使って再度速度を上げるので、WRED を使用します。 トラフィックが UDP ベースで、パケットがドロップされても動作が変わらない場合は、WRED を使わないでください。 アプリケーションの速度を制限する必要がある場合は、ポリシングを使用します。それ以外の場合はパケットをテール ドロップさせてください。

ネットワーク トポロジの確認

デバイスによっては、実装する QoS 機能を活用できるように、IOS をアップグレードする必要があります。ネットワーク トポロジの図、ルータの設定、および各デバイスに装備されたソフトウェア バージョンを確認すると、IOS をアップグレードする必要のあるデバイス数を予測できます。ネットワーク図の作成時に役立つアイコンについては、『Cisco アイコン ライブラリ』を参照してください。

  • ビジーの期間に、各ルータで CPU の利用率にアクセスすると、デバイス間にどのように QoS 機能を分散したら負荷を共有できるのかを判断しやすくなります。

  • 業務に不可欠なトラフィックのタイプと、このトラフィックが通過するインターフェイスを分類します。ネットワークの QoS の目標を実現するには、どのプライオリティ グループまたはプライオリティ クラスを作成するかを判断します。

  • 業務に不可欠なアプリケーションの大半が処理できる最大の遅延を確認するとともに、この遅延に対応できるように、トラフィック調整機能(トラフィック シェーピング機能やポリシング機能)によってバースト パラメータを調整します。

  • PVC またはサブインターフェイスで、 サポートされている速度を確認し、帯域幅が一致するように設定します。

  • ネットワーク内のどこにボトルネックがあるかを特定し、適切なインターフェイスでリンクの効率化メカニズムをどのように適用するかを決定しやすくするため、低速なリンクを特定します。

  • 業務に不可欠なトラフィックを転送するメディア タイプごとに、レイヤ 2 およびレイヤ 3 のオーバーヘッドを計算します。この結果、クラスごとに必要な正しい総帯域幅を計算できます。

  • もう 1 つの重要な情報は、アプリケーションか、IP の発信元または送信先のいずれか、またはその両方に基づいて、トラフィックを保護するかどうかです。

リンク層のヘッダー サイズ

メディアのタイプ

リンク層のヘッダー

イーサネット

14 バイト

PPP

6 バイト

フレームリレー

4 バイト

ATM

5 バイト/セル

基準に基づいたクラスの作成

アプリケーションの特性に基づいて、どのアプリケーションが QoS を必要とするのか、およびどの分類基準を使用するのかを確認した段階で、この情報に基づいてクラスを作成する準備が整いました。

各クラスをマーキングするためのポリシーの作成

適切なプライオリティ値を使って、各トラフィック クラスをマーキングするポリシーを作成します(Differentiated Services Control Point(DSCP)または IP 優先順位を使用します)。 トラフィックはルータの入力側インターフェイスに着信する場合にマーキングされます。このマーキングは、トラフィックがルータから発信される際に出力インターフェイスでトラフィックの処理に使用されます。

エッジからコアへの作業

トラフィックに最も近いルータからコアへ向かって作業します。ルータの入力側インターフェイスでマーキングを適用します。次のトポロジの場合は、ネットワーク A から受信され、ルータ B へ向けられるデータについて、ルータ A は、トラフィックをマークし、ポリシーを適用する場所です。トラフィックは、ルータ A の Ethernet0 インターフェイスで受信されるとマークされます。また、ルータから発信される際に、ルータ A の Serial0 インターフェイスで QoS ポリシーが適用されます。同じポリシーが双方向に適用された場合(その結果、ネットワーク B から受信されたトラフィックとネットワーク A へ向けられるトラフィックに同じ処理が行われます)、ネットワーク B から受信されたトラフィックは、ルータ B の Ethernet1 インターフェイスで受信されるときにマークされます。また、ルータから発信される際に Serial1 インターフェイスにおいて処理が行われます。

ルータの入力側インターフェイスでトラフィックがマーキングされると、再マーキングが実行されない限り、複数のホップを移動する間も同じマーキングが維持されます。 通常、トラフィックは 1 回マーキングするだけで十分です。その他のホップでは、これらのマーキングに基づいて QoS ポリシーを適用できます。再度マークする必要があるのは、トラフィックが信頼できないドメインから到着した場合に限られます。

wantqos01.gif

トラフィックを処理するポリシーの構築

トラフィックのマーキングが終了したため、そのマーキングを使って、ポリシーの構築と、残りのネットワーク セグメントでのトラフィック分類を実行できます。ポリシーには 4 つを越えるクラスは使わないようにし、ポリシーを簡潔にしておくことをお勧めします。

可能であれば、ラボ環境で QoS を実装してテストを行います。ラボ環境での結果に満足できたら、実働ネットワークに QoS を実装します。

ポリシーの適用

適切な方向にポリシーを適用します。ポリシーを単方向に適用するのか、双方向に適用するのかを判断します。 この文書の「各クラスをマーキングするためのポリシーの作成」のセクションに記述したように、できる限り、トラフィックのマーキングと処理は送信元の近くで行ってください。

サイトの両側で送受信するトラフィックをフィルタリングするため、双方向で同じポリシーを提供することを推奨します。つまり、ルータ A のシリアル インターフェイスから送信する場合と、ルータ B のシリアル インターフェイスから送信する場合に、同じポリシーを適用する必要があります。

ポリシーの効果を監視するための QoS Policy Manager(QPM)の使用

中央集中型のポリシー制御および自動化された高信頼性のポリシー実装のための完全なシステムとして、QPM を使用します。

汎用 QoS における推奨事項

次に、QoS カテゴリ、および各カテゴリに関連しており、よく使用される QoS 機能のいくつかを示します。

カテゴリ

関連する QoS 機能

QoS サービス モデル

可能であればプロビジョニングされた(Diffserv)QoS、または必要に応じてシグナリングされた(RSVP)QoS

分類とマーキング

Diffserv コード ポイントまたは QOS グループ ID

輻輳管理

LLQ または CBWFQ

輻輳回避

Diffserv 準拠の WRED

リンクの効率化

MLPPP、LFI、FRF.11、FRF.12、および CRTP

シグナリング

RSVP、QPPB

トラフィック調整機能およびポリシング

Class Based Policer と Generic Traffic Shaping(GTS)、または Frame-Relay Traffic Shaping(FRTS)

設定および監視

QPM、Modular QoS Command Line Interface(CLI; コマンドライン インターフェイス)、および QDM


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

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


関連情報


Document ID: 13747