test

IPQoS の管理

第 2 章 IPQoS 対応ネットワークの計画 (手順)

IPQoS は、Solaris 9 9/02 オペレーティング環境を実行する任意のシステム上で構成できます。 そして、IPQoS システムを diffserv 対応ルーターと組み合わせると、イントラネット上で差別化サービスを提供したり、トラフィック管理を行うことができます。

この章では、IPQoS 対応システムを diffserv 対応ネットワークに追加するための計画作業について説明します。

この章では、以下の内容について説明します。

一般的な IPQoS の構成計画 (作業マップ)

IPQoS などの差別化サービスをネットワーク上に実装する場合は、綿密な計画が必要です。各 IPQoS 対応システムの位置や機能だけでなく、IPQoS 対応システムとローカルネットワーク上のルーターとの関係も考慮する必要があります。 次の表に、IPQoS をネットワーク上に実装するための主な計画作業を示します。

表 2–1 IPQoS の構成計画 (作業マップ)

作業 

説明 

参照先 

1. IPQoS 対応システムを取り入れた diffserv ネットワークトポロジを計画する 

さまざまな diffserv ネットワークトポロジを考慮して、自分のサイトにもっとも適したソリューションを考える 

diffserv ネットワークトポロジの計画

2. IPQoS システムによって提供する各種サービスを計画する 

ネットワークが提供するサービスの種類をいくつかの サービスレベル契約 (service-level agreement、SLA) に分類する 

サービス品質ポリシーの計画

3. IPQoS システムごとに QoS ポリシーを計画する 

各 SLA の実装に必要なクラス、メータリング、およびアカウンティング機能を決める 

サービス品質ポリシーの計画

4. 必要であれば、diffserv ルーターのポリシーを計画する 

IPQoS システムで使用する diffserv ルーターのスケジューリングポリシーおよびキューイングポリシーを決める 

キューイングポリシーおよびスケジューリングポリシーについては、ルーターのマニュアルを参照 

diffserv ネットワークトポロジの計画

ネットワークに差別化サービスを提供するには、IPQoS 対応システムが最低 1 つと diffserv 対応ルーターが 1 台必要です。 この節で説明するように、この基本構成はさまざまな方法で拡張できます。

diffserv ネットワークのハードウェア計画

一般に、IPQoS はサーバーやサーバー統合 (Sun EnterpriseTM 10000 サーバーなど) 上で実行します。 一方、ネットワークのニーズに応じて、UltraSPARC システムなどのデスクトップシステムで IPQoS を実行することもできます。 次に、IPQoS 構成に使用できるシステムの例を示します。

IPQoS システムを導入しようとするネットワークトポロジでは、diffserv 対応ルーターがすでに機能していることもありえます。もし、現在使用しているルーターが diffserv に対応していない場合は、Cisco Systems 社や Juniper Networks 社などのルーター製造元が提供する diffserv のソリューションを検討してください。ローカルルーターが diffserv を実装していないと、パケットのマークは評価されずに次のホップへ渡されてしまいます。

IPQoS ネットワークトポロジ

以下では、ネットワーク上のさまざまなニーズを満たす IPQoS 計画を、いくつかの図で説明します。

個々のホストでの IPQoS

次の図は、IPQoS 対応システムの単一ネットワークを示しています。

図 2–1 ネットワークセグメント上の IPQoS システム

トポロジ図。diffserv ルーターと 3 つの IPQoS 対応システム (FTP サーバー、データベースサーバー、Web サーバー) を備えたローカルネットワークです。

前の図に示すネットワークは、企業のイントラネットの 1 つのセグメントにすぎません。 アプリケーションサーバーや Web サーバーで IPQoS を有効にすると、各 IPQoS システムが発信トラフィックをネットワークストリームに送出する速度を制御できます。 ルーターが diffserv に対応していれば、着信トラフィックおよび発信トラフィックをさらに制御できます。

このマニュアルで取り上げる例では、個々のホストでの IPQoS をシナリオとして使用します。このマニュアルを通じて使用するトポロジ例については、図 2–4 を参照してください。

