パート VII IP サービス品質 (IPQoS)

このパートには、Oracle Solaris での差別化サービス実装である IP サービス品質 (IPQoS) に関する作業と関連情報を記載します。

第 32 章 IPQoS の紹介 (概要)

IP サービス品質 (IPQoS) を使用すると、優先順位付け、管理、およびアカウンティング統計情報の収集を行うことができます。IPQoS によって、ネットワークのユーザーに一貫したサービスレベルを提供できます。また、ネットワークの輻輳を防ぐために、トラフィックを管理することもできます。

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

• 「IPQoS の基本」

• 「IPQoS によるサービス品質の提供」

• 「IPQoS によるネットワーク効率の向上」

• 「差別化サービスモデル」

• 「IPQoS 対応ネットワークでのトラフィック転送」

IPQoS の基本

IPQoS は、Internet Engineering Task Force (IETF) の Differentiated Services Working Group によって定義されている差別化サービス (Diffserv) アーキテクチャーに対応しています。Oracle Solaris では、TCP/IP プロトコルスタックの IP レベルで IPQoS が実装されます。

差別化サービスとは

IPQoS を有効にすることで、選択した顧客および選択したアプリケーションに対して、異なるレベルのネットワークサービスを提供できます。この異なるレベルのサービスは、まとめて「差別化サービス」と呼ばれます。顧客に提供する差別化サービスは、ユーザーの企業が顧客に提供するサービスレベルの構造を基に決定できます。ネットワーク上のアプリケーションやユーザーに設定した優先順位に基づく場合もあります。

サービス品質を提供するためには、次の作業を行います。

• 顧客や企業内の部署などのグループごとに異なるサービスレベルを提供する

• 特定のグループやアプリケーションにネットワークサービスを優先的に提供する

• ネットワーク上の障害やその他の輻輳の発生箇所を特定し、問題を取り除く

• ネットワークパフォーマンスを監視し、パフォーマンスの統計情報を提供する

• ネットワーク資源に対する帯域幅を調整する

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 年

サービス品質に関する RFC (Request for Comments)

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 アーキテクチャーを実装するためのモデルを紹介している

サービス品質に関する情報が掲載されている Web サイト

