test

Solaris のシステム管理 (IP サービス)

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

Oracle Solaris が動作する任意のシステムで IPQoS を構成できます。そして、IPQoS システムを Diffserv 対応ルーターと組み合わせると、イントラネット上で差別化サービスを提供したり、トラフィック管理を行うことができます。

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

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

IPQoS などの差別化サービスをネットワーク上に実装する場合は、綿密な計画が必要です。各 IPQoS 対応システムの位置と機能だけではなく、各システムとローカルネットワーク上のルーターとの関係についても考慮してください。次の作業マップに、ネットワーク上で 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 Sun Enterprise™ 0000 サーバーなど) 上で実行します。一方、ネットワークのニーズに応じて、UltraSPARC® システムなどのデスクトップシステムで IPQoS を実行することもできます。次に、IPQoS 構成に使用できるシステムの例を示します。

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

IPQoS ネットワークトポロジ

この節では、ネットワーク上のさまざまなニーズを満たす IPQoS 計画を図で説明します。

個々のホストでの IPQoS

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

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

トポロジ図に、Diffserv ルーターを備えたローカルネットワークと FTP サーバー、データベースサーバーおよび Web サーバーという 3 台の IPQoS 対応システムを示します。

このネットワークは、ある企業のイントラネットの一部分です。アプリケーションサーバーや Web サーバーで IPQoS を有効にすると、各 IPQoS システムが発信トラフィックを送出する速度を制御できます。ルーターが Diffserv に対応していれば、着信トラフィックおよび発信トラフィックをさらに制御できます。

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

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

次の図には、複数の異種サーバーファームを備えるネットワークを示します。

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

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

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

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

ファイアウォールでの IPQoS

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

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

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

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

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

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

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

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

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

表 33–1 QoS 計画テンプレート

クラス 

優先順位 

フィルタ 

セレクタ 

レート 

転送動作をどうするか 

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

クラス 1 

1 

フィルタ 1 

フィルタ 3 

セレクタ 1 

セレクタ 2 

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

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

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

クラス 1 

1 

フィルタ 2 

セレクタ 1 

セレクタ 2 

 

なし 

なし 

なし 

クラス 2 

2 

フィルタ 1 

セレクタ 1 

セレクタ 2 

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

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

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

クラス 2 

2 

フィルタ 2 

セレクタ 1 

セレクタ 2 

なし 

なし 

なし 

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

QoS ポリシーの計画 (作業マップ)

この作業マップでは、QoS ポリシーを計画するための主な作業の一覧と、各作業の実行手順へのリンクを示します。

作業 

説明 

説明 

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

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

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

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

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

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

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

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

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

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

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

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

5. QoS ポリシーで使用する DSCP すなわちユーザー優先順位の値を定義する 

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

「転送動作を計画する方法」

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

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

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

注 –

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

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

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

  1. ネットワークトポロジを見直します。次に、IPQoS システムと Diffserv ルーターを使用する戦略の計画を作成します。

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

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

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

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

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

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

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

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

注 –

クラスの概要は、「IPQoS クラス」を参照してください。

次の手順では、「IPQoS 用のネットワークを準備する方法」に従って、IPQoS 対応とするネットワーク上のシステムを決定済みであることを前提としています。

  1. QoS ポリシー情報を整理する QoS 計画テーブルを作成します。

    提案については、表 33–1 を参照してください。

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

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

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

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

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

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

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

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

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

      優先順位が最も高い転送動作を必要とする重要なアプリケーションには、ルーターのキューで最も高い優先順位を与える必要があります。一般的な例は、ストリーミングビデオやストリーミングオーディオです。

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

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

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

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

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

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

  4. 手順 1 で作成した QoS 計画テーブルで定義したクラスを一覧にします。

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

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

  6. クラスの定義の次は、「QoS ポリシーにフィルタを定義する方法」の説明に従って、各クラスのフィルタを定義します。

クラスの優先順位付け

クラスを作成するうちに、どのクラスの優先順位が高いか、中程度か、ベストエフォートでよいかをすぐに認識できます。「転送動作を計画する方法」に説明されているとおり、クラスの優先順位を設定する良いスキームは、出力トラフィックにホップ単位の動作を割り当てる場合に、特に重要になります。

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

フィルタの定義

パケットフローを特定のクラスのメンバーとして識別するには、フィルタを作成します。各フィルタには、パケットフローの評価基準を定義するセレクタがいくつか含まれています。IPQoS 対応システムは、次にセレクタの基準を使用して、トラフィックフローからパケットを抽出します。そして、IPQoS システムは、パケットとクラスを関連付けます。 フィルタの紹介は、「IPQoS フィルタ」を参照してください。

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

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