サーバーファームのネットワークでの IPQoS

次の図は、いくつかの異機種サーバーファームを備えたネットワークを示しています。

このようなトポロジでは、ルーターが diffserv に対応しているため、着信トラフィックと発信トラフィックの両方をキューに入れたり評価したりできます。また、ロードバランサも diffserv 対応システムであるため、サーバーファームは IPQoS 対応となります。ロードバランサは、アプリケーションデータに含まれているユーザー ID やプロジェクト ID などのセレクタを使って、ルーターの向こう側へ追加のフィルタ処理を実行することもできます。

図 2–2 IPQoS 対応サーバーファームのネットワーク

このトポロジ図は、diffserv ルーター、IPQoS 対応のロードバランサ、および 3 つのサーバーファームを備えたネットワークを示します。

このシナリオでは、フロー制御とトラフィック転送を行って、ローカルネットワーク上の輻輳を管理しています。また、このトポロジでは、サーバーファームからの発信トラフィックが原因でイントラネットの他の部分が過負荷状態になるのを防いでいます。

ファイアウォールでの IPQoS

次の図は、ファイアウォールによって他のセグメントから保護されている、企業ネットワークのセグメントの 1 つを示しています。

図 2–3 IPQoS 対応のファイアウォールによって保護されているネットワーク

このトポロジ図は、diffserv ルーター、IPQoS 対応のファイアウォール、Solaris システム、およびその他のホストから成るネットワークを示します。

このシナリオでは、トラフィックはまず diffserv 対応ルーターに入り、そこでフィルタにかけられ、キューに入れられます。次に、ルーターによって転送された着信トラフィックはすべて、IPQoS 対応のファイアウォールに進みます。IPQoS を使用するには、ファイアウォールで IP 転送スタックをバイパスしてはなりません。

ファイアウォールのセキュリティポリシーによって、着信トラフィックを内部ネットワークに入れて良いかどうかが決まります。QoS ポリシーは、ファイアウォールを通過した着信トラフィックのサービスレベルを制御します。QoS ポリシーによっては、発信トラフィックに転送動作を付けることもできます。

サービス品質ポリシーの計画

サービス品質 (QoS) ポリシーを計画するときは、ネットワークが提供するサービスの確認、分類、そして優先順位付けを行う必要があります。また、利用できる帯域幅の大きさを評価して、各トラフィッククラスがネットワークに送出される速度を決める必要もあります。

QoS ポリシー計画の手掛かり

QoS ポリシーを計画するための情報を IPQoS 構成ファイルに必要な情報を含む形式で収集します。たとえば、次のテンプレートを使って、IPQoS 構成ファイルで使用する主な情報を表にすることができます。

表 2–2 QoS 構成テンプレート

クラス 

優先順位 

フィルタ 

セレクタ 

速度 

転送動作をどうするか 

アカウンティングが必要か 

クラス 1 

1 

フィルタ 1 

 

セレクタ 1 

セレクタ 2 

メーターの速度 (メーターの種類による)  

マーカーのドロップ優先度 

フローアカウンティング統計情報を必要とする 

 

 

フィルタ 2 

セレクタ 1 

セレクタ 2 

 

 

 

 

クラス 2 

2 

フィルタ 1 

セレクタ 1 

セレクタ 2 

メーターの速度 (メーターの種類による)  

マーカーのドロップ優先度 

フローアカウンティング統計情報を必要とする 

 

 

フィルタ 2 

セレクタ 1 

セレクタ 2 

 

 

 

各カテゴリをいくつかに分けて、QoS ポリシーをさらに細かく定義することができます。以下では、テンプレートに示されているカテゴリの情報を入手する方法について説明します。

次の作業マップは、QoS ポリシーを計画するための主な作業を示しています。

表 2–3 QoS ポリシーの計画 (作業マップ)

作業 

説明 

参照先 

1. IPQoS をサポートするようネットワークトポロジを設計する 

差別化サービスを提供するネットワーク上のホストとルーターを特定する 

IPQoS 用のネットワークを準備する方法