IETF の Differentiated Services Working Group は、Diffserv Internet Draft へのリンクを含む Web サイト (http://www.ietf.org/html.charters/diffserv-charter.html) を管理しています。

Cisco Systems 社や Juniper Networks 社などのルーター製造元は、それぞれ自社の Web サイトで、差別化サービスの製品への実装状況について解説しています。

IPQoS のマニュアルページ

IPQoS の文書には、次のマニュアルページが含まれます。

• 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 によるサービス品質の提供

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 対応システム」とみなされます。

QoS ポリシーは、一般に次のことを定義します。

• 「サービスクラス」と呼ばれるネットワークトラフィックの個別グループ

• クラスごとにネットワークトラフィックの量を調整するための測定基準。これらの測定基準によって、「メータリング」と呼ばれるトラフィック測定プロセスが管理される

• IPQoS システムおよび Diffserv ルーターがパケットフローに適用するアクション。このアクションは「ホップ単位動作 (PHB)」と呼ばれる

• サービスのクラスで必要な統計の収集。たとえば、顧客または特定のアプリケーションが生成したトラフィックなどがある

パケットがネットワークに渡されると、IPQoS 対応システムはパケットヘッダーを評価します。IPQoS システムが行うアクションは、作成した QoS ポリシーに応じて決まります。

QoS ポリシーの設計作業については、「サービス品質ポリシーの計画」に説明があります。

IPQoS によるネットワーク効率の向上

IPQoS には、サービス品質の実装に伴ってネットワークパフォーマンスの効率を向上させるのに役立ついくつかの機能が含まれています。コンピュータネットワークが拡大すると、ユーザーや高機能なプロセッサの数が増加して、生成されるネットワークトラフィックを管理する必要性も増大します。ネットワークを過度に使用すると、データの消失やトラフィックの輻輳などの症状が現れます。どちらの症状も応答時間を遅らせます。

従来、システム管理者は帯域幅を拡張する方法でネットワークトラフィックの問題に対処してきました。しかし同時に、リンクごとのトラフィックのレベルには、大きなばらつきが見られがちでした。IPQoS を使用すると、既存のネットワーク上のトラフィックを管理しながら、ネットワークの拡大が必要かどうか、またどこに必要かを評価できます。

たとえば、企業や法人の場合は、効率的なネットワークを維持して、トラフィックに関する障害の発生を防ぐ必要があります。また、グループやアプリケーションが割り当てられた以上の帯域幅を消費しないようにする必要もあります。ISP や ASP は、顧客が料金分のレベルのネットワークサービスを確実に受けられるようにネットワークパフォーマンスを管理する必要があります。

ネットワークトラフィックへの帯域幅の影響

IPQoS を使用すると、ネットワークの「帯域幅」、つまりネットワークリンクまたはデバイスが完全に使用された場合に転送できるデータの最大量を調整できます。サービス品質を顧客またはユーザーに提供するには、QoS ポリシーで、帯域幅の使用に優先順位を付ける必要があります。IPQoS のメータリングモジュールを使用すると、IPQoS 対応ホスト上の各トラフィッククラスへの帯域幅の割り当て量を測定および管理できます。

ネットワーク上のトラフィックを効果的に管理するには、帯域幅の使用量に関して、次の点を明らかにしておく必要があります。

• ローカルネットワークのトラフィック問題の発生箇所はどこか

• 帯域幅を最適利用するために行うべきことは何か

• サイト内で最優先するべき、重要なアプリケーションはどれか

• 輻輳が発生しやすいアプリケーションはどれか

• 優先順位を落としてもよい、重要度の低いアプリケーションはどれか

サービスクラスを使ったトラフィックの優先順位付け

サービス品質を実現するには、ネットワークトラフィックを分析して、トラフィックを分類する大まかなグループ分けを決定します。次に、それぞれ特徴と優先順位を持つサービスクラスに各グループ分けを整理します。これらのクラスが基本的なカテゴリとなり、それに基づいて組織の QoS ポリシーを作成します。サービスクラスは、管理の対象となるトラフィックグループを代表します。

たとえば、プロバイダがプラチナ、ゴールド、シルバー、ブロンズの各レベルのサービスをそれぞれ異なる利用料金で提供するとします。プラチナレベルの SLA では、プロバイダが顧客用に運営している Web サイト宛ての着信トラフィックに対して、もっとも高い優先順位を保証します。このように、ある顧客の Web サイト宛ての着信トラフィックを 1 つのトラフィッククラスとしてまとめることができます。

企業向けには、部門の要求に基づくサービスクラスを作成できます。また、ネットワークトラフィック内の特定のアプリケーションの優位性に基づくクラスを作成することもできます。次に、企業向けのトラフィッククラスの例をいくつか示します。

• 特定のサーバー宛ての電子メールや発信 FTP などの、よく使われるアプリケーション。アプリケーションごとに 1 つのクラスを構成できる。これらのアプリケーションは従業員によって絶えず使用されるため、QoS ポリシーで、電子メールと発信 FTP には少量の帯域幅と低い優先順位を割り当てる

• 一日 24 時間実行の必要がある注文入力データベース。企業にとってのデータベースアプリケーションの重要度に応じて、大量の帯域幅と高い優先順位を割り当てる

• 人事部門などの、極めて重要な業務または機密業務を行う部署。組織にとっての部署の重要度に応じて、割り当てる優先順位と帯域幅の大きさを決める

• 企業の外部向け Web サイトへの呼び出し。このクラスには、適度な大きさの帯域幅と低い優先順位を割り当てる

差別化サービスモデル

IPQoS には次のモジュールがあります。これらのモジュールは、RFC 2475 に定義されている「差別化サービス (diffserv)」アーキテクチャーの一部です。

• クラシファイア

• メーター

• マーカー

IPQoS では、次の拡張機能が Diffserv モデルに追加されています。

• フローアカウンティングモジュール

• 802.1D データグラムマーカー

この節では、IPQoS で使用する Diffserv モジュールについて簡単に説明します。QoS ポリシーを設定するには、これらのモジュール、その名前、およびその使用目的を認識しておく必要があります。各モジュールの詳細は、「IPQoS アーキテクチャーと Diffserv モデル」を参照してください。

クラシファイア (ipgpc) の概要

Diffserv モデルでは、「クラシファイア」がネットワークトラフィックフローからパケットを選択します。「トラフィックフロー」は、次の IP ヘッダーフィールド内に同一の情報を持つパケットのグループで構成されます。

• 発信元アドレス

• 着信先アドレス

• 発信元ポート

• 着信先ポート

• プロトコル番号

IPQoS では、これらのフィールドを「5 タプル」と呼びます。

IPQoS のクラシファイアモジュールの名前は ipgpc です。ipgpcクラシファイアは、トラフィックフローを、IPQoS 構成ファイルに設定されている特性に基づいたクラスに分類します。

ipgpc の詳細については、「クラシファイアモジュール」を参照してください。

IPQoS クラス

「クラス」とは、似たような特性を共有するネットワークフローのグループのことです。たとえば、ISP は、顧客に提供するさまざまなサービスレベルを表すクラスを定義できます。一方、ASP は、アプリケーションごとに異なるサービスレベルを提供する SLA を定義できます。ASP の QoS ポリシーでは、特定の着信先 IP アドレス宛ての発信 FTP トラフィックを 1 つのクラスにまとめることができます。ある企業の外部 Web サイトからの発信トラフィックも、1 つのクラスとして定義できます。

トラフィックをいくつかのクラスに分類することは、QoS ポリシーを計画する際に欠かせない作業の 1 つです。ipqosconf ユーティリティーを使用してクラスを作成するときは、実際にはipgpc クラシファイアを構成しています。

クラスを定義するには、「QoS ポリシーのクラスを定義する方法」を参照してください。

IPQoS フィルタ

「フィルタ」は、「セレクタ」と呼ばれるパラメータを含む規則のセットです。各フィルタは、必ず 1 つのクラスを指定する必要があります。IPQoS は、パケットを各フィルタのセレクタと突き合わせて、パケットがフィルタのクラスに属しているかどうかを調べます。さまざまなセレクタを使用してパケットにフィルタをかけることができます。セレクタの例として、IPQoS 5 タプルなどのよく使うパラメータを次に示します。

• 発信元および着信先のアドレス

• 発信先および着信先のポート

• プロトコル番号

• ユーザー ID

• プロジェクト ID

• 差別化サービスコードポイント (DSCP)

• インタフェースインデックス

たとえば、簡単なフィルタに値が 80 の宛先ポートが含まれているとします。ipgpc クラシファイアは、宛先ポート 80 (HTTP) 向けのパケットをすべて選択し、QoS ポリシーの指示どおりに選択したパケットを処理します。

フィルタの作成については、「QoS ポリシーにフィルタを定義する方法」を参照してください。

メーター (tokenmt および tswtclmt) の概要

Diffserv モデルでは、「メーター」はトラフィックフローの転送速度をクラス単位で追跡します。メーターは、該当する結果 (outcome) を得るために、フローの実際の転送速度が設定された速度にどれだけ適合しているかを評価します。そして、トラフィックフローの結果に基づいて、次のアクションを選択します。次のアクションでは、パケットを別のアクションに送信したり、それ以上処理しないでネットワークに戻したりできます。

IPQoS のメーターは、ネットワークフローが、QoS ポリシーでそのクラスに定義されている転送速度に適合しているかどうかを調べます。IPQoS には、次の 2 つのメータリングモジュールがあります。

• tokenmt - 2 トークンバケットメータリング方式を使用

• tswtclmt - タイムスライディングウィンドウメータリング方式を使用

どちらのメータリングモジュールも、 赤、黄、緑という 3 つの結果を識別します。結果ごとに実行させたいアクションは、red_action_name、yellow_action_name、および green_action_name のパラメータで定義します。

また、tokenmt をカラーアウェアとして構成することもできます。カラーアウェアとして構成されているメータリングインスタンスでは、パケットのサイズ、DSCP、トラフィックの転送速度、および設定されたパラメータを使って結果を求めます。メーターは、DSCP を使用してパケットの結果を緑、黄、赤にマッピングします。

IPQoS メーターのパラーメータの定義については、「フロー制御を計画する方法」を参照してください。

マーカー (dscpmk および dlcosmk) の概要

Diffserv モデルでは、「マーカー」は転送動作を表す値をパケットに付けます。「マーキング」とは、パケットをネットワークに転送する方法を示す値を、そのパケットのヘッダーに付加するプロセスのことです。IPQoS には、次の 2 つのマーカーモジュールが含まれています。

• dscpmk – IP パケットヘッダーの DS フィールドに「差別化サービスコードポイント (DSCP)」と呼ばれる数値を付けます。Diffserv 対応ルーターは、この DS コードポイントを使って、適切な転送動作をパケットに適用できます。

• dlcosmk – Ethernet フレームヘッダーの仮想ローカルエリアネットワーク (VLAN) タグに「ユーザー優先順位」と呼ばれる数値を付けます。ユーザー優先順位は、データグラムに適用される適切な転送動作を定義する「サービスクラス (CoS)」のことです。

  dlcosmk は、IPQoS の追加機能として IETF によって設計されたものであり、Diffserv モデルの一部ではありません。

QoS ポリシーのマーカー戦略の実装については、「転送動作を計画する方法」を参照してください。

フローアカウンティング (flowacct) の概要

IPQoS では、flowacct アカウンティングモジュールが Diffserv モデルに追加されています。flowacct を使用すると、トラフィックフローに関する統計情報を取得し、SLA に合わせて顧客に課金できます。フローアカウンティングは、容量計画やシステムの監視にも役立ちます。

flowacct モジュールを acctadm コマンドと組み合わせて、アカウンティングログファイルを作成できます。基本的なログには、次に示すように、IPQoS 5 タプルのほかに 2 つの属性が記録されます。

• 発信元アドレス

• 発信元ポート

• 着信先アドレス

• 着信先ポート

• プロトコル番号

• パケット数

• バイト数

「トラフィックフローに関する情報の記録」および flowacct(7ipp) や acctadm(1M) のマニュアルページに説明されているとおり、その他の属性の統計を集めることもできます。

フローアカウンティング戦略の計画については、「フローアカウンティングを計画する方法」を参照してください。

トラフィックが IPQoS モジュールをどのように通過するか

次の図は、着信トラフィックが IPQoS モジュールのいくつかを通過するときに取りうる経路を示しています。

図 32–1 diffserv モデルの IPQoS 実装を通過するトラフィックフロー

この図は、IPQoS 対応マシンにおける一般的なトラフィックフローシーケンスを示しています。

1. クラシファイアが、システムの QoS ポリシーのフィルタリング条件に適合するすべてのパケットをパケットストリームから選択します。

2. 選択したパケットが評価されて、次に実行されるアクションが決められます。

3. クラシファイアが、フロー制御を必要としないトラフィックをマーカーに送信します。

4. フロー制御が必要なトラフィックは、メーターに送信されます。

5. メーターは、設定速度を実施します。次に、トラフィックの適合値をフロー制御されているパケットに割り当てます。

6. フロー制御されるパケットが評価されて、アカウンティングが必要であるかどうかが判断されます。

7. メーターが、フローアカウンティングを必要としないトラフィックをマーカーに送信します。

8. フローアカウンティングモジュールが、受信したパケットに関する統計情報を収集します。次に、それらのパケットをマーカーに送信します。

9. マーカーが DS コードポイントをパケットヘッダーに割り当てます。この DSCP は、Diffserv 対応システムがパケットに適用するべきホップ単位動作 (PHB) を示します。

IPQoS 対応ネットワークでのトラフィック転送

この節では、IPQoS 対応ネットワークでのパケット転送に関係するいくつかの要素について簡単に説明します。IPQoS 対応システムは、着信先としてそのシステムの IP アドレスを持つ、ネットワークストリーム上のパケットを処理します。そして、IPQoS システムの QoS ポリシーをパケットに適用して、差別化サービスを確立します。

DS コードポイント

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 環境でのパケット転送

次の図は、Diffserv 対応環境を部分的に備えた企業のイントラネット部分を示しています。このシナリオでは、ネットワーク 10.10.0.0 および 10.14.0.0 上のホストはすべて IPQoS に対応しており、ローカルルーターは Diffserv に対応しています。しかし、間にある 2 つのネットワークは Diffserv に対応していません。

図 32–2 diffserv 対応ネットワークのホップ間のパケット転送

次の手順は、前の図に示すパケットの流れをたどっています。この手順は、ホスト ipqos1 で発生するパケットの前進で開始されます。手順は数回のホップでホスト ipqos2 に続きます。

1. ipqos1 のユーザーが ftp コマンドを実行して、3 ホップ離れたところにあるホスト ipqos2 にアクセスしようとします。

2. ipqos1 は、結果生じたパケットフローに QoS ポリシーを適用します。ipqos1 は、ftp トラフィックを正常に分類します。

   システム管理者は、ローカルネットワーク 10.10.0.0 で発生するすべての発信 ftp トラフィックのためのクラスを作成しています。ftp クラスのトラフィックには、次のような AF22 ホップ単位動作を割り当てます。 クラス 2、標準ドロップ優先順位ftp クラスには、2Mb/秒のトラフィックフロー速度が設定されます。

3. ipqos-1 は、ftp フローを測定し、フローが 2 Mbit/秒を超過していないかどうかを判断します。

4. ipqos1 上のマーカーが、発信 ftp パケットの DS フィールドに 010100 DSCP (AF22 PHB に対応している) を付加します。

5. ルーター diffrouter1 は、ftp パケットを受信します。次に、DSCP をチェックします。diffrouter1 が輻輳している場合、AF22 でマークされているパケットは振り落とされます。

6. diffrouter1 のファイルで AF22 に対して設定されている PHB に合わせて、ftp トラフィックが次のホップに転送されます。

7. ftp トラフィックがネットワーク 10.12.0.0 を通って genrouter に進みます。genrouter は Diffserv に対応していません。その結果、トラフィックはベストエフォートの転送動作を与えられます。

8. genrouter が ftp トラフィックをネットワーク 10.13.0.0 に渡し、diffrouter2 がそのトラフィックを受け取ります。

9. diffrouter2 は Diffserv に対応しています。したがって、ルーターのポリシーで AF22 パケットに対して定義されている PHB に合わせて、ftp パケットをネットワークに転送します。

10. ipqos2 は、ftp トラフィックを受信します。 ipqos2 は、ipqos1 のユーザーにユーザー名とパスワードの入力を促します。

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

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

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

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

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

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

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

• 「IPQoS の構成例の紹介」

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

IPQoS などの差別化サービスをネットワーク上に実装する場合は、綿密な計画が必要です。各 IPQoS 対応システムの位置と機能だけではなく、各システムとローカルネットワーク上のルーターとの関係についても考慮してください。次の作業マップに、ネットワーク上で IPQoS を実装するための主な計画作業の一覧と、各作業を完了するための手順へのリンクを示します。

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

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

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

一般に、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 計画を図で説明します。

個々のホストでの IPQoS

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

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

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

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

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

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

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

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

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

ファイアウォールでの IPQoS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クラスの優先順位付け

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

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

フィルタの定義

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

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

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

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

始める前に

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

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

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

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

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

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

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

参照

• フロー制御スキームを定義するには、「フロー制御を計画する方法」を参照してください。

• フローがネットワークストリームに戻るときのフローの転送動作を定義するには、「転送動作を計画する方法」を参照してください。

• 特定の種類のトラフィックのフローアカウンティングを計画するには、「フローアカウンティングを計画する方法」を参照してください。

• QoS ポリシーにさらにクラスを追加するには、「QoS ポリシーのクラスを定義する方法」を参照してください。

• QoS ポリシーにさらにフィルタを追加するには、「QoS ポリシーにフィルタを定義する方法」を参照してください。

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

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

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

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

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

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

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

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

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

   ---

   注 –

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

   ---

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

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

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

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

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

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

   • 認定速度

   • 最大速度

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

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

   • 認定バースト

   • 最大バースト

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

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

   • 認定速度

   • 最大速度

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

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

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

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

例 33–2 メーターの定義

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

参照

• パケットがネットワークストリームに戻るときのフローの転送動作を定義するには、「転送動作を計画する方法」を参照してください。

• 特定の種類のトラフィックのフローアカウンティングを計画するには、「フローアカウンティングを計画する方法」を参照してください。

• QoS ポリシーにさらにクラスを追加するには、「QoS ポリシーのクラスを定義する方法」を参照してください。

• QoS ポリシーにさらにフィルタを追加するには、「QoS ポリシーにフィルタを定義する方法」を参照してください。

• 別のフロー制御スキームを定義するには、「フロー制御を計画する方法」を参照してください。

• IPQoS 構成ファイルを作成するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。

転送動作を計画する方法

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

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

• dscpmk – IP パケットの DS フィールドに DSCP を付けるために使用する

• dlcosmk – データグラムの VLAN タグにサービスクラス (CoS) 値を付けるために使用する

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

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

始める前に

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

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

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

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

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

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

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

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

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

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

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

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

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

参照

• 特定の種類のトラフィックのフローアカウンティングを計画するには、「フローアカウンティングを計画する方法」を参照してください。

• QoS ポリシーにさらにクラスを追加するには、「QoS ポリシーのクラスを定義する方法」を参照してください。

• QoS ポリシーにさらにフィルタを追加するには、「QoS ポリシーにフィルタを定義する方法」を参照してください。

• フロー制御スキームを定義するには、「フロー制御を計画する方法」を参照してください。

• パケットがネットワークストリームに戻るときのフローの転送動作をさらに定義するには、「転送動作を計画する方法」を参照してください。

• IPQoS 構成ファイルを作成するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。

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

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

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

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

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

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

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

参照

• QoS ポリシーにさらにクラスを追加するには、「QoS ポリシーのクラスを定義する方法」を参照してください。

• QoS ポリシーにさらにフィルタを追加するには、「QoS ポリシーにフィルタを定義する方法」を参照してください。

• フロー制御スキームを定義するには、「フロー制御を計画する方法」を参照してください。

• パケットがネットワークストリームに戻るときのフローの転送動作を定義するには、「転送動作を計画する方法」を参照してください。

• 特定の種類のトラフィックの追加フローのアカウンティングを計画するには、「フローアカウンティングを計画する方法」を参照してください。

• IPQoS 構成ファイルを作成するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。

IPQoS の構成例の紹介

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

IPQoS トポロジ

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

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

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 ルーターによって制御されます。

第 34 章 IPQoS 構成ファイルの作成 (手順)

この章では、IPQoS 構成ファイルの作成方法について説明します。この章では、次の内容について説明します。

• 「IPQoS 構成ファイル内での QoS ポリシーの定義 (作業マップ)」

• 「QoS ポリシー作成用のツール」

• 「Web サーバー用 IPQoS 構成ファイルの作成」

• 「アプリケーションサーバー用 IPQoS 構成ファイルの作成」

• 「ルーター上での差別化サービスの提供」

この章の説明は、完全な QoS ポリシーを定義していること、このポリシーを IPQoS 構成ファイルのベースとしてすぐに使用できることを前提としています。QoS ポリシーを計画するには、「サービス品質ポリシーの計画」を参照してください。

IPQoS 構成ファイル内での QoS ポリシーの定義 (作業マップ)

この作業マップでは、IPQoS 構成ファイルを作成するための一般的な作業の一覧と、各作業の実行手順を説明した節へのリンクを示します。

QoS ポリシー作成用のツール

ネットワーク用の QoS ポリシーは、IPQoS 構成ファイル内に格納します。テキストエディタでこの構成ファイルを作成します。次に、作成したファイルを IPQoS 構成ユーティリティー ipqosconf の引数とします。ipqosconf に対し、構成ファイル内で定義されたポリシーの適用を指示すると、ポリシーがカーネル IPQoS システムに書き込まれます。ipqosconf コマンドの詳細については、ipqosconf(1M) のマニュアルページを参照してください。ipqosconf の使用方法については、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。

基本 IPQoS 構成ファイル

IPQoS 構成ファイルは、Planning the Quality-of-Service Policyで定義した QoS ポリシーを実行する 「サービス品質ポリシーの計画」 文のツリーで構成されています。IPQoS 構成ファイルは、IPQoS モジュールの構成を行います。各アクション文には、アクション文の中で呼び出されるモジュールが処理する「クラス」、「フィルタ」、または「パラメータ」のセットが含まれます。

IPQoS 構成ファイルの完全な構文については、例 37–3 および ipqosconf(1M) のマニュアルページを参照してください。

IPQoS トポロジ例の構成

この章では、3 つの IPQoS 対応システム用の IPQoS 構成ファイルを作成する方法を示します。これらのシステムは、図 33–4 で紹介した BigISP 社のネットワークトポロジの一部です。

• Goldweb – プレミアムレベル SLA を購入した顧客用 Web サイトのホストとして機能する Web サーバー

• Userweb – ベストエフォート SLA を購入したホームユーザー向けの個人用 Web サイトのホストとして機能する、やや能力の劣る Web サーバー

• BigAPPS – ゴールドレベルとベストエフォートの両方の顧客に、メール、ネットワークニュース、および FTP を提供するアプリケーションサーバー

3 つの構成ファイルを通して、最も一般的な IPQoS 構成を示します。IPQoS を実装するために、次の節のサンプルファイルをテンプレートとして使用することもできます。

Web サーバー用 IPQoS 構成ファイルの作成

この節では、まず、プレミアム Web サーバー用の構成を通して、IPQoS 構成ファイルを紹介します。次に、個人用 Web サイトのホストとして機能するサーバー用の構成ファイルで、まったく異なるサービスレベルを構成する方法を示します。両方のサーバーは、図 33–4 のネットワーク例の一部です。

次の構成ファイルは、Goldweb サーバーの IPQoS アクティビティーを定義します。このサーバーは、プレミアム SLA を購入した Goldco 社の Web サイトのホストです。

例 34–1 プレミアム Web サーバー用 IPQoS 構成ファイルの例

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 を利用する顧客からのトラフィックを処理したあとに、できるかぎり最良のサービスをベストエフォートの顧客に保証します。

例 34–2 ベストエフォート Web サーバー用の構成例

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 構成ファイルは、メンテナンスしやすい任意のディレクトリに作成できます。この章では、IPQoS 構成ファイルの位置としてディレクトリ /var/ipqos を使用します。次の手順では、例 34–1 の IPQoS 構成ファイルの最初のセグメントを構築します。

IPQoS 構成ファイルを作成する際、各 action 文および句を必ず中括弧 ({ }) で囲んでください。中括弧の使用例については、例 34–1 を参照してください。

1. プレミアム Web サーバーにログインし、新規 IPQoS 構成ファイルを拡張子 .qos を付けて作成します。

   すべての IPQoS 構成ファイルで、最初の非コメント行にバージョン番号 fmt_version 1.0 を記述する必要があります。

2. 冒頭のパラメータに続き、初期 action 文を記述して汎用の IP クラシファイア ipgpc を構成します。

   IPQoS 構成ファイルを成す action 文のツリーは、この初期アクションから始まります。たとえば、/var/ipqos/Goldweb.qos ファイルは、 ipgpc クラシファイアを呼び出す初期 action 文で始まります。

   fmt_version 1.0 action { module ipgpc name ipgpc.classify

   fmt_version 1.0

   IPQoS 構成ファイルを開始する

   action {

   action 文を開始する

   module ipgpc

   構成ファイル内の最初のアクションとして ipgpc クラシファイアを構成する

   name ipgpc.classify

   クラシファイアの action 文の名前を定義する。名前は常に ipgpc.classify でなければならない

   action 文の詳しい構文については、「action 文」および ipqosconf(1M) のマニュアルページを参照してください。

3. 統計パラメータ 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) のマニュアルページを参照してください。

4. プレミアムサーバーに向かうトラフィックを特定するクラスを定義します。

   class { name goldweb next_action markAF11 enable_stats FALSE }

   この文は、「class 句」と呼ばれます。class 句には次の内容が含まれます。

   name goldweb

   goldweb クラスを作成して、Goldweb サーバーに向かうトラフィックを特定する

   next_action markAF11

   ipgpc モジュールに対し、goldweb クラスのパケットをアクション文 markAF11 に渡すよう指示する。アクション文 markAF11 は、 dscpmk マーカーを呼び出す

   enable_stats FALSE

   goldweb クラスの統計取得を可能にする。ただし、enable_stats の値が FALSE であるため、このクラスの統計取得は有効にはならない

   class 句の構文の詳細については、「class 句」と ipqosconf(1M) のマニュアルページを参照してください。

5. もっとも高い優先順位の転送を必要とするアプリケーションを特定するクラスを定義します。

   class { name video next_action markEF enable_stats FALSE }

   name video

   video クラスを作成して、Goldweb サーバーから発信されるストリーミングビデオのトラフィックを特定する

   next_action markEF

   ipgpc モジュールに対し、ipgpc による処理が完了した video クラスのパケットを、markEF 文に渡すよう指示する。markEF 文は、dscpmk マーカーを呼び出す

   enable_stats FALSE

   video クラスの統計収集を可能にする。ただし、enable_stats の値が FALSE であるため、このクラスの統計収集は有効にはならない

参照

• 作成したばかりのクラスにフィルタを定義するには、「IPQoS 構成ファイル内でフィルタを定義する方法」を参照してください。

• 構成ファイルに対して別の class 句を作成するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。

IPQoS 構成ファイル内でフィルタを定義する方法

次の手順では、IPQoS 構成ファイル内でクラスのフィルタを定義します。

始める前に

次の手順の前に、構成ファイルの作成を開始しており、クラスを定義してあるものとします。この手順は、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」で作成された /var/ipqos/Goldweb.qos ファイルを引き続き構築します。

IPQoS 構成ファイルを作成する際、各 class 句および filter 句を必ず中括弧 ({ }) で囲んでください。中括弧の使用例については、例 34–1 を参照してください。

1. IPQoS 構成ファイルを開き、最後に定義したクラスの末尾を探します。

   たとえば、IPQoS 対応サーバー Goldweb 用の構成ファイル /var/ipqos/Goldweb.qos では、次の class 句のあとから作業を始めます。

   class { name video next_action markEF enable_stats FALSE }

2. filter 句を定義し、IPQoS システムからの出力トラフィックを選択します。

   filter { name webout sport 80 direction LOCAL_OUT class goldweb }

   name webout

   フィルタに webout という名前を付ける

   sport 80

   ソースポート 80 のトラフィックを選択する。これは、既知の HTTP (Web) トラフィック用ポート

   direction LOCAL_OUT

   ローカルシステムから発信されるトラフィックを選択する

   class goldweb

   フィルタが所属するクラス (このインスタンスでは goldweb クラス) を特定する

   IPQoS 構成ファイル内の filter 句の構文などについては、「filter 句」を参照してください。

3. IPQoS システムのストリーミングビデオトラフィックを選択する filter 句を定義します。

   filter { name videoout sport videosrv direction LOCAL_OUT class video }

   name videoout

   フィルタに videoout という名前を付ける

   sport videosrv

   ソースポート videosrv のトラフィックを選択する。これは、以前にこのシステムのストリーミングビデオアプリケーション用に定義したポート

   direction LOCAL_OUT

   ローカルシステムから発信されるトラフィックを選択する

   class video

   フィルタが所属するクラス (このインスタンスでは video クラス) を特定する

参照

• マーカーモジュールの転送動作を定義するには、「IPQoS 構成ファイル内でトラフィック転送を定義する方法」を参照してください。

• メータリングモジュールのフロー制御パラメータを定義するには、「IPQoS 構成ファイル内でフロー制御を構成する方法」を参照してください。

• IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。

• さらにフィルタを定義するには、「IPQoS 構成ファイル内でフィルタを定義する方法」を参照してください。

• アプリケーションからのトラフィックフロー向けのクラスを作成するには、「アプリケーションサーバー用 IPQoS 構成ファイルを作成する方法」を参照してください。

IPQoS 構成ファイル内でトラフィック転送を定義する方法

次の手順では、IPQoS 構成ファイルにクラスのホップ単位の動作を追加して、トラフィック転送を定義します。

始める前に

次の手順の前に、既存の IPQoS 構成ファイルにクラスおよびフィルタを定義してあるものとします。この手順では、Example 34–1 の 例 34–1 ファイルを引き続き構築します。

次の手順では、dscpmk マーカーモジュールを使用してトラフィック転送を構成する方法を示します。dlclosmk マーカーを使用した VLAN システムのトラフィック転送については、「VLAN デバイスでの dlcosmk マーカーの使用」を参照してください。

1. IPQoS 構成ファイルを開き、最後に定義したフィルタの末尾を探します。

   たとえば、IPQoS 対応サーバー Goldweb 用の構成ファイル /var/ipqos/Goldweb.qos では、次の filter 句のあとから作業を始めます。

   filter { name videoout sport videosrv direction LOCAL_OUT class video } }

   この filter 句は、ipgpc クラシファイアの action 文の最後に位置します。このため、フィルタを終了させる閉じ括弧のあとに、action 文を終了させる閉じ括弧が必要です。

2. 次の action 文でマーカーを呼び出します。

   action { module dscpmk name markAF11

   module dscpmk

   dscpmk マーカーモジュールを呼び出す

   name markAF11

   action 文に markAF11 という名前を付ける

   以前に定義した goldweb クラスには next_action markAF11 という文が含まれています。この文は、クラシファイアによる処理が完了したトラフィックフローを、アクション文 markAF11 に送信します。

3. トラックフローに対してマーカーが取るアクションを定義します。

   params { global_stats FALSE dscp_map{0-63:10} next_action continue } }

   global_stats FALSE

   マーカー action 文 markAF11 の統計収集を可能にする。ただし、global_stats の値が FALSE であるため、統計は収集されない

   dscp_map{0–63:10}

   DSCP 10 を、マーカーにより処理中の goldweb クラスのパケットヘッダーに割り当てる

   next_action continue

   userweb クラスのパケットに対しこれ以上処理を行う必要がないこと、およびこれらのパケットをネットワークストリームに戻してもよいことを示す

   DSCP 10 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 10 (バイナリ値 001010) に設定するよう指示します 。このコードポイントは、goldweb トラフィッククラスのパケットが AF11 ホップ単位動作 (PHB) に従うことを示します。AF11 は、DSCP 10 を持つすべてのパケットが、低ドロップ、および高い優先順位のサービスを受けることを保証します。このため、Goldweb 上のプレミアム顧客用の発信トラフィックには、AF (相対的優先転送) PHB で指定可能なもっとも高い優先順位が与えられます。AF に設定可能な DSCP の表については、表 37–2 を参照してください。

4. 別のマーカー action 文を開始します。

   action { module dscpmk name markEF

   module dscpmk

   dscpmk マーカーモジュールを呼び出す

   name markEF

   action 文に markEF という名前を付ける

5. トラフィックフローに対してマーカーが取るアクションを定義します。

   params { global_stats TRUE dscp_map{0-63:46} next_action acct } }

   global_stats TRUE

   video クラスの統計収集を有効にする。このクラスはストリーミングビデオのパケットを選択する

   dscp_map{0–63:46}

   DSCP 46 を、マーカーにより処理中の video クラスのパケットヘッダーに割り当てる

   next_action acct

   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」を参照してください。

6. 作成したばかりの DSCP を Diffserv ルーターの適切なファイルに追加します。

   詳細については、「IPQoS 対応ネットワーク上でルーターを構成する方法」を参照してください。

参照

• トラフィックフローのフローアカウンティング統計の収集を開始するには、「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 ファイルを引き続き構築します。

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 } }

