このパートには、Oracle Solaris での差別化サービス実装である IP サービス品質 (IPQoS) に関する作業と関連情報を記載します。
IP サービス品質 (IPQoS) を使用すると、優先順位付け、管理、およびアカウンティング統計情報の収集を行うことができます。IPQoS によって、ネットワークのユーザーに一貫したサービスレベルを提供できます。また、ネットワークの輻輳を防ぐために、トラフィックを管理することもできます。
この章では、次の内容について説明します。
IPQoS は、Internet Engineering Task Force (IETF) の Differentiated Services Working Group によって定義されている差別化サービス (Diffserv) アーキテクチャーに対応しています。Oracle Solaris では、TCP/IP プロトコルスタックの IP レベルで IPQoS が実装されます。
IPQoS を有効にすることで、選択した顧客および選択したアプリケーションに対して、異なるレベルのネットワークサービスを提供できます。この異なるレベルのサービスは、まとめて「差別化サービス」と呼ばれます。顧客に提供する差別化サービスは、ユーザーの企業が顧客に提供するサービスレベルの構造を基に決定できます。ネットワーク上のアプリケーションやユーザーに設定した優先順位に基づく場合もあります。
顧客や企業内の部署などのグループごとに異なるサービスレベルを提供する
特定のグループやアプリケーションにネットワークサービスを優先的に提供する
ネットワーク上の障害やその他の輻輳の発生箇所を特定し、問題を取り除く
ネットワークパフォーマンスを監視し、パフォーマンスの統計情報を提供する
ネットワーク資源に対する帯域幅を調整する
ipqosconf QoS ポリシーを設定するためのコマンド行ツール
アクションを選択するクラシファイア。アクションは、組織の QoS ポリシーを設定するフィルタに基づいている
Diffserv モデルに従ってネットワークトラフィックを測定するメータリングモジュール
パケットの IP ヘッダーに転送情報を付ける機能に基づく、サービスの差別化
トラフィックフローの統計情報を収集するフローアカウンティングモジュール
UNIX® の kstat コマンドによる、トラフィッククラスごとの統計情報の収集
SPARC® および x86 アーキテクチャーのサポート
IPv4 および IPv6 アドレス指定のサポート
IP セキュリティーアーキテクチャーの相互運用性 (IPsec)
仮想ローカルエリアネットワーク (VLAN) の 802.1D ユーザー優先順位マークのサポート
差別化サービスやサービス品質の詳細情報は、印刷物やオンラインで入手できます。
サービス品質の理論や実践については、次の関連書籍を参照してください。
Ferguson, Paul および Geoff Huston 著『Quality of Service』John Wiley & Sons, Inc. 発行、1998 年
Kilkki, Kalevi 著『Differentiated Services for the Internet 』Macmillan Technical Publishing 発行、1999 年
IPQoS は、次の RFC および Internet Draft の仕様に準拠しています。
RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers – 差別化サービスをサポートするための、IPv4 や IPv6 パケットヘッダーのサービスタイプ (ToS) フィールドまたは DS フィールドの拡張を説明している
RFC 2475, An Architecture for Differentiated Services – Diffserv アーキテクチャーの構成とモジュールについて詳細に解説している
RFC 2597, Assured Forwarding PHB Group – 相対的優先転送 (AF) ホップ単位動作について解説している
RFC 2598, An Expedited Forwarding PHB – 完全優先転送 (EF) ホップ単位動作について解説している
インターネットドラフト「An Informal Management Model for Diffserv Routers」 – ルーター上に Diffserv アーキテクチャーを実装するためのモデルを紹介している
IETF の Differentiated Services Working Group は、Diffserv Internet Draft へのリンクを含む Web サイト (http://www.ietf.org/html.charters/diffserv-charter.html) を管理しています。
Cisco Systems 社や Juniper Networks 社などのルーター製造元は、それぞれ自社の Web サイトで、差別化サービスの製品への実装状況について解説しています。
ipqosconf(1M) - IPQoS 構成ファイルを設定するコマンドについて説明する
ipqos(7ipp) – Diffserv アーキテクチャーモデルの IPQoS 実装について説明する
ipgpc(7ipp) – Diffserv クラシファイアの IPQoS 実装について説明する
tokenmt(7ipp) – IPQoS の tokenmt メーターについて説明する
tswtclmt(7ipp) – IPQoS の tswtclmt メーターについて説明する
dscpmk(7ipp) – DSCP マーカーモジュールについて説明する
dlcosmk(7ipp) – IPQoS 802.1D ユーザー優先順位マーカーモジュールについて説明する
flowacct(7ipp) – IPQoS フローアカウンティングモジュールについて説明する
acctadm(1M) – Oracle Solaris 拡張アカウンティング機能を構成するコマンドについて説明する。acctadm コマンドには、IPQoS の拡張が含まれます。
IPQoS 機能を使用すると、インターネットサービスプロバイダ (ISP) やアプリケーションサービスプロバイダ (ASP) は、顧客ごとに異なるレベルのネットワークサービスを提供できます。同様に、一般企業や教育機関では、この機能を使って内部組織向けのサービスや主要なアプリケーションのサービスを優先できます。
ISP や ASP では、顧客に提示する「サービスレベル契約 (Service-Level Agreement、SLA)」に基づいて IPQoS の構成を行うことができます。個々の SLA では、サービスプロバイダは、価格体系に基づいた一定レベルのネットワークサービスを顧客に保証します。たとえば、プレミアム価格の SLA では、顧客はすべての種類のネットワークトラフィックに対して毎日 24 時間もっとも高い優先順位が与えられます。逆に、中ぐらいの価格の SLA では、業務時間に電子メールだけに高い優先順位が保証されている場合もあります。ほかのトラフィックはすべて、一日 24 時間、中ぐらいの優先順位になります。
一般企業や法人である場合でも、ネットワークにサービス品質機能を提供できます。つまり、特定のグループまたは特定のアプリケーションのトラフィックに対して高レベルまたは低レベルのサービスを保証できます。
サービス品質を実装するには、「サービス品質 (Quality-of-Service、QoS) ポリシー」を定義します。QoS ポリシーでは、顧客またはアプリケーションの優先順位、さまざまなカテゴリのトラフィックを処理するアクションなど、各種のネットワーク属性を定義します。組織の QoS ポリシーは IPQoS 構成ファイルに実装します。このファイルは、Oracle Solaris のカーネルに入っている IPQoS モジュールを構成します。IPQoS ポリシーが適用されているホストは、「IPQoS 対応システム」とみなされます。
「サービスクラス」と呼ばれるネットワークトラフィックの個別グループ
クラスごとにネットワークトラフィックの量を調整するための測定基準。これらの測定基準によって、「メータリング」と呼ばれるトラフィック測定プロセスが管理される
IPQoS システムおよび Diffserv ルーターがパケットフローに適用するアクション。このアクションは「ホップ単位動作 (PHB)」と呼ばれる
サービスのクラスで必要な統計の収集。たとえば、顧客または特定のアプリケーションが生成したトラフィックなどがある
パケットがネットワークに渡されると、IPQoS 対応システムはパケットヘッダーを評価します。IPQoS システムが行うアクションは、作成した QoS ポリシーに応じて決まります。
QoS ポリシーの設計作業については、「サービス品質ポリシーの計画」に説明があります。
IPQoS には、サービス品質の実装に伴ってネットワークパフォーマンスの効率を向上させるのに役立ついくつかの機能が含まれています。コンピュータネットワークが拡大すると、ユーザーや高機能なプロセッサの数が増加して、生成されるネットワークトラフィックを管理する必要性も増大します。ネットワークを過度に使用すると、データの消失やトラフィックの輻輳などの症状が現れます。どちらの症状も応答時間を遅らせます。
従来、システム管理者は帯域幅を拡張する方法でネットワークトラフィックの問題に対処してきました。しかし同時に、リンクごとのトラフィックのレベルには、大きなばらつきが見られがちでした。IPQoS を使用すると、既存のネットワーク上のトラフィックを管理しながら、ネットワークの拡大が必要かどうか、またどこに必要かを評価できます。
たとえば、企業や法人の場合は、効率的なネットワークを維持して、トラフィックに関する障害の発生を防ぐ必要があります。また、グループやアプリケーションが割り当てられた以上の帯域幅を消費しないようにする必要もあります。ISP や ASP は、顧客が料金分のレベルのネットワークサービスを確実に受けられるようにネットワークパフォーマンスを管理する必要があります。
IPQoS を使用すると、ネットワークの「帯域幅」、つまりネットワークリンクまたはデバイスが完全に使用された場合に転送できるデータの最大量を調整できます。サービス品質を顧客またはユーザーに提供するには、QoS ポリシーで、帯域幅の使用に優先順位を付ける必要があります。IPQoS のメータリングモジュールを使用すると、IPQoS 対応ホスト上の各トラフィッククラスへの帯域幅の割り当て量を測定および管理できます。
ネットワーク上のトラフィックを効果的に管理するには、帯域幅の使用量に関して、次の点を明らかにしておく必要があります。
ローカルネットワークのトラフィック問題の発生箇所はどこか
帯域幅を最適利用するために行うべきことは何か
サイト内で最優先するべき、重要なアプリケーションはどれか
輻輳が発生しやすいアプリケーションはどれか
優先順位を落としてもよい、重要度の低いアプリケーションはどれか
サービス品質を実現するには、ネットワークトラフィックを分析して、トラフィックを分類する大まかなグループ分けを決定します。次に、それぞれ特徴と優先順位を持つサービスクラスに各グループ分けを整理します。これらのクラスが基本的なカテゴリとなり、それに基づいて組織の QoS ポリシーを作成します。サービスクラスは、管理の対象となるトラフィックグループを代表します。
たとえば、プロバイダがプラチナ、ゴールド、シルバー、ブロンズの各レベルのサービスをそれぞれ異なる利用料金で提供するとします。プラチナレベルの SLA では、プロバイダが顧客用に運営している Web サイト宛ての着信トラフィックに対して、もっとも高い優先順位を保証します。このように、ある顧客の Web サイト宛ての着信トラフィックを 1 つのトラフィッククラスとしてまとめることができます。
企業向けには、部門の要求に基づくサービスクラスを作成できます。また、ネットワークトラフィック内の特定のアプリケーションの優位性に基づくクラスを作成することもできます。次に、企業向けのトラフィッククラスの例をいくつか示します。
特定のサーバー宛ての電子メールや発信 FTP などの、よく使われるアプリケーション。アプリケーションごとに 1 つのクラスを構成できる。これらのアプリケーションは従業員によって絶えず使用されるため、QoS ポリシーで、電子メールと発信 FTP には少量の帯域幅と低い優先順位を割り当てる
一日 24 時間実行の必要がある注文入力データベース。企業にとってのデータベースアプリケーションの重要度に応じて、大量の帯域幅と高い優先順位を割り当てる
人事部門などの、極めて重要な業務または機密業務を行う部署。組織にとっての部署の重要度に応じて、割り当てる優先順位と帯域幅の大きさを決める
IPQoS には次のモジュールがあります。これらのモジュールは、RFC 2475 に定義されている「差別化サービス (diffserv)」アーキテクチャーの一部です。
クラシファイア
メーター
マーカー
IPQoS では、次の拡張機能が Diffserv モデルに追加されています。
フローアカウンティングモジュール
802.1D データグラムマーカー
この節では、IPQoS で使用する Diffserv モジュールについて簡単に説明します。QoS ポリシーを設定するには、これらのモジュール、その名前、およびその使用目的を認識しておく必要があります。各モジュールの詳細は、「IPQoS アーキテクチャーと Diffserv モデル」を参照してください。
Diffserv モデルでは、「クラシファイア」がネットワークトラフィックフローからパケットを選択します。「トラフィックフロー」は、次の IP ヘッダーフィールド内に同一の情報を持つパケットのグループで構成されます。
IPQoS では、これらのフィールドを「5 タプル」と呼びます。
IPQoS のクラシファイアモジュールの名前は ipgpc です。ipgpcクラシファイアは、トラフィックフローを、IPQoS 構成ファイルに設定されている特性に基づいたクラスに分類します。
ipgpc の詳細については、「クラシファイアモジュール」を参照してください。
「クラス」とは、似たような特性を共有するネットワークフローのグループのことです。たとえば、ISP は、顧客に提供するさまざまなサービスレベルを表すクラスを定義できます。一方、ASP は、アプリケーションごとに異なるサービスレベルを提供する SLA を定義できます。ASP の QoS ポリシーでは、特定の着信先 IP アドレス宛ての発信 FTP トラフィックを 1 つのクラスにまとめることができます。ある企業の外部 Web サイトからの発信トラフィックも、1 つのクラスとして定義できます。
トラフィックをいくつかのクラスに分類することは、QoS ポリシーを計画する際に欠かせない作業の 1 つです。ipqosconf ユーティリティーを使用してクラスを作成するときは、実際にはipgpc クラシファイアを構成しています。
クラスを定義するには、「QoS ポリシーのクラスを定義する方法」を参照してください。
「フィルタ」は、「セレクタ」と呼ばれるパラメータを含む規則のセットです。各フィルタは、必ず 1 つのクラスを指定する必要があります。IPQoS は、パケットを各フィルタのセレクタと突き合わせて、パケットがフィルタのクラスに属しているかどうかを調べます。さまざまなセレクタを使用してパケットにフィルタをかけることができます。セレクタの例として、IPQoS 5 タプルなどのよく使うパラメータを次に示します。
発信元および着信先のアドレス
発信先および着信先のポート
プロトコル番号
ユーザー ID
プロジェクト ID
差別化サービスコードポイント (DSCP)
インタフェースインデックス
たとえば、簡単なフィルタに値が 80 の宛先ポートが含まれているとします。ipgpc クラシファイアは、宛先ポート 80 (HTTP) 向けのパケットをすべて選択し、QoS ポリシーの指示どおりに選択したパケットを処理します。
フィルタの作成については、「QoS ポリシーにフィルタを定義する方法」を参照してください。
Diffserv モデルでは、「メーター」はトラフィックフローの転送速度をクラス単位で追跡します。メーターは、該当する結果 (outcome) を得るために、フローの実際の転送速度が設定された速度にどれだけ適合しているかを評価します。そして、トラフィックフローの結果に基づいて、次のアクションを選択します。次のアクションでは、パケットを別のアクションに送信したり、それ以上処理しないでネットワークに戻したりできます。
IPQoS のメーターは、ネットワークフローが、QoS ポリシーでそのクラスに定義されている転送速度に適合しているかどうかを調べます。IPQoS には、次の 2 つのメータリングモジュールがあります。
どちらのメータリングモジュールも、 赤、黄、緑という 3 つの結果を識別します。結果ごとに実行させたいアクションは、red_action_name、yellow_action_name、および green_action_name のパラメータで定義します。
また、tokenmt をカラーアウェアとして構成することもできます。カラーアウェアとして構成されているメータリングインスタンスでは、パケットのサイズ、DSCP、トラフィックの転送速度、および設定されたパラメータを使って結果を求めます。メーターは、DSCP を使用してパケットの結果を緑、黄、赤にマッピングします。
IPQoS メーターのパラーメータの定義については、「フロー制御を計画する方法」を参照してください。
Diffserv モデルでは、「マーカー」は転送動作を表す値をパケットに付けます。「マーキング」とは、パケットをネットワークに転送する方法を示す値を、そのパケットのヘッダーに付加するプロセスのことです。IPQoS には、次の 2 つのマーカーモジュールが含まれています。
dscpmk – IP パケットヘッダーの DS フィールドに「差別化サービスコードポイント (DSCP)」と呼ばれる数値を付けます。Diffserv 対応ルーターは、この DS コードポイントを使って、適切な転送動作をパケットに適用できます。
dlcosmk – Ethernet フレームヘッダーの仮想ローカルエリアネットワーク (VLAN) タグに「ユーザー優先順位」と呼ばれる数値を付けます。ユーザー優先順位は、データグラムに適用される適切な転送動作を定義する「サービスクラス (CoS)」のことです。
dlcosmk は、IPQoS の追加機能として IETF によって設計されたものであり、Diffserv モデルの一部ではありません。
QoS ポリシーのマーカー戦略の実装については、「転送動作を計画する方法」を参照してください。
IPQoS では、flowacct アカウンティングモジュールが Diffserv モデルに追加されています。flowacct を使用すると、トラフィックフローに関する統計情報を取得し、SLA に合わせて顧客に課金できます。フローアカウンティングは、容量計画やシステムの監視にも役立ちます。
flowacct モジュールを acctadm コマンドと組み合わせて、アカウンティングログファイルを作成できます。基本的なログには、次に示すように、IPQoS 5 タプルのほかに 2 つの属性が記録されます。
発信元アドレス
発信元ポート
着信先アドレス
着信先ポート
プロトコル番号
パケット数
バイト数
「トラフィックフローに関する情報の記録」および flowacct(7ipp) や acctadm(1M) のマニュアルページに説明されているとおり、その他の属性の統計を集めることもできます。
フローアカウンティング戦略の計画については、「フローアカウンティングを計画する方法」を参照してください。
次の図は、着信トラフィックが IPQoS モジュールのいくつかを通過するときに取りうる経路を示しています。
この図は、IPQoS 対応マシンにおける一般的なトラフィックフローシーケンスを示しています。
クラシファイアが、システムの QoS ポリシーのフィルタリング条件に適合するすべてのパケットをパケットストリームから選択します。
選択したパケットが評価されて、次に実行されるアクションが決められます。
クラシファイアが、フロー制御を必要としないトラフィックをマーカーに送信します。
フロー制御が必要なトラフィックは、メーターに送信されます。
メーターは、設定速度を実施します。次に、トラフィックの適合値をフロー制御されているパケットに割り当てます。
フロー制御されるパケットが評価されて、アカウンティングが必要であるかどうかが判断されます。
メーターが、フローアカウンティングを必要としないトラフィックをマーカーに送信します。
フローアカウンティングモジュールが、受信したパケットに関する統計情報を収集します。次に、それらのパケットをマーカーに送信します。
マーカーが DS コードポイントをパケットヘッダーに割り当てます。この DSCP は、Diffserv 対応システムがパケットに適用するべきホップ単位動作 (PHB) を示します。
この節では、IPQoS 対応ネットワークでのパケット転送に関係するいくつかの要素について簡単に説明します。IPQoS 対応システムは、着信先としてそのシステムの IP アドレスを持つ、ネットワークストリーム上のパケットを処理します。そして、IPQoS システムの QoS ポリシーをパケットに適用して、差別化サービスを確立します。
DS コードポイント (DSCP) は、マークされたパケットに対して Diffserv 対応システムが実行するアクションをパケットヘッダーに定義します。diffserv アーキテクチャーは、使用する IPQoS 対応システムと diffserv ルーターに対して一連の DS コードポイントを定義します。また、DSCP に対応する「転送動作」と呼ばれる一連の処理も定義します。IPQoS 対応システムは、パケットヘッダーにある DS フィールドの優先度ビットに DSCP を付けます。DSCP 値を持つパケットを受信すると、ルーターは、その DSCP と関連付けられた転送動作を実行します。次にパケットはネットワーク上に送出されます。
dlcosmk マーカーは、DSCP を使用しません。代わりに、Ethernet フレームヘッダーに CoS 値を付加します。VLAN デバイスを使用するネットワークで IPQoS を構成する予定の場合は、「マーカーモジュール」を参照してください。
Diffserv 用語では、DSCP に割り当てられる転送動作を「ホップ単位動作 (Per-Hop Behavior、PHB)」と呼びます。PHB は、Diffserv 対応システム上で、マークされたパケットの転送がほかのトラフィックに比べて優先される度合いを定義します。この優先度によって、IPQoS 対応システムまたは Diffserv ルーターが、マークされたパケットを転送するかドロップするかが最終的に決まります。パケットが転送された場合、パケットがその着信先への途中で通過する各 Diffserv ルーターは、同じ PHB をそのパケットに適用します。ただし、別の Diffserv システムによって DSCP が変更された場合は例外です。PHB の詳細については、「パケット転送での dscpmk マーカーの使用」を参照してください。
PHB の目的は、指定された量のネットワーク資源を連続したネットワーク上のトラフィッククラスに提供することです。この目的は、QoS ポリシーで達成できます。トラフィックフローが IPQoS 対応システムを離れたときのトラフィッククラスの優先順位を示す DSCP を定義します。優先度は、高い優先度 (ドロップ率が低い) から低い優先度 (ドロップ率が高い) の範囲になります。
たとえば、QoS ポリシーによってあるトラフィッククラスにドロップ率が低い PHB を保証する DSCP 割り当てることができます。このトラフィッククラスは、ドロップ率が低い優先度の PHB をすべての Diffserv 対応ルーターから与えられ、このクラスのパケットの帯域幅が保証されます。QoS ポリシーに別の DSCP を追加して、ほかのトラフィッククラスにさまざまなレベルの優先度を割り当てることもできます。優先度の低いパケットには、パケットの DSCP に示された優先順位に応じた帯域幅を、Diffserv システムが割り当てます。
IPQoS は、Diffserv アーキテクチャーに定義されている 2 種類の転送動作、完全優先転送 (EF) と相対的優先転送 (AF) をサポートしています。
「完全優先転送 (Expedited Forwarding、EF)」PHB は、EF 関連の DSCP を持つトラフィッククラスが一番高い優先順位を割り当てられることを保証します。EF DSCP のトラフィックは、キューに格納されません。EF では、低損失、低遅延、低ジッターのサービスを提供します。EF の推奨 DSCP は、101110 です。101110 が付加されたパケットは、着信先への途中で Diffserv 対応ネットワークを通過するときに、ドロップ率の低い優先度を与えられます。EF DSCP は、プレミアム SLA を持つ顧客またはアプリケーションに優先順位を割り当てるときに使用してください。
「相対的優先転送 (Assured Forwarding、AF)」PHB には、パケットに割り当てられる転送クラスが 4 種類あります。表 37–2 に示すように、各転送クラスは 3 つのドロップ優先順位を提供します。
AF コードポイントには、顧客やアプリケーションにさまざまなレベルのサービスを割り当てる機能があります。QoS ポリシーでは、QoS ポリシーを計画するときに、ネットワーク上のトラフィックやサービスに優先順位を付けておきます。そうすれば、優先順位の付いたトラフィックにそれぞれ異なる AF レベルを割り当てることができます。
次の図は、Diffserv 対応環境を部分的に備えた企業のイントラネット部分を示しています。このシナリオでは、ネットワーク 10.10.0.0 および 10.14.0.0 上のホストはすべて IPQoS に対応しており、ローカルルーターは Diffserv に対応しています。しかし、間にある 2 つのネットワークは Diffserv に対応していません。
次の手順は、前の図に示すパケットの流れをたどっています。この手順は、ホスト ipqos1 で発生するパケットの前進で開始されます。手順は数回のホップでホスト ipqos2 に続きます。
ipqos1 のユーザーが ftp コマンドを実行して、3 ホップ離れたところにあるホスト ipqos2 にアクセスしようとします。
ipqos1 は、結果生じたパケットフローに QoS ポリシーを適用します。ipqos1 は、ftp トラフィックを正常に分類します。
システム管理者は、ローカルネットワーク 10.10.0.0 で発生するすべての発信 ftp トラフィックのためのクラスを作成しています。ftp クラスのトラフィックには、次のような AF22 ホップ単位動作を割り当てます。 クラス 2、標準ドロップ優先順位ftp クラスには、2Mb/秒のトラフィックフロー速度が設定されます。
ipqos-1 は、ftp フローを測定し、フローが 2 Mbit/秒を超過していないかどうかを判断します。
ipqos1 上のマーカーが、発信 ftp パケットの DS フィールドに 010100 DSCP (AF22 PHB に対応している) を付加します。
ルーター diffrouter1 は、ftp パケットを受信します。次に、DSCP をチェックします。diffrouter1 が輻輳している場合、AF22 でマークされているパケットは振り落とされます。
diffrouter1 のファイルで AF22 に対して設定されている PHB に合わせて、ftp トラフィックが次のホップに転送されます。
ftp トラフィックがネットワーク 10.12.0.0 を通って genrouter に進みます。genrouter は Diffserv に対応していません。その結果、トラフィックはベストエフォートの転送動作を与えられます。
genrouter が ftp トラフィックをネットワーク 10.13.0.0 に渡し、diffrouter2 がそのトラフィックを受け取ります。
diffrouter2 は Diffserv に対応しています。したがって、ルーターのポリシーで AF22 パケットに対して定義されている PHB に合わせて、ftp パケットをネットワークに転送します。
ipqos2 は、ftp トラフィックを受信します。 ipqos2 は、ipqos1 のユーザーにユーザー名とパスワードの入力を促します。
Oracle Solaris が動作する任意のシステムで IPQoS を構成できます。そして、IPQoS システムを Diffserv 対応ルーターと組み合わせると、イントラネット上で差別化サービスを提供したり、トラフィック管理を行うことができます。
この章では、IPQoS 対応システムを Diffserv 対応ネットワークに追加するための計画作業について説明します。この章の内容は次のとおりです。
IPQoS などの差別化サービスをネットワーク上に実装する場合は、綿密な計画が必要です。各 IPQoS 対応システムの位置と機能だけではなく、各システムとローカルネットワーク上のルーターとの関係についても考慮してください。次の作業マップに、ネットワーク上で IPQoS を実装するための主な計画作業の一覧と、各作業を完了するための手順へのリンクを示します。
作業 |
説明 |
説明 |
---|---|---|
1. IPQoS 対応システムを取り入れた Diffserv ネットワークトポロジを計画する |
さまざまな Diffserv ネットワークトポロジを考慮して、自分のサイトにもっとも適したソリューションを考える | |
2. IPQoS システムによって提供する各種サービスを計画する |
ネットワークが提供するサービスの種類をいくつかの サービスレベル契約 (service-level agreement、SLA) に分類する | |
3. IPQoS システムごとに QoS ポリシーを計画する |
各 SLA の実装に必要なクラス、メータリング、およびアカウンティング機能を決める | |
4. 必要であれば、Diffserv ルーターのポリシーを計画する |
IPQoS システムで使用する Diffserv ルーターのスケジューリングポリシーおよびキューイングポリシーを決める |
キューイングポリシーおよびスケジューリングポリシーについては、ルーターのマニュアルを参照 |
ネットワークに差別化サービスを提供するには、IPQoS 対応システムが最低 1 つと Diffserv 対応ルーターが 1 台必要です。この節で説明するように、この基本構成はさまざまな方法で拡張できます。
一般に、IPQoS はサーバーやサーバー統合 (Sun Sun Enterprise™ 0000 サーバーなど) 上で実行します。一方、ネットワークのニーズに応じて、UltraSPARC® システムなどのデスクトップシステムで IPQoS を実行することもできます。次に、IPQoS 構成に使用できるシステムの例を示します。
Oracle Solaris システム。Web サーバーやデータベースサーバーなどの各種サービスを提供する
アプリケーションサーバー。電子メール、FTP などのよく使われるネットワークアプリケーションを提供する
Web キャッシュサーバーまたはプロキシサーバー
IPQoS 対応サーバーファームのネットワーク。Diffserv 対応ロードバランサによって管理される
ファイアウォール。単一の異機種システム混在ネットワークのトラフィックを管理する
仮想ローカルエリアネットワーク (LAN) の一部である IPQoS システム
IPQoS システムを導入しようとするネットワークトポロジでは、Diffserv 対応ルーターがすでに機能していることもありえます。もし、現在使用しているルーターが Diffserv に対応していない場合は、Cisco Systems 社や Juniper Networks 社などのルーター製造元が提供する Diffserv のソリューションを検討してください。ローカルルーターが Diffserv を実装していないと、パケットのマークは評価されずに次のホップへ渡されてしまいます。
この節では、ネットワーク上のさまざまなニーズを満たす IPQoS 計画を図で説明します。
次の図は、IPQoS 対応システムの単一ネットワークを示しています。
このネットワークは、ある企業のイントラネットの一部分です。アプリケーションサーバーや Web サーバーで IPQoS を有効にすると、各 IPQoS システムが発信トラフィックを送出する速度を制御できます。ルーターが Diffserv に対応していれば、着信トラフィックおよび発信トラフィックをさらに制御できます。
このマニュアルで取り上げる例では、「個々のホストでの IPQoS 」シナリオを使用します。このマニュアルを通して使用されているサンプルトポロジについては、図 33–4 を参照してください。
次の図には、複数の異種サーバーファームを備えるネットワークを示します。
このようなトポロジでは、ルーターが Diffserv に対応しているため、着信トラフィックと発信トラフィックの両方をキューに入れたり評価したりできます。また、ロードバランサも Diffserv 対応システムであるため、サーバーファームは IPQoS 対応となります。ロードバランサは、ユーザー ID やプロジェクト ID などのセレクタを使用することによって、ルーター以外で追加フィルタリングを提供できます。これらのセレクタは、アプリケーションデータに含まれます。
このシナリオでは、フロー制御とトラフィック転送を行って、ローカルネットワーク上の輻輳を管理しています。また、このシナリオでは、サーバーファームからの発信トラフィックが原因でイントラネットのほかの部分が過負荷状態になるのを防いでいます。
次の図は、ファイアウォールによってほかのセグメントから保護されている、企業ネットワークのセグメントの 1 つを示しています。
このシナリオでは、トラフィックはまず Diffserv 対応ルーターに入り、そこでフィルタにかけられ、キューに入れられます。次に、ルーターによって転送された着信トラフィックはすべて、IPQoS 対応のファイアウォールに進みます。IPQoS を使用するには、ファイアウォールで IP 転送スタックをバイパスしないでください。
ファイアウォールのセキュリティーポリシーによって、着信トラフィックを内部ネットワークに入れて良いかどうかが決まります。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 ポリシーを計画するための主な作業の一覧と、各作業の実行手順へのリンクを示します。
作業 |
説明 |
説明 |
---|---|---|
1. IPQoS をサポートするようネットワークトポロジを設計する |
差別化サービスを提供するネットワーク上のホストとルーターを特定する | |
2. ネットワーク上のサービスを分類するためのクラスを定義する |
自分のサイトで提供するサービスの種類と SLA を調べ、これらのサービスを分類するためのトラフィッククラスを決める | |
3. クラス用のフィルタを定義する |
特定のトラフィッククラスをネットワークトラフィックフローから取り出すための最善の方法を決める | |
4. IPQoS システムから送出されるトラフィックを測定するためのフロー制御速度を定義する |
トラフィッククラスごとに容認できるフロー速度を決める | |
5. QoS ポリシーで使用する DSCP すなわちユーザー優先順位の値を定義する |
トラフィックフローがルーターまたはスイッチによって処理されるときに割り当てられる転送動作を決める方法を計画する | |
6. 必要であれば、ネットワーク上のトラフィックフローに対する統計監視計画を設定する |
トラフィッククラスを評価して、アカウンティングまたは統計上の目的で監視するトラフィックフローを決める |
この節の残りの部分では、IPQoS 対応システムの QoS ポリシーを計画する方法について説明します。Diffserv ルーター向けの QoS ポリシーの計画を立てるには、ルーターのマニュアルおよびルーター製造元の Web サイトを参照してください。
次の手順では、QoS ポリシーを作成する前に行う一般的な計画作業を示します。
ネットワークトポロジを見直します。次に、IPQoS システムと Diffserv ルーターを使用する戦略の計画を作成します。
トポロジの例は、「diffserv ネットワークトポロジの計画」を参照してください。
IPQoS を必要とするホスト、または IPQoS サービスの有力な候補となるホストをトポロジで特定します。
IPQoS 対応後に同じ QoS ポリシーを共用できそうなシステムを調べます。
たとえば、ネットワーク上のすべてのホストで IPQoS を有効にする場合は、同じ QoS ポリシーを使用できるホストをすべて特定します。各 IPQoS 対応システムにはローカル QoS ポリシーが必要で、そのポリシーはそれぞれの IPQoS 構成ファイルに実装されます。ただし、IPQoS 構成ファイルを 1 つだけ作成し、これを同じ QoS ポリシー要件を持つすべてのシステムにコピーして使うこともできます。
ネットワーク上の Diffserv ルーターに対して必要な計画作業をすべて確認し、実行します。
詳細については、ルーターのマニュアルとルーター製造元の Web サイトを参照してください。
QoS ポリシーを定義するための最初の手順は、トラフィックフローをクラスに整理することです。Diffserv ネットワーク上のトラフィックの種類ごとにクラスを作成する必要はありません。また、計画したネットワークトポロジによっては、IPQoS 対応システムごとに異なる QoS ポリシーを作成する必要があります。
クラスの概要は、「IPQoS クラス」を参照してください。
次の手順では、「IPQoS 用のネットワークを準備する方法」に従って、IPQoS 対応とするネットワーク上のシステムを決定済みであることを前提としています。
QoS ポリシー情報を整理する QoS 計画テーブルを作成します。
提案については、表 33–1 を参照してください。
ネットワーク上にあるすべての QoS ポリシーについて、残りの手順を実行します。
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 を提供している場合は、アカウンティングを必要とするトラフィックのクラスはおそらく作成済みです。また、クラスを定義して、監視しているトラフィックフローの統計収集を可能にすることもできます。さらに、セキュリティー上の理由でアクセスを制限するトラフィックのクラスも作成できます。
手順 1 で作成した QoS 計画テーブルで定義したクラスを一覧にします。
優先レベルを各クラスに割り当てます。
たとえば、優先レベル 1 がもっとも高い優先順位のクラスを表すようにし、それ以降の優先レベルを残りのクラスに割り当てます。割り当てた優先レベルの目的は、クラスを整理することだけです。QoS ポリシーテンプレートで設定した優先レベルは、実際に IPQoS によって使用されるわけではありません。また、QoS ポリシーによっては、同じ優先順位を複数のクラスに割り当てることもできます。
クラスの定義の次は、「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 パフォーマンスに与える影響も大きくなります。
次の手順を実行する前に、「QoS ポリシーのクラスを定義する方法」の手順を完了しておく必要があります。
「QoS ポリシーのクラスを定義する方法」で作成した QoS 計画テーブルの各クラスに 1 つ以上のフィルタを作成します。
必要であれば、1 つのクラスの着信トラフィックと発信トラフィックに対して、フィルタを別々に作成することを検討してください。たとえば、ftp-in フィルタと ftp-out フィルタを IPQoS 対応の FTP サーバーの QoS ポリシーに追加します。そうすれば、基本セレクタに加えて、該当する方向セレクタも定義できます。
クラスのフィルタごとにセレクタを最低 1 つ定義します。
表 33–1 で紹介されている QoS 計画テーブルを使用して、定義したクラスのフィルタを埋めます。
次の表は、出力 FTP トラフィック向けにフィルタを定義する方法を示す例です。
クラス |
優先順位 |
フィルタ |
セレクタ |
---|---|---|---|
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 ポリシーにフィルタを定義する方法」の説明に従って、フィルタとセレクタを定義していることが前提になります。
ネットワークの最大帯域幅を調べます。
ネットワークでサポートされている SLA を見直します。顧客と各顧客に保証されているサービスの種類を特定します。
一定レベルのサービスを保証するには、顧客によって生成される特定のトラフィッククラスを計測する必要があります。
「QoS ポリシーのクラスを定義する方法」で作成したクラスの一覧を見直します。
SLA に対応付けられているクラス以外に計測する必要があるクラスがあるかどうか確認します。
たとえば、IPQoS システムが大量のトラフィックを生成するアプリケーションを実行するとします。この場合は、そのアプリケーションのトラフィックを分類したあと、フローのパケットがネットワークに戻される速度を制御して、フローを計測します。
すべてのクラスを計測する必要があるとは限りません。クラスのリストを確認するときは、このガイドラインに留意してください。
各クラスのどのフィルタがフロー制御に必要なトラフィックを選択するのかを判断します。次に、メータリングを必要とするクラスのリストを精緻化します。
複数のフィルタを持つクラスでも 1 つのフィルタに対してだけ計測を必要とする場合もあります。たとえば、あるクラスの着信トラフィックと発信トラフィックに対してフィルタを定義したとします。しかし、結果的にどちらかの方向のトラフィックしかフロー制御を必要としない場合があります。
フロー制御を行うクラスごとにメーターモジュールを選択します。
作成した QoS 計画表のメーター欄にモジュール名を追加します。
計測するクラスごとの速度を構成表に追加します。
tokenmt モジュールを使用する場合は、次の速度を bps で定義する必要があります。
認定速度
最大速度
特定のクラスの計測に十分な場合は、認定速度と認定バーストを tokenmt に定義するだけでも構いません。
必要に応じて、次の速度も定義できます。
認定バースト
最大バースト
tokenmt 速度の詳しい説明については、 「tokenmt をツーレートメーターとして構成する」を参照してください。tokenmt(7ipp) のマニュアルページでも詳しく説明しています。
tswtclmt モジュールを使用する場合は、次の速度を bps で定義する必要があります。
認定速度
最大速度
また、ウィンドウサイズをミリ秒単位で定義することもできます。これらの速度は、「tswtclmt メータリングモジュール」および twstclmt(7ipp) のマニュアルページで定義されています。
計測するトラフィックのトラフィック適合結果 (outcome) を追加します。
どちらのメータリングモジュールでも、結果は緑、赤、黄の 3 つです。定義した速度に当てはまるトラフィック適合結果を QoS 構成表に追加します。メーターの結果については、「メーターモジュール」で詳しく説明されています。
認定速度に適合したトラフィックまたは適合しなかったトラフィックに対して取るべきアクションを決める必要があります。常にではありませんが多くの場合、このアクションは、ホップ単位の動作でパケットヘッダーをマークすることです。緑レベルのトラフィックに対して取りうるアクションの 1 つとして、トラフィックフローが認定速度を超えないかぎり処理を続行することもあります。あるいは、フローが最大速度を超えた場合にそのクラスのパケットをドロップすることもできます。
次の表は、電子メールトラフィックのクラスに対するメーターの記入例を示す例です。IPQoS システムを持つネットワークの総帯域幅は 100 Mbits/秒、つまり毎秒 10000000 ビットです。QoS ポリシーは、電子メールクラスに低い優先順位を割り当てます。このクラスには、ベストエフォート型の転送動作も割り当てられます。
クラス |
優先順位 |
フィルタ |
セレクタ |
レート |
---|---|---|---|---|
|
8 |
mail_in |
daddr10.50.50.5 dport imap direction LOCAL_IN |
|
|
8 |
mail_out |
saddr10.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 トラフィックに優先順位を付けるには、各パケットに DSCP を割り当てる必要があります。dscpmk マーカーは、パケットの DS フィールドに DSCP のマークを設定します。クラスの DSCP は、転送動作の種類に対応付けられている既知のコードポイントのグループから選択します。既知のコードポイントには、EF PHB 用の 46 (101110) や AF PHB 用のいくつかのコードポイントがあります。DSCP と転送の概要情報については、「IPQoS 対応ネットワークでのトラフィック転送」を参照してください。
次の手順の前に、QoS ポリシーのクラスとフィルタを定義してあるものとします。トラフィックを制御する場合は、メーターをマーカーと組み合わせて使用しますが、転送動作を定義するだけであれば、マーカーを単独で使用できます。
これまでに作成したクラスとそれらに割り当てた優先順位を確認します。
すべてのトラフィッククラスをマークする必要があるとは限りません。
もっとも高い優先順位のクラスに EF PHB を割り当てます。
EF PHB は、EF DSCP 46 (101110) を持つパケットが、AF PHB を割り当てたパケットよりも先にネットワーク上に送出されることを保証します。このため、もっとも高い優先順位のトラフィックには EF PHB を使用します。EF については、「完全優先転送 (Expedited Forwarding、EF) PHB」を参照してください。
トラフィックを計測するクラスに転送動作を割り当てます。
残りのクラスに、すでに割り当てた優先順位に応じた DS コードポイントを割り当てます。
トラフィックの計測は、一般に次の理由で行います。
SLA は、ネットワークの使用率が高いときでも、このクラスのパケットにある程度のサービスを保証する
低い優先順位のクラスがネットワークをあふれさせる傾向がある
マーカーをメーターと組み合わせて使用すると、これらのクラスに対して差別化サービスを提供したり帯域幅の管理を行ったりできます。たとえば、次の表は 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 を参照してください。
特定の種類のトラフィックのフローアカウンティングを計画するには、「フローアカウンティングを計画する方法」を参照してください。
QoS ポリシーにさらにクラスを追加するには、「QoS ポリシーのクラスを定義する方法」を参照してください。
QoS ポリシーにさらにフィルタを追加するには、「QoS ポリシーにフィルタを定義する方法」を参照してください。
フロー制御スキームを定義するには、「フロー制御を計画する方法」を参照してください。
パケットがネットワークストリームに戻るときのフローの転送動作をさらに定義するには、「転送動作を計画する方法」を参照してください。
IPQoS 構成ファイルを作成するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。
IPQoS flowacct モジュールを使用して、請求またはネットワーク管理のためにトラフィックフローを追跡します。次の手順に従って、QoS ポリシーにフローアカウンティングを含める必要があるかどうか判断してください。
顧客に SLA を提示していますか
提示している場合は、フローアカウンティングを使用する必要があります。まず、SLA を確認して、企業が顧客に使用料を請求するネットワークトラフィックの種類を調べます。次に、QoS ポリシーを確認して、課金の対象となるトラフィックが含まれるクラスを調べます。
ネットワークの問題を防ぐために監視またはテストを必要とするアプリケーションはありますか
ある場合は、フローアカウンティングを使ってそれらのアプリケーションの動作を監視することを検討します。QoS ポリシーを確認して、監視を必要とするトラフィックに割り当てたクラスを調べます。
QoS 計画表で、フローアカウンティングを必要とする各クラスのフローアカウンティング欄に Y と記入します。
QoS ポリシーにさらにクラスを追加するには、「QoS ポリシーのクラスを定義する方法」を参照してください。
QoS ポリシーにさらにフィルタを追加するには、「QoS ポリシーにフィルタを定義する方法」を参照してください。
フロー制御スキームを定義するには、「フロー制御を計画する方法」を参照してください。
パケットがネットワークストリームに戻るときのフローの転送動作を定義するには、「転送動作を計画する方法」を参照してください。
特定の種類のトラフィックの追加フローのアカウンティングを計画するには、「フローアカウンティングを計画する方法」を参照してください。
IPQoS 構成ファイルを作成するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。
このマニュアルの残りの章で説明する作業では、この節で紹介する IPQoS の構成例を使用します。この例は、架空のサービスプロバイダである BigISP の公共イントラネットでの差別化サービスソリューションを示しています。BigISP は、専用回線によって BigISP にアクセスする大企業向けにサービスを提供しています。モデムによるダイアルインを行う個人顧客も BigISP からサービスを購入しています。
次の図は、BigISP の公共イントラネットで使用するネットワークトポロジを示しています。
BigISP は、公共イントラネットにこれらの 4 つの層を実装しています。
第 0 層 – ネットワーク 10.10.0.0 には、Bigrouter という大規模な Diffserv ルーターがあり、外部インタフェースと内部インタフェースの両方を備えています。Goldco 社という大企業をはじめとする数社の企業が Bigrouter で終端する専用回線サービスを借りています。第 0 層では、電話回線または ISDN を介して接続する個人客も管理しています。
第 1 層 – ネットワーク 10.11.0.0 では、Web サービスを提供しています。Goldweb サーバーは、Goldco 社が BigISP から購入したプレミアムサービスの一部である Web サイトのホストとして動作します。Userweb サーバーは、個人客が購入した小規模の Web サイトのホストして動作します。Goldweb と Userweb のどちらのサーバーも IPQoS に対応しています。
第 2 層 – ネットワーク 10.12.0.0 では、すべての顧客が使用するアプリケーションを提供します。アプリケーションサーバーの 1 つである BigAPPS は IPQoS 対応サーバーです。BigAPPS は、SMTP、ニュース、および FTP サービスを提供します。
第 3 層 – ネットワーク 10.13.0.0 には、大規模データベースサーバーがいくつか格納されています。第 3 層へのアクセスは datarouter という Diffserv ルーターによって制御されます。
この章では、IPQoS 構成ファイルの作成方法について説明します。この章では、次の内容について説明します。
この章の説明は、完全な QoS ポリシーを定義していること、このポリシーを IPQoS 構成ファイルのベースとしてすぐに使用できることを前提としています。QoS ポリシーを計画するには、「サービス品質ポリシーの計画」を参照してください。
この作業マップでは、IPQoS 構成ファイルを作成するための一般的な作業の一覧と、各作業の実行手順を説明した節へのリンクを示します。
作業 |
説明 |
説明 |
---|---|---|
1. IPQoS 対応のネットワーク構成を計画する |
ローカルネットワーク上でどのシステムを IPQoS 対応にするかを決定する | |
2. ネットワーク上の IPQoS システム用 QoS ポリシーを計画する |
トラフィックフローを区別できるサービスクラスとして識別する。次に、トラフィック管理が必要なフローを決定する | |
3. IPQoS 構成ファイルを作成し、その最初のアクションを定義する |
IPQoS ファイルを作成し、IP クラシファイアを呼び出し、処理を実行させるクラスを定義する | |
4. クラス用のフィルタを作成する |
トラフィックの選択とクラス分けとを規定するフィルタを追加する | |
5. IPQoS 構成ファイルにクラスおよびフィルタをさらに追加する |
IP クラシファイアに処理させるクラスおよびフィルタをさらに作成する | |
6. メータリングモジュールを構成するパラメータを含む action 文を追加する |
QoS ポリシーがフロー制御を必要とする場合、フロー制御速度および適合レベルをメーターに割り当てる | |
7. マーカーを構成するパラメータを含む action 文を追加する |
QoS ポリシーが差別化転送動作を必要とする場合、トラフィッククラスの転送方法を定義する | |
8. フローアカウンティングモジュールを構成するパラメータを含む action 文を追加する |
QoS ポリシーがトラフィックフローに関する統計の取得を必要とする場合、これらのアカウンティング統計の収集方法を定義する | |
9. IPQoS 構成ファイルを適用する |
作成した IPQoS 構成ファイルの内容を、適切なカーネルモジュールに追加する | |
10. 転送動作をルーターファイル内で構成する |
ネットワーク上のいずれかの IPQoS 構成ファイルで転送動作が定義されている場合、結果として得られる DSCP を、ルーターの適切なスケジューリングファイルに追加する |
ネットワーク用の QoS ポリシーは、IPQoS 構成ファイル内に格納します。テキストエディタでこの構成ファイルを作成します。次に、作成したファイルを IPQoS 構成ユーティリティー ipqosconf の引数とします。ipqosconf に対し、構成ファイル内で定義されたポリシーの適用を指示すると、ポリシーがカーネル IPQoS システムに書き込まれます。ipqosconf コマンドの詳細については、ipqosconf(1M) のマニュアルページを参照してください。ipqosconf の使用方法については、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。
IPQoS 構成ファイルは、Planning the Quality-of-Service Policyで定義した QoS ポリシーを実行する 「サービス品質ポリシーの計画」 文のツリーで構成されています。IPQoS 構成ファイルは、IPQoS モジュールの構成を行います。各アクション文には、アクション文の中で呼び出されるモジュールが処理する「クラス」、「フィルタ」、または「パラメータ」のセットが含まれます。
IPQoS 構成ファイルの完全な構文については、例 37–3 および ipqosconf(1M) のマニュアルページを参照してください。
この章では、3 つの IPQoS 対応システム用の IPQoS 構成ファイルを作成する方法を示します。これらのシステムは、図 33–4 で紹介した BigISP 社のネットワークトポロジの一部です。
Goldweb – プレミアムレベル SLA を購入した顧客用 Web サイトのホストとして機能する Web サーバー
Userweb – ベストエフォート SLA を購入したホームユーザー向けの個人用 Web サイトのホストとして機能する、やや能力の劣る Web サーバー
BigAPPS – ゴールドレベルとベストエフォートの両方の顧客に、メール、ネットワークニュース、および FTP を提供するアプリケーションサーバー
3 つの構成ファイルを通して、最も一般的な IPQoS 構成を示します。IPQoS を実装するために、次の節のサンプルファイルをテンプレートとして使用することもできます。
この節では、まず、プレミアム Web サーバー用の構成を通して、IPQoS 構成ファイルを紹介します。次に、個人用 Web サイトのホストとして機能するサーバー用の構成ファイルで、まったく異なるサービスレベルを構成する方法を示します。両方のサーバーは、図 33–4 のネットワーク例の一部です。
次の構成ファイルは、Goldweb サーバーの IPQoS アクティビティーを定義します。このサーバーは、プレミアム SLA を購入した Goldco 社の Web サイトのホストです。
fmt_version 1.0 action { module ipgpc name ipgpc.classify params { global_stats TRUE } class { name goldweb next_action markAF11 enable_stats FALSE } class { name video next_action markEF enable_stats FALSE } filter { name webout sport 80 direction LOCAL_OUT class goldweb } filter { name videoout sport videosrv direction LOCAL_OUT class video } } action { module dscpmk name markAF11 params { global_stats FALSE dscp_map{0-63:10} next_action continue } } action { module dscpmk name markEF params { global_stats TRUE dscp_map{0-63:46} next_action acct } } action { module flowacct name acct params { enable_stats TRUE timer 10000 timeout 10000 max_limit 2048 } }
次の構成ファイルは、Userweb の IPQoS アクティビティーを定義します。このサーバーは、低価格または「ベストエフォート型」の SLA を購入した個人の Web サイトのホストです。このサービスレベルでは、IPQoS システムがより高額の SLA を利用する顧客からのトラフィックを処理したあとに、できるかぎり最良のサービスをベストエフォートの顧客に保証します。
fmt_version 1.0 action { module ipgpc name ipgpc.classify params { global_stats TRUE } class { name Userweb next_action markAF12 enable_stats FALSE } filter { name webout sport 80 direction LOCAL_OUT class Userweb } } action { module dscpmk name markAF12 params { global_stats FALSE dscp_map{0-63:12} next_action continue } }
最初の IPQoS 構成ファイルは、メンテナンスしやすい任意のディレクトリに作成できます。この章では、IPQoS 構成ファイルの位置としてディレクトリ /var/ipqos を使用します。次の手順では、例 34–1 の IPQoS 構成ファイルの最初のセグメントを構築します。
IPQoS 構成ファイルを作成する際、各 action 文および句を必ず中括弧 ({ }) で囲んでください。中括弧の使用例については、例 34–1 を参照してください。
プレミアム Web サーバーにログインし、新規 IPQoS 構成ファイルを拡張子 .qos を付けて作成します。
すべての IPQoS 構成ファイルで、最初の非コメント行にバージョン番号 fmt_version 1.0 を記述する必要があります。
冒頭のパラメータに続き、初期 action 文を記述して汎用の IP クラシファイア ipgpc を構成します。
IPQoS 構成ファイルを成す action 文のツリーは、この初期アクションから始まります。たとえば、/var/ipqos/Goldweb.qos ファイルは、 ipgpc クラシファイアを呼び出す初期 action 文で始まります。
fmt_version 1.0 action { module ipgpc name ipgpc.classify |
IPQoS 構成ファイルを開始する
action 文を開始する
構成ファイル内の最初のアクションとして ipgpc クラシファイアを構成する
クラシファイアの action 文の名前を定義する。名前は常に ipgpc.classify でなければならない
action 文の詳しい構文については、「action 文」および ipqosconf(1M) のマニュアルページを参照してください。
統計パラメータ global_stats を含む params 句を追加します。
params { global_stats TRUE } |
ipgpc.classify 文のパラメータ global_stats TRUE は、そのアクションに関する統計の収集を可能にします。また、global_stats TRUE を使用し、かつクラス句定義に enable_stats TRUE を指定すれば、そのクラスの統計の収集が可能になります。
統計の取得を有効にすると、パフォーマンスが影響を受けます。新規 IPQoS 構成ファイルを作成したときには、IPQoS が適正に動作するか検証するために、統計収集を有効にしてもかまいません。あとで global_stats の引数を FALSE に変更すれば、統計取得を無効にできます。
グローバル統計は、params 句で定義可能なパラメータの 1 種類に過ぎません。params 句の構文などについては、「params 句」および ipqosconf(1M) のマニュアルページを参照してください。
プレミアムサーバーに向かうトラフィックを特定するクラスを定義します。
class { name goldweb next_action markAF11 enable_stats FALSE } |
この文は、「class 句」と呼ばれます。class 句には次の内容が含まれます。
goldweb クラスを作成して、Goldweb サーバーに向かうトラフィックを特定する
ipgpc モジュールに対し、goldweb クラスのパケットをアクション文 markAF11 に渡すよう指示する。アクション文 markAF11 は、 dscpmk マーカーを呼び出す
goldweb クラスの統計取得を可能にする。ただし、enable_stats の値が FALSE であるため、このクラスの統計取得は有効にはならない
class 句の構文の詳細については、「class 句」と ipqosconf(1M) のマニュアルページを参照してください。
もっとも高い優先順位の転送を必要とするアプリケーションを特定するクラスを定義します。
class { name video next_action markEF enable_stats FALSE } |
video クラスを作成して、Goldweb サーバーから発信されるストリーミングビデオのトラフィックを特定する
ipgpc モジュールに対し、ipgpc による処理が完了した video クラスのパケットを、markEF 文に渡すよう指示する。markEF 文は、dscpmk マーカーを呼び出す
video クラスの統計収集を可能にする。ただし、enable_stats の値が FALSE であるため、このクラスの統計収集は有効にはならない
作成したばかりのクラスにフィルタを定義するには、「IPQoS 構成ファイル内でフィルタを定義する方法」を参照してください。
構成ファイルに対して別の class 句を作成するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。
次の手順では、IPQoS 構成ファイル内でクラスのフィルタを定義します。
次の手順の前に、構成ファイルの作成を開始しており、クラスを定義してあるものとします。この手順は、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」で作成された /var/ipqos/Goldweb.qos ファイルを引き続き構築します。
IPQoS 構成ファイルを作成する際、各 class 句および filter 句を必ず中括弧 ({ }) で囲んでください。中括弧の使用例については、例 34–1 を参照してください。
IPQoS 構成ファイルを開き、最後に定義したクラスの末尾を探します。
たとえば、IPQoS 対応サーバー Goldweb 用の構成ファイル /var/ipqos/Goldweb.qos では、次の class 句のあとから作業を始めます。
class { name video next_action markEF enable_stats FALSE } |
filter 句を定義し、IPQoS システムからの出力トラフィックを選択します。
filter { name webout sport 80 direction LOCAL_OUT class goldweb } |
フィルタに webout という名前を付ける
ソースポート 80 のトラフィックを選択する。これは、既知の HTTP (Web) トラフィック用ポート
ローカルシステムから発信されるトラフィックを選択する
フィルタが所属するクラス (このインスタンスでは goldweb クラス) を特定する
IPQoS 構成ファイル内の filter 句の構文などについては、「filter 句」を参照してください。
IPQoS システムのストリーミングビデオトラフィックを選択する filter 句を定義します。
filter { name videoout sport videosrv direction LOCAL_OUT class video } |
フィルタに videoout という名前を付ける
ソースポート videosrv のトラフィックを選択する。これは、以前にこのシステムのストリーミングビデオアプリケーション用に定義したポート
ローカルシステムから発信されるトラフィックを選択する
フィルタが所属するクラス (このインスタンスでは video クラス) を特定する
マーカーモジュールの転送動作を定義するには、「IPQoS 構成ファイル内でトラフィック転送を定義する方法」を参照してください。
メータリングモジュールのフロー制御パラメータを定義するには、「IPQoS 構成ファイル内でフロー制御を構成する方法」を参照してください。
IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。
さらにフィルタを定義するには、「IPQoS 構成ファイル内でフィルタを定義する方法」を参照してください。
アプリケーションからのトラフィックフロー向けのクラスを作成するには、「アプリケーションサーバー用 IPQoS 構成ファイルを作成する方法」を参照してください。
次の手順では、IPQoS 構成ファイルにクラスのホップ単位の動作を追加して、トラフィック転送を定義します。
次の手順の前に、既存の IPQoS 構成ファイルにクラスおよびフィルタを定義してあるものとします。この手順では、Example 34–1 の 例 34–1 ファイルを引き続き構築します。
次の手順では、dscpmk マーカーモジュールを使用してトラフィック転送を構成する方法を示します。dlclosmk マーカーを使用した VLAN システムのトラフィック転送については、「VLAN デバイスでの dlcosmk マーカーの使用」を参照してください。
IPQoS 構成ファイルを開き、最後に定義したフィルタの末尾を探します。
たとえば、IPQoS 対応サーバー Goldweb 用の構成ファイル /var/ipqos/Goldweb.qos では、次の filter 句のあとから作業を始めます。
filter { name videoout sport videosrv direction LOCAL_OUT class video } } |
この filter 句は、ipgpc クラシファイアの action 文の最後に位置します。このため、フィルタを終了させる閉じ括弧のあとに、action 文を終了させる閉じ括弧が必要です。
action { module dscpmk name markAF11 |
dscpmk マーカーモジュールを呼び出す
action 文に markAF11 という名前を付ける
以前に定義した goldweb クラスには next_action markAF11 という文が含まれています。この文は、クラシファイアによる処理が完了したトラフィックフローを、アクション文 markAF11 に送信します。
トラックフローに対してマーカーが取るアクションを定義します。
params { global_stats FALSE dscp_map{0-63:10} next_action continue } } |
マーカー action 文 markAF11 の統計収集を可能にする。ただし、global_stats の値が FALSE であるため、統計は収集されない
DSCP 10 を、マーカーにより処理中の goldweb クラスのパケットヘッダーに割り当てる
userweb クラスのパケットに対しこれ以上処理を行う必要がないこと、およびこれらのパケットをネットワークストリームに戻してもよいことを示す
DSCP 10 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 10 (バイナリ値 001010) に設定するよう指示します 。このコードポイントは、goldweb トラフィッククラスのパケットが AF11 ホップ単位動作 (PHB) に従うことを示します。AF11 は、DSCP 10 を持つすべてのパケットが、低ドロップ、および高い優先順位のサービスを受けることを保証します。このため、Goldweb 上のプレミアム顧客用の発信トラフィックには、AF (相対的優先転送) PHB で指定可能なもっとも高い優先順位が与えられます。AF に設定可能な DSCP の表については、表 37–2 を参照してください。
別のマーカー action 文を開始します。
action { module dscpmk name markEF |
dscpmk マーカーモジュールを呼び出す
action 文に markEF という名前を付ける
トラフィックフローに対してマーカーが取るアクションを定義します。
params { global_stats TRUE dscp_map{0-63:46} next_action acct } } |
video クラスの統計収集を有効にする。このクラスはストリーミングビデオのパケットを選択する
DSCP 46 を、マーカーにより処理中の video クラスのパケットヘッダーに割り当てる
dscpmk モジュールに対し、dscpmk による処理が完了した video クラスのパケットを、acct 文 action に渡すよう指示する。 action 文 acct は flowacct モジュールを呼び出す
DSCP 46 は、dscpmk モジュールに対し、dscp マップのすべてのエントリを DS フィールドの 10 進数の 46 (バイナリ 101110) に設定するよう指示します。このコードポイントは、video トラフィッククラスのパケットが完全優先転送ホップ単位動作 (PHB) に従うことを示します。
EF のコードポイントは 46 (バイナリ値 101110) にすることをお勧めします。その他の DSCP は、AF PHB をパケットに割り当てるときに使用します。
EF PHB は、DSCP 46 を持つパケットが IPQoS および Diffserv 対応システムによりもっとも高い優先度を与えられることを保証します。ストリーミングアプリケーションは、もっとも高い優先順位のサービスを必要とします。これが、QoS ポリシーでこれらのアプリケーションに EF PHB を割り当てる理由です。PHB の完全優先転送の詳細については、「完全優先転送 (Expedited Forwarding、EF) PHB」を参照してください。
作成したばかりの DSCP を Diffserv ルーターの適切なファイルに追加します。
詳細については、「IPQoS 対応ネットワーク上でルーターを構成する方法」を参照してください。
トラフィックフローのフローアカウンティング統計の収集を開始するには、「IPQoS 構成ファイル内でクラスのアカウンティングを有効にする方法」を参照してください。
マーカーモジュールの転送動作を定義するには、「IPQoS 構成ファイル内でトラフィック転送を定義する方法」を参照してください。
メータリングモジュールのフロー制御パラメータを定義するには、「IPQoS 構成ファイル内でフロー制御を構成する方法」を参照してください。
IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。
さらにフィルタを定義するには、「IPQoS 構成ファイル内でフィルタを定義する方法」を参照してください。
アプリケーションからのトラフィックフロー向けのクラスを作成するには、「アプリケーションサーバー用 IPQoS 構成ファイルを作成する方法」を参照してください。
次の手順では、IPQoS 構成ファイル内でトラフィッククラスのアカウンティングを有効にします。この手順では、How to Create the IPQoS Configuration File and Define Traffic Classesで紹介した 「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」 クラスのフローアカウンティングを定義します。このクラスは、プレミアム SLA の一部として課金されるストリーミングビデオのトラフィックを選択します。
次の手順の前に、既存の IPQoS 構成ファイルにクラス、フィルタ、メーターのアクション (必要な場合だけ)、およびマーカーのアクション (必要な場合だけ) を定義してあるものとします。この手順では、Example 34–1 の 例 34–1 ファイルを引き続き構築します。
IPQoS 構成ファイルを開き、最後に定義した action 文の末尾を探します。
たとえば、IPQoS 対応サーバー Goldweb 用の構成ファイル /var/ipqos/Goldweb.qos. では、次の action 文 markEF のあとから作業を始めます。
action { module dscpmk name markEF params { global_stats TRUE dscp_map{0-63:46} next_action acct } } |
フローアカウンティングを呼び出す action 文を開始します。
action { module flowacct name acct |
flowacct フローアカウンティングモジュールを呼び出す
action 文に acct という名前を付ける
トラフィッククラスに関するアカウンティングを制御する params 句を定義します。
params { global_stats TRUE timer 10000 timeout 10000 max_limit 2048 next_action continue } } |
video クラスの統計収集を有効にする。このクラスはストリーミングビデオのパケットを選択する
フローテーブル内で、タイムアウトしたフローが走査される間隔を、ミリ秒単位で指定する。このパラメータでは、間隔は 10000 ミリ秒
最小の間隔タイムアウト値を指定する。フローのパケットがタイムアウト値で指定された時間検出されないと、フローは「タイムアウト」する。このパラメータでは、パケットは 10000 ミリ秒後にタイムアウトする
このアクションインスタンスのフローテーブル内でアクティブなフローレコードの最大数を設定する
video クラスのパケットに対しこれ以上処理を行う必要がないこと、およびこれらのパケットをネットワークストリームに戻してもよいことを示す
flowacct モジュールは、指定されたタイムアウト値に達するまで、特定のクラスのパケットフローに関する統計情報を収集します。
ルーターでホップ単位の動作を設定するには、「IPQoS 対応ネットワーク上でルーターを構成する方法」を参照してください。
IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。
アプリケーションからのトラフィックフロー向けのクラスを作成するには、「アプリケーションサーバー用 IPQoS 構成ファイルを作成する方法」を参照してください。
ベストエフォート Web サーバー用の IPQoS 構成ファイルは、プレミアム Web サーバー用の IPQoS 構成ファイルとは少し違います。この手順では、例として 例 34–2 の構成ファイルを使用します。
ベストエフォート Web サーバーにログインします。
新規 IPQoS 構成ファイルを拡張子 .qos を付けて作成します。
fmt_vesion 1.0 action { module ipgpc name ipgpc.classify params { global_stats TRUE } |
/var/ipqos/userweb.qos ファイルは、ipgpc クラシファイアを呼び出す部分 action 文から始める必要があります。この action 文には、統計収集を有効にする params 句も含めています。この action 文については、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。
ベストエフォート Web サーバーに向かうトラフィックを特定するクラスを定義します。
class { name userweb next_action markAF12 enable_stats FALSE } |
userweb クラスを作成して、ユーザーから Userweb サーバーに向かうトラフィックを特定する
ipgpc モジュールに対し、ipgpc による処理が完了した userweb クラスのパケットを、action 文 markAF12 に渡すよう指示する。action 文 markAF12 は、dscpmk マーカーを呼び出す
userweb クラスの統計収集を可能にする。ただし、enable_stats の値が FALSE であるため、このクラスの統計は収集されない
class 句の処理については、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。
userweb クラスのトラフィックフローを選択する filter 句を定義します。
filter { name webout sport 80 direction LOCAL_OUT class userweb } } |
フィルタに webout という名前を付ける
ソースポート 80 のトラフィックを選択する。これは、既知の HTTP (Web) トラフィック用ポート
ローカルシステムから発信されるトラフィックを選択する
フィルタが所属するクラス (このインスタンスでは userweb クラス) を特定する
filter 句の処理については、「IPQoS 構成ファイル内でフィルタを定義する方法」を参照してください。
dscpmk マーカーを呼び出す action 文を開始します。
action { module dscpmk name markAF12 |
dscpmk マーカーモジュールを呼び出す
action 文に markAF12 という名前を付ける
以前に定義した userweb クラスには next_action markAF12 という文が含まれています。この文は、クラシファイアによる処理が完了したトラフィックフローを、 action 文 markAF12 に送信します。
トラフィックフローの処理に使用する、マーカーのパラメータを定義します。
params { global_stats FALSE dscp_map{0-63:12} next_action continue } } |
マーカー action 文 markAF12 の統計収集を可能にする。ただし、enable_stats の値が FALSE であるため、統計は収集されない
DSCP 12 を、マーカーにより処理中の userweb クラスのパケットヘッダーに割り当てる
userweb クラスのパケットに対しこれ以上処理を行う必要がないこと、およびこれらのパケットをネットワークストリームに戻してもよいことを示す
DSCP 12 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 12 (バイナリ値 001100) に設定するよう指示します。このコードポイントは、userweb トラフィッククラスのパケットが AF12 ホップ単位動作 (PHB) に従うことを示します。AF12 は、DS フィールド内に DSCP 12 を持つすべてのパケットが、中程度のドロップ、および高い優先順位のサービスを受けることを保証します。
IPQoS 構成ファイルを完成したら、構成を適用します。
アプリケーションからのトラフィックフローに対して、クラスやほかの構成を追加するには、「アプリケーションサーバー用 IPQoS 構成ファイルを作成する方法」を参照してください。
ルーターでホップ単位の動作を設定するには、「IPQoS 対応ネットワーク上でルーターを構成する方法」を参照してください。
IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。
この節では、顧客に主要アプリケーションを提供するアプリケーションサーバー用の、構成ファイルを作成する方法について説明します。この手順では、例として図 33–4 の BigAPPS サーバーを使用します。
次の構成ファイルは、BigAPPS サーバーの IPQoS アクティビティーを定義します。このサーバーは、顧客向けの FTP、電子メール (SMTP)、およびネットワークニュース (NNTP) のホストです。
fmt_version 1.0 action { module ipgpc name ipgpc.classify params { global_stats TRUE } class { name smtp enable_stats FALSE next_action markAF13 } class { name news next_action markAF21 } class { name ftp next_action meterftp } filter { name smtpout sport smtp class smtp } filter { name newsout sport nntp class news } filter { name ftpout sport ftp class ftp } filter { name ftpdata sport ftp-data class ftp } } action { module dscpmk name markAF13 params { global_stats FALSE dscp_map{0-63:14} next_action continue } } action { module dscpmk name markAF21 params { global_stats FALSE dscp_map{0-63:18} next_action continue } } action { module tokenmt name meterftp params { committed_rate 50000000 committed_burst 50000000 red_action_name AF31 green_action_name markAF22 global_stats TRUE } } action { module dscpmk name markAF31 params { global_stats TRUE dscp_map{0-63:26} next_action continue } } action { module dscpmk name markAF22 params { global_stats TRUE dscp_map{0-63:20} next_action continue } }
IPQoS 対応アプリケーションサーバーにログインし、新規 IPQoS 構成ファイルを拡張子 .qos を付けて作成します。
たとえば、アプリケーションサーバー用に /var/ipqos/BigAPPS.qos ファイルを作成します。action 文の最初に、ipgpc クラシファイアを呼び出す次の記述を配置します。これらは必ず記述する必要があります。
fmt_version 1.0 action { module ipgpc name ipgpc.classify params { global_stats TRUE } |
冒頭の action 文については、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。
BigAPPS サーバー上の 3 つのアプリケーションからのトラフィックをそれぞれ選択するクラスを作成します。
冒頭の action 文のあとに、クラス定義を追加します。
class { name smtp enable_stats FALSE next_action markAF13 } class { name news next_action markAF21 } class { name ftp enable_stats TRUE next_action meterftp } |
smtp という名前のクラスを作成する。 このクラスには、SMTP アプリケーションが扱う電子メールのトラフィックフローが含まれる
smtp クラスの統計収集を可能にする。ただし、enable_stats の値が FALSE であるため、このクラスの統計は取得されない
ipgpc モジュールに対し、ipgpc による処理が完了した smtp クラスのパケットを、action 文 markAF13 に渡すよう指示する
news という名前のクラスを作成する。 このクラスには、NNTP アプリケーションが扱うネットワークニュースのトラフィックフローが含まれる
ipgpc モジュールに対し、ipgpc による処理が完了した news クラスのパケットを、アクション文 markAF21 に渡すよう指示する
ftp という名前のクラスを作成する。 このクラスには、FTP アプリケーションが扱う発信トラフィックが含まれる
ftp クラスの統計収集を可能にする
ipgpc モジュールに対し、ipgpc による処理が完了した ftp クラスのパケットを、action 文 meterftp に渡すよう指示する
クラスの定義の詳細については、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。
手順 2 で定義したクラスのトラフィックを選択する filter 句を定義します。
filter { name smtpout sport smtp class smtp } filter { name newsout sport nntp class news } filter { name ftpout sport ftp class ftp } filter { name ftpdata sport ftp-data class ftp } } |
フィルタに smtpout という名前を付ける
ソースポート 25 のトラフィックを選択する。これは、既知の sendmail (SMTP) アプリケーション用ポート
フィルタが所属するクラス (このインスタンスでは smtp クラス) を特定する
フィルタに newsout という名前を付ける
ソースポート名 nntp のトラフィックを選択する。これは、既知のネットワークニュース (NNTP) アプリケーション用ポート
フィルタが所属するクラス (このインスタンスでは news クラス) を特定する
フィルタに ftpout という名前を付ける
ソースポート 21 の制御データを選択する。これは、既知の FTP トラフィック用ポート番号
フィルタに ftpdata という名前を付ける
ソースポート 20 のトラフィックを選択する。これは、既知の FTP データトラフィック用ポート番号
ftpout および ftpdata フィルタが所属するクラス (このインスタンスでは ftp) を特定する
フィルタを定義するには、「IPQoS 構成ファイル内でフィルタを定義する方法」を参照してください。
アプリケーショントラフィックの転送動作を定義するには、「IPQoS 構成ファイル内でアプリケーショントラフィックの転送を構成する方法」を参照してください。
メータリングモジュールを使用してフロー制御を設定するには、「IPQoS 構成ファイル内でフロー制御を構成する方法」を参照してください。
フローアカウンティングを設定するには、「IPQoS 構成ファイル内でクラスのアカウンティングを有効にする方法」を参照してください。
次の手順では、アプリケーショントラフィックの転送を設定します。次の手順では、アプリケーショントラフィッククラスのホップ単位動作を定義します。これらのクラスは、ネットワーク上のほかのトラフィックよりも優先度を低くする場合があります。この手順では、例 34–3 の /var/ipqos/BigAPPS.qos ファイルを引き続き構築します。
この手順では、マークしたアプリケーションに対してクラスとフィルタをすでに定義した既存の IPQoS 構成ファイルがあることを前提にしています。
アプリケーションサーバー用に作成した IPQoS 構成ファイルを開き、最後の filter 句の末尾を検索します。
/var/ipqos/BigAPPS.qos ファイルでは、最後のフィルタは次のとおりです。
filter { name ftpdata sport ftp-data class ftp } } |
action { module dscpmk name markAF13 |
dscpmk マーカーモジュールを呼び出す
action 文に markAF13 という名前を付ける
電子メールのトラフィックフローにマークされるホップ単位動作を定義します。
params { global_stats FALSE dscp_map{0-63:14} next_action continue } } |
マーカー action 文 markAF13 の統計収集を可能にする。ただし、global_stats の値が FALSE であるため、統計は収集されない
DSCP 14 を、マーカーにより処理中の smtp クラスのパケットヘッダーに割り当てる
smtp クラスのパケットに対しこれ以上処理を行う必要がないことを示す。よって、これらのパケットはネットワークストリームに戻すことができる
DSCP 14 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 14 (バイナリ値 001110) に設定するよう指示します。DSCP 14 は、AF13 のホップ単位の動作を設定します。マーカーは、DS フィールドの DSCP 14 で smtp トラフィッククラスのパケットをマークします。
AF13 は、DSCP 14 を持つすべてのパケットに高いドロップ優先度を割り当てますが、それと同時に Class 1 の優先順位も保証するため、ルーターは電子メールの発信トラフィックに対し、キューの中で高い優先順位を与えます。設定可能な AF コードポイントの表については、表 37–2 を参照してください。
マーカー action 文を追加して、ネットワークニュースのトラフィック用のホップ単位動作を定義します。
action { module dscpmk name markAF21 params { global_stats FALSE dscp_map{0-63:18} next_action continue } } |
action 文に markAF21 という名前を付ける
DSCP 18 を、マーカーにより処理中の nntp クラスのパケットヘッダーに割り当てる
DSCP 18 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 18 (バイナリ値 010010) に設定するよう指示します。DSCP 18 は、AF21 のホップ単位の動作を設定します。マーカーは、DS フィールドの DSCP 18 で news トラフィッククラスのパケットをマークします。
AF21 は DSCP 18 を持つすべてのパケットに低いドロップ優先度を保証しますが、優先順位は Class 2 にとどまります。よって、ネットワークニューストラフィックが振り落とされる可能性は低くなります。
Web サーバーの構成情報を追加するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。
メータリングモジュールを使用してフロー制御を設定するには、「IPQoS 構成ファイル内でフロー制御を構成する方法」を参照してください。
フローアカウンティングを設定するには、「IPQoS 構成ファイル内でクラスのアカウンティングを有効にする方法」を参照してください。
ルーターで転送動作を設定するには、「IPQoS 対応ネットワーク上でルーターを構成する方法」を参照してください。
IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。
ネットワークに送出される特定のトラフィックフローの速度を制御するには、メーターのパラメータを定義しなければなりません。IPQoS 構成ファイル内で、2 つのメーター tokenmt と tswtclmt とのどちらかを使用できます。
次の手順では、例 34–3 のアプリケーションサーバーの IPQoS 構成ファイルを引き続き構築します。次の手順では、メーターを構成するだけではなく、メーター action 文の内部で呼び出される 2 つの マーカーアクションも構成します。
この手順の前に、フローを制御するアプリケーション用のクラスおよびフィルタを定義してあるものとします。
アプリケーションサーバー用に作成した IPQoS 構成ファイルを開きます。
/var/ipqos/BigAPPS.qos ファイルで、次のマーカーアクションのあとから作業を開始します。
action { module dscpmk name markAF21 params { global_stats FALSE dscp_map{0-63:18} next_action continue } } |
ftp クラスのトラフィックをフロー制御するメーター action 文を作成します。
action { module tokenmt name meterftp |
tokenmt メーターを呼び出す
action 文に meterftp という名前を付ける
params { committed_rate 50000000 committed_burst 50000000 |
ftp クラスのトラフィックに 50,000,000 bps の転送速度を割り当てる
ftp クラスのトラフィックに 50,000,000 ビットのバーストサイズを割り当てる
tokenmt パラメータについては、「tokenmt をツーレートメーターとして構成する」を参照してください。
次のようにパラメータを追加して、トラフィック適合優先順位を設定します。
red_action markAF31 green_action_name markAF22 global_stats TRUE } } |
ftp クラスのトラフィックフローが認定速度を超過した場合、パケットは、markAF31 マーカー action 文に送信されることを示す
ftp クラスのトラフィックフローが認定速度に適合する場合、パケットがアクション文 markAF22 に送られることを示す
ftp クラスのメータリング統計取得を有効にする
トラフィックの適合性については、「メーターモジュール」を参照してください。
ホップ単位動作を ftp クラスの不適合トラフィックフローに割り当てるマーカー action 文を追加します。
action { module dscpmk name markAF31 params { global_stats TRUE dscp_map{0-63:26} next_action continue } } |
dscpmk マーカーモジュールを呼び出す
action 文に markAF31 という名前を付ける
ftp クラスの統計取得を有効にする
ftp クラスのトラフィックが認定速度を超過した場合は常に、DSCP 26 を ftp クラスのパケットヘッダーに割り当てる
ftp クラスのパケットに対しこれ以上処理を行う必要がないことを示す。よって、これらのパケットはネットワークストリームに戻すことができる
DSCP 26 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 26 (バイナリ値 011010) に設定するよう指示します。DSCP 26 は、AF31 のホップ単位の動作を設定します。マーカーは、DS フィールドの DSCP 26 で ftp トラフィッククラスのパケットをマークします。
AF31 は DSCP 26 を持つすべてのパケットに低いドロップ優先度を保証しますが、優先順位は Class 2 にとどまります。このため、速度不適合の FTP トラフィックがドロップされる可能性は低くなりますが、設定可能な AF コードポイントの表については、表 37–2 を参照してください。
認定速度に適合する ftp トラフィックフローにホップ単位動作を割り当てるマーカー action 文を追加します。
action { module dscpmk name markAF22 params { global_stats TRUE dscp_map{0-63:20} next_action continue } } |
marker アクションに markAF22 という名前を付ける
ftp クラスのトラフィックが認定速度に適合する場合は常に、DSCP 20 をパケットヘッダーに割り当てる
DSCP 20 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 20 (バイナリ値 010100) に設定するよう指示します。DSCP 20 は、AF22 のホップ単位の動作を設定します。マーカーは、DS フィールドの DSCP 20 で ftp トラフィッククラスのパケットをマークします。
AF22 は、DSCP 20 を持つすべてのパケットに中程度のドロップ優先度と Class 2 の優先順位を保証します。このため、速度適合の FTP トラフィックは、IPQoS システムから同時に送出されるフロー内で中程度のドロップ優先度を保証されます。ただし、ルーターは、Class 1 で中程度のドロップ優先度以上を持つトラフィッククラスの転送を優先します。設定可能な AF コードポイントの表については、表 37–2 を参照してください。
アプリケーションサーバー用に作成した DSCP を、Diffserv ルーターの適切なファイルに追加します。
IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。
Web サーバーの構成情報を追加するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。
フローアカウンティングを設定するには、「IPQoS 構成ファイル内でクラスのアカウンティングを有効にする方法」を参照してください。
ルーターで転送動作を設定するには、「IPQoS 対応ネットワーク上でルーターを構成する方法」を参照してください。
差別化サービスを提供するには、「diffserv ネットワークのハードウェア計画」の説明に従って、ネットワークトポロジに Diffserv 対応ルーターを含める必要があります。ルーター上で Diffserv を構成し、ルーターのファイルを更新する実際の手順は、このマニュアルの扱う範囲ではありません。
この節では、ネットワーク上のさまざまな IPQoS 対応システムおよび Diffserv ルーター間で、転送情報を調整する一般的な手順を説明します。
次の手順では、例として図 33–4 のトポロジを使用します。
次の手順の前に、この章のこれまでの作業を実行することにより、ネットワーク上で IPQoS システムを構成してあるものとします。
ネットワーク上のすべての IPQoS 対応システムの構成ファイルを確認します。
さまざまな QoS ポリシーで使用される各コードポイントを特定します。
コードポイント、およびコードポイントを適用するシステムとクラスの表を作成します。次の表から、同じコードポイントを使用した領域を知ることができます。同じコードポイントを使用したままでもかまいませんが、同じマークが付けられたクラス間の優先度を決めるには、IPQoS 構成ファイル内に precedence セレクタなどほかの条件を指定する必要があります。
たとえば、この章の手順で使用するネットワーク例の場合、次のコードポイント表を作成できます。
システム |
クラス |
PHB |
DS コードポイント |
---|---|---|---|
Goldweb |
video |
EF |
46 (101110) |
Goldweb |
goldweb |
AF11 |
10 (001010) |
Userweb |
webout |
AF12 |
12 ( 001100) |
BigAPPS |
smtp |
AF13 |
14 ( 001110) |
BigAPPS |
news |
AF18 |
18 ( 010010) |
BigAPPS |
ftp 適合トラフィック |
AF22 |
20 ( 010100) |
BigAPPS |
ftp 不適合トラフィック |
AF31 |
26 ( 011010) |
ネットワークの IPQoS 構成ファイルから得たコードポイントを、Diffserv ルーターの適切なファイルに追加します。
これらのコードポイントは、ルーターの Diffserv スケジューリング機構の設定に役立ちます。詳しくは、ルーターの製造元の文書および Web サイトを参照してください。
この章では、IPQoS 構成ファイルを有効化する方法および IPQoS 関連のイベントを記録する方法について説明します。次の項目について説明します。
この節には、Oracle Solaris システム上で IPQoS を起動および保守するための一連の作業を示します。作業を行う前に、「IPQoS 構成ファイル内での QoS ポリシーの定義 (作業マップ)」に従って、IPQoS 構成ファイルを完成しておく必要があります。
次の表では、それらの作業について箇条書き形式で説明し、各作業を完了する方法が詳しく説明された節へのリンクを示しています。
作業 |
説明 |
説明 |
---|---|---|
1. システムで IPQoS を構成します。 |
ipqosconf コマンドを使用して、システムの IPQoS 構成ファイルを有効にします。 | |
2. Oracle Solaris 起動スクリプトを使用して、各システムの起動後にデバッグ済みの IPQoS 構成ファイルを適用します。 |
システムを再起動するたびに、IPQoS 構成ファイルが確実に適用されるようにします。 | |
3. syslog を使用した IPQoS のログ記録を有効にします。 |
エントリを追加して、syslog による IPQoS メッセージのログ記録を有効にします。 | |
4. 発生する IPQoS の問題を解決します。 |
エラーメッセージを利用して IPQoS の問題を解決します。 |
表 35–1 のエラーメッセージを参照してください。 |
IPQoS 構成の有効化およびそのほかの操作には、 ipqosconf コマンドを使用します。
ipqosconf コマンドで、IPQoS 構成ファイルを読み取り、UNIX カーネルで IPQoS モジュールを構成します。次の手順では、Creating IPQoS Configuration Files for Web Serversで作成した 「Web サーバー用 IPQoS 構成ファイルの作成」 ファイルを例として使用します。詳細については、ipqosconf(1M) のマニュアルページを参照してください。
IPQoS 対応システムで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
# /usr/sbin/ipqosconf -a/var/ipqos/Goldweb.qos |
ipqosconf により、指定された IPQoS 構成ファイル内の情報が Oracle Solaris カーネル内の IPQoS モジュールに書き込まれます。この例では、/var/ipqos/Goldweb.qos の内容が現行の Oracle Solaris カーネルに適用されます。
-a オプションを指定して IPQoS 構成ファイルを適用すると、ファイル内のアクションが現行のセッションの間だけ有効になります。
新規 IPQoS 構成のテストおよびデバッグを行います。
UNIX ユーティリティーを使用して、IPQoS の動作を追跡し、IPQoS 実装に関する統計を収集します。この情報は、構成が予想どおりに機能するかを判断するのに役立ちます。
IPQoS モジュールがどのように機能するかに関する統計は、「統計情報の収集」を参照してください。
ipqosconf メッセージをログ記録するには、「IPQoS メッセージの syslog によるログ記録の有効化」を参照してください。
起動のたびに現在の IPQoS 構成を適用させるには、「再起動後にも IPQoS 構成を適用する方法」を参照してください。
再起動後にも IPQoS 構成を持続させるには、明示的に指定する必要があります。そのように指定しないと、システムの再起動後に現行の構成が適用されません。システムで IPQoS が適正に動作するときは、次の操作を実行して再起動後にも構成が持続するようにします。
IPQoS 対応システムで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
カーネルモジュール内に IPQoS 構成が存在することを確認します。
# ipqosconf -l |
構成がすでに存在する場合は、ipqosconf によって画面に表示されます。出力が行われない場合は、「新規構成を IPQoS カーネルモジュールへ適用する方法」の説明に従って、構成を適用します。
IPQoS システムを再起動するたびに既存の IPQoS 構成が適用されるようにします。
# /usr/sbin/ipqosconf -c |
-c オプションを指定すると、現行の IPQoS 構成が、起動時の構成ファイル /etc/inet/ipqosinit.conf に書き込まれます。
IPQoS 起動時のメッセージを記録するには、次に示す手順に従って /etc/syslog.conf ファイルを変更する必要があります。
IPQoS 対応システムで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
/etc/syslog.conf ファイルを開きます。
ファイルの最後に、次のエントリを追加します。
user.info /var/adm/messages |
列の区切りは、空白ではなくタブを使用してください。
このエントリを指定すると、IPQoS により生成された起動時のメッセージがすべて /var/adm/messages ファイルに記録されます。
システムを再起動して設定を適用します。
システムの再起動後に /var/adm/messages を表示すると、出力に次のような IPQoS ログメッセージが含まれることがあります。
May 14 10:44:33 ipqos-14 ipqosconf: [ID 815575 user.info] New configuration applied. May 14 10:44:46 ipqos-14 ipqosconf: [ID 469457 user.info] Current configuration saved to init file. May 14 10:44:55 ipqos-14 ipqosconf: [ID 435810 user.info] Configuration flushed. |
また、IPQoS システムの /var/adm/messages ファイル内に、次のような IPQoS エラーメッセージが表示される場合もあります。
May 14 10:56:47 ipqos-14 ipqosconf: [ID 123217 user.error] Missing/Invalid config file fmt_version. May 14 10:58:19 ipqos-14 ipqosconf: [ID 671991 user.error] No ipgpc action defined. |
これらのエラーメッセージについては、表 35–1 を参照してください。
この節には、IPQoS によって生成されるエラーメッセージと考えられる解決方法を示します。
表 35–1 IPQoS のエラーメッセージ
エラーメッセージ |
説明 |
解決方法 |
---|---|---|
Undefined action in parameter parameter-name's action action-name |
parameter-name に指定したアクション名が IPQoS 構成ファイル内に存在しません。 |
アクションを作成します。またはパラメータ内の別の既存のアクションを参照します。 |
action action-name involved in cycle |
IPQoS 構成ファイル内の action-name はアクション循環の一部です。これは IPQoS では許可されません。 |
アクション循環を決定します。次に、IPQoS 構成ファイルから循環参照の 1 つを削除します。 |
Action action-name isn't referenced by any other actions |
ipgpc アクション以外で、ほかの定義済みアクションにより参照されないアクション定義が IPQoS 構成内にあります。これは IPQoS では許可されません。 |
参照されていないアクションを削除します。または別のアクションに現在参照されていないアクションを参照させます。 |
Missing/Invalid config file fmt_version |
構成ファイルのフォーマットがファイルの最初のエントリに指定されていません。これは IPQoS では必須です。 |
「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」の説明に従って、書式のバージョンを追加します。 |
Unsupported config file format version |
IPQoS がサポートしないフォーマットのバージョンが、構成ファイル内で指定されています。 |
フォーマットのバージョンを、Solaris 9 9/02 バージョンの IPQoS 実行に必要な fmt_version 1.0 以降に変更します。 |
No ipgpc action defined. |
構成ファイル内で、ipgpc クラシファイアのアクションが定義されていません。これは IPQoS では必須です。 |
「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」のように ipgpc のアクションを定義します。 |
Can't commit a null configuration |
ipqosconf -c を実行して空の構成をコミットしようとしました。IPQoS は空の構成を許可しません。 |
構成ファイルを確実に適用してから構成をコミットします。手順については、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。 |
Invalid CIDR mask on line line-number |
構成ファイル内で、CIDR マスクの IP アドレスとして無効なアドレスを使用しました。 |
マスク値を 1–32 (IPv4 の場合) および 1–128 (IPv6 の場合) の範囲内の値に変更します。 |
Address masks aren't allowed for host names line line-number |
構成ファイル内で、ホストの CIDR マスク値を定義しました。これは IPQoS では許可されません。 |
マスクを削除するか、あるいはホスト名を IP アドレスに変更します。 |
Invalid module name line line-number |
構成ファイル内のアクション文に無効なモジュール名を指定しました。 |
モジュール名のスペルに入力ミスがないか確認します。IPQoS モジュールのリストについては、表 37–5 を参照してください。 |
ipgpc action has incorrect name line line-number |
構成ファイル内で ipgpc アクションに付けた名前が、必須の ipgpc.classify ではありません。 |
アクション名を ipgpc.classify に変更します。 |
Second parameter clause not supported line line-number |
構成ファイル内で、単一のアクションに対し 2 つのパラメータ句を指定しました。これは IPQoS では許可されません。 |
アクションのパラメータすべてを結合して、単一のパラメータ句にします。 |
Duplicate named action |
構成ファイル内で、2 つのアクションに同じ名前を付けました。 |
どちらかのアクションの名前を変更するか、あるいは削除します。 |
Duplicate named filter/class in action action-name |
1 つのアクション内の 2 つのフィルタまたは 2 つのクラスに同じ名前を付けました。これは IPQoS 構成ファイルでは許可されません。 |
どちらかのフィルタまたはクラスの名前を変更するか、あるいは削除します。 |
Undefined class in filter filter-name in action action-name |
フィルタが、構成ファイル内のアクションで定義されていないクラスを参照します。 |
クラスを作成するか、あるいは既存のクラスへの参照に変更します。 |
Undefined action in class class-name action action-name |
クラスが、構成ファイル内で定義されていないアクションを参照します。 |
アクションを作成するか、あるいは既存のアクションへの参照に変更します。 |
Invalid parameters for action action-name |
構成ファイル内のパラメータのどれかが無効です。 |
指名されたアクションが呼び出すモジュールについては、「IPQoS アーキテクチャーと Diffserv モデル」のモジュールエントリを参照してください。あるいは、ipqosconf(1M) のマニュアルページを参照します。 |
Mandatory parameter missing for action action-name |
アクションに必要なパラメータが構成ファイル内に定義されていません。 |
指名されたアクションが呼び出すモジュールについては、「IPQoS アーキテクチャーと Diffserv モデル」のモジュールエントリを参照してください。あるいは、ipqosconf(1M) のマニュアルページを参照します。 |
Max number of classes reached in ipgpc |
IPQoS 構成ファイルの ipgpc アクションに、許可される数を超えたクラスを指定しました。最大数は 10007 です。 |
構成ファイルを確認して、不要なクラスを削除します。または、/etc/system ファイルにエントリ ipgpc_max_classesclass-number を追加して最大クラス数を増やすこともできます。 |
Max number of filters reached in action ipgpc |
IPQoS 構成ファイルの ipgpc アクションに、許可される数を超えたフィルタを指定しました。最大数は 10007 です。 |
構成ファイルを確認して、不要なフィルタを削除します。または、/etc/system ファイルにエントリ ipgpc_max_filtersfilter-number を追加して最大フィルタ数を増やすこともできます。 |
Invalid/missing parameters for filter filter-name in action ipgpc |
構成ファイル内で、フィルタ filter-name に無効なパラメータが指定されているか、あるいはパラメータが不足しています。 |
ipqosconf(1M) のマニュアルページで、有効なパラメータのリストを参照します。 |
Name not allowed to start with '!', line line-number |
アクション、フィルタまたはクラス名の最初に感嘆符 (!) を記述しました。IPQoS ファイルでは感嘆符は許可されていません。 |
感嘆符を削除するか、あるいは、アクション、クラス、またはフィルタの名前を変更します。 |
Name exceeds the maximum name length line line-number |
構成ファイル内のアクション、クラス、またはフィルタの名前が、最大長の 23 文字を超えています。 |
アクション、クラス、またはフィルタの名前を短くします。 |
Array declaration line line-number is invalid |
構成ファイル内で、line-number 行のパラメータの配列宣言が無効です。 |
無効な配列を持つ action 文が呼び出す配列宣言の正しい構文については、「IPQoS アーキテクチャーと Diffserv モデル」を参照してください。あるいは、ipqosconf(1M) のマニュアルページを参照します。 |
Quoted string exceeds line, line-number |
文字列の最後の閉じ引用符が同一行に存在しません。これは構成ファイルでは必須です。 |
引用符で囲まれた文字列を、構成ファイルの同一行内に収めます。 |
Invalid value, line line-number |
構成ファイルの line-number に、パラメータとしてサポートされない値が指定されています。 |
action 文が呼び出すモジュールの許容値については、「IPQoS アーキテクチャーと Diffserv モデル」のモジュールの説明を参照してください。あるいは、ipqosconf(1M) のマニュアルページを参照します。 |
Unrecognized value, line line-number |
構成ファイルの line-number に、パラメータとしてサポートされない列挙値が指定されています。 |
パラメータの列挙値が適正であるかどうかを確認します。認識されない行番号を持つ action 文の説明については、「IPQoS アーキテクチャーと Diffserv モデル」を参照してください。あるいは、ipqosconf(1M) のマニュアルページを参照します。 |
Malformed value list line line-number |
構成ファイルの line-number で指定された列挙が、仕様構文に適合しません。 |
間違った形式の値リストを持つ action 文が呼び出すモジュールの正しい構文については、「IPQoS アーキテクチャーと Diffserv モデル」のモジュールの説明を参照してください。あるいは、ipqosconf(1M) のマニュアルページを参照します。 |
Duplicate parameter line line-number |
重複したパラメータが line-number に指定されています。これは構成ファイルでは許可されません。 |
重複したパラメータのどちらかを削除します。 |
Invalid action name line line-number |
構成ファイルの line-number のアクションに、定義済みの名前 continue または drop を含む名前を付けました。 |
定義済みの名前を使用しないよう、アクションの名前を変更します。 |
Failed to resolve src/dst host name for filter at line line-number, ignoring filter |
構成ファイル内で、あるフィルタ用に定義された発信元または着信先アドレスを、ipqosconf が解釈処理できません。このため、このフィルタは無視されます。 |
フィルタが重要な場合、あとで構成の適用を試みます。 |
Incompatible address version line line-number |
line-number 上の IP バージョンのアドレスが、すでに指定済みの IP アドレスのバージョンまたは ip_version パラメータと互換性がありません。 |
競合する 2 つのエントリを変更して、互換性を持たせます。 |
Action at line line-number has the same name as currently installed action, but is for a different module |
システムの IPQoS 構成内にすでに存在するアクションのモジュールを変更しようとしました。これは許可されません。 |
現行の構成をフラッシュしてから、新しい構成を適用します。 |
この章では、IPQoS システムによって処理されるトラフィックに関して、アカウンティング情報と統計情報を取得する方法について説明します。この章では、次の内容について説明します。
次の作業マップは、flowacct モジュールを使用してトラフィックフローに関する情報を取得するための一般的な作業を示しています。マップでは、これらの作業の実施手順へのリンクも示しています。
作業 |
説明 |
説明 |
---|---|---|
1. トラフィックフローのアカウンティング情報を格納するためのファイルを作成する |
acctadm コマンドを使用して、flowacct による処理結果を格納するファイルを作成する | |
2. flowacct のパラメータを IPQoS 構成ファイルに定義する |
timer、timeout、および max_limit の各パラメータの値を定義する |
トラフィックフローに関する情報を収集するには、IPQoS flowacct モジュールを使用します。たとえば、発信元アドレスや 宛先アドレス、フロー内のパケット数などのデータを収集することが可能です。フローに関する情報を蓄積して記録するプロセスのことを「フローアカウンティング」と呼びます。
特定のクラスのトラフィックに関するフローアカウンティングの結果は、「フローレコード」というテーブルに記録されます。各フローレコードは、一連の属性から構成されます。これらの属性には、特定のクラスの一定時間のトラフィックフローに関するデータが格納されます。flowacct 属性のリストについては、表 37–4 を参照してください。
フローアカウンティングは、サービスレベル契約 (SLA) に定義されているとおりに顧客に課金するために、非常に役立ちます。また、フローアカウンティングを使って、重要なアプリケーションのフロー統計情報を取得することもできます。この節では、flowacct を Oracle Solaris 拡張アカウンティング機能と組み合わせて、トラフィックフローに関するデータを取得するための作業について説明します。
この章以外の場所からも次の情報が入手できます。
IPQoS 構成ファイル内の flowacct のアクション文の作成方法については、「IPQoS 構成ファイル内でフロー制御を構成する方法」を参照してください。
flowacct がどのように機能するかについては、「クラシファイアモジュール」を参照してください。
技術的な情報については、flowacct(7ipp) のマニュアルページを参照してください。
flowacct アクションを IPQoS 構成ファイルに追加する前に、flowacct モジュールからフローレコードのファイルを作成します。このためには、acctadm コマンドを使用します。acctadm では、基本属性または拡張属性のどちらもファイルに記録できます。すべての flowacct 属性のリストについては、表 37–4 を参照してください。acctadm については、acctadm(1M) のマニュアルページを参照してください。
IPQoS 対応システムで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
基本フローアカウンティングファイルを作成します。
次の例に、例 34–1 で構成されるプレミアム Web サーバ用の基本的なフローアカウンティングファイルの作成方法を示します。
# /usr/sbin/acctadm -e basic -f /var/ipqos/goldweb/account.info flow |
acctadm を -e オプションを指定して呼び出します。-e オプションによって、あとに続く引数が有効になる
flowacct の 8 つの基本属性のデータだけがファイルに記録されることを示す
flowacct から得られるフローレコードを格納するファイルの絶対パス名を示す
acctadm にフローアカウンティングを有効にするよう指示する
引数を指定しないで acctadm と入力し、IPQoS システムのフローアカウンティングに関する情報を表示します。
acctadm によって次の出力が生成されます。
Task accounting: inactive Task accounting file: none Tracked task resources: none Untracked task resources: extended Process accounting: inactive Process accounting file: none Tracked process resources: none Untracked process resources: extended,host,mstate Flow accounting: active Flow accounting file: /var/ipqos/goldweb/account.info Tracked flow resources: basic Untracked flow resources: dsfield,ctime,lseen,projid,uid
最後の 4 つのエントリ以外はすべて、Solaris のリソースマネージャー機能で使用されます。次の表では、IPQoS に固有のエントリについて説明します。
エントリ |
説明 |
---|---|
Flow accounting: active |
フローアカウンティングが有効になっていることを示す |
Flow accounting file: /var/ipqos/goldweb/account.info |
現在のフローアカウンティングファイルの名前を示す |
Tracked flow resources: basic |
基本フロー属性だけが記録されることを示す |
Untracked flow resources: dsfield,ctime,lseen,projid,uid |
ファイルに記録されない flowacct の属性を示す |
(オプション) 拡張属性をアカウンティングファイルに追加します。
# acctadm -e extended -f /var/ipqos/goldweb/account.info flow |
(オプション) 基本属性だけがアカウンティングファイルに記録されるような設定に戻します。
# acctadm -d extended -e basic -f /var/ipqos/goldweb/account.info |
-d オプションによって拡張アカウンティングが無効になります。
フローアカウンティングファイルの内容を参照します。
フローアカウンティングファイルの内容の参照方法については、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の「libexacct に対する Perl インタフェース」を参照してください。
拡張アカウンティング機能の詳細については、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の第 4 章「拡張アカウンティング (概要)」を参照してください。
IPQoS 構成ファイル内に flowacct パラメータを定義するには、「IPQoS 構成ファイル内でクラスのアカウンティングを有効にする方法」を参照してください。
acctadm で作成されたファイルのデータを印刷するには、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の「libexacct に対する Perl インタフェース」を参照してください。
kstat コマンドを使用すると、IPQoS モジュールから統計情報を生成できます。構文は次のとおりです。
/bin/kstat -m ipqos-module-name |
表 37–5 に示されている、有効な IPQoS モジュール名であればどれでも指定できます。たとえば、dscpmk マーカーによって生成される統計情報を表示するには、次の形の kstat を使用します。
/bin/kstat -m dscpmk |
技術的な情報については、kstat(1M) のマニュアルページを参照してください。
ここでは、kstat を実行して flowacct モジュールに関する統計情報を取得した場合に予想される結果の一例について説明します。
# kstat -m flowacct module: flowacct instance: 3 name: Flowacct statistics class: flacct bytes_in_tbl 84 crtime 345728.504106363 epackets 0 flows_in_tbl 1 nbytes 84 npackets 1 snaptime 345774.031843301 usedmem 256 |
トラフィックフローが属するクラスの名前 (この例では flacct) を示す
フローテーブルの総バイト数。フローテーブルの総バイト数とは、フローテーブルに現在格納されているすべてのフローレコードの合計バイト数。このフローテーブルの総バイト数は 84 である。テーブルにフローがない場合、bytes_in_tbl の値は 0 になる
この kstat 出力が作成された最も最近の時間
処理中にエラーが発生したパケットの数 (この例では 0)
フローテーブルのフローレコード数 (この例では 1)。テーブルにレコードがない場合、flows_in_tbl の値は 0 になる
この flowacct アクションのインスタンスで表示される合計バイト数 (この例では 84)。フローテーブルに現在格納されているバイトを含む値。この値には、タイムアウトになり、フローテーブルに現在は含まれていない値も含まれる
この flowacct アクションのインスタンスで表示される合計パケット数 (この例では 1)。npackets には、フローテーブルに現在あるパケットが含まれる。npackets には、タイムアウトになり、フローテーブルに現在は含まれていないパケットも含まれる
この flowacct インスタンスで保持されているフローテーブルが使用しているメモリーのバイト数。この例では、usedmem の値は 256。フローテーブルにフローレコードがまったく存在しない場合、usedmem の値は 0 になる
この章は、IPQoS の詳細を説明するリファレンスです。この章では、次の内容について説明します。
概要は、第 32 章IPQoS の紹介 (概要)を参照してください。計画については、第 33 章IPQoS 対応ネットワークの計画 (手順)を参照してください。IPQoS の構成手順については、第 34 章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) フィールドの値を調べ、差別化サービスコードポイント (DSCP) の存在を確認します
DSCP は、受信したトラフィックに送信側によって転送動作のマークが付けられているかどうかを示します。
特定クラスのパケットに関して、IPQoS 構成ファイル内で次に指定されているアクションを調べます。
パケットを、IPQoS 構成ファイルで指定された次の IPQoS モジュールに渡すか、あるいはネットワークストリームに戻します。
クラシファイアの概要は、「クラシファイア (ipgpc) の概要」を参照してください。IPQoS 構成ファイルでクラシファイアを呼び出すには、「IPQoS 構成ファイル」を参照してください。
ipgpc クラシファイアは、IPQoS 構成ファイルの filter 句で使用可能なさまざまなセレクタをサポートします。フィルタを定義するときには、特定クラスのトラフィック取得に必要な最小限のセレクタを使用してください。定義するフィルタの数が、IPQoS のパフォーマンスに影響を与える可能性があります。
表 37–1 IPQoS クラシファイアで利用可能なフィルタセレクタ
セレクタ |
引数 |
選択される情報 |
---|---|---|
saddr |
IP アドレス番号 |
発信元アドレス |
daddr |
IP アドレス番号 |
着信先アドレス |
sport |
ポート番号またはサービス名。/etc/services の定義に従う |
トラフィッククラスの発信元ポート |
dport |
ポート番号またはサービス名。/etc/services の定義に従う |
トラフィッククラスの着信先ポート |
プロトコル |
プロトコル番号またはプロトコル名。/etc/protocols の定義に従う |
このトラフィッククラスが使用するプロトコル |
dsfield |
0 - 63 の値を持つ DS コードポイント (DSCP) |
DSCP。パケットに適用される転送動作を定義する。このパラメータを指定した場合は、dsfield_mask パラメータも指定すること |
dsfield_mask |
0 - 255 の値を持つビットマスク |
dsfield セレクタと組み合わせて使用。dsfield_mask は、dsfield セレクタに適用して、ビットのどれが一致するかを決定する |
if_name |
インタフェース名 |
特定クラスの着信トラフィックまたは発信トラフィックで使用されるインタフェース |
user |
選択する UNIX ユーザー ID の番号またはユーザー名。パケットにユーザー ID またはユーザー名が存在しない場合、デフォルトの –1 が使用される |
アプリケーションに指定されるユーザー ID |
projid |
選択するプロジェクト ID の番号 |
アプリケーションに付加されるプロジェクト ID |
priority |
優先順位の番号。もっとも低い優先順位は 0 |
このクラスのパケットに与えられる優先順位。優先順位は、同じクラスに複数存在するフィルタの重要度の順位付けに使用される |
direction |
次の引数のいずれかを指定できる。 |
IPQoS マシン上のパケットフローの方向 |
LOCAL_IN |
ローカルシステムから IPQoS システムへの入力トラフィック |
|
LOCAL_OUT |
ローカルシステムから IPQoS システムへの出力トラフィック |
|
FWD_IN |
転送される入力トラフィック |
|
FWD_OUT |
転送される出力トラフィック |
|
precedence |
優先度の値。もっとも高い優先度は 0 |
優先度は、同一優先順位のフィルタの順序付けに使用される |
ip_version |
V4 または V6 |
パケットにより使用されるアドレス指定スキーマ (IPv4 または IPv6) |
「meter」は、パケット単位でフローの転送速度を追跡します。このメーターは、設定されているパラメータにパケットが一致するかどうかを決定します。メーターモジュールは、パケットサイズ、設定されたパラメータ、およびフロー速度に基づき、パケットの次のアクションをアクションセットの中から決定します。
メーターには 2 つのメータリングモジュール、すなわち tokenmt および tswtclmt があります。モジュールの構成は、IPQoS 構成ファイルで行います。モジュールのどちらか一方または両方をクラスに設定できます。
メータリングモジュールを構成する際、速度に関する 2 つのパラメータを定義できます。
committed-rate – 特定クラスのパケットに容認可能な転送速度を bps で定義する
peak-rate – 特定クラスのパケットに最大限容認可能な転送速度を bps で定義する
パケットに対するメータリングアクションの結果 (outcome) は、次の 3 つのどれかになります。
green – パケットの生成するフローは認定速度内である
yellow – パケットの生成するフローは認定速度を超過しているが、最大速度内である
red – パケットの生成するフローは最大速度を超過している
IPQoS 構成ファイル内で、結果ごとに異なるアクションを構成できます。認定速度および最大速度については、次に説明します。
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 の例については、例 34–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 文の例を次に示します。
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 は、ツーレートメーター用のパラメータに加え、パケットヘッダー内の DSCP も使用してパケットを評価します。
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 mark22 のように、引数を指定してパケットをマーカーアクションに送信することもできます。
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 フィールドの値をマークします。この値は、DSCP (Differentiated Services Codepoint) と呼ばれます。Diffserv アーキテクチャーは、2 種類の転送動作、すなわち EF および AF を定義しており、各転送動作はそれぞれ異なる DSCP を使用します。DSCP の概要については、「DS コードポイント」を参照してください。
IPQoS システムは、トラフィックフローの DSCP を読み取り、ほかの送信トラフィックフローに対する相対的な優先度を評価します。次に IPQoS システムは、並行するトラフィックフローすべての優先順位を定め、各フローを優先順位に従ってネットワーク上に送出します。
Diffserv ルーターは、送信トラフィックフローを受け取り、パケットヘッダー内の DS フィールドを読み取ります。DSCP を使用すると、ルーターで現在のトラフィックフローに優先順位を付け、スケジュールを設定できます。ルーターは、PHB で指示された優先順位に従って各フローを転送します。あとに続くホップ上の Diffserv 対応システムも同じ PHB を認識する場合を除いて、ネットワークの境界ルーターを越えて PHB を適用することはできません。
「完全優先転送」(EF) は、推奨される EF コードポイント 46 (101110) の付いたパケットが、ネットワークに送出される時に、可能なかぎり最良の扱いを受けることを保証します。完全優先転送は、しばしば専用回線に例えられます。コードポイント 46 (101110) を持つパケットには、宛先に向かう途中、すべての Diffserv ルーターによる優先待遇が保証されます。EF の技術情報については、RFC 2598 (An Expedited Forwarding PHB) を参照してください。
「相対的優先転送」(AF) では、4 つの異なるクラスの転送動作をマーカーに指定できます。次の表に、クラス、各クラスに指定できる 3 つのドロップ優先度、および各優先度に対応する推奨 DSCP を示します。各 DSCP は、AF 値 (10 進数値およびバイナリ値) で表されます。
表 37–2 相対的優先転送のコードポイント
|
クラス 1 |
クラス 2 |
クラス 3 |
クラス 4 |
---|---|---|---|---|
低ドロップ優先度 |
AF11 = 10 (001010) |
AF21 = 18 (010010) |
AF31 = 26 (011010) |
AF41 = 34 (100010) |
Medium-Drop Precedence |
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 対応システム上で使用できます。
これらのパケットが Diffserv ルーターに達すると、ルーターはパケットのコードポイントを、キュー内のほかのトラフィックの DSCP とともに評価します。次にルーターは、利用可能な帯域幅、およびパケットの DSCP により割り当てられた優先順位に応じて、パケットを転送またはドロップします。EF PHB の付いたパケットは、どの AF PHB の付いたパケットよりも広い帯域幅の使用が保証されます。
ネットワーク上の IPQoS システムと Diffserv ルーターとの間でパケットのマーキングを合致させて、パケットが意図したとおりに転送されるようにしてください。たとえば、ネットワーク上の IPQoS システムがパケットにコードポイント AF21 (010010)、AF13 (001110)、AF43 (100110)、および EF (101110) を付けるとします。この場合、AF21、AF13、AF43、および EF DSCP を、Diffserv ルーターの適切なファイルに追加する必要があります。
AF コードポイント表の技術的な説明については、RFC 2597 を参照してください。ルーターの製造元である Cisco Systems とJuniperNetworks は、Web サイトに AF PHB の設定に関する詳細な情報を載せています。この情報を使用して、IPQoS システムおよびルーター用の AF PHB を定義できます。また、ルーター製造元のマニュアルには、自社製品での DS コードポイントの設定方法が含まれています。
DSCP の長さは 6 ビットです。DS フィールドの長さは 1 バイトです。DSCP を定義すると、マーカーは、DS コードポイントでパケットヘッダーの最初の 6 つの重みビットをマークします。残りの 2 ビットは、使用されません。
DSCP を定義するには、マーカーアクション文の中で次のパラメータを使用します。
dscp_map{0-63:DS_codepoint} |
dscp_map パラメータは、(DSCP) 値を使用して生成する 64 要素の配列です。dscp_map は、dscpmk マーカーによって着信 DSCP を発信 DSCP にマップするために使用されます。
DSCP 値は、10 進表記で dscp_map に指定する必要があります。たとえば、EF コードポイント 101110 は 10 進数値 46 に変換する必要があり、その結果 dscp_map{0-63:46} になります。AF コードポイントの場合は、表 37–2 のさまざまなコードポイントを 10 進数表記に変換して、dscp_map で使用できるようにしてください。
dlcosmk マーカーモジュールは、データグラムの MAC ヘッダー内に転送動作をマークします。VLAN インタフェースを持つ IPQoS システムでだけ、dlcosmk を使用できます。
dlcosmk は、「VLAN タグ」と呼ばれる 4 バイトを MAC ヘッダーに追加します。VLAN タグには、IEEE 801.D 標準に定義されている 3 ビットのユーザー優先順位値が含まれます。VLAN を認識する Diffserv 対応スイッチは、データグラム内のユーザー優先順位フィールドを読み取ることができます。801.D ユーザー優先順位値は、サービスクラス (CoS) マークを実装します。CoS マークは、商用スイッチで一般的に使われています。
次の表のサービスマークのクラスを定義することによって、dlcosmk マーカーアクションのユーザー優先値を使用できます。
表 37–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 マーカーアクションは、CoS が 4 でクラスが myclass のデータグラムに VLAN マークを追加するように dlcosmk に指示します。ユーザー優先値 4 は、2 台のマシン間の切り替えによって、machine1 からの myclass トラフィックフローへの制御された負荷転送を指定しなければならないことを示します。
IPQoS の flowacct モジュールは、トラフィックフローに関する情報を記録します。このプロセスは、「フローアカウンティング」と呼ばれます。フローアカウンティングは、顧客への課金や特定クラスへのトラフィック量の評価に使用できるデータを作成します。
フローアカウンティングは、オプションです。通常、flowacct は、メーターまたはマーカーに処理されたトラフィックフローが、ネットワークストリームへ送出される前に通る、最後のモジュールです。Diffserv モデルでの flowacct の位置の図については、図 32–1 を参照してください。flowacct の詳細な技術情報については、flowacct(7ipp) のマニュアルページを参照してください。
フローアカウンティングを有効にするには、flowacct に加えて、Oracle Solaris の exacct アカウンティング機能および acctadm コマンドを使用する必要があります。フローアカウンティングの設定の全手順については、「フローアカウンティングの設定 (作業マップ)」を参照してください。
flowacct モジュールは、「フローレコード」で構成された「フローテーブル」内に、フローに関する情報を収集します。テーブル内の各エントリには、1 つのフローレコードが含まれます。フローテーブルは、表示できません。
フローレコードを測定してフローテーブルへ書き込むには、IPQoS 構成ファイル内で次の flowacct パラメータを定義します。
timer – タイムアウトしたフローをフローテーブルから削除し、acctadm により作成されたファイルに書き込む間隔を、ミリ秒単位で定義する
timeout – パケットフローがタイムアウトするまでの非アクティブな時間を、ミリ秒単位で定義する
timer と timeout には異なる値を指定できます。
max_limit – フローテーブルに格納可能なフローレコードの数に上限を設定する
flowacct パラメータの IPQoS 構成ファイルでの使用例については、「IPQoS 構成ファイル内でフロー制御を構成する方法」を参照してください。
flowacct モジュールは、flowacct インスタンスが認識するすべてのパケットフローを記録するフローテーブルを管理します。フローは、次のパラメータによって特定されます。これらを、flowacct の 8 タプルと呼びます。
発信元アドレス
着信先アドレス
発信元ポート
着信先ポート
DSCP
ユーザー ID
プロジェクト ID
プロトコル番号
フローの 8 タプルのパラメータが変化しないかぎり、フローテーブルには 1 つのエントリだけが含まれます。max_limit パラメータにより、フローテーブルに含めることのできるエントリ数が決定されます。
フローテーブルは、IPQoS 構成ファイル内の timer パラメータに指定された間隔でスキャンされます。デフォルトは 15 秒です。IPQoS 構成ファイル内の timeout 間隔に指定された時間以上、IPQoS システムがパケットを認識しない場合、フローは「タイムアウト」します。デフォルトのタイムアウト間隔は 60 秒です。タイムアウトしたエントリは、acctadm コマンドを使用して作成されたアカウンティングファイルに書き込まれます。
flowacct レコードには、次の表に示される属性が含まれています。
表 37–4 flowacct レコードの属性
属性名 |
属性の内容 |
種類 |
---|---|---|
src-addr-address-type |
オリジネータの発信元アドレス。address-type は、IPQoS 構成ファイルの指定に従い、v4 (IPv4 の場合) または v6 (IPv6 の場合) になる |
基本 |
dest-addr-address-type |
パケットの着信先アドレス。address-type は、IPQoS 構成ファイルの指定に従い、v4 (IPv4 の場合) または v6 (IPv6 の場合) になる |
基本 |
src-port |
フローの起点となる発信元ポート |
基本 |
dest-port |
ブローの宛先となる着信先ポート番号 |
基本 |
プロトコル |
フローのプロトコル番号 |
基本 |
total-packets |
フロー内のパケット数 |
基本 |
total-bytes |
フロー内のバイト数 |
基本 |
action-name |
このフローを記録した flowacct アクションの名前 |
基本 |
creation-time |
flowacct がそのフローのパケットを最初に認識した時間 |
拡張 (Extended) のみ |
last-seen |
そのフローのパケットを最後に認識した時間 |
拡張 (Extended) のみ |
diffserv-field |
フローの発信パケットヘッダー内の DSCP |
拡張 (Extended) のみ |
user |
アプリケーションから取得される UNIX ユーザー ID またはユーザー名 |
拡張 (Extended) のみ |
projid |
アプリケーションから取得されるプロジェクト ID |
拡張 (Extended) のみ |
acctadm コマンドを使用して、flowacct により生成されるさまざまなフローレコードを格納するファイルを作成します。acctadm は、拡張アカウンティング機能と連動して動作します。acctadm の技術的情報については、acctadm(1M) のマニュアルページを参照してください。
flowacct モジュールは、フローを観察し、フローレコードにフローテーブルを入力します。次に flowacct は、timer に指定された間隔でパラメータと属性を評価します。last_seen 値に timeout 値を加えた時間以上パケットが検出されない場合、パケットはタイムアウトします。タイムアウトしたエントリはすべて、フローテーブルから削除されます。削除されたタイムアウトエントリは、timer パラメータに指定された時間が経過するたびに、アカウンティングファイルに書き込まれます。
acctadm を呼び出して flowacct モジュールで使用するには、次の構文を使用します。
acctadm -e file-type -f filename flow
acctadm を -e オプションを指定して呼び出します。-e は、直後にタイプを指定することを示します。
収集するタイプを指定します。file-type は、basic または extended に置き換える必要があります。各ファイルタイプの属性の一覧については、表 37–4 を参照してください。
フローレコードを格納するファイル file-name を作成します。
acctadm を IPQoS 上で実行することを示します。
この節では、IPQoS 構成ファイル各部の詳細を説明します。IPQoS のブート時にアクティブになるポリシーは、/etc/inet/ipqosinit.conf ファイルに格納されています。このファイルは編集可能ですが、新しい IPQoS システムの場合、別の名前で構成ファイルを作成するのが最善の方法です。IPQoS 構成の適用とデバッグについては、第 34 章IPQoS 構成ファイルの作成 (手順)で説明されています。
IPQoS 構成ファイルの構文については、例 37–3 を参照してください。この例では、次の表記上の規則に従います。
computer-style type – 構成ファイル各部を説明する構文情報。このテキストは、入力しない
bold type – IPQoS 構成ファイルに入力する必要のあるリテラルテキスト。たとえば、IPQoS 構成ファイルは、常に fmt_version で始める必要がある
イタリック体 – 構成を説明する情報と置き換える変数テキスト。たとえば、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 構成ファイルを新規作成する場合、必ずバージョン番号から始める必要があります。ついで、次の action 文を追加して、クラシファイアを呼び出す必要があります。
fmt_version 1.0 action { module ipgpc name ipgpc.classify } |
クラシファイア action 文の次に、params 句または class 句を記述します。
action { name action-name module module-name params-clause | "" cf-clauses }
アクションに名前を付ける
呼び出し予定の IPQoS モジュールを識別します。表 37–5 のモジュールの 1 つでなければなりません。
クラシファイアが処理するパラメータ (グローバル統計、次に処理するアクションなど) を指定する
class 句または filter 句のゼロ以上のセット
モジュールの定義によって、action 文のパラメータを処理するモジュールが示されます。IPQoS 構成ファイルには、次のモジュールを含めることができます。
表 37–5 IPQoS モジュール
モジュール名 |
定義 |
---|---|
ipgpc |
IP クラシファイア |
dscpmk |
IP パケット内で DSCP 作成に使用するマーカー |
dlcosmk |
VLAN デバイスで使用するマーカー |
tokenmt |
トークンバケットメーター |
tswtclmt |
タイムスライディングウィンドウメーター |
flowacct |
フローアカウンティングモジュール |
IPQoS 構成内の残りのクラスを定義するには、次の構文を使用します。
class { name class-name next_action next-action-name } |
特定のクラスに関する統計情報収集を有効にするには、最初に ipgpc.classify アクション文でグローバル統計を有効にする必要があります。詳細は、「action 文」を参照してください。
クラスに関する統計を収集したいときは、enable_stats TRUE 文を使用します。クラスの統計を収集する必要がない場合は、enable_stats FALSE を指定します。あるいは、 enable_stats 文を削除してもかまいません。
IPQoS 対応ネットワーク上のトラフィックは、特に定義しなければ「デフォルトクラス」になります。
「フィルタ」は、トラフィックフローをクラスに分類するセレクタで構成されます。これらのセレクタは、クラス句で作成されたクラスのトラフィックへ適用する条件を、明確に定義します。パケットがもっとも高い優先順位のフィルタのセレクタすべてに一致する場合、パケットはそのフィルタのクラスのメンバーと見なされます。ipgpc クラシファイアと使用できるセレクタの完全なリストについては、表 37–1 を参照してください。
次の構文を持つ「filter 句」を使用して 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 命令は、グローバル統計を呼び出した action 文に関する UNIX スタイルの統計を有効にします。kstat コマンドを使用して、統計情報を表示できます。クラス単位の統計を有効にする前に、action 文の統計を有効にする必要があります。
IPQoS 構成ファイルを読んだり、UNIX カーネル内の IPQoS モジュールを構成したりするには、ipqosconf ユーティリティーを使用します。ipqosconf は、次のアクションを実行します。
構成ファイルを IPQoS カーネルモジュールに適用する (ipqosconf -a filename)
カーネル内に現在常駐している IPQoS 構成ファイルを表示する (ipqosconf -l)
マシンをリブートするたびに、現行の IPQoS 構成を読み取り、適用するようにする (ipqosconf -c)
現行の IPQoS カーネルモジュールをフラッシュする (ipqosconf -f)
技術的な情報は、ipqosconf(1M) のマニュアルページを参照してください。