2. ネットワーク上のサービスを分類するためのクラスを定義する 

自分のサイトで提供するサービスの種類と SLA を調べ、これらのサービスを分類するためのトラフィッククラスを決める 

QoS ポリシーのクラスを定義する方法

3. クラス用のフィルタを定義する 

特定のトラフィッククラスをネットワークトラフィックフローから取り出すための最善の方法を決める 

QoS ポリシーにフィルタを定義する方法

4. IPQoS システムから送出されるトラフィックを測定するためのフロー制御速度を定義する 

トラフィッククラスごとに容認できるフロー速度を決める 

フロー制御を計画する方法

5. QoS ポリシーで使用する DS コードポイントすなわちユーザー優先順位の値を定義する 

トラフィックフローがルーターまたはスイッチによって処理されるときに割り当てられる転送動作を決める方法を計画する 

転送動作を計画する方法

6. 必要であれば、ネットワーク上のトラフィックフローに対する統計監視計画を設定する 

トラフィッククラスを評価して、アカウンティングまたは統計上の目的で監視するトラフィックフローを決める 

フローアカウンティングを計画する方法

注 –

この節の残りの部分では、IPQoS 対応システムの QoS ポリシーを計画する方法について説明します。diffserv ルーターの QoS ポリシーを計画する方法については、ルーターのマニュアルおよびルーター製造元の Web サイトを参照してください。

IPQoS 用のネットワークを準備する方法

次の手順は、QoS ポリシーを作成する前に行う一般的な計画作業を示しています。

  1. ネットワークトポロジを確認し、IPQoS システムと diffserv ルーターを使用するトポロジを計画します。

    トポロジの例については、diffserv ネットワークトポロジの計画を参照してください。

  2. IPQoS を必要とするホスト、または IPQoS サービスの有力な候補となるホストをトポロジで特定します。

  3. IPQoS 対応後に同じ QoS ポリシーを共用できそうなシステムを調べます。

    たとえば、ネットワーク上のすべてのホストで IPQoS を有効にする場合は、同じ QoS ポリシーを使用できるホストをすべて特定します。 各 IPQoS 対応システムにはローカル QoS ポリシーが必要で、そのポリシーはそれぞれの IPQoS 構成ファイルに実装されます。 ただし、IPQoS 構成ファイルを 1 つだけ作成し、これを同じ QoS 要件を持つすべてのシステムにコピーして使うこともできます。

  4. ネットワーク上の diffserv ルーターに対して必要な計画作業をすべて確認し、実行します。

    詳細については、ルーターのマニュアルとルーター製造元の Web サイトを参照してください。

QoS ポリシーのクラスを定義する方法

QoS ポリシーを定義する最初の手順は、トラフィックフローをいくつかのクラスに分類することです。diffserv ネットワーク上のトラフィックの種類ごとにクラスを作成する必要はありません。また、計画したネットワークトポロジによっては、IPQoS 対応システムごとに異なる QoS ポリシーを作成する必要があります。

注 –

クラスの概要については、クラスを参照してください。