2. フローアカウンティングを呼び出す action 文を開始します。

   action { module flowacct name acct

   module flowacct

   flowacct フローアカウンティングモジュールを呼び出す

   name acct

   action 文に acct という名前を付ける

3. トラフィッククラスに関するアカウンティングを制御する params 句を定義します。

   params { global_stats TRUE timer 10000 timeout 10000 max_limit 2048 next_action continue } }

   global_stats TRUE

   video クラスの統計収集を有効にする。このクラスはストリーミングビデオのパケットを選択する

   timer 10000

   フローテーブル内で、タイムアウトしたフローが走査される間隔を、ミリ秒単位で指定する。このパラメータでは、間隔は 10000 ミリ秒

   timeout 10000

   最小の間隔タイムアウト値を指定する。フローのパケットがタイムアウト値で指定された時間検出されないと、フローは「タイムアウト」する。このパラメータでは、パケットは 10000 ミリ秒後にタイムアウトする

   max_limit 2048

   このアクションインスタンスのフローテーブル内でアクティブなフローレコードの最大数を設定する

   next_action continue

   video クラスのパケットに対しこれ以上処理を行う必要がないこと、およびこれらのパケットをネットワークストリームに戻してもよいことを示す

   flowacct モジュールは、指定されたタイムアウト値に達するまで、特定のクラスのパケットフローに関する統計情報を収集します。

