この章は、IPQoS の詳細を説明するリファレンスです。
この章では、以下の内容について説明します。
IPQoS の概要については、第 1 章「IPQoS の紹介 (概要)」を参照してください。計画情報については、第 2 章「IPQoS 対応ネットワークの計画 (手順)」を参照してください。IPQoS の構成手順については、第 3 章「IPQoS 構成ファイルの作成 (手順)」を参照してください。
この節では、IPQoS アーキテクチャとこのアーキテクチャが RFC 2475 (An Architecture for Differentiated Services) で定義された差別化サービス (diffserv) モデルを実装する方法について説明します。 次に示す diffserv モデルの要素が、IPQoS に含まれます。
クラシファイア
メーター
マーカー
さらに、IPQoS にはフローアカウンティングモジュールおよびVLAN デバイスで使用する dlcosmk マーカーも含まれます。
diffserv モデルでは、「クラシファイア」は、トラフィックフローを選択して、それぞれに異なるサービスレベルを適用するためのグループに分類する作業を担当します。RFC 2475 で定義されたクラシファイアは、当初、境界ルーター用に設計されました。それとは対照的に、IPQoS クラシファイア ipgpc は、内部ホストからローカルネットワークへのトラフィックフローを処理するために設計されています。このため、IPQoS システムと diffserv ルーターの両方を備えたネットワークは、より広範囲な差別化サービスを提供できます。ipgpc の技術情報については、ipgpc(7ipp) のマニュアルページを参照してください。
IPQoS 対応システムの IPQoS 構成ファイルに指定された条件を満たすトラフィックフローを選択します。
QoS ポリシーは、パケットヘッダーに存在する必要のあるさまざまな条件を定義します。これらの条件は、「セレクタ」と呼ばれます。 ipgpc クラシファイアは、これらのセレクタを、IPQoS システムから受信したパケットのヘッダーと比較して、一致するパケットをすべて選択します。
パケットフローを、IPQoS 構成ファイルの定義に従い、同じ特性を持つネットワークトラフィックである 「クラス」に分類します。
パケットの差別化サービス (DS) フィールドの値を調べ、差別化サービス (DS) コードポイントの存在を確認します
DS コードポイントすなわち DSCP は、受信したトラフィックに送信側によって転送動作のマークが付けられているかどうかを示します。
特定クラスのパケットに関して、IPQoS 構成ファイル内で次に指定されているアクションを調べます。
パケットを、IPQoS 構成ファイルで指定された次の IPQoS モジュールに渡すか、あるいはネットワークストリームに戻します。
クラシファイアの概要については、クラシファイア (ipgpc) の概要を参照してください。IPQoS 構成ファイル内でのクラシファイアの呼び出しに関しては、IPQoS 構成ファイルを参照してください。
ipgpc は、IPQoS 構成ファイルのフィルタ句で使用可能なさまざまなセレクタをサポートします。フィルタを定義するときには、特定クラスのトラフィック取得に必要な最小限のセレクタを使用してください。定義するフィルタの数が、IPQoS のパフォーマンスに影響を与える可能性があります。
表 6–1 IPQoS クラシファイアで利用可能なフィルタセレクタ
セレクタ |
引数 |
選択される情報 |
---|---|---|
saddr |
IP アドレス番号 |
発信元アドレス |
daddr |
IP アドレス番号 |
着信先アドレス |
sport |
ポート番号またはサービス名。/etc/services の定義に従う |
トラフィッククラスの発信元ポート |
dport |
ポート番号またはサービス名。/etc/services の定義に従う |
トラフィッククラスの着信先ポート |
protocol |
プロトコル番号またはプロトコル名。/etc/protocols の定義に従う |
このトラフィッククラスが使用するプロトコル |
dsfield |
DS コードポイント。デフォルトはゼロ (0) |
DS コードポイント。パケットに適用される転送動作を定義する |
if_name |
インタフェース名 |
特定クラスの着信トラフィックまたは発信トラフィックで使用されるインタフェース |
if_groupname |
インタフェースグループ名 |
特定クラスの着信トラフィックまたは発信トラフィックで使用されるインタフェースグループ |
user |
選択する UNIX userID の番号またはユーザー名。パケットに userID またはユーザー名が存在しない場合、デフォルトの –1 が使用される |
アプリケーションに指定される UserID |
projid |
選択するプロジェクト ID の番号 |
アプリケーションに付加されるプロジェクト ID |
priority |
優先順位の番号。もっとも低い優先順位は 0 |
このクラスのパケットに与えられる優先順位。優先順位は、同じクラスに複数存在するフィルタの重要度の順位付けに使用される |
direction |
次の引数のいずれかを指定できる。 |
IPQoS マシン上のパケットフローの方向 |
|
LOCAL_IN |
ローカルシステムから IPQoS システムへの入力トラフィック |
|
LOCAL_OUT |
ローカルシステムから IPQoS システムへの出力トラフィック |
|
FWD_IN |
転送される入力トラフィック |
|
FWD_OUT |
転送される出力トラフィック |
|
0 |
LOCAL_IN と LOCAL_OUT、または FORWARD_IN と FORWARD_OUT を表すワイルドカード |
precedence |
優先度の値。もっとも高い優先度は 0 |
優先度は、同一優先順位のフィルタの順序付けに使用される |
ip_version |
v4 または v6 |
パケットにより使用されるアドレス指定スキーマ (IPv4 または IPv6) |
「メーター」は、フローの転送速度をパケット単位で追跡し、設定されたパラメータにパケットが適合するかどうかを調べます。メーターモジュールは、パケットサイズ、設定されたパラメータ、およびフロー速度に基づき、パケットの次のアクションをアクションセットの中から決定します。
メーターには 2 つのメータリングモジュール、すなわち tokenmt および tswtclmt があります。モジュールの構成は、IPQoS 構成ファイルで行います。モジュールのどちらか一方または両方をクラスに設定できます。
メータリングモジュールを構成する際、速度に関する 2 つのパラメータを定義できます。
認定速度 – 特定クラスのパケットに容認可能な転送速度を bps で定義する
最大速度 – 特定クラスのパケットに最大限容認可能な転送速度を bps で定義する
パケットに対するメータリングアクションの結果 (outcome) は、次の 3 つのどれかになります。
緑 – パケットの生成するフローは認定速度内である
黄 – パケットの生成するフローは認定速度を超過しているが、最大速度内である
赤 – パケットの生成するフローは最大速度を超過している
tokenmt モジュールは、「トークンバケット」を使用してフローの転送速度を測定します。tokenmt は、シングルレートメーターまたはツーレートメーターとして機能するように構成できます。tokenmt アクションインスタンスは、2 つのトークンバケットを管理します。これらのトークンバケットは、トラフィックフローが設定されたパラメータに適合するかどうかを調べます。
tokenmt(7ipp) のマニュアルページは、IPQoS がトークンメーターパラダイムを実装する方法を説明しています。トークンバケットに関する一般的な情報は、Kalevi Kilkki 著『Differentiated Services for the Internet』および多数の Web サイトで入手できます。
committed_rate – フローの認定速度を bps で指定する
committed_burst – 認定バーストサイズをビット単位で指定する。committed_burst パラメータは、認定速度でネットワークに渡すことのできる、特定クラスの発信パケット数を定義する
peak_rate – 最大速度を bps で指定する
peak_burst – 最大バーストサイズまたは超過バーストサイズをビット単位で指定する。peak_burst パラメータは、トラフィッククラスに、認定速度を超過する最大バーストサイズを付与する
color_aware – tokenmt のカラーアウェアモードを有効にする
color_map – DSCP 値を緑、黄、または赤にマッピングする整数配列を定義する
tokenmt をシングルレートメーターとして構成するには、IPQoS 構成ファイル内で tokenmt に peak_rate パラメータを指定しないでください。赤、緑、または黄の結果 (outcome) を識別するようにシングルレートの tokenmt インスタンスを構成するには、peak_burst パラメータを指定する必要があります。peak_burst パラメータを使用しないことによって、tokenmt が赤または緑の結果だけを識別するように構成することもできます。2 つの結果を識別するシングルレート tokenmt の例については、例 3–3 を参照してください。
tokenmt がシングルレートメーターとして機能する場合、 peak_burst パラメータは実質的にバーストサイズを超過します。committed_burst と peak_burst のどちらかと committed_rate は、ゼロ以外の正の整数にする必要があります。
tokenmt をツーレートメーターとして構成するには、IPQoS 構成ファイル内で tokenmt アクション用の peak_rate パラメータを指定します。 ツーレートの tokenmt は、必ず赤、黄、および緑の 3 つの結果 (outcome) を識別します。committed_rate、committed_burst、および peak_burst パラメータは、すべてゼロ以外の正の整数にする必要があります。
ツーレートの tokenmt をカラーアウェアとして構成するには、「カラーアウェアネス」を有効にするパラメータを追加する必要があります。次に、カラーアウェアの tokenmt を構成するアクション文の例を示します。
action { module tokenmt name meter1 params { committed_rate 4000000 peak_rate 8000000 committed_burst 4000000 peak_burst 8000000 global_stats true red_action_name continue yellow_action_name continue green_action_name continue color_aware true color_map {0-20,22:GREEN;21,23-42:RED;43-63:YELLOW} } }
color_aware パラメータを true に設定することによって、カラーアウェアを有効にできます。カラーアウェアにした tokenmt メーターは、以前の tokenmt アクションによってパケットが赤、黄、または緑にマーキング済みであるものと見なします。カラーアウェアの tokenmt は、ツーレートメーター用のパラメータに加え、パケットヘッダー内の DS コードポイントも使用してパケットを評価します。
color_map パラメータには、パケットヘッダー内の DSCP がマッピングされた配列が含まれます。次の color_map 配列について説明します。
color_map {0-20,22:GREEN;21,23-42:RED;43-63:YELLOW}
DSCP が 0〜20 および 22 のパケットは緑にマッピングされます。DSCP が 21 および 23〜42 のパケットは赤にマッピングされます。DSCP が 43〜63 のパケットは黄にマッピングされます。tokenmt は、デフォルトのカラーマップを持っていますが、必要に応じ color_map パラメータを使用してカラーマップを変更できます。
color_action_name パラメータでは、continue を指定するとパケットの処理を完了できます。また、たとえば yellow_action_name markAF22 のように、引数を指定してパケットをマーカーアクションに送信することもできます。
tswtclmt メータリングモジュールは、時間ベースの速度エスティメータを使用して、トラフィッククラスの平均帯域幅を見積もります。tswtclmt は必ず 3 つの結果 (outcome) を識別するメーターとして機能します。 速度エスティメータは、フローの到着速度の見積もりを提供します。この速度は、一定期間すなわち「ウィンドウ」内の、トラフィックストリームの実行帯域幅の平均を見積もります。速度概算アルゴリズムは、RFC 2859 (A Time Sliding Window Three Colour Marker) に基づいています。
tswtclmt を構成するには、次のパラメータを使用します。
committed_rate – 認定速度を bps で指定する
peak_rate – 最大速度を bps で指定する
window – タイムウィンドウをミリ秒で定義する。このタイムウィンドウに対して平均帯域幅の履歴が記録される
tswtclmt の技術的な詳細については、tswtclmt(7ipp) のマニュアルページを参照してください。tswtclmt に似た速度シェーパの一般的な情報については、RFC 2963 (A Rate Adaptive Shaper for Differentiated Services) を参照してください。
IPQoS には 2 つのマーカーモジュール、すなわち dscpmk および dlcosmk が含まれます。ここでは、両方のマーカーの使用方法を説明します。dlcosmk は VLAN デバイスを使用する IPQoS システムでだけ利用可能であるため、通常は dscpmk を使用する必要があります。
dscpmk の技術情報については、dscpmk(7ipp) のマニュアルページを参照してください。dlcosmk の技術情報については、dlcosmk(7ipp) のマニュアルページを参照してください。
マーカーは、クラシファイアモジュールまたはメータリングモジュールによって処理されたあとのトラフィックフローを受け取ります。マーカーは、トラフィックに転送動作のマークを付けます。転送動作は、フローが IPQoS システムを離れたあとに実行されます。トラフィッククラスに対して実行される転送動作は、ホップ単位動作 (PHB) に定義されます。PHB はトラフィッククラスに優先順位を割り当てます。これは、そのクラスのフローに割り当てられる、ほかのトラフィッククラスに対する相対的な優先度です。PHB は、IPQoS システムの隣接するネットワーク上での転送動作だけを制御します。PHB の詳細については、ホップ単位動作を参照してください。
パケット転送とは、特定クラスのトラフィックを、ネットワーク上の次の宛先へ送信するプロセスを指します。IPQoS システムなどのホストの場合、パケットはホストからローカルネットワークストリームへ転送されます。diffserv ルーターの場合、パケットはローカルネットワークからルーターの次のホップへ転送されます。
マーカーは、パケットヘッダー内の DS フィールドに、IPQoS 構成ファイル内で定義された既知の転送動作のマークを付けます。以後、IPQoS システムおよびあとに続く diffserv 対応システムは、マークが変更されないかぎり、DS フィールド内の指示に従ってトラフィックを転送します。PHB を割り当てるときには、IPQoS システムはパケットヘッダーの DS フィールドに、差別化サービス (DS) コードポイントすなわち DSCP と呼ばれる値を付けます。diffserv アーキテクチャは、2 種類の転送動作、すなわち EF および AF を定義しており、各転送動作はそれぞれ異なる DS コードポイントを使用します。DS コードポイントの概要については、DS コードポイント (DSCP)を参照してください。
IPQoS システムは、トラフィックフローの DS コードポイントを読み取り、ほかの送信トラフィックフローに対する相対的な優先度を評価します。次に IPQoS システムは、並行するトラフィックフローすべての優先順位を定め、各フローを優先順位に従ってネットワーク上に送出します。
diffserv ルーターは、送信トラフィックフローを受け取り、パケットヘッダー内の DS フィールドを読み取ります。ルーターは、DS コードポイントを使用して、並行するトラフィックフロー間の優先順位付けおよびスケジューリングを行い、PHB で指示された優先順位に従って各フローを転送します。あとに続くホップ上の diffserv 対応システムも同じ PHB を認識する場合を除いて、ネットワークの境界ルーターを越えて PHB を適用することはできません。
完全優先転送 (EF) は、推奨される EF コードポイント 46 (101110) の付いたパケットが、ネットワークに送出される時に、可能なかぎり最良の扱いを受けることを保証します。 EF 転送は、しばしば専用回線に例えられます。コードポイント 46 (101110) を持つパケットには、宛先に向かう途中、すべての diffserv ルーターによる優先待遇が保証されます。EF の技術情報については、RFC 2598 (An Expedited Forwarding PHB) を参照してください。
相対的優先転送 (AF) では、4 つのクラスの転送動作をマーカーに指示できます。次の表に、クラス、各クラスに指定できる 3 つのドロップ優先度、および各優先度に対応する推奨 DSCP を示します。各 DSCP は、AF 値 (10 進数値およびバイナリ値) で表されます。
表 6–2 相対的優先転送のコードポイント
|
クラス 1 |
クラス 2 |
クラス 3 |
クラス 4 |
---|---|---|---|---|
低ドロップ優先度 |
AF11 = 10 (001010) |
AF21 = 18 (010010) |
AF31 = 26 (011010) |
AF41 = 34 (100010) |
中ドロップ優先度 |
AF12 = 12 (001100) |
AF22 = 20 (010100) |
AF32 = 28 (011100) |
AF42 = 36 (100100) |
高ドロップ優先度 |
AF13 = 14 (001110) |
AF23 = 22 (010110) |
AF33 = 30 (011110) |
AF43 = 38 (100110) |
AF コードポイントは、各トラフィッククラスに差別化転送動作を提供する際のガイドとして、すべての diffserv 対応システム上で使用できます。
たとえば、QoS ポリシーにより 2 つのトラフィッククラスに対してそれぞれ AF31 と AF13 の DSCP を割り当てるとします。AF31 (011010) の付いたパケットは、IPQoS システムからの送信時に、AF13 (001110) の付いたパケットよりも低い転送優先順位が与えられます。
これらのパケットが diffserv ルーターに達すると、ルーターはパケットのコードポイントを、キュー内のほかのトラフィックの DS コードポイントとともに評価します。次にルーターは、利用可能な帯域幅、およびパケットの DS コードポイントにより割り当てられた優先順位に応じて、パケットを転送またはドロップします。EF PHB の付いたパケットは、どの AF PHB の付いたパケットよりも広い帯域幅の使用が保証されます。
ネットワーク上の IPQoS システムと diffserv ルーターとの間でパケットのマーキングを合致させて、パケットが意図したとおりに転送されるようにしてください。たとえば、ネットワーク上の IPQoS システムがパケットにコードポイント AF21 (010010)、AF13 (001110)、AF43 (100110)、および EF (101110) を付けるとします。この場合、AF21、AF13、AF43、および EF DS コードポイントを、diffserv ルーターの適切なファイルに追加する必要があります。
AF コードポイント表に関する技術情報については、RFC 2597 を参照してください。ルーター製造元の Cisco Systems 社および Juniper Networks 社は、それぞれ自社の Web サイトで AF PHB の設定に関する詳細な情報を提供しています。この情報を使用して、IPQoS システムおよびルーター用の AF PHB を定義できます。また、ルーター製造元のマニュアルには、自社製品での DS コードポイントの設定方法が記載されています。
DS コードポイントの長さは 6 ビットです。DS フィールドの長さは 1 バイトです。IPQoS 構成ファイルで DS コードポイントを定義すると、マーカーはパケットヘッダーの最初の 6 ビットに DS コードポイントをマークします。残りの 2 ビットは、使用されません。
DS コードポイントを定義するには、マーカーアクション文の中で次のパラメータを使用します。
dscp_map{0-63:DS_codepoint} |
dscp_map パラメータは、「DS コードポイント (DSCP)」値を使用して生成する 64 要素の配列です。dscp_map は、dscpmk マーカーによって着信 DSCP を発信 DSCP にマップするために使用されます。
DSCP 値は、10 進表記で dscp_map に指定する必要があります。たとえば、EF コードポイント 101110 は 10 進数値 46 に変換する必要があり、その結果 dscp_map{0-63:46} になります。AF コードポイントの場合、表 6–2 に示したコードポイントを、10 進数値に変換する必要があります。
dlcosmk マーカーモジュールは、データグラムの MAC ヘッダー内に転送動作をマークします。VLAN インタフェースを持つ IPQoS システムでだけ、dlcosmk を使用できます。
dlcosmk は、「VLAN タグ」と呼ばれる 4 バイトを MAC ヘッダーに追加します。VLAN タグには、IEEE 801.D 標準に定義されている 3 ビットのユーザー優先順位値が含まれます。VLAN を認識する Diffserv 対応スイッチは、データグラム内のユーザー優先順位フィールドを読み取ることができます。801.D ユーザー優先順位値は、サービスクラス (CoS) マークを実装します。CoS マークは、商用スイッチで一般的に使われています。
次の表に示すサービスクラスマークを定義することにより、dlcosmk マーカーアクション内でユーザー優先順位値を使用できます。
表 6–3 801.D ユーザー優先順位値
サービスクラス |
定義 |
---|---|
0 |
ベストエフォート |
1 |
バックグラウンド |
2 |
スペア |
3 |
エクセレントエフォート |
4 |
制御された負荷 |
5 |
応答時間 100ms 未満のビデオ |
6 |
応答時間 10ms 未満のビデオ |
7 |
ネットワーク制御 |
dlcosmk の詳細は、dlcosmk(7ipp) のマニュアルページを参照してください。
ここでは、VLAN デバイスを持つシステムでの IPQoS の実装方法を示す、単純なネットワークのシナリオを紹介します。このシナリオには、スイッチで接続された 2 つの IPQoS システム、すなわち machine1 および machine2 が含まれます。machine1 上の VLAN デバイスの IP アドレスは 10.10.8.1、machine2 上の VLAN デバイスの IP アドレスは 10.10.8.3 です。
次に示す machine1 用 IPQoS 構成ファイルは、machine2 へのスイッチを介してトラフィックをマークするための簡単なソリューションを表します。
fmt_version 1.0 action { module ipgpc name ipgpc.classify filter { name myfilter2 daddr 10.10.8.3 class myclass } class { name myclass next_action mark4 } } action { name mark4 module dlcosmk params { cos 4 next_action continue global_stats true } }
この構成では、machine2 上の VLAN デバイスを着信先とする machine1 からのすべてのトラフィックが、dlcosmk マーカーに渡されます。マーカーアクション mark4 は、dlcosmk に対し、myclass クラスのデータグラムに CoS 4 の VLAN マークを追加するよう指示します。ユーザー優先順位置 4 は、2 つのマシン間のスイッチが、 machine1 からの myclass トラフィックフローに対して制御された負荷転送を与えることを示します。
IPQoS の flowacct モジュールは、トラフィックフローに関する情報を記録します。このプロセスは、「フローアカウンティング」と呼ばれます。フローアカウンティングによって得られたデータは、顧客への課金や特定クラスへのトラフィック量の評価に使用できます。
フローアカウンティングは、オプションです。通常、flowacct は、メーターまたはマーカーに処理されたトラフィックフローが、ネットワークストリームへ送出される前に通る、最後のモジュールです。diffserv モデル内での flowacct の位置については、図 1–1 を参照してください。flowacct の詳細な技術情報については、flowacct(7ipp) のマニュアルページを参照してください。
フローアカウンティングを有効にするには、flowacct に加えて、Solaris の exacct アカウンティング機能および acctadm コマンドを使用する必要があります。フローアカウンティングの設定に関する全般的な手順については、表 5–1 を参照してください。
flowacct は、「フローレコード」で構成された「フローテーブル」内に、フローに関する情報を収集します。テーブル内の各エントリには、1 つのフローレコードが含まれます。フローアカウントテーブルは、表示できません。
フローレコードを測定してテーブルへ書き込むには、IPQoS 構成ファイル内で次の flowacct パラメータを定義します。
timer – タイムアウトしたフローをフローテーブルから削除し、acctadm により作成されたファイルに書き込む間隔を、ミリ秒単位で定義する
timeout – パケットフローがタイムアウトするまでの非アクティブな時間を、ミリ秒単位で定義する
timer と timeout には異なる値を指定できます。
max_limit – テーブルに格納可能なフローレコードの数に上限を設定する
flowacct モジュールは、flowacct インスタンスが認識するすべてのパケットフローを記録するフローテーブルを管理します。フローは、次のパラメータによって特定されます。これらを、flowacct の 8 タプルと呼びます。
発信元アドレス
着信先アドレス
発信元ポート
着信先ポート
DSCP
ユーザー ID
プロジェクト ID
プロトコル
フローの 8 タプルのパラメータが変化しないかぎり、フローテーブルには 1 つのエントリだけが含まれます。max_limit パラメータにより、フローテーブルに含めることのできるエントリ数が決定されます。
フローテーブルは、IPQoS 構成ファイル内の timer パラメータに指定された間隔でスキャンされます。デフォルトは 15 秒です。IPQoS 構成ファイル内の timeout に指定された時間以上、IPQoS システムがパケットを認識しない場合、フローは「タイムアウト」します。デフォルトのタイムアウト間隔は 60 秒です。タイムアウトしたエントリは、acctadm コマンドを使用して作成されたアカウンティングファイルに書き込まれます。
flowacct レコードには、次の属性が含まれます。
表 6–4 flowacct レコードの属性
属性名 |
属性の内容 |
タイプ |
---|---|---|
src -addr-address_type |
オリジネータの発信元アドレス。address_type は、IPQoS 構成ファイルの指定に従い、v4 (IPv4 の場合) または v6 (IPv6 の場合) になる |
基本 (Basic) |
dest_ addr_address_type |
パケットの着信先アドレス。address_type は、IPQoS 構成ファイルの指定に従い、v4 (IPv4 の場合) または v6 (IPv6 の場合) になる |
基本 (Basic) |
src- port |
フローの起点となる発信元ポート |
基本 (Basic) |
dest-port |
ブローの宛先となる着信先ポート番号 |
基本 (Basic) |
protocol |
フローのプロトコル番号 |
基本 (Basic) |
total-packets |
フロー内のパケット数 |
基本 (Basic) |
total-bytes |
フロー内のバイト数 |
基本 (Basic) |
action_name |
このフローを記録した flowacct アクションの名前 |
基本 (Basic) |
creation_time |
flowacct がそのフローのパケットを最初に認識した時間 |
拡張 (Extended) のみ |
last_seen |
そのフローのパケットを最後に認識した時間 |
拡張 (Extended) のみ |
diffserv-field |
フローの発信パケットヘッダー内の DS コードポイント |
拡張 (Extended) のみ |
user |
アプリケーションから取得される UNIX UserID またはユーザー名 |
拡張 (Extended) のみ |
projid |
アプリケーションから取得されるプロジェクト ID |
拡張 (Extended) のみ |
acctadm コマンドを使用して、flowacct により生成されるさまざまなフローレコードを格納するファイルを作成します。acctadm は、拡張アカウンティング機能と連動して動作します。acctadm の技術情報については、acctadm(1M) のマニュアルページを参照してください。
flowacct は、フローを監視し、テーブルにフローレコードを記録します。次に flowacct は、timer に指定された間隔でパラメータと属性を評価します。last_seen 値に timeout 値を加えた時間以上パケットが検出されない場合、パケットはタイムアウトします。タイムアウトしたエントリはすべて、フローテーブルから削除されます。削除されたタイムアウトエントリは、timer パラメータに指定された時間が経過するたびに、アカウンティングファイルに書き込まれます。
acctadm を呼び出して flowacct モジュールで使用するには、次の構文を使用します。
acctadm -e type -f filename flow
acctadm -e |
acctadm を -e オプションを指定して呼び出す。-e は、直後にタイプを指定することを示す |
type |
収集するタイプを指定する。file-type は、basic または extended に置き換える必要がある。各ファイルタイプの属性については、表 6–4 を参照 |
-f file_name |
フローレコードを格納するファイル file_name を作成する |
flow |
acctadm を IPQoS 上で実行することを示す |
この節では、IPQoS 構成ファイル各部の詳細を説明します。IPQoS のブート時にアクティブになるポリシーは、/etc/inet/ipqosinit.conf ファイルに格納されています。このファイルは編集可能ですが、新しい IPQoS システムの場合、別の名前で構成ファイルを作成するのが最善の方法です。IPQoS 構成の適用作業およびデバッグ作業については、第 4 章「IPQoS の起動と保守(手順)」を参照してください。
次の例に、IPQoS 構成ファイルの構文を示します。この例では、次の表記上の規則に従います。
computer-style type - 構成ファイル各部を説明する構文情報。このテキストは、入力しない
bold type - IPQoS 構成ファイルに入力する必要のあるリテラルテキスト。たとえば、IPQoS 構成ファイルは、常に fmt_version で始める必要がある
italics type - 構成に関する記述的情報に置き換える可変テキスト。たとえば、action_name または module_name は、常に構成に関する情報で置き換える必要がある
file_format_version ::= fmt_version version action_clause ::= action { name action_name module module_name params_clause | "" cf_clauses } action_name ::= string module_name ::= ipgpc | dlcosmk | dscpmk | tswtclmt | tokenmt | flowacct params_clause ::= params { parameters params_stats | "" } parameters ::= prm_name_value parameters | "" prm_name_value ::= param_name param_value params_stats ::= global_stats boolean cf_clauses ::= class_clause cf_clauses | filter_clause cf_clauses | "" class_clause ::= class { name class_name next_action next_action_name class_stats | "" } class_name ::= string next_action_name ::= string class_stats ::= enable_stats boolean boolean ::= TRUE | FALSE filter_clause ::= filter { name filter_name class class_name parameters } filter_name ::= string
以下では、IPQoS 構成ファイルの各主要部分について説明します。
action 文を使用して、IPQoS アーキテクチャと diffserv モデルに示されたさまざまな IPQoS モジュールを呼び出します。
IPQoS 構成ファイルを新規作成する場合、必ずバージョン番号から始める必要があります。ついで、次のアクションを追加して、クラシファイアを呼び出す必要があります。
fmt_version 1.0 action { module ipgpc name ipgpc.classify } |
action { name action_name module module_name params_clause | "" cf_clauses }
文 |
定義 |
---|---|
name action_name |
アクションに名前を付ける |
module module_name |
呼び出す IPQoS モジュールを特定する。モジュールは、表 6–5 に示したモジュールのどれかでなければならない |
params_clause |
クラシファイアが処理するパラメータ (グローバル統計、次に処理するアクションなど) を指定する |
cf_clauses |
クラス句またはフィルタ句のゼロ以上のセット |
モジュール定義は、アクション文のパラメータを処理するモジュールを示します。IPQoS 構成ファイルには、次のモジュールを含めることができます。
表 6–5 IPQoS モジュール
モジュール名 |
定義 |
---|---|
ipgpc |
IP クラシファイア |
dscpmk |
IP パケット内で DS コードポイント作成に使用するマーカー |
dlcosmk |
VLAN デバイスで使用するマーカー |
tokenmt |
トークンバケットメーター |
tswtclmt |
タイムスライディングウィンドウメーター |
flowacct |
フローアカウンティングモジュール |
IPQoS 構成内の残りのクラスを定義するには、次の構文を使用します。
class { name class_name next_action next_action_name } |
特定のクラスに関する統計情報取得を有効にするには、最初に ipgpc.classify アクション文でグローバル統計を有効にする必要があります。詳細については、アクション文を参照してください。
クラスに関する統計を有効にしたいときは、enable_stats TRUE 文を使用します。 クラスの統計を収集する必要がない場合は、enable_stats FALSE を指定します。あるいは、 enable_stats 文を削除してもかまいません。
IPQoS 対応ネットワーク上のトラフィックは、特に定義しなければ「デフォルトクラス」になります。
フィルタは、トラフィックフローをクラスに分類するセレクタで構成されます。これらのセレクタは、クラス句で作成されたクラスのトラフィックへ適用する条件を、明確に定義します。パケットがもっとも高い優先順位のフィルタのセレクタすべてに一致する場合、パケットはそのフィルタのクラスのメンバーと見なされます。ipgpc クラシファイアで使用可能なセレクタについては、表 6–1 を参照してください。
IPQoS 構成ファイル内でフィルタを定義するには、「フィルタ句」を使用します。フィルタ句の構文を次に示します。
filter { name filter_name class class_name parameters (selectors) }
params 句には、アクション文で定義されたモジュールの処理方法が含まれます。params 句の構文を次に示します。
params { parameters params_stats | "" } |
params 句では、モジュールに適用するパラメータを使用します。
params 句の params_stats 値は、global_stats TRUE または global_stats FALSE になります。global_stats TRUE 命令は、グローバル統計を呼び出したアクション文に関する UNIX スタイルの統計を有効にします。kstat コマンドを使用して、統計情報を表示できます。クラス単位の統計を有効にする前に、アクション文の統計を有効にする必要があります。
IPQoS 構成ファイルを読んだり、UNIX カーネル内の IPQoS モジュールを構成したりするには、ipqosconf ユーティリティを使用します。ipqosconf では、次のアクションを実行できます。
構成ファイルを IPQoS カーネルモジュールに適用する ( ipqosconf -a filename)
カーネル内に現在常駐している IPQoS 構成ファイルを表示する (ipqosconf -l)
マシンをリブートするたびに、現行の IPQoS 構成を読み取り、適用するようにする (ipqosconf -c)
現行の IPQoS カーネルモジュールをフラッシュする (ipqosconf -f)
技術情報については、ipqosconf(1M) のマニュアルページを参照してください。