次の手順の前に、IPQoS 用のネットワークを準備する方法で特定したとおり、ネットワーク上のどのシステムを IPQoS 対応とするかが決まっているものとします。

  1. QoS ポリシーを構成するための表を作成します。

    推奨される表については、表 2–2を参照してください。

  2. ネットワーク上にあるすべての QoS ポリシーについて、残りの手順を実行します。

  3. QoS ポリシーで使用するクラスを定義します。

    次の質問は、ネットワークトラフィックを解析してクラス定義を行うためのガイドラインとなります。

    • 顧客にサービスレベル契約を提示しているか

      提示する場合は、顧客に提供する複数の SLA 間の相対的な優先レベルを評価します。保証されている優先レベルが異なる顧客に同じアプリケーションを提供する場合もあります。

      たとえば、企業が各顧客に対して Web サイトの運営サービスを提供するとします。この場合は、顧客の Web サイトごとに 1 つのクラスを定義する必要があります。また、プレミアム Web サイトをサービスレベルの 1 つとして提供する SLA もあれば、ベストエフォートの個人用 Web サイトを割引き客に提供する SLA もあります。この場合は、Web サイトのクラスが異なるだけでなく、クラスに割り当てられる PHB も異なる可能性があります。

    • IPQoS システムでは、フロー制御を必要としそうなよく使われるアプリケーションを提供しているか

      よく使われるアプリケーションを提供しているために大量のトラフィックが生成されるサーバーの場合、IPQoS を有効にするとネットワークパフォーマンスが向上します。そのようなアプリケーションの例として、電子メール、ネットワークニュース、FTP などがあげられます。該当する場合は、サービスの種類ごとに着信トラフィックと発信トラフィックのクラスを別々に作成することを検討してください。たとえば、メールサーバーの QoS ポリシーに対して、mail-in クラスと mail-out クラスを作成します。

    • ネットワークでもっとも高い優先順位の転送動作を必要とする特定のアプリケーションを実行しているか

      もっとも高い優先順位の転送動作を必要とする重要なアプリケーションは、ルーターで特別な処理を受ける必要があります。一般的な例は、ストリーミングビデオやストリーミングオーディオです。

      まず、優先順位の高いこれらのアプリケーションに対して、それぞれ着信クラスと発信クラスを定義します。次に、定義したクラスを、それらのアプリケーションを提供する IPQoS 対応システムと diffserv ルーターの両方の QoS ポリシーに追加します。

    • 帯域幅を大量に消費するため、ネットワークで制御を必要とするトラフィックフローが発生したことがあるか

      netstat、snoop などのネットワーク監視ユーティリティを使用して、ネットワーク上で問題のあるトラフィックの種類を検出します。これまでに作成したクラスを確認し、問題のトラフィックカテゴリが未定義である場合は、このカテゴリに対して新しいクラスを作成します。問題のトラフィックカテゴリのクラスが定義済みである場合は、このトラフィックを制御するメーターの速度を定義します。

      問題のあるトラフィックのクラスは、ネットワーク上の IPQoS 対応システムごとに作成します。これによって、各 IPQoS システムは、問題のあるトラフィックを受け取った場合に、トラフィックフローをネットワークに送出する速度を制限できるようになります。また、diffserv ルーターの QoS ポリシーにもこれらの問題のあるクラスを必ず定義してください。これによって、diffserv ルーターは、QoS ポリシーの設定に従って、問題のあるフローをキューに入れたりスケジュールしたりできるようになります。

    • 特定の種類のトラフィックに対して統計情報を取得する必要があるか

      SLA をざっと確認すると、どのタイプの顧客のトラフィックにアカウンティングが必要であるかがわかります。自分のサイトで SLA を提供している場合は、アカウンティングを必要とするトラフィックのクラスはおそらく作成済みです。また、クラスを新たに定義して、監視中のトラフィックフローやセキュリティ上の目的でアクセスを制限しているトラフィックフローの統計情報を取得することもできます。

  4. QoS 構成表に定義したクラスを記入します。

  5. 優先レベルを各クラスに割り当てます。

    たとえば、優先レベル 1 がもっとも高い優先順位のクラスを表すようにし、それ以降の優先レベルを残りのクラスに割り当てます。優先レベルは、構成上の目的で割り当てているだけで、IPQoS が実際に使用するわけではありません。また、QoS ポリシーによっては、同じ優先順位を複数のクラスに割り当てることもできます。

    クラスの優先順位付けの重要性については、次の項を参照してください。

  6. クラスの定義が終わったら、次はクラスごとにフィルタを定義します (QoS ポリシーにフィルタを定義する方法を参照)。

クラスの優先順位付け

クラスを作成するうちに、どのクラスの優先順位が高いか、中程度か、ベストエフォートでよいかがすぐに明らかになってきます。クラスの優先順位付けは、PHB (ホップ単位動作) を発信トラフィックに割り当てるときに特に重要となります (転送動作を計画する方法を参照)。