参照

• ルーターでホップ単位の動作を設定するには、「IPQoS 対応ネットワーク上でルーターを構成する方法」を参照してください。

• IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。

• アプリケーションからのトラフィックフロー向けのクラスを作成するには、「アプリケーションサーバー用 IPQoS 構成ファイルを作成する方法」を参照してください。

ベストエフォート Web サーバー用の IPQoS 構成ファイルを作成する方法

ベストエフォート Web サーバー用の IPQoS 構成ファイルは、プレミアム Web サーバー用の IPQoS 構成ファイルとは少し違います。この手順では、例として 例 34–2 の構成ファイルを使用します。

1. ベストエフォート Web サーバーにログインします。

2. 新規 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 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。

3. ベストエフォート Web サーバーに向かうトラフィックを特定するクラスを定義します。

   class { name userweb next_action markAF12 enable_stats FALSE }

   name userweb

   userweb クラスを作成して、ユーザーから Userweb サーバーに向かうトラフィックを特定する

   next_action markAF1

   ipgpc モジュールに対し、ipgpc による処理が完了した userweb クラスのパケットを、action 文 markAF12 に渡すよう指示する。action 文 markAF12 は、dscpmk マーカーを呼び出す

   enable_stats FALSE

   userweb クラスの統計収集を可能にする。ただし、enable_stats の値が FALSE であるため、このクラスの統計は収集されない

   class 句の処理については、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。