名前 

定義 

saddr

発信元アドレス 

daddr

着信先アドレス 

sport

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

dport

着信先ポート番号 

プロトコル

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

ip_version

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

dsfield

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

priority

クラスに割り当てられている優先レベル。詳細は、「QoS ポリシーのクラスを定義する方法」を参照

user

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

projid

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

direction

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

注 –

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

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

始める前に

次の手順を実行する前に、「QoS ポリシーのクラスを定義する方法」の手順を完了しておく必要があります。

  1. 「QoS ポリシーのクラスを定義する方法」で作成した QoS 計画テーブルの各クラスに 1 つ以上のフィルタを作成します。

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

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

    表 33–1 で紹介されている QoS 計画テーブルを使用して、定義したクラスのフィルタを埋めます。

例 33–1 FTP トラフィック向けのフィルタの定義

次の表は、出力 FTP トラフィック向けにフィルタを定義する方法を示す例です。

クラス 

優先順位 

フィルタ 

セレクタ 

ftp-traffic

4 

ftp-out

saddr 10.190.17.44

daddr 10.100.10.53

sport 21

direction LOCAL_OUT

参照

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

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

次の手順は、「QoS ポリシーにフィルタを定義する方法」の説明に従って、フィルタとセレクタを定義していることが前提になります。

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

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

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

  3. 「QoS ポリシーのクラスを定義する方法」で作成したクラスの一覧を見直します。

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

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

    注 –

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

  4. 各クラスのどのフィルタがフロー制御に必要なトラフィックを選択するのかを判断します。次に、メータリングを必要とするクラスのリストを精緻化します。

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

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

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

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

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

    • 認定速度

    • 最大速度

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

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

    • 認定バースト

    • 最大バースト

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

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

    • 認定速度

    • 最大速度

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

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

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

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

例 33–2 メーターの定義

次の表は、電子メールトラフィックのクラスに対するメーターの記入例を示す例です。IPQoS システムを持つネットワークの総帯域幅は 100 Mbits/秒、つまり毎秒 10000000 ビットです。QoS ポリシーは、電子メールクラスに低い優先順位を割り当てます。このクラスには、ベストエフォート型の転送動作も割り当てられます。

クラス 

優先順位 

フィルタ 

セレクタ 

レート 

email

8 

mail_in

daddr10.50.50.5

dport imap

direction LOCAL_IN

 

email

8 

mail_out

saddr10.50.50.5

sport imap

direction LOCAL_OUT

メーター =tokenmt

認定速度 =5000000 

認定バースト =5000000 

最大速度 =10000000 

最大バースト =1000000 

緑の優先度 = 処理続行 

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

赤の優先度 = ドロップ 

参照

Procedure転送動作を計画する方法

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

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

注 –

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

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

始める前に

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

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

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

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

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

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

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

例 33–3 ゲームアプリケーション向け QoS ポリシー

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

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

クラス 

優先順位 

フィルタ 

セレクタ 

レート 

転送動作をどうするか 

games_app

9 

games_in

sport 6080

なし 

なし 

games_app

9 

games_out

dport 6081

メーター =tokenmt

認定速度 =5000000 

認定バースト =5000000 

最大速度 =10000000 

最大バースト =15000000 

緑の優先度 = 処理続行 

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

赤の優先度 = ドロップ 

緑 =AF31 

黄 =AF42 

赤 = ドロップ 

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

参照

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

IPQoS flowacct モジュールを使用して、請求またはネットワーク管理のためにトラフィックフローを追跡します。次の手順に従って、QoS ポリシーにフローアカウンティングを含める必要があるかどうか判断してください。

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

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

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

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

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

参照

IPQoS の構成例の紹介

このマニュアルの残りの章で説明する作業では、この節で紹介する IPQoS の構成例を使用します。この例は、架空のサービスプロバイダである BigISP の公共イントラネットでの差別化サービスソリューションを示しています。BigISP は、専用回線によって BigISP にアクセスする大企業向けにサービスを提供しています。モデムによるダイアルインを行う個人顧客も BigISP からサービスを購入しています。

IPQoS トポロジ

次の図は、BigISP の公共イントラネットで使用するネットワークトポロジを示しています。

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

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

BigISP は、公共イントラネットにこれらの 4 つの層を実装しています。