PHB をクラスに割り当てるほかに、そのクラスのフィルタに優先順位セレクタを定義することもできます。優先順位セレクタは、IPQoS 対応ホストでのみ有効です。たとえば、同じ速度と同じ DSCP を持ついくつかのクラスが、IPQoS システムから送出されるときに帯域幅をめぐって競合することがあるとします。このような場合、各クラスの優先順位セレクタによって、他の点ではまったく同じ評価のクラスに割り当てられるサービスレベルをさらに細かく順序付けることができます。

QoS ポリシーにフィルタを定義する方法

パケットフローを特定のクラスのメンバーとして識別するには、フィルタを作成します。各フィルタには、パケットフローの評価基準を定義するセレクタがいくつか含まれています。IPQoS 対応システムは、セレクタに定義されている基準を使ってトラフィックフローからパケットを取り出し、それらのパケットをクラスに対応付けます (フィルタの概要については、フィルタを参照)。

次の手順に進む前に、QoS ポリシーのクラスを定義する方法を終わらせておく必要があります。

  1. QoS ポリシーのクラスを定義する方法で作成した QoS 構成表のクラスごとにフィルタを最低 1 つ作成します。

    必要であれば、1 つのクラスの着信トラフィックと発信トラフィックに対して、フィルタを別々に作成することを検討してください。たとえば、ftp-in フィルタと ftp-out フィルタを IPQoS 対応の FTP サーバーの QoS ポリシーに追加します。そうすれば、基本セレクタに加えて、該当する方向セレクタも定義できます。

  2. クラスのフィルタごとにセレクタを最低 1 つ定義します。

    次の表に、もっとも一般的に使用されるセレクタを示します。最初の 5 つのセレクタは、IPQoS 5 タプルを表し、IPQoS システムがパケットをフローのメンバーとして識別するときに使用します。利用可能なセレクタについては、表 6–1 を参照してください。

    注 –

    セレクタは正しい判断のもとで選択してください。 また、クラスのパケットを取り出すのに必要なものだけを使用してください。 定義するセレクタが多いほど、IPQoS パフォーマンスに与える影響も大きくなります。

    表 2–4 一般的な IPQoS セレクタ

    名前 

    定義 

    saddr

    発信元アドレス 

    daddr

    着信先アドレス 

    sport

    発信元ポート番号。 /etc/services に定義されている既知のポート番号、またはユーザー定義のポート番号を使用できる

    dport

    着信先ポート番号 

    protocol

    IP プロトコル番号またはプロトコル名。/etc/protocols のトラフィックフロータイプに割り当てられる

    ip_version

    使用するアドレス指定方式。V4 または V6 を使用する。デフォルトは V4 

    dsfield

    DS フィールドの内容、つまり DS コードポイント。 このセレクタは、特定の DSCP が付いている着信パケットを取り出すために使用する 

    priority

    クラスに割り当てられている優先レベル。 詳細については、クラスの優先順位付けを参照

    user

    UNIX のユーザー ID またはユーザー名。上位アプリケーションの実行時に使用される 

    projid

    プロジェクト ID。上位アプリケーションの実行時に使用される 

    direction

    トラフィックフローの方向。 LOCAL_IN、LOCAL_OUT、FWD_IN、または FWD_OUT のいずれかの値 

表 2–2 で紹介したテンプレートを使用して、定義したクラスのフィルタを記入します。

クラス 

優先順位 

フィルタ 

セレクタ 

ftp-traffic 

4 

ftp-out 

saddr 10.190.17.44

daddr 10.100.10.53

sport 21

direction LOCAL_OUT

次に進む手順

作業 

参照先  

フロー制御方式を定義する 

フロー制御を計画する方法

フローがネットワークストリームに戻されるときの転送動作を定義する 

転送動作を計画する方法

特定の種類のトラフィックに対してフローアカウンティングを計画する 

フローアカウンティングを計画する方法

QoS ポリシーにさらにクラスを追加する 

QoS ポリシーのクラスを定義する方法

QoS ポリシーにさらにフィルタを追加する 

QoS ポリシーにフィルタを定義する方法

フロー制御を計画する方法