4. userweb クラスのトラフィックフローを選択する filter 句を定義します。

   filter { name webout sport 80 direction LOCAL_OUT class userweb } }

   name webout

   フィルタに webout という名前を付ける

   sport 80

   ソースポート 80 のトラフィックを選択する。これは、既知の HTTP (Web) トラフィック用ポート

   direction LOCAL_OUT

   ローカルシステムから発信されるトラフィックを選択する

   class userweb

   フィルタが所属するクラス (このインスタンスでは userweb クラス) を特定する

   filter 句の処理については、「IPQoS 構成ファイル内でフィルタを定義する方法」を参照してください。

5. dscpmk マーカーを呼び出す action 文を開始します。

   action { module dscpmk name markAF12

   module dscpmk

   dscpmk マーカーモジュールを呼び出す

   name markAF12

   action 文に markAF12 という名前を付ける

   以前に定義した userweb クラスには next_action markAF12 という文が含まれています。この文は、クラシファイアによる処理が完了したトラフィックフローを、 action 文 markAF12 に送信します。

6. トラフィックフローの処理に使用する、マーカーのパラメータを定義します。

   params { global_stats FALSE dscp_map{0-63:12} next_action continue } }

   global_stats FALSE

   マーカー action 文 markAF12 の統計収集を可能にする。ただし、enable_stats の値が FALSE であるため、統計は収集されない

   dscp_map{0–63:12}

   DSCP 12 を、マーカーにより処理中の userweb クラスのパケットヘッダーに割り当てる

   next_action continue

   userweb クラスのパケットに対しこれ以上処理を行う必要がないこと、およびこれらのパケットをネットワークストリームに戻してもよいことを示す

   DSCP 12 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 12 (バイナリ値 001100) に設定するよう指示します。このコードポイントは、userweb トラフィッククラスのパケットが AF12 ホップ単位動作 (PHB) に従うことを示します。AF12 は、DS フィールド内に DSCP 12 を持つすべてのパケットが、中程度のドロップ、および高い優先順位のサービスを受けることを保証します。

7. IPQoS 構成ファイルを完成したら、構成を適用します。

参照

• アプリケーションからのトラフィックフローに対して、クラスやほかの構成を追加するには、「アプリケーションサーバー用 IPQoS 構成ファイルを作成する方法」を参照してください。

• ルーターでホップ単位の動作を設定するには、「IPQoS 対応ネットワーク上でルーターを構成する方法」を参照してください。

• IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。

アプリケーションサーバー用 IPQoS 構成ファイルの作成

この節では、顧客に主要アプリケーションを提供するアプリケーションサーバー用の、構成ファイルを作成する方法について説明します。この手順では、例として図 33–4 の BigAPPS サーバーを使用します。

次の構成ファイルは、BigAPPS サーバーの IPQoS アクティビティーを定義します。このサーバーは、顧客向けの FTP、電子メール (SMTP)、およびネットワークニュース (NNTP) のホストです。

例 34–3 アプリケーションサーバー用サンプル IPQoS 構成ファイル

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 構成ファイルを作成する方法

1. 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 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。

2. 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 }

   name smtp

   smtp という名前のクラスを作成する。 このクラスには、SMTP アプリケーションが扱う電子メールのトラフィックフローが含まれる

   enable_stats FALSE

   smtp クラスの統計収集を可能にする。ただし、enable_stats の値が FALSE であるため、このクラスの統計は取得されない

   next_action markAF13

   ipgpc モジュールに対し、ipgpc による処理が完了した smtp クラスのパケットを、action 文 markAF13 に渡すよう指示する

   name news

   news という名前のクラスを作成する。 このクラスには、NNTP アプリケーションが扱うネットワークニュースのトラフィックフローが含まれる

   next_action markAF21

   ipgpc モジュールに対し、ipgpc による処理が完了した news クラスのパケットを、アクション文 markAF21 に渡すよう指示する

   name ftp

   ftp という名前のクラスを作成する。 このクラスには、FTP アプリケーションが扱う発信トラフィックが含まれる

   enable_stats TRUE

   ftp クラスの統計収集を可能にする

   next_action meterftp

   ipgpc モジュールに対し、ipgpc による処理が完了した ftp クラスのパケットを、action 文 meterftp に渡すよう指示する

   クラスの定義の詳細については、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。

3. 手順 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 } }

   name smtpout

   フィルタに smtpout という名前を付ける

   sport smtp

   ソースポート 25 のトラフィックを選択する。これは、既知の sendmail (SMTP) アプリケーション用ポート

   class smtp

   フィルタが所属するクラス (このインスタンスでは smtp クラス) を特定する

   name newsout

   フィルタに newsout という名前を付ける

   sport nntp

   ソースポート名 nntp のトラフィックを選択する。これは、既知のネットワークニュース (NNTP) アプリケーション用ポート

   class news

   フィルタが所属するクラス (このインスタンスでは news クラス) を特定する

   name ftpout

   フィルタに ftpout という名前を付ける

   sport ftp

   ソースポート 21 の制御データを選択する。これは、既知の FTP トラフィック用ポート番号

   name ftpdata

   フィルタに ftpdata という名前を付ける

   sport ftp-data

   ソースポート 20 のトラフィックを選択する。これは、既知の FTP データトラフィック用ポート番号

   class ftp

   ftpout および ftpdata フィルタが所属するクラス (このインスタンスでは ftp) を特定する

参照

• フィルタを定義するには、「IPQoS 構成ファイル内でフィルタを定義する方法」を参照してください。

• アプリケーショントラフィックの転送動作を定義するには、「IPQoS 構成ファイル内でアプリケーショントラフィックの転送を構成する方法」を参照してください。

• メータリングモジュールを使用してフロー制御を設定するには、「IPQoS 構成ファイル内でフロー制御を構成する方法」を参照してください。

• フローアカウンティングを設定するには、「IPQoS 構成ファイル内でクラスのアカウンティングを有効にする方法」を参照してください。

IPQoS 構成ファイル内でアプリケーショントラフィックの転送を構成する方法

次の手順では、アプリケーショントラフィックの転送を設定します。次の手順では、アプリケーショントラフィッククラスのホップ単位動作を定義します。これらのクラスは、ネットワーク上のほかのトラフィックよりも優先度を低くする場合があります。この手順では、例 34–3 の /var/ipqos/BigAPPS.qos ファイルを引き続き構築します。

始める前に

この手順では、マークしたアプリケーションに対してクラスとフィルタをすでに定義した既存の IPQoS 構成ファイルがあることを前提にしています。

1. アプリケーションサーバー用に作成した IPQoS 構成ファイルを開き、最後の filter 句の末尾を検索します。

   /var/ipqos/BigAPPS.qos ファイルでは、最後のフィルタは次のとおりです。

   filter { name ftpdata sport ftp-data class ftp } }

2. 次の方法でマーカーを呼び出します。

   action { module dscpmk name markAF13

   module dscpmk

   dscpmk マーカーモジュールを呼び出す

   name markAF13

   action 文に markAF13 という名前を付ける

3. 電子メールのトラフィックフローにマークされるホップ単位動作を定義します。

   params { global_stats FALSE dscp_map{0-63:14} next_action continue } }

   global_stats FALSE

   マーカー action 文 markAF13 の統計収集を可能にする。ただし、global_stats の値が FALSE であるため、統計は収集されない

   dscp_map{0–63:14}

   DSCP 14 を、マーカーにより処理中の smtp クラスのパケットヘッダーに割り当てる

   
   next_action continue

   smtp クラスのパケットに対しこれ以上処理を行う必要がないことを示す。よって、これらのパケットはネットワークストリームに戻すことができる

   DSCP 14 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 14 (バイナリ値 001110) に設定するよう指示します。DSCP 14 は、AF13 のホップ単位の動作を設定します。マーカーは、DS フィールドの DSCP 14 で smtp トラフィッククラスのパケットをマークします。

   AF13 は、DSCP 14 を持つすべてのパケットに高いドロップ優先度を割り当てますが、それと同時に Class 1 の優先順位も保証するため、ルーターは電子メールの発信トラフィックに対し、キューの中で高い優先順位を与えます。設定可能な AF コードポイントの表については、表 37–2 を参照してください。

4. マーカー action 文を追加して、ネットワークニュースのトラフィック用のホップ単位動作を定義します。

   action { module dscpmk name markAF21 params { global_stats FALSE dscp_map{0-63:18} next_action continue } }

   name markAF21

   action 文に markAF21 という名前を付ける

   dscp_map{0–63:18}

   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 構成ファイル内でフロー制御を構成する方法

ネットワークに送出される特定のトラフィックフローの速度を制御するには、メーターのパラメータを定義しなければなりません。IPQoS 構成ファイル内で、2 つのメーター tokenmt と tswtclmt とのどちらかを使用できます。

次の手順では、例 34–3 のアプリケーションサーバーの IPQoS 構成ファイルを引き続き構築します。次の手順では、メーターを構成するだけではなく、メーター action 文の内部で呼び出される 2 つの マーカーアクションも構成します。

始める前に

この手順の前に、フローを制御するアプリケーション用のクラスおよびフィルタを定義してあるものとします。

1. アプリケーションサーバー用に作成した IPQoS 構成ファイルを開きます。

   /var/ipqos/BigAPPS.qos ファイルで、次のマーカーアクションのあとから作業を開始します。

   action { module dscpmk name markAF21 params { global_stats FALSE dscp_map{0-63:18} next_action continue } }

2. ftp クラスのトラフィックをフロー制御するメーター action 文を作成します。

   action { module tokenmt name meterftp

   module tokenmt

   tokenmt メーターを呼び出す

   name meterftp

   action 文に meterftp という名前を付ける

3. メーターの速度を設定するパラメータを追加します。

   params { committed_rate 50000000 committed_burst 50000000

   committed_rate 50000000

   ftp クラスのトラフィックに 50,000,000 bps の転送速度を割り当てる

   committed_burst 50000000

   ftp クラスのトラフィックに 50,000,000 ビットのバーストサイズを割り当てる

   tokenmt パラメータについては、「tokenmt をツーレートメーターとして構成する」を参照してください。

4. 次のようにパラメータを追加して、トラフィック適合優先順位を設定します。

   red_action markAF31 green_action_name markAF22 global_stats TRUE } }

   red_action_name markAF31

   ftp クラスのトラフィックフローが認定速度を超過した場合、パケットは、markAF31 マーカー action 文に送信されることを示す

   green_action_name markAF22

   ftp クラスのトラフィックフローが認定速度に適合する場合、パケットがアクション文 markAF22 に送られることを示す

   global_stats TRUE

   ftp クラスのメータリング統計取得を有効にする

   トラフィックの適合性については、「メーターモジュール」を参照してください。

5. ホップ単位動作を ftp クラスの不適合トラフィックフローに割り当てるマーカー action 文を追加します。

   action { module dscpmk name markAF31 params { global_stats TRUE dscp_map{0-63:26} next_action continue } }

   module dscpmk

   dscpmk マーカーモジュールを呼び出す

   name markAF31

   action 文に markAF31 という名前を付ける

   global_stats TRUE

   ftp クラスの統計取得を有効にする

   dscp_map{0–63:26}

   ftp クラスのトラフィックが認定速度を超過した場合は常に、DSCP 26 を ftp クラスのパケットヘッダーに割り当てる

   next_action continue

   ftp クラスのパケットに対しこれ以上処理を行う必要がないことを示す。よって、これらのパケットはネットワークストリームに戻すことができる

   DSCP 26 は、マーカーに対し、dscp マップ内のすべてのエントリを 10 進数値の 26 (バイナリ値 011010) に設定するよう指示します。DSCP 26 は、AF31 のホップ単位の動作を設定します。マーカーは、DS フィールドの DSCP 26 で ftp トラフィッククラスのパケットをマークします。

   AF31 は DSCP 26 を持つすべてのパケットに低いドロップ優先度を保証しますが、優先順位は Class 2 にとどまります。このため、速度不適合の FTP トラフィックがドロップされる可能性は低くなりますが、設定可能な AF コードポイントの表については、表 37–2 を参照してください。

6. 認定速度に適合する ftp トラフィックフローにホップ単位動作を割り当てるマーカー action 文を追加します。

   action { module dscpmk name markAF22 params { global_stats TRUE dscp_map{0-63:20} next_action continue } }

   name markAF22

   marker アクションに markAF22 という名前を付ける

   dscp_map{0–63:20}

   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 を参照してください。

7. アプリケーションサーバー用に作成した DSCP を、Diffserv ルーターの適切なファイルに追加します。

参照

• IPQoS 構成ファイルをアクティブにするには、「新規構成を IPQoS カーネルモジュールへ適用する方法」を参照してください。

• Web サーバーの構成情報を追加するには、「IPQoS 構成ファイルを作成し、トラフィッククラスを定義する方法」を参照してください。

• フローアカウンティングを設定するには、「IPQoS 構成ファイル内でクラスのアカウンティングを有効にする方法」を参照してください。

• ルーターで転送動作を設定するには、「IPQoS 対応ネットワーク上でルーターを構成する方法」を参照してください。

ルーター上での差別化サービスの提供

差別化サービスを提供するには、「diffserv ネットワークのハードウェア計画」の説明に従って、ネットワークトポロジに Diffserv 対応ルーターを含める必要があります。ルーター上で Diffserv を構成し、ルーターのファイルを更新する実際の手順は、このマニュアルの扱う範囲ではありません。

この節では、ネットワーク上のさまざまな IPQoS 対応システムおよび Diffserv ルーター間で、転送情報を調整する一般的な手順を説明します。

IPQoS 対応ネットワーク上でルーターを構成する方法

次の手順では、例として図 33–4 のトポロジを使用します。

始める前に

次の手順の前に、この章のこれまでの作業を実行することにより、ネットワーク上で IPQoS システムを構成してあるものとします。

1. ネットワーク上のすべての IPQoS 対応システムの構成ファイルを確認します。

2. さまざまな 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)

3. ネットワークの IPQoS 構成ファイルから得たコードポイントを、Diffserv ルーターの適切なファイルに追加します。

   これらのコードポイントは、ルーターの Diffserv スケジューリング機構の設定に役立ちます。詳しくは、ルーターの製造元の文書および Web サイトを参照してください。

第 35 章 IPQoS の起動と保守(手順)

この章では、IPQoS 構成ファイルを有効化する方法および IPQoS 関連のイベントを記録する方法について説明します。次の項目について説明します。

• 「IPQoS の管理 (作業マップ)」

• 「IPQoS 構成の適用」

• 「IPQoS メッセージの syslog によるログ記録の有効化」

• 「IPQoS のエラーメッセージの障害追跡」

IPQoS の管理 (作業マップ)

この節には、Oracle Solaris システム上で IPQoS を起動および保守するための一連の作業を示します。作業を行う前に、「IPQoS 構成ファイル内での QoS ポリシーの定義 (作業マップ)」に従って、IPQoS 構成ファイルを完成しておく必要があります。

次の表では、それらの作業について箇条書き形式で説明し、各作業を完了する方法が詳しく説明された節へのリンクを示しています。

IPQoS 構成の適用

IPQoS 構成の有効化およびそのほかの操作には、 ipqosconf コマンドを使用します。

新規構成を IPQoS カーネルモジュールへ適用する方法

ipqosconf コマンドで、IPQoS 構成ファイルを読み取り、UNIX カーネルで IPQoS モジュールを構成します。次の手順では、Creating IPQoS Configuration Files for Web Serversで作成した 「Web サーバー用 IPQoS 構成ファイルの作成」 ファイルを例として使用します。詳細については、ipqosconf(1M) のマニュアルページを参照してください。

1. IPQoS 対応システムで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. 新規構成を適用します。

   # /usr/sbin/ipqosconf -a/var/ipqos/Goldweb.qos

   ipqosconf により、指定された IPQoS 構成ファイル内の情報が Oracle Solaris カーネル内の IPQoS モジュールに書き込まれます。この例では、/var/ipqos/Goldweb.qos の内容が現行の Oracle Solaris カーネルに適用されます。

   ---

   注 –

   -a オプションを指定して IPQoS 構成ファイルを適用すると、ファイル内のアクションが現行のセッションの間だけ有効になります。

   ---

3. 新規 IPQoS 構成のテストおよびデバッグを行います。

   UNIX ユーティリティーを使用して、IPQoS の動作を追跡し、IPQoS 実装に関する統計を収集します。この情報は、構成が予想どおりに機能するかを判断するのに役立ちます。

参照

• IPQoS モジュールがどのように機能するかに関する統計は、「統計情報の収集」を参照してください。

• ipqosconf メッセージをログ記録するには、「IPQoS メッセージの syslog によるログ記録の有効化」を参照してください。

• 起動のたびに現在の IPQoS 構成を適用させるには、「再起動後にも IPQoS 構成を適用する方法」を参照してください。

再起動後にも IPQoS 構成を適用する方法

再起動後にも IPQoS 構成を持続させるには、明示的に指定する必要があります。そのように指定しないと、システムの再起動後に現行の構成が適用されません。システムで IPQoS が適正に動作するときは、次の操作を実行して再起動後にも構成が持続するようにします。

1. IPQoS 対応システムで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. カーネルモジュール内に IPQoS 構成が存在することを確認します。

   # ipqosconf -l

   構成がすでに存在する場合は、ipqosconf によって画面に表示されます。出力が行われない場合は、「新規構成を IPQoS カーネルモジュールへ適用する方法」の説明に従って、構成を適用します。

3. IPQoS システムを再起動するたびに既存の IPQoS 構成が適用されるようにします。

   # /usr/sbin/ipqosconf -c

   -c オプションを指定すると、現行の IPQoS 構成が、起動時の構成ファイル /etc/inet/ipqosinit.conf に書き込まれます。

IPQoS メッセージの syslog によるログ記録の有効化

IPQoS 起動時のメッセージを記録するには、次に示す手順に従って /etc/syslog.conf ファイルを変更する必要があります。

起動時に IPQoS メッセージを記録する方法

1. IPQoS 対応システムで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. /etc/syslog.conf ファイルを開きます。

3. ファイルの最後に、次のエントリを追加します。

   user.info /var/adm/messages

   列の区切りは、空白ではなくタブを使用してください。

   このエントリを指定すると、IPQoS により生成された起動時のメッセージがすべて /var/adm/messages ファイルに記録されます。

4. システムを再起動して設定を適用します。

例 35–1 /var/adm/messages からの IPQoS 出力

システムの再起動後に /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 のエラーメッセージの障害追跡

この節には、IPQoS によって生成されるエラーメッセージと考えられる解決方法を示します。

第 36 章 フローアカウンティングの使用と統計情報の収集 (手順)

この章では、IPQoS システムによって処理されるトラフィックに関して、アカウンティング情報と統計情報を取得する方法について説明します。この章では、次の内容について説明します。

• 「フローアカウンティングの設定 (作業マップ)」

• 「トラフィックフローに関する情報の記録」