フロー制御では、まずクラスのトラフィックフローを測定し、次に定義された速度でパケットをネットワークに送出します。フロー制御を計画するときは、IPQoS メータリングモジュールが使用するパラメータを定義します。メーターは、トラフィックがネットワークに送出される速度を決定します。メーターの概要については、メーター (tokenmt および tswtclmt) の概要を参照してください。

次の手順の前に、QoS ポリシーにフィルタを定義する方法の説明に従って、フィルタとセレクタを定義してあるものとします。

  1. ネットワークの最大帯域幅を調べます。

  2. ネットワーク上でサポートされている SLA をすべて確認して、顧客と各顧客に保証されているサービスの種類を特定します。

    SLA はある一定レベルのサービスを顧客に保証しているため、顧客によって生成される特定のトラフィッククラスを計測する必要があります。

  3. QoS ポリシーのクラスを定義する方法で作成したクラスのリストを確認します。

    SLA に対応付けられているクラス以外に計測する必要があるクラスがあるかどうか確認します。

    たとえば、IPQoS システムが大量のトラフィックを生成するアプリケーションを実行するとします。この場合は、そのアプリケーションのトラフィックを分類したあと、フローのパケットがネットワークに戻される速度を制御して、フローを計測します。

    注 –

    すべてのクラスを計測する必要があるとは限りません。 クラスのリストを確認するときは、このガイドラインに留意してください。

  4. クラスのどのフィルタがフロー制御を必要とするトラフィックを選択するかを確認することにより、計測するクラスのリストを作成し直します。

    複数のフィルタを持つクラスでも 1 つのフィルタに対してだけ計測を必要とする場合もあります。たとえば、あるクラスの着信トラフィックと発信トラフィックに対してフィルタを定義したとします。しかし、結果的にどちらかの方向のトラフィックしかフロー制御を必要としない場合があります。

  5. フロー制御を行うクラスごとにメーターモジュールを選択します。

    作成した構成表のメーター欄にモジュール名を追加します。

  6. 計測するクラスごとの速度を構成表に追加します。

    tokenmt モジュールを使用する場合は、次の速度を bps で定義する必要があります。

    • 認定速度

    • 最大速度

    特定のクラスの計測に十分な場合は、認定速度と認定バーストを tokenmt に定義するだけでも構いません。

    必要に応じて、次の速度も定義できます。

    • 認定バースト

    • 最大バースト

    tokenmt の速度の詳細については、tokenmt をツーレートメーターとして構成するを参照してください。tokenmt(7ipp) のマニュアルページでも詳しく説明しています。

    tswtclmt モジュールを使用する場合は、次の速度を bps で定義する必要があります。

    • 認定速度

    • 最大速度

    また、ウィンドウサイズをミリ秒単位で定義することもできます。これらの速度は、tswtclmt メータリングモジュールおよび twstclmt(7ipp) のマニュアルページに定義されています。

  7. 計測するトラフィックのトラフィック適合結果 (outcome) を追加します。

    どちらのメータリングモジュールでも、結果は緑、赤、黄の 3 つです。定義した速度に当てはまるトラフィック適合結果を QoS 構成表に追加します。これらのメーターの結果については、メーターモジュールで詳しく説明します。

    認定速度に適合したトラフィックまたは適合しなかったトラフィックに対して取るべきアクションを決める必要があります。よく取られるアクションは、パケットヘッダーに PHB を付けることですが、常にそうするわけではありません。緑レベルのトラフィックに対して取りうるアクションの 1 つとして、トラフィックフローが認定速度を超えないかぎり処理を続行することもあります。あるいは、フローが最大速度を超えた場合にそのクラスのパケットをドロップすることもできます。

次の表に、電子メールトラフィックのクラスに対するメーターの記入例を示します。この IPQoS システムが配置されているネットワークには、合計 100 Mbps (100000000 bps) の帯域幅があります。QoS ポリシーは、電子メールクラスに対して、低い優先順位とベストエフォートの転送動作を割り当てています。

表 2–5 メーターが定義されている QoS ポリシーの例

クラス 

優先順位 

フィルタ 

セレクタ 

速度 

email

8 

mail_in

daddr 10.50.50.5

dport imap

direction LOCAL_IN

 

 

 

mail_out

saddr 10.50.50.5

sport imap

direction LOCAL_OUT

メーター =tokenmt

認定速度 =5000000 

認定バースト =5000000 

最大速度 =10000000 

最大バースト =1000000 

緑の優先度 = 処理続行 

黄の優先度 = 黄の PHB を付加 

赤の優先度 = ドロップ  

次に進む手順

作業 

参照先  

フローがネットワークストリームに戻されるときの転送動作を定義する 

転送動作を計画する方法

特定の種類のトラフィックに対してフローアカウンティングを計画する 

フローアカウンティングを計画する方法

QoS ポリシーにさらにクラスを追加する 

QoS ポリシーのクラスを定義する方法

QoS ポリシーにさらにフィルタを追加する 

QoS ポリシーにフィルタを定義する方法

別のフロー制御方式を定義する 

フロー制御を計画する方法

IPQoS 構成ファイルを作成する 

IPQoS 構成ファイルの開始方法およびトラフィッククラスの定義方法

転送動作を計画する方法

転送動作は、ネットワークに転送されようとしているトラフィックフローの優先順位とドロップ優先度を決めます。 選択できる主な転送動作は 2 つあります。1 つは他のトラフィッククラスとの関連でクラスのフローに優先順位を付けることで、もう 1 つはフローを完全にドロップすることです。

diffserv モデルでは、マーカーを使用して、選択した転送動作をトラフィックフローに割り当てます。 IPQoS には、次のマーカーモジュールが用意されています。

注 –

この節では、IP パケットに限定して説明します。 IPQoS システムに VLAN デバイスが含まれている場合は、dlcosmk マーカーを使って、データグラムの転送動作をマークできます。 詳細については、VLAN デバイスでの dlcosmk マーカーの使用を参照してください。

IP トラフィックに優先順位を付けるには、各パケットに DS コードポイントを割り当てる必要があります。 dscpmk マーカーでは、パケットの DS フィールドに DS コードポイントを付けます。 クラスの DS コードポイントは、転送動作の種類に対応付けられている既知のコードポイントのグループから選択します。既知のコードポイントには、EF PHB 用の 46 (101110) や AF PHB 用のいくつかのコードポイントがあります。DS コードポイントと転送の概要については、IPQoS 対応ネットワークでのトラフィック転送を参照してください。

次の手順の前に、QoS ポリシーのクラスとフィルタを定義してあるものとします。トラフィックを制御する場合は、メーターをマーカーと組み合わせて使用しますが、転送動作を定義するだけであれば、マーカーを単独で使用できます。

  1. これまでに作成したクラスとそれらに割り当てた優先順位を確認します。

    すべてのトラフィッククラスをマークする必要があるとは限りません。

  2. もっとも高い優先順位のクラスに EF PHB を割り当てます。

    EF PHB は、EF DS コードポイント 46 (101110) を持つパケットが、AF PHB を割り当てたパケットよりも先にネットワーク上に送出されることを保証します。このため、もっとも高い優先順位のトラフィックには EF PHB を使用します。EF の詳細については、完全優先転送 (Expedited Forwarding、EF) PHBを参照してください。

  3. トラフィックを計測するクラスに転送動作を割り当てます。

    トラフィックの計測は、一般に次の理由で行います。

    • SLA は、ネットワークの使用率が高いときでも、このクラスのパケットにある程度のサービスを保証する

    • 低い優先順位のクラスがネットワークをあふれさせる傾向がある

    マーカーをメーターと組み合わせて使用すると、これらのクラスに対して差別化サービスを提供したり帯域幅の管理を行ったりできます。次の表に、高いレベルのトラフィックを生成するよく使われるゲーム用アプリケーションのクラスを定義した、QoS ポリシー例の一部を示します。

    クラス 

    優先順位 

    フィルタ 

    セレクタ 

    速度 

    転送 

    games_app

    9 

    games_in

    sport 6080 

     

     

     

     

    games_out

    dport 6081  

    メーター =tokenmt

    認定速度 =5000000 

    認定バースト =5000000 

    最大速度 =10000000 

    最大バースト =15000000 

    緑の優先度 = 処理続行 

    黄の優先度 = 黄の PHB を付加 

    赤の優先度 = ドロップ  

     

    緑 =AF31 

    黄 =AF42 

    赤 = ドロップ 

    これらの転送動作では、認定速度に適合しているか、最大速度を下回っている games_app トラフィックには、低い優先順位の DS コードポイントを割り当てます。games_app トラフィックが最大速度を上回ると、QoS ポリシーは games_app のパケットをドロップするよう指示します。すべての AF コードポイントは、表 6–2 に示してあります。

  4. 残りのクラスに、すでに割り当てた優先順位に応じた DS コードポイントを割り当てます。