• 「統計情報の収集」

フローアカウンティングの設定 (作業マップ)

次の作業マップは、flowacct モジュールを使用してトラフィックフローに関する情報を取得するための一般的な作業を示しています。マップでは、これらの作業の実施手順へのリンクも示しています。

トラフィックフローに関する情報の記録

トラフィックフローに関する情報を収集するには、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) のマニュアルページを参照してください。

1. IPQoS 対応システムで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. 基本フローアカウンティングファイルを作成します。

   次の例に、例 34–1 で構成されるプレミアム Web サーバ用の基本的なフローアカウンティングファイルの作成方法を示します。

   # /usr/sbin/acctadm -e basic -f /var/ipqos/goldweb/account.info flow

   acctadm -e

   acctadm を -e オプションを指定して呼び出します。-e オプションによって、あとに続く引数が有効になる

   basic

   flowacct の 8 つの基本属性のデータだけがファイルに記録されることを示す

   /var/ipqos/goldweb/account.info

   flowacct から得られるフローレコードを格納するファイルの絶対パス名を示す

   flow

   acctadm にフローアカウンティングを有効にするよう指示する

3. 引数を指定しないで 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 の属性を示す

4. (オプション) 拡張属性をアカウンティングファイルに追加します。

   # acctadm -e extended -f /var/ipqos/goldweb/account.info flow

5. (オプション) 基本属性だけがアカウンティングファイルに記録されるような設定に戻します。

   # acctadm -d extended -e basic -f /var/ipqos/goldweb/account.info

   -d オプションによって拡張アカウンティングが無効になります。

6. フローアカウンティングファイルの内容を参照します。

   フローアカウンティングファイルの内容の参照方法については、『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) のマニュアルページを参照してください。

例 36–1 IPQoS 用の kstat 統計

ここでは、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

class: flacct

トラフィックフローが属するクラスの名前 (この例では flacct) を示す

bytes_in_tbl

フローテーブルの総バイト数。フローテーブルの総バイト数とは、フローテーブルに現在格納されているすべてのフローレコードの合計バイト数。このフローテーブルの総バイト数は 84 である。テーブルにフローがない場合、bytes_in_tbl の値は 0 になる

crtime

この kstat 出力が作成された最も最近の時間

epackets

処理中にエラーが発生したパケットの数 (この例では 0)

flows_in_tbl

フローテーブルのフローレコード数 (この例では 1)。テーブルにレコードがない場合、flows_in_tbl の値は 0 になる

nbytes

この flowacct アクションのインスタンスで表示される合計バイト数 (この例では 84)。フローテーブルに現在格納されているバイトを含む値。この値には、タイムアウトになり、フローテーブルに現在は含まれていない値も含まれる

npackets

この flowacct アクションのインスタンスで表示される合計パケット数 (この例では 1)。npackets には、フローテーブルに現在あるパケットが含まれる。npackets には、タイムアウトになり、フローテーブルに現在は含まれていないパケットも含まれる

usedmem

この flowacct インスタンスで保持されているフローテーブルが使用しているメモリーのバイト数。この例では、usedmem の値は 256。フローテーブルにフローレコードがまったく存在しない場合、usedmem の値は 0 になる

第 37 章 IPQoS の詳細 (リファレンス)

この章は、IPQoS の詳細を説明するリファレンスです。この章では、次の内容について説明します。

• 「IPQoS アーキテクチャーと Diffserv モデル」

• 「IPQoS 構成ファイル」

• 「ipqosconf 構成ユーティリティー」

概要は、第 32 章IPQoS の紹介 (概要)を参照してください。計画については、第 33 章IPQoS 対応ネットワークの計画 (手順)を参照してください。IPQoS の構成手順については、第 34 章IPQoS 構成ファイルの作成 (手順)を参照してください。

IPQoS アーキテクチャーと Diffserv モデル

この節では、IPQoS アーキテクチャーとこのアーキテクチャーが RFC 2475, An Architecture for Differentiated Services で定義された差別化サービス (Diffserv) モデルを実装する方法について説明します。次に示す Diffserv モデルの要素が、IPQoS に含まれます。

• クラシファイア

• メーター

• マーカー

さらに、IPQoS には、仮想ローカルエリアネットワーク (VLAN) デバイスで使用されるフローアカウンティングモジュールと dlcosmk マーカーが含まれています。

クラシファイアモジュール

Diffserv モデルでは、「クラシファイア」は、トラフィックフローを選択して、それぞれに異なるサービスレベルを適用するためのグループに分類する作業を担当します。RFC 2475 で定義されたクラシファイアは、当初、境界ルーター用に設計されました。それとは対照的に、IPQoS クラシファイア ipgpc は、内部ホストからローカルネットワークへのトラフィックフローを処理するために設計されています。このため、IPQoS システムと Diffserv ルーターの両方を備えたネットワークは、より広範囲な差別化サービスを提供できます。ipgpc の技術情報については、ipgpc(7ipp) のマニュアルページを参照してください。

ipgpc クラシファイアは、次の機能を実行します。

1. IPQoS 対応システムの IPQoS 構成ファイルに指定された条件を満たすトラフィックフローを選択します。

   QoS ポリシーは、パケットヘッダーに存在する必要のあるさまざまな条件を定義します。これらの条件は、「セレクタ」と呼ばれます。 ipgpc クラシファイアは、これらのセレクタを、IPQoS システムから受信したパケットのヘッダーと比較して、一致するパケットをすべて選択します。

2. パケットフローを、IPQoS 構成ファイルの定義に従い、同じ特性を持つネットワークトラフィックである 「クラス」に分類します。

3. パケットの差別化サービス (DS) フィールドの値を調べ、差別化サービスコードポイント (DSCP) の存在を確認します

   DSCP は、受信したトラフィックに送信側によって転送動作のマークが付けられているかどうかを示します。

4. 特定クラスのパケットに関して、IPQoS 構成ファイル内で次に指定されているアクションを調べます。

5. パケットを、IPQoS 構成ファイルで指定された次の IPQoS モジュールに渡すか、あるいはネットワークストリームに戻します。

クラシファイアの概要は、「クラシファイア (ipgpc) の概要」を参照してください。IPQoS 構成ファイルでクラシファイアを呼び出すには、「IPQoS 構成ファイル」を参照してください。

IPQoS セレクタ

ipgpc クラシファイアは、IPQoS 構成ファイルの filter 句で使用可能なさまざまなセレクタをサポートします。フィルタを定義するときには、特定クラスのトラフィック取得に必要な最小限のセレクタを使用してください。定義するフィルタの数が、IPQoS のパフォーマンスに影響を与える可能性があります。

次の表に、 ipgpc で使用できるセレクタを示します。

メーターモジュール

「meter」は、パケット単位でフローの転送速度を追跡します。このメーターは、設定されているパラメータにパケットが一致するかどうかを決定します。メーターモジュールは、パケットサイズ、設定されたパラメータ、およびフロー速度に基づき、パケットの次のアクションをアクションセットの中から決定します。

メーターには 2 つのメータリングモジュール、すなわち tokenmt および tswtclmt があります。モジュールの構成は、IPQoS 構成ファイルで行います。モジュールのどちらか一方または両方をクラスに設定できます。

メータリングモジュールを構成する際、速度に関する 2 つのパラメータを定義できます。

• committed-rate – 特定クラスのパケットに容認可能な転送速度を bps で定義する

• peak-rate – 特定クラスのパケットに最大限容認可能な転送速度を bps で定義する

パケットに対するメータリングアクションの結果 (outcome) は、次の 3 つのどれかになります。

• green – パケットの生成するフローは認定速度内である

• yellow – パケットの生成するフローは認定速度を超過しているが、最大速度内である

• red – パケットの生成するフローは最大速度を超過している

IPQoS 構成ファイル内で、結果ごとに異なるアクションを構成できます。認定速度および最大速度については、次に説明します。

tokenmt メータリングモジュール

tokenmt モジュールは、「トークンバケット」を使用してフローの転送速度を測定します。tokenmt は、シングルレートメーターまたはツーレートメーターとして機能するように構成できます。tokenmt アクションインスタンスは、2 つのトークンバケットを管理します。これらのトークンバケットは、トラフィックフローが設定されたパラメータに適合するかどうかを調べます。

tokenmt(7ipp) のマニュアルページでは、IPQoS がどのようにトークンメーターパラダイムを実装するかが説明されています。トークンバケットに関する一般的な情報は、Kalevi Kilkki 著『Differentiated Services for the Internet』および多数の Web サイトで入手できます。

tokenmt の構成パラメータを次に示します。

• committed_rate – フローの認定速度を bps で指定する

• committed_burst – 認定バーストサイズをビット単位で指定する。committed_burst パラメータは、認定速度でネットワークに渡すことのできる、特定クラスの発信パケット数を定義する

• peak_rate – 最大速度を bps で指定する

• peak_burst – 最大バーストサイズまたは超過バーストサイズをビット単位で指定する。peak_burst パラメータは、トラフィッククラスに、認定速度を超過する最大バーストサイズを付与する

• color_aware – tokenmt のカラーアウェアモードを有効にする

• color_map – DSCP 値を緑、黄、または赤にマッピングする整数配列を定義する

tokenmt をシングルレートメーターとして構成する

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 をツーレートメーターとして構成する

tokenmt をツーレートメーターとして構成するには、IPQoS 構成ファイル内で tokenmt アクション用の peak_rate パラメータを指定します。ツーレートの tokenmt は、必ず赤、黄、および緑の 3 つの結果 (outcome) を識別します。committed_rate、committed_burst、および peak_burst パラメータは、ゼロ以外の正の整数にする必要があります。

tokenmt をカラーアウェアとして構成する