次に進む手順

作業 

参照先  

特定の種類のトラフィックに対してフローアカウンティングを計画する 

フローアカウンティングを計画する方法

QoS ポリシーにさらにクラスを追加する 

QoS ポリシーのクラスを定義する方法

QoS ポリシーにさらにフィルタを追加する 

QoS ポリシーにフィルタを定義する方法

フロー制御方式を定義する 

フロー制御を計画する方法

フローがネットワークストリームに戻されるときの追加の転送動作を定義する 

転送動作を計画する方法

IPQoS 構成ファイルを作成する 

IPQoS 構成ファイルの開始方法およびトラフィッククラスの定義方法

フローアカウンティングを計画する方法

IPQoS の flowacct モジュールを使用すると、課金やネットワーク管理の目的で、トラフィックフローを常時監視できます。 次の手順に従って、QoS ポリシーにフローアカウンティングを含める必要があるかどうか判断してください。

  1. 顧客に SLA を提示していますか

    提示している場合は、フローアカウンティングを使用する必要があります。まず、SLA を確認して、企業が顧客に使用料を請求するネットワークトラフィックの種類を調べます。次に、QoS ポリシーを確認して、課金の対象となるトラフィックが含まれるクラスを調べます。

  2. ネットワークの問題を防ぐために監視またはテストを必要とするアプリケーションはありますか

    ある場合は、フローアカウンティングを使ってそれらのアプリケーションの動作を監視することを検討します。QoS ポリシーを確認して、監視を必要とするトラフィックに割り当てたクラスを調べます。

  3. QoS 計画テンプレートで、フローアカウンティングを必要とする各クラスのフローアカウンティング欄に Y と記入します。

次に進む手順

作業 

参照先  

QoS ポリシーにさらにクラスを追加する 

QoS ポリシーのクラスを定義する方法

QoS ポリシーにさらにフィルタを追加する 

QoS ポリシーにフィルタを定義する方法

フロー制御方式を定義する 

フロー制御を計画する方法

フローがネットワークストリームに戻されるときの転送動作を定義する 

転送動作を計画する方法

特定の種類のトラフィックに対して追加のフローアカウンティングを計画する 

フローアカウンティングを計画する方法

IPQoS 構成ファイルを作成する 

IPQoS 構成ファイルの開始方法およびトラフィッククラスの定義方法

IPQoS の構成例の紹介

このマニュアルの残りの章で説明する作業では、この節で紹介する IPQoS の構成例を使用します。この例は、BigISP と呼ばれる架空のサービスプロバイダのパブリックイントラネットで実装される差別化サービスのソリューションを示しています。BigISP は、専用回線で BigISP に接続する大企業と、モデムから電話回線で BigISP に接続する個人の、2 種類のユーザーにサービスを提供しています。

例 — IPQoS トポロジ

次の図は、BigISP のパブリックイントラネットに使用されるネットワークトポロジを示しています。

図 2–4 IPQoS のトポロジの例

このトポロジ図は、企業と個人の 2 種類のユーザーがアクセスする ISP ネットワークを示しています。このネットワークについては以下で定義します。

前の図に示すように、BigISP のパブリックイントラネットには、4 つの層が実装されています。