ツーレートの tokenmt をカラーアウェアとして構成するには、「カラーアウェアネス」を特に追加するパラメータを追加します。tokenmt をカラーアウェアとして構成する action 文の例を次に示します。

例 37–1 IPQoS 構成ファイル用のカラーアウェア 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 は、ツーレートメーター用のパラメータに加え、パケットヘッダー内の 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 メータリングモジュールは、時間ベースの「速度エスティメータ」を使用して、トラフィッククラスの平均帯域幅を見積もります。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) のマニュアルページを参照してください。

パケット転送での dscpmk マーカーの使用

マーカーは、クラシファイアモジュールまたはメータリングモジュールによって処理されたあとのトラフィックフローを受け取ります。マーカーは、転送動作をトラフィックにマークします。転送動作とは、フローが 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 を適用することはできません。

完全優先転送 (Expedited Forwarding、EF) PHB

「完全優先転送」(EF) は、推奨される EF コードポイント 46 (101110) の付いたパケットが、ネットワークに送出される時に、可能なかぎり最良の扱いを受けることを保証します。完全優先転送は、しばしば専用回線に例えられます。コードポイント 46 (101110) を持つパケットには、宛先に向かう途中、すべての Diffserv ルーターによる優先待遇が保証されます。EF の技術情報については、RFC 2598 (An Expedited Forwarding PHB) を参照してください。

相対的優先転送 (Assured Forwarding、AF) PHB

「相対的優先転送」(AF) では、4 つの異なるクラスの転送動作をマーカーに指定できます。次の表に、クラス、各クラスに指定できる 3 つのドロップ優先度、および各優先度に対応する推奨 DSCP を示します。各 DSCP は、AF 値 (10 進数値およびバイナリ値) で表されます。

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 の設定

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 で使用できるようにしてください。

VLAN デバイスでの dlcosmk マーカーの使用

dlcosmk マーカーモジュールは、データグラムの MAC ヘッダー内に転送動作をマークします。VLAN インタフェースを持つ IPQoS システムでだけ、dlcosmk を使用できます。

dlcosmk は、「VLAN タグ」と呼ばれる 4 バイトを MAC ヘッダーに追加します。VLAN タグには、IEEE 801.D 標準に定義されている 3 ビットのユーザー優先順位値が含まれます。VLAN を認識する Diffserv 対応スイッチは、データグラム内のユーザー優先順位フィールドを読み取ることができます。801.D ユーザー優先順位値は、サービスクラス (CoS) マークを実装します。CoS マークは、商用スイッチで一般的に使われています。

次の表のサービスマークのクラスを定義することによって、dlcosmk マーカーアクションのユーザー優先値を使用できます。

dlcosmk の詳細は、dlcosmk(7ipp) のマニュアルページを参照してください。

VLAN デバイスを持つシステムでの IPQoS 構成

ここでは、VLAN デバイスを持つシステムでの IPQoS の実装方法を示す、単純なネットワークのシナリオを紹介します。このシナリオには、スイッチで接続された 2 つの IPQoS システム、すなわち machine1 および machine2 が含まれます。machine1 上の VLAN デバイスの IP アドレスは 10.10.8.1、machine2 上の VLAN デバイスの IP アドレスは 10.10.8.3 です。

machine1 向けの次の IPQoS 構成ファイルは、machine2 への切り替えによる、トラフィックのマーキングの簡単な解決策を示しています。

例 37–2 VLAN デバイスを持つシステムの IPQoS 構成ファイル

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 トラフィックフローへの制御された負荷転送を指定しなければならないことを示します。

flowacct モジュール

IPQoS の flowacct モジュールは、トラフィックフローに関する情報を記録します。このプロセスは、「フローアカウンティング」と呼ばれます。フローアカウンティングは、顧客への課金や特定クラスへのトラフィック量の評価に使用できるデータを作成します。

フローアカウンティングは、オプションです。通常、flowacct は、メーターまたはマーカーに処理されたトラフィックフローが、ネットワークストリームへ送出される前に通る、最後のモジュールです。Diffserv モデルでの flowacct の位置の図については、図 32–1 を参照してください。flowacct の詳細な技術情報については、flowacct(7ipp) のマニュアルページを参照してください。

フローアカウンティングを有効にするには、flowacct に加えて、Oracle Solaris の exacct アカウンティング機能および acctadm コマンドを使用する必要があります。フローアカウンティングの設定の全手順については、「フローアカウンティングの設定 (作業マップ)」を参照してください。

flowacct パラメータ

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 レコード

flowacct レコードには、次の表に示される属性が含まれています。

flowacct モジュールでの acctadm の使用

acctadm コマンドを使用して、flowacct により生成されるさまざまなフローレコードを格納するファイルを作成します。acctadm は、拡張アカウンティング機能と連動して動作します。acctadm の技術的情報については、acctadm(1M) のマニュアルページを参照してください。

flowacct モジュールは、フローを観察し、フローレコードにフローテーブルを入力します。次に flowacct は、timer に指定された間隔でパラメータと属性を評価します。last_seen 値に timeout 値を加えた時間以上パケットが検出されない場合、パケットはタイムアウトします。タイムアウトしたエントリはすべて、フローテーブルから削除されます。削除されたタイムアウトエントリは、timer パラメータに指定された時間が経過するたびに、アカウンティングファイルに書き込まれます。

acctadm を呼び出して flowacct モジュールで使用するには、次の構文を使用します。

acctadm -e file-type -f filename flow

acctadm -e

acctadm を -e オプションを指定して呼び出します。-e は、直後にタイプを指定することを示します。

file-type

収集するタイプを指定します。file-type は、basic または extended に置き換える必要があります。各ファイルタイプの属性の一覧については、表 37–4 を参照してください。

-ffile-name

フローレコードを格納するファイル file-name を作成します。

flow

acctadm を IPQoS 上で実行することを示します。

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 は、常に構成に関する情報で置き換える必要がある

例 37–3 IPQoS 構成ファイルの構文

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 文

action 文を使用して、「IPQoS アーキテクチャーと Diffserv モデル」で説明されているさまざまな IPQoS モジュールを呼び出します。

IPQoS 構成ファイルを新規作成する場合、必ずバージョン番号から始める必要があります。ついで、次の action 文を追加して、クラシファイアを呼び出す必要があります。

fmt_version 1.0

action {
    module ipgpc
    name ipgpc.classify
}

クラシファイア action 文の次に、params 句または class 句を記述します。

ほかのすべての action 文には次の構文を使用します。

action {
name action-name
module module-name
params-clause | ""
cf-clauses
}

name action_name

アクションに名前を付ける

module module_name

呼び出し予定の IPQoS モジュールを識別します。表 37–5 のモジュールの 1 つでなければなりません。

params_clause

クラシファイアが処理するパラメータ (グローバル統計、次に処理するアクションなど) を指定する

cf_clauses

class 句または filter 句のゼロ以上のセット

モジュール定義

モジュールの定義によって、action 文のパラメータを処理するモジュールが示されます。IPQoS 構成ファイルには、次のモジュールを含めることができます。

class 句

トラフィックのクラスごとに「class 句」を定義します。

IPQoS 構成内の残りのクラスを定義するには、次の構文を使用します。

class {
     
      name class-name
      next_action next-action-name
}      

特定のクラスに関する統計情報収集を有効にするには、最初に ipgpc.classify アクション文でグローバル統計を有効にする必要があります。詳細は、「action 文」を参照してください。

クラスに関する統計を収集したいときは、enable_stats TRUE 文を使用します。クラスの統計を収集する必要がない場合は、enable_stats FALSE を指定します。あるいは、 enable_stats 文を削除してもかまいません。

IPQoS 対応ネットワーク上のトラフィックは、特に定義しなければ「デフォルトクラス」になります。

filter 句

「フィルタ」は、トラフィックフローをクラスに分類するセレクタで構成されます。これらのセレクタは、クラス句で作成されたクラスのトラフィックへ適用する条件を、明確に定義します。パケットがもっとも高い優先順位のフィルタのセレクタすべてに一致する場合、パケットはそのフィルタのクラスのメンバーと見なされます。ipgpc クラシファイアと使用できるセレクタの完全なリストについては、表 37–1 を参照してください。

次の構文を持つ「filter 句」を使用して IPQoS 構成ファイル内にフィルタを定義します。

filter { 
       name filter-name
       class class-name 
       parameters (selectors)
       }

params 句

params 句には、アクション文で定義されたモジュールの処理方法が含まれます。params 句の構文を次に示します。

params {
           parameters
           params-stats | ""
       }

params 句では、モジュールに適用するパラメータを使用します。

params 句の params-stats 値は、global_stats TRUE または global_stats FALSE になります。global_stats TRUE 命令は、グローバル統計を呼び出した action 文に関する UNIX スタイルの統計を有効にします。kstat コマンドを使用して、統計情報を表示できます。クラス単位の統計を有効にする前に、action 文の統計を有効にする必要があります。

ipqosconf 構成ユーティリティー

IPQoS 構成ファイルを読んだり、UNIX カーネル内の IPQoS モジュールを構成したりするには、ipqosconf ユーティリティーを使用します。ipqosconf は、次のアクションを実行します。

• 構成ファイルを IPQoS カーネルモジュールに適用する (ipqosconf -a filename)

• カーネル内に現在常駐している IPQoS 構成ファイルを表示する (ipqosconf -l)

• マシンをリブートするたびに、現行の IPQoS 構成を読み取り、適用するようにする (ipqosconf -c)

• 現行の IPQoS カーネルモジュールをフラッシュする (ipqosconf -f)

技術的な情報は、ipqosconf(1M) のマニュアルページを参照してください。