junos 基本シリーズ - juniper networks...本書を読む前に知っておくべきこと...

Day One：基本的なQoSの導入

著者：ガイ・デーヴィス

Junos®基本シリーズ

第1章: QoSの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

第2章: JunosのQoSの基本概念とルーティングノード経由のパケットフロー . . 11

第3章: Junosソフトウェアによる基本的なQoS実装の構築 . . . . . . . . . . . . . . . . 23

第4章: 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

© 2011 by Juniper Networks, Inc. All rights reserved.

Juniper Networks、Juniper Networksのロゴ、Junos、NetScreen、および ScreenOSは、Juniper Networks, Inc.（以下、ジュニパーネットワークス）の米国およびその他の国における登録商標です。Junosは、ジュニパーネットワークスの商標です。その他の商標、サービスマーク、登録商標、登録サービスマークは、それぞれの所有者に帰属します。

ジュニパーネットワークスは、本書に誤りが含まれることがあっても責任を負いません。ジュニパーネットワークスは、予告なく本書を変更、修正、転載、または改訂する権利を留保します。ジュニパーネットワークスが製造、販売する製品、あるいはその部品は、ジュニパーネットワークスが保有する、あるいはライセンスを受けた以下の米国特許のうち 1件または複数により保護されている場合があります。米国特許第 5,473,599号、第5,905,725 号、第 5,909,440 号、第 6,192,051 号、第 6,333,650号、第 6,359,479号、第 6,406,312号、第 6,429,706号、第 6,459,579号、第 6,493,347号、第 6,538,518号、第 6,538,899号、第 6,552,918号、第 6,567,902号、第 6,578,186号、第 6,590,785号。

発行者：Juniper Networks Books著者：ガイ・デーヴィス主編集者：パトリック・エイムズ原稿整理編集者：ナンシー・ケルベルJ-Netコミュニティ管理者：ジュリー・ワイダー

ISBN：978-1-936779-30-7（書籍）印刷：Vervante Corporation（米国）ISBN：978-1-936779-31-4（電子書籍）

改訂：初版、2011年 7月 2 3 4 5 6 7 8 9 10 #7500213

著者の紹介ガイ・デーヴィスは、ジュニパーネットワークスのグローバル PSモバイルコアネットワーク部門でシニアソリューションコンサルタントを務めています。ジュニパーネットワークスの EMEAおよびグローバル PS部門で 5年間にわたって、大規模な高可用性ネットワークを構築し、きめ細かいサービス品質を顧客に提供しようと取り組んでいるサービスプロバイダや大企業のお客様を支援してきました。ジュニパーネットワークスの前にはシステムインテグレータの Telindus社に 6年間、さらにTelindus社の前には英国の UUNET社に 5年間、勤務していました。この経歴を通じて、大規模なMPLSおよび IPコアやプロバイダエッジネットワーク、サブスクライバ管理プラットフォーム、AAAプラットフォームなどの開発に携わってきました。これらの技術はすべて、QoS（Quality of Service）を差別化する上で重要度が増し続けている要素です。ガイは、JNCIE-M #20の認定を受けています。

著者の謝辞私を支え続けてくれた家族に感謝したいと思います。本書の執筆と完成を後押ししてくれた Juniper Networks Booksチームにも感謝いたします。彼らの支援がなければ、本書は完成しなかったことでしょう。最後に、本書について助言し、レビューを担当してくれた私の同僚、ミゲル・バレイロスにも感謝いたします。

本書はさまざまな形式で、www.juniper.net/dayoneから入手できます。また、iTunesや Amazonでも入手できます。

本書についてのご意見・ご感想は、電子メールで[email protected]宛にお寄せください。

ii

本書を読む前に知っておくべきこと � パケットベースのネットワークの原理について、きちんと理解している必要があります。

� Junosのコマンドラインインタフェースについての知識・経験があれば役に立ちます。『Junos基本シリーズ』の他の『Day One』マニュアルを通読しておくことも役に立ちます。

本書の学習目標： � ベンダーの実装の種類に関係なく、QoSの原理について理解する。 � QoS実装の基本的な構成単位を確認する。 � 一般的なトラフィックの動作と、その操作方法を確認する。 � 基本的な構成単位を組み合わせて、必要な動作を実現する。

QoSが求められる理由今日では、ネットワークに対する需要は、信じられないペースで増加し続けています。ネットワークへ接続するデバイス数は急増しており、これらのデバイス（特にビデオアプリケーション）によって生成されるトラフィック量も爆発的に増加しています。その上、隔離された単一タイプのトラフィックを伝送するために設計された、複数のレガシーネットワークの収束といった要因が重なり、単に過剰設備によってデータ量の潜在的なピークに対処するという古いアプローチは、商業的にも技術的にも継続できなくなりました。特定のサービス（電話サービスなど）の加入者は、サービスが常に利用可能であると同時に、許容できる品質を維持していることを求めています。このような可用性と品質を確保するため、最初に取るべき対応は、同じ処理を要求するクラスごとにトラフィックをグループ化することです。さらに、この処理は、グループ内のすべてのトラフィックに均一に提供する必要があります。この一貫性は単一のデバイスだけでなく、送信元から宛先への経路でトラフィックが通過するすべてのデバイスで必要になります。本書はQoS用語について簡単に説明するとともに、比較的シンプルなCoS（Class-of-Service）設定の実装を可能にする Junos OSのツールやテクニックを紹介することを目的としています。本書のタイトルは『基本的な QoSの導入』であり、ジュニパーネットワークスが販売する各プラットフォームのすべての CoSオプションを網羅して説明しようとするものではありません。そのような目的では、http://www.juniper.net/techpubs/software/junosで入手できるマニュアルが参考になります。

iii

iv

本書は、基本的な要件や設定ツール、実際の設定に応用できるツールやサンプルの使用法について、一通り説明することを目的としています。CoS設定にはさまざまな側面があり、そのすべてを本書で網羅することはできません。そのような内容は、さらに詳細なマニュアルで取り上げることになります。

さらに詳しくは QoS関連で参考になる資料としては、新しく刊行された『QoS Enabled Networks:Tools and Foundations』（John Wiley & Sons 社、2011 年、ISBN 978-0-470-68697-3）が挙げられます。同書は、ジュニパーネットワークスのシニアエンジニアであるピーター・ルンドクヴィストとミゲル・バレイロスの共著です。同書とその内容の詳細については、ご利用のオンライン書店か、www.juniper.net/booksをご覧ください。

第1章

QoSの概要

QoSとCoSの比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

動作とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

ロス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

遅延 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

ジッター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6 Day One：基本的なQoSの導入

第 1章では、QoS（サービス品質）の基本原理について詳しく見ていきます。具体的には、エンドツーエンドのユーザエクスペリエンスという基本的な考え方から始めて、一連のホップバイホップ方式の動作としてQoSを実装する方法に進みます。この章では、標準化されたものを含めて、QoS動作の基本モデルを明確にするとともに、それぞれの動作に影響を及ぼす目的で使用可能なテクノロジーについて説明します。

QoSとCoSの比較

QoSの定義にはさまざまなものが考えられますが、本書の目的上、QoS（Quality of Service）はトラフィックの集約操作であると定義します。QoSに基づいて、そのトラフィックの生成元であるアプリケーションに必要な動作と整合性のある方法で、それぞれのトラフィックは転送されます。個々のユーザーの視点からは、QoSはエンドツーエンド（通常、双方向）のトラフィックフローであると捉えられます。同時に、QoSは、各ホップの一連の動作として実装されます。この点は QoSの絶対的な基本事項であり、重要な特徴として、読者はこの点をはっきりと理解しておく必要があります。実際には、QoSが設定されていないホップが 1つでも存在すると、エンドツーエンドのユーザーエクスペリエンスは損なわれて、以降のノードではエンドツーエンドのユーザーエクスペリエンスの品質を回復できません。ホップ単位にQoSを設定することは、必ずしも絶対条件ではありません。ただし、輻輳状態のホップが 1つでも存在すると、複雑なQoS設計によっては破綻するものがあるということは、理解しておく必要があります。これに対して、CoS（Class-of-Service）は、エンドツーエンドのQoSが一貫性のあるエンドツーエンドのユーザーエクスペリエンスやアプリケーション動作を目的とするように、個々のノードを設定してそのノードに特定の動作を実装する目的で、Junos OSで使用される設定構造です。各クラスは、ネットワークデバイスを通過するときに同じ動作が求められるトラフィックの集約と関連付けられます。クラスは、単一のアプリケーションに属しているトラフィックと暗黙的に関連付けられるものではありません。逆に、同じ動作を必要とするアプリケーションによって、同じクラスに属しているトラフィックが生成されることになります。

ヒント QoSとCoSの違いの意味を理解できたでしょうか。理解に不安がある場合は、ここまでの説明の段落をもう一度、よく読んでください。ここまでの説明は、QoSの文脈ではわかりにくいかもしれませんが、本書全体で基本となる考え方です。

第1章：QoSの概要 7

動作とは第 1章の冒頭で、動作についてはすでに触れました。その理由として、動作は QoSの概念を構成する中心的な要素であることが挙げられます。動作の定義については特に目新しいものではありませんが、QoSの観点から捉えた概念についてはよく知られていないでしょう。少し時間をかけて、QoSの動作について詳しく見ていきましょう。QoSの動作では、特定のトラフィックのフローが各ネットワークデバイスを通過するときに、そのトラフィックのフローをどのように処理するかという方法を規定します。通常は、特定のトラフィックのクラスに関連する 3つの特性で表現されます。この 3つの特性は、以下のとおりです。

� ロス：パケットのエラーであり、送信元からネットワークに伝送されたパケットが目的の宛先に到達しなかったことを示します。

� 遅延：送信元からネットワークに伝送されたパケットが目的の宛先に到達するまでの遅延を示します。

� ジッター：単一のフローで連続したパケットの間に生じる遅延の変動を示します。

一般に、この 3つの特性に基づいて、エンドツーエンドに提供される特定のアプリケーションに属しているトラフィック関連の QoSは規定されます。ホップ単位の動作を規定して、目的のエンドツーエンドQoSが確実にトラフィックに適用されるよう（場合によっては間接的に）、ホップバイホップ単位に操作できる特性もあります。言うまでもありませんが、3つの特性はそれぞれ、特定のアプリケーションに大きな影響を及ぼします。それでは、個別に見ていきましょう。

ロスパケットの障害であり、送信元からネットワークに伝送されたパケットが目的の宛先に到達しなかったことを示します。エラー、リンクやノードの障害、ネットワークの輻輳、ネットワークのいずれかのノードでの意図的なアクションなど、ロスはさまざまな要因で引き起こされます。効果的に対処できるようにするため、ロスの実際の原因を理解することは重要ですが、QoSの観点では通常、ロスの原因はそれほど重要ではありません。

その理由として、パケットのロスが発生したときに起こり得る結果は、アプリケーションではロスを無視できる場合（損失したパケットの情報をアプリケーション側で推測できる、または、アプリケーションが単発のロスを許容できる）と、パケットを再送する必要がある場合の 2つに限定されることが挙げられます。パケットを再送する必要がある


場合は、信頼できる伝送メカニズム（たとえば、TCP）をトランスポートレイヤーが提供するか、アプリケーション側の責任で再送が要求されます。図 1.1に示すように、ロスを許容できるアプリケーションの例として、音声アプリケーションがあります。音声ストリームでパケットが失われた場合、ごく短時間の無声状態か、ポップ音が発生します。この場合、図の回線下の記号に示すように、アプリケーションの「エラー」として処理されます。ただし、人の耳と脳はこのような短時間の無音や音のひずみを補うことができるので、音声アプリケーションの低レベルなパケットロスをネットワーク側で補償する必要はありません。

ロス

XX

図 1.1 デジタル化されたアナログ信号のロスによる影響を簡単にまとめた図

逆に、銀行のシステムやネットワークは信じられないほどロスに対する許容度が低く、ロスを許容できないアプリケーションの例として挙げられます。給与の送金データを含むパケットが失われて、給与の金額が 1桁少なくなってしまうような状況を想像してみてください。1000のはずが 100になってしまうわけです。このような状況は、単純に見過ごせません。特定した上で、パケットを再送する必要があります。

遅延遅延は、パケットの送受信の間に生じる遅延を示します。図 1.2に示すように、多くのアプリケーションで、遅延はそれほど重要ではありません。

第1章：QoSの概要 9

遅延

XX

図 1.2 遅延の原因と影響を簡単にまとめた図

たとえば、インターネットラジオの伝送はエンコードの遅延による影響が大きいので、ネットワークに起因する遅延はそれほど重要な問題であると認識されません。いずれにせよ、DJによる時間チェックは 1～15秒遅れるので、影響が限定的なものになるよう時間的な余裕が考慮されています。ただし、音声通話で遅延が発生したときには、会話を始める前に無言で待つ必要があるので余計なものに感じるでしょう。通話者同士が同時に話し出す可能性は、常に高いものです。人の耳と脳は、200ms程度の遅延には特に問題なく耐えられます。遅延が 500msを超えると問題として認識され、通話は困難になります。

注どちらの例も音声ストリームに関連していますが、インターネットラジオはその単方向性という特徴によって遅延の許容度は高くなっています。これに対して、インタラクティブなアプリケーションでは、遅延がほぼ収まるまで、双方向性に影響が現れます。

ジッタージッターは連続したパケットの間に生じる遅延の変動を示し、音声通話サービスやビデオサービスなど、高付加価値型のサービスに大きな影響を及ぼすことがあります。特に、音声通話サービスは、アナログ音声信号をパケットで伝送可能なデータチャンクにデジタル化して、受信側でアナログストリームに再組み立てする処理に依存しています。通常、このデジタル化処理では、パケットが等間隔で送出される安定したストリーミングが生成されます。受信側では、固定長のバッファにパケットが格納され、十分な量のパケットが揃った時点で、次のセクションのアナログ信号がデコードされます。伝送中に、連続したパ


ケットの遅延によって、連続したパケットが到着する時間間隔が大きく変動した場合、有意なアナログ信号に変換する所定の時点で、必要なパケットがバッファに存在しないので、アナログ信号への再変換に失敗します。具体例として、図 1.3を参照してください。

異常遅延

XX

平均遅延ジッター

図 1.3 デジタル化されたアナログ信号のジッターによる影響を簡単にまとめた図

図 1.3に示すように、ジッターバッファを追加することで、ジッターによる影響は軽減できます。ジッターはジッターバッファの最大長よりも小さいという想定です。このアプローチのデメリットは、暗黙的に遅延が増加するということで、これまで説明してきたように、双方向の音声通話アプリケーションに悪影響を及ぼすということです。

まとめこれで説明は終わりです。動作の 3つの特性によって、世界全体のQoS、さらには世界全体のネットワークが評価されます。さまざまなアプリケーションやトラフィック動作の 3つの特性を微調整する目的で、ネットワークの個々のノードを調整しようとして混乱した場合には、この章に戻って、わかりやすくまとめられた定義を再確認してください。

第2章

JunosのQoSの基本概念とルーティングノード経由のパケットフロー

JunosのCoS設定の構成単位 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

CoS機能によるパケットフロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ハードウェアによるパケットフロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22


第 1章では、QoS、CoS、および動作の基本概念について説明しました。次に、第 2章では、Junosの CoS設定の基本的な構成単位について詳しく見ていくとともに、Junosのルーティング、スイッチング、およびセキュリティプラットフォームで（ほぼ）共通する、さまざまなQoS機能によるパケットフローについて説明します。さらに、現在のいくつかのプラットフォームに焦点を当て、特定の Junosのハードウェアプラットフォームに基づいて、QoS機能をパケットフローと対応付けて説明します。

ヒント各ネットワークデバイスは他のネットワークデバイスとはほぼ無関係に動作するので、実際に操作できるのはホップ単位の動作に限定されます。

Junosの CoS設定の構成単位本書の以降のセクションでは、M/Tシリーズルーティングノード、MXシリーズイーサネットサービスルーター、および SRXセキュリティノードに実装された Junosの CoSに焦点を当てて説明します。各製品は、最新のコア、エッジ、およびセキュリティノードの例として引用しています。JunosのあらゆるCoS実装には、特定のインタフェースのアウトバウンドパケットの動作を制御するために必要とされる特定の機能があります。

注各機能の制御を実装する方法は各ベンダーのネットワーク機器でそれぞれ異なり、若干、異なる用語で表現される場合もあります。本書で使用される用語と、本章で定義した用語は、Junosの設定で使用される用語です。ただし、さまざまなベンダーの機器に幅広く当てはまるよう、特定のベンダーの視点にとらわれずに説明しています。

最初に、アウトバウンドパケットの動作を制御できる Junosの主要なCoS機能を紹介して、それぞれ短いセクションで説明していきます。

� 転送クラス � 分類 � ポリシング � RED（Random Early Discard） � シェーピング � スケジューリング � リマーキング

第2章：JunosのQoSの基本概念とルーティングノード経由のパケットフロー 13

転送クラス

転送クラスは、ノードから送信されるときに個別の動作を必要とするすべてのトラフィックを識別する目的で、ネットワークノード内だけで使用されるラベルです。転送クラスは、ノードの外部に明示的には表示されませんが、ネットワーク内の全ノードの QoS設定に一貫性がある場合、パケットヘッダ内の情報から簡単に導出できます。

分類

分類は、パケットの所属クラスを識別する処理です。通常、各ノードでの受信時に最初に実行されますが、ネットワークノードのパス上のさまざまなポイントでパケットが再分類される場合もあります。Junosでは、主要な 3つのアプローチでパケットを分類します。それぞれのアプローチは、必要な設定の柔軟性と複雑性が異なります。具体的には、インタフェースベース分類、BA（Behavior Aggregate）分類、MF（Multifield）分類という3つのアプローチです。これらのアプローチは相互に排他的なわけではなく、組み合わせて適用することで、大まかな初回動作を設定してから、トラフィックのサブセットをさらにきめ細かく再分類することが可能になります。

インタフェースベース分類あるインタフェースに到達するすべてのトラフィックが単一のクラスに関連付けられることがあらかじめ確定している場合は、インタフェースに到達したすべてのトラフィックをそのまま関連する転送クラスに関連付けることが最も簡単なトラフィックの分類メカニズムです。実装自体に特に言及すべき点はありませんが、この方法では、インタフェースに到達するすべてのトラフィックのクラスは同じであると想定しています。例外を示唆する固有メカニズムは存在しないので、柔軟性には欠けるアプローチです。ただし、MF分類と組み合わせて使用することで、必要に応じて、デフォルトのインタフェース分類に対する例外にも、さらにきめ細かく対応できます。

ヒントこのメカニズムは、アップストリームノードが信頼されておらず、単一のクラスを適用することで、受信トラフィックをすべて無害化する場合にも役立ちます（通常、この状況ではベストエフォートの対応）。


BA分類BA（Behavior Aggregate）分類は、柔軟性と複雑性の両方で適切なバランスを実現します。分類対象のトラフィックが大規模な集約で伝送される場合には特に有効です（たとえば、MF（Multifield）分類が効果を発揮しない、さまざまな固有のアプリケーションに関連付けられたトラフィックが単一のリンクを通過するネットワークのコア領域）。BA分類は、受信パケットのヘッダーに含まれているマーキングに依存します（イーサネットフレーム、IPv4または IPv6パケット、MPLSフレームなど）。これらのパケットまたはフレームタイプにはそれぞれ、以前に割り当てられたパケットのクラスを明示する目的専用のフィールドがヘッダー内に用意されています。イーサネット（802.1Q VLANフレームの使用）の場合には、802.1pの 3ビットがあります。IPv4パケットの場合には、TOS（Type of Service）フィールドがあり、先頭から 3ビット使用する IP Precedenceか、先頭 6ビットを使用するDSCP（DiffServe Code Point）のどちらかを使用することができます。IPv6の場合には、IPv6 DSCPの 6ビットがあります。MPLSの場合には、試験ビット用の 3ビットがあります。

注 IPv6の場合、実際には 8ビットがありますが、そのうち 2ビットは将来の使用に備えて確保されています。

注 MPLSの試験ビットという用語を使用すると、誤解を招く可能性があります。この 3ビットは、実際の試験用途には使用されていません。この 3ビットには他の用途は規定されておらず、現在の機能に即した名前に変更する取り組みが進められています。

重要なポイントは、このモデルの主な制約として、パケットを正しく（かつ適切に）マーキングするため、アップストリームノードが信頼されている必要があるということが挙げられます。アップストリームノードが信頼できない場合、必要以上に高い QoSが割り当てられるクラスや、アップストリームノードの所有者が費用を負担するクラスに対して、ノードが誤ってトラフィックをマーキングするという問題が生じる可能性があります。

MF分類設定・管理の柔軟性は最も優れていますが、最も複雑な対応が必要になるのが、MF（Multifield）分類です。ファイアウォールフィルタ（アクセスリスト）を使用して、IPパケットの任意の属性（非 IPタイプのトラフィックに適用される場合は少ない）を識別し、IPパケットの内容に基づいてトラフィックを特定のトラフィッククラスに適用します。


実際、このアプローチが制約を受けるのはファイアウォールフィルタで照合できる特性だけに限定されるので、パケットの所属トラフィッククラスをきめ細かく選択できます。ただし、きめ細かく選択するには、比較的複雑なフィルタが必要になり、場合によっては、顧客専用のフィルタを用意する必要があります。複雑さと管理コストの度合いを考えると、MF分類が特に役に立つのは、パケットをマーキングするアップストリームノードが信頼されていない（信頼できない）場合や、任意のパラメータに基づいてQoSを提供する要件が厳しい場合です。さらに、MF分類を使用して、BA分類やインタフェース分類で選択された転送クラスを変更できます。したがって、前述のように、BA分類のマーキング（またはインタフェース分類のマーキング）に基づいて大まかな分類を行ってから IPヘッダー内の任意の属性に基づいてトラフィックのサブセットを再分類できます。

ポリシング

ポリシングは、（たとえば、ノードでの受信時や送信のキューイング時に）トラフィックがリソースにアクセスできるレートに対して、ハードリミットを適用する方法です。ノードやキューへのアクセスはポリサーによって制限されるので、パケットが不適合であると判定され、保護されたリソースへのアクセスが許可されない場合、そのパケットはドロップ（または再分類）されます。このようなハードドロップ動作は、TCPトラフィックや、ポリサーが常に制限に従って動作している状況では、悪影響を及ぼす場合があります。ポリサーに基づいてパケットを再分類することは可能ですが、パケットを受信した順序に制約があるアプリケーションでは、パケットの並べ替えが発生しないよう注意する必要があります。Junosでは、ポリシングは以下の 3つのモードで動作できます。

� シンプルなポリサーは、単一のレートリミットと単一のバーストサイズに基づいて動作します。このようなポリサーは、シングルレート、2カラーポリサーとも呼ばれています。

� シングルレート、3カラーポリサーは、単一のレートリミットと2つのバーストサイズを使用します。この場合、3つのロスプライオリティを作成するメカニズム（RFC2597の説明では、相対的優先転送（Assured Forwarding））が可能になります。

� 2レート、3カラーポリサーは、2つのレート（コミットレートとピークレート）を使用して、シングルレート、3カラーポリサーと同じ結果をもたらします。


RED（Random Early Discard）

RED（Random Early Discard、または Random Early Detection）は、輻輳回避メカニズムです。輻輳による影響を軽減する働きがあります（特に、TCPベースのトラフィック）。

さらに詳しくは実際に輻輳が発生しているときの TCPの動作についての詳しい解説や、REDがこの動作の最悪の部分を回避できる理由の説明については、『QoS Enabled Networks:Tools and Foundations』、ピーター・ルンドクヴィストとミゲル・バレイロス共著（2011年、John Wiley & Sons社）を参照してください。同書は、ご利用のオンラインストアや、www.juniper.net/booksから入手できます。

キューからランダムな TCPパケットを選択して破棄することで、そのパケットの配信を待機しているエンドポイントは、そのパケットの確認応答の送信に失敗します（または、そのパケットが確認応答であった場合、受信側は確認応答を受信しません）。この場合、パケットの再送と伝送ウィンドウサイズの縮小がトリガーされます（結果として、送信元が TCPパケットを伝送する速度も低下します）。ドロップ対象のパケットがランダムに選択されるという特性によって、すべてのトラフィックフロー、アプリケーション、および送信元が不公平にペナルティを受けて、輻輳状態に近いリンクで利用可能な処理容量をあらゆるソースが公平に共有し続けることになります。パケットがドロップされた TCP送信元はパケットの伝送速度を低下させるので、輻輳の度合いは低下します。したがって、あらゆる要素に対して公平なメカニズムが実現します。ただし、QoSはあらゆる要素に対して公平である必要はなく、通常は優先順位の高い（高価値で、ロス、遅延、またはジッターの影響を受けやすい）トラフィックに優先順位が割り当てられます。特定の転送クラスに属しているパケットがドロップされる速度を操作するには、各転送クラスの REDに重みを適用する必要があります。このプロセスは、WRED（Weighted RED）として知られています。特にロスを許容できない転送クラス（たとえば、緊急転送（Expected Forwarding）や相対的優先転送（Assured Forwarding））でパケットのドロップを避けるには、REDに重みを適用することが極めて重要になります。

注緊急転送（Expected Forwarding）と相対的優先転送（Assured Forwarding）は既定の動作であり、その定義はそれぞれ RFC3246とRFC3260に記載されています。


多くの場合、ロス、遅延、およびジッターを許容できないアプリケーションに関連付けられたトラフィックは、UDPで伝送されます。この場合、アプリケーションで感知されるQoSが損なわれるので、REDの適用は逆効果になります。さらに、UDPにはパケットのロスを識別して伝送レートを調整する組み込みのメカニズムがないので、パケットは結局、スループットに特に影響を及ぼすことなく、そのまま失われるか（感知されるQoSの低下）、さらに悪い場合は、アプリケーションがロスを識別して無条件にパケットの再送を要求し、パケットが二重に送信されて、輻輳の悪化を招く可能性があります。

シェーピング

シェーピングは、トラフィックの伝送可能なレートに対するリミットの適用です。ポリシングとは異なり、キューへのアクセスがすでに許可されていて、伝送リソースへのアクセスを待機している状態のトラフィックに対して作用します。シェーパの基準に適合しないトラフィックは通常、基準に適合するまでキューで保持されます。（キューが満杯になっていない限り）キューに入力されるトラフィックがさらに増えても、明示的な制約は設定されません。したがって、シェーピングはポリシングほど積極的な処理ではなく、悪影響も少なくなっています。シェーパは通常、CIR（Committed Information Rate）および /または PIR（Peak Information Rate）を単位として定義されます。

スケジューリング

スケジューリングは、パケットの所属クラス（または待機中のキュー）に基づいて、パケットをクラスに基づいてワイヤに配置する順序を決定する処理です。複数のキューが存在し、それぞれのキューで伝送待機中のパケットが保持されていて、使用できるのがシリアル伝送メディアに限定される場合は、優先的に処理するキュー、期間、各キューでトラフィックが送信されたかどうか再チェックする頻度を決定する必要があります。

リマーキング

前述のように、イーサネット、MPLS、IPv4、および IPv6パケットはすべて、パスで先に決定された分類の情報を別のノードに通知する目的で使用可能なフィールドをヘッダー内に保持しています。リマーキングは、伝送ルーターによってパケットが割り当てられたクラスを識別するための値を、送信パケットのヘッダーに格納（置き換え）する処理です。以降のノードは、このマーキングを使用して、BA分類で整合性を維持


したままパケットを簡単に分類することが可能になります。BA分類で使用可能なマーキングタイプ（IEEE 802.1p、MPLS EXP、IPv4 Precedence、IPv4 DSCP、または IPv6 DSCP）を使用して、パケットのヘッダータイプごとにリマーキングできます。

CoS機能によるパケットフロー図 2.1は、ジュニパーネットワークスのルーティング、スイッチング、およびセキュリティノードのさまざまな CoS機能によるパケットのフローを示します。パケットの動きに沿って、上から右方向に、受信ハードウェアで実行される機能を示します。これに対して、下から左方向に、送信ハードウェアで実行される機能を示します。中央の四角形の枠は、転送クラスとロスプライオリティの格納場所を表します。この 2つの値は、パケットのフローがルーターで処理されるときに操作できます。最終的には、パケットの処理方法に基づいて決定されます（最後の 2つの枠）。

受信

送信

BA分類

ポリシング（受信）

MF分類

転送ポリシー

マーカーのリライト

MF分類

ポリシング（送信）スケジューラシェーパ RED

転送クラス

ロスプライオリティファブリック

図 2.1 Junosの CoS処理

この図に示す枠のラベルのほとんどすべてについて、本章と第 1章で説明しています。この点に気が付かなかった場合は、それぞれの機能を簡単に復習してください。

注図 2.1の BA分類の枠には、これまでに説明した BA分類の機能とインタフェース分類の両方が含まれています。この両方のスタイルの BA分類を同時に単一のインタフェースに適用することはできません。


注 Junosでは、ポリシング（受信）とMF分類は同じファイアウォールフィルタ構造で実装されています。したがって、単一のファイアウォールフィルタで、最初に基準不適合のトラフィックをポリシングしてから、ファイアウォールフィルタのアクションとして定義した転送クラスとロスプライオリティを基準適合のトラフィックに適用する処理が可能です。

ネットワークデバイスのスイッチファブリックに伝送する前に、トラフィックを転送ポリシーに従って処理することが可能です。この機能は、別のファイアウォールフィルタとして実装されています。具体的には、トラフィックがスイッチファブリックに到達しようとした時点で、転送テーブルの情報と既存の転送クラスとロスプライオリティに基づいて処理を実行します。図 2.1の中央、転送ポリシーと中央の四角形の枠の間にある双方向の矢印に注目してください。送信時には、キューイング前の送信パケットの転送クラスとロスプライオリティを再び操作できます。この機能は、別のポリシング（送信）/MF分類の組み合わせを使用して、受信時と同様にファイアウォールフィルタとして実装されます。最終的なポリシングと分類の処理が実行された時点で、トラフィックはキューイングされ、REDプロファイル、シェーパ、およびスケジューラによって処理されます。最後に、回線で伝送される直前に、イーサネット、MPLS、IPv4、または IPv6ヘッダー内のマーキングが再書き込みルールに従って修正されます。この情報によって、パケットが大規模に集約されたフローの一部になっている場合でも、ダウンストリームのネットワークデバイスで分類の決定が容易になります。

ハードウェアによるパケットフロージュニパーネットワークスのルーターのパケット転送アーキテクチャは、1998年にM40が最初にリリースされてから、大きく進化しました。ただし、ルーターの基本的なアーキテクチャは変更されていません。あらゆるルーターは、コントロールプレーン（この機能は 1つ以上のルーティングエンジンによって実行される）、フォワーディングプレーン（この機能は 1つ以上のパケット転送エンジン（PFE）によって実行される）、サービスプレーン（この機能は 1つ以上のサービス PICまたはDPCによって実行される）という3つの要素で構成されています。図 2.2に、この各要素によるパケットフローを示します。


マスターRE

サービスPIC/DPC

制御トラフィック

バックアップRE

パケット転送エンジン（PFE）

ユーザートラフィック

ユーザートラフィック

図 2.2 ルーティングノードによるパケットフロー

PFE（Packet Forwarding Engine）は、最も進化した要素です。M40のシングル共有メモリアーキテクチャや続いてリリースされたM20、M5、M10、M7iおよびM10iから、スイッチファブリックカードに PFEを搭載したM160およびM120、1つ以上の PFE複合体がラインカードに搭載され、複数のスイッチファブリックによってPFE間で回復力の高いパスを実現するM320、Tシリーズ、およびMXシリーズに至るまで、製品としての考え方は一貫して同じです。すなわち、「ユーザートラフィックは、コントロールプレーン（RE）の負荷に左右されずに転送される必要がある」という考え方です。

新しい PFEハードウェアの開発によって、CoSは強化され、Junos TrioチップセットをベースとするMX3Dプラットフォーム（多数の加入者に大容量で提供されるさまざまなサービスの規模拡張に対応するプラットフォーム）の現在の対応範囲は最高レベルに達しています。さらに、このような加入者、サービス、および帯域幅の規模拡張によって、QoS設計の重要度は増しています。

ハードウェアによるパケットフローは、極めて高いレベルで、各プラットフォーム間で一貫性を保っています。図 2.3に示すように、スイッチファブリックの数に応じて、単一のラインカード上の PFE複合体とPICの数は異なる場合がありますが、考え方自体は同じです。


PIC PFE

PIC PFE

PIC PFE

PIC PFE

PFE PIC

PFE PIC

PFE PIC

PFE PIC

スイッチファブリック

図 2.3 ラインカード上の PFE複合体とPIC

ハードウェアによるパケットフローは、以下の一連の処理に従います。 � PICに到達したパケットが解析されて（レイヤー 2）、そのパケットが、PICによって取得されたレイヤー 2の関連情報とともに、PFEに転送されます。

� 受信 PFEが残りのヘッダー情報を解析して、パケットに関するメタデータの固定長ブロックを作成します。さらに、ルーターとラインカードによっては、データ部分が一時的な格納用のチャンクに分割されます。

� PFE内で、パケットは転送クラスとパケットロスプライオリティに基づいて分類されます。さらに、パケットの転送先となる PFEが決定されます。この決定はパケットの宛先だけでなく、パケットと一致する可能性があるファイアウォールフィルタ、転送クラス、パケットの PLP（Packet Loss Priority）に基づいています。


� 次に、パケットとメタデータをスイッチファブリックで伝送するため、受信 PFEが送信 PFEのリソースを要求します。パケットは複数のスイッチファブリックで送信される可能性があります。

� 送信 PFEで、パケットは再組み立てされて、パケット全体が正しく組み立てされたことと、パケットが伝送された順序で返されたことが検証されます（スイッチファブリックで並べ替えられた場合）。

� 次に、送信 PFEは、まったく同じ手順（パケットの解析、送信ポリサー、ドロッププロファイル、スケジューラ、およびシェーパに基づいた転送の決定、最後にヘッダーの再書き込み）を実行します。これで、パケットは適切なマーキングを付加されて、回線で伝送可能な状態になります。

図 2.3からもわかるように、パケットが単一のラインカードの PICに到達して、同じラインカードの別の PICが宛先に決定した場合でも、そのパケットはスイッチファブリックを経由することになります。唯一の例外は、パケットが PICのポートに到達して、同じPICの別のポートが宛先に決定した場合です。この場合、プラットフォームによっては、パケットは PFEの受信機能ブロックとPFEの送信機能ブロックの間のショートカットを経由します。ただし、どのような場合でも、ポート間のスイッチングのため、パケットは必ず PFEを経由します。

まとめこれまでの学習で、QoSを操作するための基本要素、各要素が影響を及ぼす動作、この動作を実装する基盤となるハードウェア機能、ジュニパーネットワークスのプラットフォームでの実装順序といった項目について、はっきりと理解している必要があります。次に、Junosで比較的シンプルな CoS設定一式を作成するため、これらの要素をそれぞれ設定する方法について詳しく見ていきます。

第3章

Junosソフトウェアによる基本的なQoS実装の構築

コードポイント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

分類アプローチの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

受信ポリサー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

転送テーブルポリシー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

送信ポリサー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

ドロッププロファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

スケジューリングとシェーピング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

書き換えのルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

概略 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44


本章では、一貫性と柔軟性に優れた QoS設計を実現するために、基本的な QoS機能を個別に選択して、パケットフローのさまざまなポイントで組み合わせる方法について説明します。各セクションには、機能を設定する場合にも流用できるテンプレート設定が用意されています。このテンプレートには、以下の形式で変数が含まれています。 $variable_name$

設定を完成させるには、この変数を有効な値で置き換える必要があります。有効な設定では、一部の要素は複数回、出現する場合があります。ただし、簡潔に示すため、テンプレートでは、出現回数を 1回だけに変更しています。参考として、図 3.1は、本書で使用しているトポロジーです。もちろん実際のネットワークとは異なるでしょうが、このシンプルなトポロジーに従って試験用のテストベッドを構築すれば、実践的な試験を実施できるでしょう。

P

P PPE

BNG

PE

BNG

図 3.1 本書で使用するトポロジー

コードポイント今回のQoSの実装を開始する前に、使用するコードポイントのタイプを確認しておく必要があります。Pルーターと、PEルーターの対向インタフェースであるコアでは、BA分類を使用する可能性が高いと考えられます。したがって、コードポイントのエイリアスを指定する必要があるかどうか判断する必要があります。エイリアスとは、数値に対して指定する、わかりやすい名前です。このエイリアスを使用すると、コードポイントが覚えやすくなり、特定の転送クラスと簡単に関連付けられるようになります。ただし、エイリアス自体はまったくのオプションです。エイリアスのデフォルトのセットは、マーキングのタイプごとに用意されています。

第3章：Junosソフトウェアによる基本的なQoS実装の構築 25

一般に、独自のエイリアスを作成する必要はありませんが、以下のように、必要に応じてエイリアスを設定するためのテンプレートが用意されています。

class-of-service { code-point-aliases { $marking_type$ { $alias$ $code_point_bits$; } }}

分類アプローチの選択受信インタフェースごとに、以下の 3つの分類アプローチから選択する必要があります。

� インタフェース分類 � MF（Multifield）分類 � BA（Behavior Aggregate）分類

第 2章では、機能の管理の複雑性と柔軟性のバランスを取るためのさまざまな方法について説明しました。以下の例では、分類のスタイルごとの使用法とともに、実際の使用事例と選択の理由について説明しています。

インタフェース分類用の設定テンプレート

以下のテンプレートでは、転送クラス$class_name$が論理インタフェース $interface_name$.$unit_id$に適用されていることがわかります。このすべてが [edit class-of-service]階層レベルで適用されることに注意してください。

class-of-service { forwarding-classes { class $class_name$ queue $queue_number$; } interfaces { $interface_name$ { unit $unit_id$ { forwarding-class $class_name$; } } }}


forwarding-classesの定義用テンプレートも用意されていることに注意してください（転送クラスの設定オプションについては、本章で後ほど詳しく説明します）。forwarding-classesのテンプレート要素は、interface設定で使用される $class_name$にリンクしていることを示す目的だけで紹介しています。

BA分類用の設定テンプレート

このテンプレートは、BA分類の設定および適用に必要な 3つの要素を示しています。最初の要素は、一般的な転送クラスの定義です。

class-of-service { forwarding-classes { class $class_name$ queue $queue_number$; } classifiers { $marking_type$ $classifier_name$ { class $class_name$ { loss-priority $loss_priority$ code-points [$code_points]; } } } interfaces { $interface_name$ { unit $unit_id$ { classifiers { $marking_type$ $classifier_name$; } } } }}

注転送クラスは、設定全体で 1回定義するだけで済みます。ここで繰り返し紹介しているのは、3つの方法それぞれで必要になることを示すためです。

2番目の要素では、各分類が特定の $marking_type$（ieee-802.1、exp、inet-precedence、dscp、または dscp6）と関連付けられ、コードポイント（またはコードポイントのセット）ごとに、転送クラス$class_name$とロスプライオリティ$loss_priority$がパケットに適用されます。必要な 3番目の要素は、論理インタフェース $interface_name$.$unit_

id$への分類の適用です。この設定はすべて、[edit class-of-service]階層レベルで適用されます。


MF分類用の設定テンプレート

MF分類は、これまでに説明した他の 2つのタイプの分類とは実装方法が少し異なります。具体的には、設定の大半が [edit firewall]

および [edit interfaces]階層レベルで適用されます（forwarding-

classesの定義だけが [edit class-of-service]階層レベルで適用されます）。

firewall { family inet { filter $filter_name$ { term $term_name$ { from { $match_conditions$; } then { forwarding-class $class_name$; $other_actions$; } } } }}interfaces { $interface_name$ { unit $unit_id$ { family inet { filter { input $filter_name$; } } } }}class-of-service { forwarding-classes { class $class_name$ queue $queue_number$; }}

ここでは、MF分類は、ファイアウォールフィルタとして実装されています。フィルタ条件に一致したトラフィックは、特定の forwarding-

classesに分類されるという処理が適用されます。このファイアウォールフィルタは、family inetまたは family inet6

階層で入力フィルタとして論理インタフェースに直接適用されます。


クラスの定義

次に、転送クラスを定義して、その転送クラスをキューにマッピングする方法を定義する必要があります。Junosは最大 32の転送クラスをサポートしていますが、転送クラスをマッピングできるキューの最大数は 8です。つまり、転送クラスとキューのマッピングは、4対 1の割合になります。転送クラスごとに適用されたドロッププロファイル（WRED）だけに基づいて、単一のキュー内で複数の転送クラスを区別することは可能です。

警告転送クラスの数が上限の 8を超えていて、1つ以上のキューに複数の転送クラスが関連付けられる場合、単一のキューに関連付けられているすべての転送クラスで必ず同じスケジューラを使用する必要があります。

最もシンプルなアプローチは、転送クラスからキューに対して 1対 1のマッピングを使用することです。通常は、8つの転送クラスで十分であり、本書で使用する例は、このモデルに焦点を当てています。

ヒント「この転送クラスに分類する必要があるのは、特定のアプリケーションのトラフィックに決まっているので、そのアプリケーションにちなんで転送クラスの名前を設定しよう」という衝動に駆られて、このような対応を取らないことを強く推奨します。転送クラスの名前は、動作にちなんで設定する方が適切です。そうすることで、同じ動作を必要とする、別のアプリケーションからのトラフィックを同じ転送クラスに分類するときに混乱せずに済みます。たとえば、videoという名前のキューに、中程度の遅延、極めて低いジッター、適度な低いロスを必要とするトラフィックがキューイングされた場合には、混乱を招く原因になるでしょう。

転送クラスの設定テンプレートのサンプルは、以下のとおりです。class-of-service { forwarding-classes { class $class_name$ queue $queue_number$ priority $fabric_priority$; queue $queue_num$ $class_name$ priority $fabric_priority$; }}

任意の単一の設定ですべての転送クラスに使用するのは、ここで紹介している 2つの設定メカニズムのどちらか 1つだけであることに注意してください。


受信ポリサー場合によっては、アップストリームノードが所定の契約に従ってトラフィックを送信していることを確認する必要があります。アップストリームノードが契約に従っていることを確認するため、ネットワークノードに到達したトラフィックをポリシングすることが可能です。この機能は、CE（Customer Edge）デバイスとPE（Provider Edge）デバイスの間の境界で、顧客の送信トラフィック（BAマーキングで定義した、合意済みのクラスごとに）が所定の容量を超えていないことを確認する場合に特に役に立ちます。Junos OSには、受信側のポリシングに対応するさまざまなモデルが用意されています。主なモデルは、以下のとおりです。

� シングルレート 2カラーマーキング � シングルレート3カラーマーキング � 2レート3カラーマーキング

シングルレート2カラーマーキング（ポリシング）

単一の値を使用して、許容可能なトラフィックレートをバーストサイズとともに定義します。既定のレートを上回っていると、トラフィックは契約範囲外（赤色）であると判定されます。既定のレートを下回っていると、トラフィックは契約範囲内（緑色）であると判定されます。契約範囲外のトラフィックはマーキング（再分類）されるか、即座に破棄されます。シングルレート2カラーマーキング（ポリシング）の設定テンプレートは、以下のとおりです。

firewall { policer $policer_name$ { if-exceeding { bandwidth-limit $PIR$; burst-size-limit $burst_size$; } then $action$; } family $family_name$ { filter $filter_name$ { term $term_name$ { from { $match_conditions$; } then { policer $policer_name$; } } } }


}interfaces { $interface_name$ { unit $unit_id$ { family $family_name$ { filter { input $filter_name$; } } } } $interface_name$ { unit $unit_id$ { family $family_name$ { policer $policer_name$; } } }}

srTCM（Single Rate Three-Color Marking：シングルレート3カラーマーキング）

シングルレート 3カラーマーキングでは、CIR（Committed Information Rate）、CBS（Committed Burst Size）、および EBS（Excess Burst Size）を使用します。CIRの範囲内のトラフィックは緑色、CBSを上回り、かつ EBSの範囲内のトラフィックは黄色に分類されます。EBSを上回るトラフィックは赤色に分類されます。この3色それぞれに異なるPLP（Packet Loss Priority）を適用できます。緑色は低 PLP、黄色は中～高 PLP、赤色は高 PLPにそれぞれ割り当てられます。シングルレート 3カラーマーキングの設定テンプレートは、以下のとおりです。

firewall { three-color-policer $tcm_policer_name$ { single-rate { (color-aware|color-blind); committed-information-rate $CIR$; committed-burst-size $CBS$; excess-burst-size $EBS$; } logical-interface-policer; action { loss-priority high then discard; } } family $family_name$ { filter $filter_name$ { term $term_name$ { from { $match_conditions$;


} then { three-color-policer $tcm_policer_name$; $other_actions$; } } } }}interfaces { $interface_name$ { unit $unit_id$ { family $family_name$ { filter { input $filter_name$; } } } }}

trTCM（Two Rate Three-Color Marking：2レート3カラーマーキング）

2レート 3カラーマーキングでは、CIR（Committed Information Rate）とPIR（Peak Information Rate）を使用します。srTCMの場合と同様に、トラフィックが 3色のいずれかに分類されます。このモデルでは、2つのレートが定義されます。CIRの範囲内のトラフィックは緑色、CIRとPIRの間のトラフィックは黄色、PIRを上回るトラフィックは赤色にそれぞれ分類されます。この 3色それぞれに異なるPLP（Packet Loss Priority）を適用できます。緑色は低 PLP、黄色は中～高 PLP、赤色は高 PLPにそれぞれ割り当てられます。srTCMと trTCMどちらのポリサーも color-awareモードまたはcolor-blindモードで動作できます。color-awareモードでは、すべてのパケットがすでに測定およびマーキング済みであり、適用済みのマーキングが考慮されているとポリサーは想定します。PLPの値を書き換えて高くすることはできますが、低くすることはできません。color-blindモードでは、以前に測定やマーキングは実行されていないとポリサーは想定し、PLPマーキングはすべて無視されます。すべてローカルの判定に基づいてPLPの値は設定されます。2レート3カラーマーキングの設定テンプレートは、以下のとおりです。


firewall { three-color-policer $tcm_policer_name$ { two-rate { (color-aware|color-blind); committed-information-rate $CIR$; committed-burst-size $CBS$; peak-information-rate $PIR$; peak-burst-size $PBS$; } logical-interface-policer; action { loss-priority high then discard; } } family $family_name$ { filter $filter_name$ { term $term_name$ { from { $match_conditions$; } then { three-color-policer $tcm_policer_name$; $other_actions$; } } } }}interfaces { $interface_name$ { unit $unit_id$ { family $family_name$ { filter { input $filter_name$; } } } }}

転送テーブルポリシー転送テーブルポリシーでは、転送テーブルの情報に基づいて転送クラスとロスプライオリティを操作できます。転送テーブルポリシーの設定および適用には、MF分類と類似の構文を使用します。この分類の設定には、転送クラスの設定アクションを含むファイアウォールフィルタを使用します。


ファイアウォールフィルタは、以下のように [edit forwarding-options

family $family$]階層レベルで入力フィルタとして適用されます。firewall { family $family_name$ { filter $filter_name$ { term $term_name$ { from { $match_conditions$; } then { forwarding-class $class_name$; $other_actions$; } } } }}forwarding-options { family $family_name$ { filter { input $filter_name$; } }}routing-instance $instance_name$ { forwarding-options { family $family_name$ { filter { input $fiter_name$; } } }}

このフィルタでは、単一のルーティングインスタンスと関連付けられている全トラフィックに適用される分類を決定できます。その際、ルーティングインスタンスに関連付けられているインタフェースに入力フィルタを適用する必要はありません。

送信ポリサー送信ポリサーは、送信キューに送られるトラフィックのレートリミットを設定します。送信ポリサーを作成するには、PIR（Peak Information Rate）とCBS（Committed Burst Size）を定義するポリサーを設定します。指定したアクションは、この PIRとCBSを上回ったトラフィックに適用されます。


このポリサーは、ファイアウォールフィルタのアクションとして使用されます。したがって、トラフィックを識別する照合条件を指定して、条件に適合したトラフィックに限定してポリサーを適用することで、キューイングされたトラフィックのサブセットにフィルタを適用することが可能です。最後に、ファイアウォールフィルタは、以下のように出力の関連インタフェースに適用されます。

firewall { policer $policer_name$ { if-exceeding { bandwidth-limit $max_bandwidth$; burst-size-limit $bytes$; } then { discard; } } family $family_name$ { filter $filter_name$ { term $term_name$ { from { $match_conditions$; } then { policer $policer_name$; $other_actions$; } } } }}interfaces { $interface_name$ { unit $unit_id$ { family $family_name$ { filter { output $filter_name$; } } } }}

ポリサーを論理インタフェース全体に適用することも可能です。この場合、インタフェースのすべてのキューで、キューイングされたトラフィックは属している転送クラスに関係なく、指定されたレートでポリシングされます。


ドロッププロファイルJunosでは、RED（正確には、Weighted RED）を実装する場合にドロッププロファイルを使用します。ドロッププロファイルを使用して、グラフ上の一連のポイントを定義します。この定義は、待機中にキューが特定の奥行に達した時点でドロップされるという条件に適合するトラフィックの割合を表します。ドロッププロファイルを作成する場合、2種類の基本的なアプローチがあります。最初のアプローチでは、グラフ上の一連のポイントを手動で定義します。このグラフは、基準レベルに達した時点で、次のドロップ確率の段階に上がるという階段グラフになります。この最初のアプローチのテンプレートは、以下のとおりです。

class-of-service { drop-profiles { $drop_profile_name$ { fill-level $fill_level_pc$ drop-probability $drop_pc$; } } scheduler $scheduler_name$ { drop-profile-map loss-priority $loss_priority$ protocol $protocol$ $drop_profile_name$; }}

ヒント MXシリーズルーターでは、drop-profile-mapの適用時に設定できるのは protocol anyに限定されます。一般に、トラフィックの大半が TCPベースのものである可能性が高く、ベストエフォートの転送クラスやその他の転送クラスに REDを適用することで、大きなプラスの影響をもたらすことも可能です。主に UDPトラフィックで構成される、ロスが許容されないクラスに適用されたスケジューラでは、ドロッププロファイルマップを使用することは避けてください。

このタイプのアプローチによる結果の例は、図 3.2のグラフに示します。この例では、定義する必要があるのは 2個のポイントだけですが、Junosでは最大 64個のポイントを定義できます。


ドロップ確率

基準レベル

100

10050

50

25

80

図 3.2 手動で定義したドロッププロファイルのグラフ

図 3.2のグラフは、以下の設定の抜粋を使用して実装されたものです。class-of-service { drop-profile { my_example_drop_profile { fill-level 50 drop-probability 25; fill-level 80 drop-probability 50; } }}

2番目のアプローチでは、2～ 64個のポイントを定義します。

注ポイントを 64個よりも多く定義することは可能ですが、ドロッププロファイルの作成に使用されるポイントは、64個に限定されます。

Junosでは、各ポイント間が補間され、64個の離散点 (0, 0) (f1, d1) (f2, d2) (fn, dn)および (100, 100)に基づいて、スムーズな曲線が作成されます。この最初と最後のポイントは、デフォルトで挿入されます。ドロッププロファイルを定義する 2番目のアプローチのテンプレートは、以下のとおりです。

class-of-service { drop-profiles { $drop_profile_name$ {


interpolate { fill-level [ $fill_1$ $fill_2$ ...$fill_n$ 100 ]; drop-probability [ $drop_1$ $drop_2$ ...$drop_n$ 100 ]; } } } schedulers { $scheduler_name$ { drop-profile-map loss-priority $loss_priority$ protocol $protocol$ $drop_profile_name$; } }}

ドロップ確率

基準レベル

100

10050

50

25

80

図 3.3 補間されたドロッププロファイルのグラフ

図 3.3のグラフは、以下の設定の抜粋を使用して実装されたものです。class-of-service { drop-profiles { my_example_interpolate_profile { interpolate { fill-level [50 80]; drop-probability [25 50]; } } }}


注 MXシリーズプラットフォームの拡張キューイング DPCで定義できるのは、(f1, 0)および (f2, 100)という2個のポイントに限定されます。図 3.4で 2つの値の間を結ぶ直線で示されるように、最初の点を下回っているトラフィックはすべて伝送され、2番目の点を上回っているトラフィックはすべて破棄されます。

ドロップ確率

基準レベル

100

10050

50

25

80

図 3.4 2個のポイントが定義されたドロッププロファイルのグラフ

図 3.4のグラフは、以下の設定の抜粋を使用して実装されたものです。class-of-service { drop-profiles { my_example_interpolate_eqdpc_profile { interpolate { fill-level [50 80]; drop-probability [0 100]; } } }}


スケジューリングとシェーピングスケジューリングとシェーピングは、QoSで最もわかりにくい部分かもしれません。ただし、段階的なアプローチで取り組めば、理解できないわけではありません。Junosでは、スケジューリングとシェーピングは、スケジューラ、スケジューラマップ、およびトラフィック制御プロファイルという3つの構成要素で設定します。送信インタフェースで適用される動作を網羅した定義を作成するため、この 3つの要素を順番に作成します。最も基本的な要素はスケジューラであり、単一の送信キューに関連付けられているトラフィックの動作を定義する目的で使用されます。スケジューラはスケジューラマップにまとめてグループ化され、（直接または間接を問わず）スケジューラマップが適用されるインタフェースで、トラフィックのクラスごとに 1つ設定されます。最後に作成されるのがトラフィック制御プロファイルであり、スケジューラマップとシェーパの機能を統合します。トラフィック制御プロファイルは、物理インタフェース、論理インタフェース、インタフェースセットと呼ばれる論理インタフェースの任意のグループなど、インタフェース階層のさまざまなレベルごとに適用できます。

スケジューラ

スケジューラは、個別のキューの動作と、個別のキューによって受信されるサービスを設定する目的で使用されます。スケジューラは抽象的な構成要素であり、特定の転送クラスに関連付けられていない場合、固有の設定を必要とせずに、複数のキューに適用できます。ただし、対象のすべてのキューが同じ動作を必要としていることが条件です。スケジューラは単純に、バッファのサイズ、キューの処理レート（利用可能なリソースの合計に対する割合または絶対的な伝送レートとして定義）、キューに適用される優先順位（厳密な優先順位に基づくキューイングのアプローチの場合）およびキューに関連付ける必要があるドロッププロファイルを定義します。設定の例は、以下のようになります。

class-of-service { schedulers { $scheduler_name$ { buffer-size [percent|temporal] $buffer_size$; transmit-rate [percent] $transmit_rate$ [rate-limit|exact]; priority $scheduler_priority$;


excess-priority $scheduler_priority_excess$; excess-rate [percent] $transmit_rate$; drop-profile-map loss-priority $loss_priority$ protocol any drop-profile $drop_profile_name$; } }}

Junos は、PQ-DWRR（Priority Queueing – Deficit Weighted Round Robin）モデルでスケジューリングを実装しています。このモデルでは、キューのスケジューリング順を定義する目的で上の例のように設定される 2つの属性を利用します。priorityには、5つの値（strict-high、high、medium-high、 medium-low、および low）のいずれかが設定されます。実際には、strict-highは契約範囲外にならないという点を除けば、strict-highとhighの動作は同じなので、この値の種類は 4つです。理解しておく必要がある 2番目に重要な属性は、キューの重みを定義する transmit-rateです。この属性は、トラフィックが契約範囲内であると判定される基準を宣言します。この基準のリミットを超えた時点で、トラフィックは契約範囲外であると判定されます。この 2つの属性に基づいて、キューは以下の順序でスケジューリングされます。

1. 契約範囲内で優先順位 high（および strict-high）のキューは、完全に空になるか、完全に契約範囲外になるまで処理されます。

2. 契約範囲内で優先順位medium-highのキューはすべて、完全に空になるか、完全に契約範囲外になるまで処理されます。

3. 契約範囲内で優先順位medium-lowのキューはすべて、完全に空になるか、完全に契約範囲外になるまで処理されます。

4. 契約範囲内で優先順位 lowのキューはすべて、完全に空になるか、完全に契約範囲外になるまで処理されます。

5. 契約範囲外で優先順位 highのキューは、空になるまで処理されます。

6. 契約範囲外で優先順位medium-highのキューは、空になるまで処理されます。

7. 契約範囲外で優先順位medium-lowのキューは、空になるまで処理されます。

8. 契約範囲外で優先順位 lowのキューは、空になるまで処理されます。


注それぞれの段階で、パケットの伝送後に、優先順位が高いパケットが伝送待機中の状態ではないことを確認するチェックが毎回実行されます。該当するパケットが存在した場合、スケジューラはそのキューを再スケジューリングします。したがって、契約範囲内で優先順位が高いキューは、再スケジューリングが可能になる前に、最大サイズのパケット 1つの伝送に要する時間を超えて待機することはありません。

契約範囲外になったキューに関連付けられている優先順位および伝送レートを変更するには、excess-priorityと excess-transmit-rateを変更します。

注スケジューラは、使用する動作ごとに作成する必要があります。この結果、さまざまなタイプや速度のインタフェースを使用して、幅広いサービスを提供している場合、特にエッジルーターでは、スケジューラの数が増えることがあります。提供するサービスを細かく定義することで、サービスの内容自体を変えずに、スケジューラの数を大幅に減らすことができます。

スケジューラマップ

スケジューラマップは、スケジューラをまとめてグループ化し、インタフェースに存在するそれぞれの転送クラスに適用する目的で使用されます。スケジューラマップの作成時には、各転送クラスに割り当てられたサービスの量とその転送クラスの相対優先順位を確認します。

注作成した転送クラスの数が 8個を超えて、複数の転送クラスを単一のキューにマッピングしている場合、単一のキューにマッピングしているすべての転送クラスで、必ず同じスケジューラを使用する必要があります。単一の転送クラスのトラフィックは、スケジューラのロスプライオリティごとに固有のドロッププロファイルを適用することで、ロスプライオリティに基づいて区別できます。

注スケジューラマップの適用先であるインタフェースに発生する可能性があるトラフィックの各転送クラスには、対応するスケジューラを適用することを強くお勧めします。転送クラスに対して特定のスケジューラが適用されていない場合、そのクラスでインタフェースに到達したトラフィックには、明示的に設定されたサービスが提供されません（たとえば、バッファや伝送レートなどが未設定の状態）。したがって、インタフェースが他のトラフィックでまったく使用されていない場合を除いて、サービス品質が極端に低下します。


スケジューラマップの設定テンプレートは、以下のとおりです。class-of-service { scheduler-maps { $scheduler_map_name$ { forwarding-class $class_name$ scheduler $scheduler_name$; } } interfaces { $interface_name$ { unit $unit_id$ { scheduler-map $scheduler_map_name$; } } }}

スケジューラマップは、上のテンプレートの例のように、論理インタフェース（unit $unit_id$）に直接適用されるか、MXシリーズルーターの場合のように、トラフィック制御プロファイル（次のセクションを参照）を使用して適用されます。インタフェースに直接適用された場合、シェーピングは適用できません。ただし、ポリシングは、標準的な送信ファイアウォールフィルタを使用して適用できます。

トラフィック制御プロファイル

トラフィック制御プロファイルは、階層型のシェーパおよびスケジューラの作成を可能にします。トラフィック制御プロファイルは、シェーピングとスケジューリングのそれぞれ 4つのレベルに適用できます。また、以下のように使用すれば、シェーパ、スケジューラ、またはこの両方に適用できます。

class-of-service { traffic-control-profiles { $tcp_name$ { scheduler-map $scheduler_map_name$; shaping-rate $pir$; guaranteed-rate $cir$; } $per_priority_tcp_name$ { shaping-rate-priority-high $pir_high$; shaping-rate-priority-medium $pir_medium$; shaping-rate-priority-low $pir_low$; } } interfaces {


interface-set $interface_set_name$ { output-traffic-control-profile $per_priority_tcp_name$; } $interface_id$ { output-traffic-control-profile $tcp_name$; unit $unit_id$ { output-traffic-control-profile $tcp_name$; } } }}

書き換えのルールダウンストリームノードによる BA分類の実行を可能にするには、送信時にパケットをマーキングする必要があります（まだマーキングされていない場合）。マーキングは、分類（IEEE 802.1p、MPLS EXP ビット、IP Precedence（IP DSCP、または IPv6 DSCP）と同じ一連のアドレスファミリに対して実行できます。マーキングを適用するメカニズムは、分類と正反対の処理を行うメカニズムに近いと言えます。ただし、注意すべき点として、単一の転送クラスおよびロスプライオリティが設定されているパケットは、以下に示すように、同じマーキングを共有する必要があります。

class-of-service { rewrite-rules { $marking_type$ $rewrite_rule_name$ { class $forwarding_class$ { loss-priority $loss_priority$ code-point $code_point$; } } } interfaces { $interface_name$ { unit $unit_id$ { rewrite-rules { $marking_type$ $rewrite_rule_name$; } } } }}


概略本章の各セクションは、ネットワークノードでのパケットフローに沿った順序で記載されています。図 3.5に、この順序をわかりやすく示しています。

インタフェース

物理インタフェース

論理インタフェース

ファイアウォールフィルタ

ポリサー

分類

CoS

物理インタフェース

論理インタフェース

スケジューラマップ

スケジューラ

ドロッププロファイル

転送オプション

転送テーブル

転送テーブルフィルタ

リライトの規則トラフィック制御プロファイル

図 3.5 概略図

第4章

例

QoSのコア設定の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

分散/プロバイダエッジの階層型のQoS設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

ブロードバンド加入者向けの動的なQoS設定の例 . . . . . . . . . . . . . . . . . . . . . . .56

ハイエンドセキュリティノード向けのQoS設定 . . . . . . . . . . . . . . . . . . . . . . . . . . .59


これまでの学習で、QoSの基本的な考え方と、Junosの設定の構成要素を使用してQoSの各機能を実装する方法については十分に理解できたことでしょう。これまでに学んだ知識を背景に、この最終章では、本書で以前に取り上げたツールを使用して、特定の状況に応じたQoS設定を作成する方法について、いくつかの広範な例に基づいて説明します。第 1章で最初に説明したように、本書のタイトルは『Day One：基本的な QoSの導入』であり、基本的な事項に重点を置いて説明しています。本書は、1998年のM40のリリース以降、ジュニパーネットワークスが販売してきたハードウェアのあらゆる組み合わせを網羅して、実現可能な QoSの実装をすべて解説することを目的とはしていません。本書で取り上げている例は、コア設定についてはTシリーズのルーティングプラットフォーム、エッジおよび BNG設定についてはMXシリーズ、セキュリティ設定についてはSRXにそれぞれ基づいています。全体を網羅した詳細な設定ガイドについては、各プラットフォームの最新機能ごとに、http://www.juniper.net/techpubs/software/junosで入手できます。

ヒント本章の例に含まれている識別子のうち、Junos以外の識別子で、設定の各要素を関連付ける目的で使用されるタグを表すものについては、UPPER_CASE_WITH_UNDERSCORESというスタイル（アンダースコア付きの大文字）で表記しています。Junosのキーワードは常に、lower-

case-with-dashesというスタイル（ダッシュ付きの小文字）で表記しています。このように異なる表記でキーワードと変数を表すことは必須ではありませんが、両者をはっきりと区別できるようになります。

QoSのコア設定の例ここでは、ルーターを通過するトラフィックはすべてMPLSでカプセル化され、MPLSヘッダー内の EXPビットで一貫した値ですでにマーキングされていると想定しています。ただし、このような想定は、必ずしも現実的ではないことに注意してください。トラフィック（管理トラフィックやネイティブマルチキャストなど）によってはネイティブ IPのままであることが一般的であり、トラフィックにCoSを提供するには、特に inet-precedenceや dscp用に分類やリライトの規則を追加する必要があり、設定の例で考えると、設計全体が明確にならずに、複雑性だけが増してしまいます。さらに、この設定は、MX以外のルーター（たとえば、Tシリーズルーター）で動作していると想定しています。

第4章：例 47

class-of-service { forwarding-classes { class NC queue 7 priority high; class EF queue 5 priority high; class AF11 queue 4 priority medium-high; class AF13 queue 3 priority medium-high; class AF22 queue 2 priority medium-low; class AF42 queue 1 priority medium-low; class BE queue 0 priority low; class LBE queue 6 priority low; } classifiers { exp BA_CORE_EXP_CLASSIFIER { forwarding-class NC { loss-priority low code-points 111; } forwarding-class EF { loss-priority low code-points 101; } forwarding-class AF11 { loss-priority low code-points 100; } forwarding-class AF13 { loss-piority high code-points 011; } forwarding-class AF22 { loss-priority medium code-points 010; } forwarding-class AF42 { loss-priority medium code-points 110; } forwarding-class BE { loss-priority high code-points 000; } forwarding-class LBE { loss-priority high code-points 001; } } } schedulers { HIGH_5PC_5PC_SCHEDULER { transmit-rate percent 5; buffer-size percent 5; priority high; } HIGH_50PC_RL_20MS_SCHEDULER { transmit-rate percent 50 rate-limit; buffer-size temporal 20000; priority high; } MEDIUM_HIGH_10PC_20PC_SCHEDULER {


transmit-rate percent 10; buffer-size percent 20; priority medium-high; } MEDIUM_HIGH_10PC_10PC_SCHEDULER { transmit-rate percent 10; buffer-size percent 10; priority medium-high; drop-profile-map loss-priority high protocol any drop-profile AGGRESSIVE; } MEDIUM_LOW_10PC_10PC_SCHEDULER { transmit-rate percent 10; buffer-size percent 10; priority medium-low; drop-profile-map loss-priority high protocol any drop-profile MODERATE; } LOW_5PC_20PC_SCHEDULER { transmit-rate percent 10; buffer-size percent 20; priority low; drop-profile-map loss-priority high protocol any drop-profile AGGRESSIVE; } LOW_REM_REM_SCHEDULER { transmit-rate remainder; buffer-size remainder; priority low; drop-profile-map loss-priority any protocol any drop-profile AGGRESSIVE; } } scheduler-maps { CORE_UPLINK_SCHED_MAP { class NC scheduler HIGH_5PC_5PC_SCHEDULER; class EF scheduler HIGH_50PC_RL_20MS_SCHEDULER; class AF11 scheduler MEDIUM_HIGH_10PC_20PC_SCHEDULER; class AF13 scheduler MEDIUM_HIGH_10PC_10PC_SCHEDULER; class AF22 scheduler MEDIUM_LOW_10PC_10PC_SCHEDULER; class AF42 scheduler MEDIUM_LOW_10PC_10PC_SCHEDULER; class BE scheduler LOW_10PC_10PC_SCHEDULER; class LBE scheduler LOW_REM_REM_SCHEDULER; } } drop-profiles { AGGRESSIVE { interpolate { fill-level [25 60 80]; drop-probability [40 80 90]; } }

第4章：例 49

MODERATE { interpolate { fill-level [50 75 95]; drop-probability [10 25 40]; } } } rewrite-rules { exp CORE_EXP_REWRITE { forwarding-class NC { loss-priority low code-point 111; } forwarding-class EF { loss-priority low code-point 101; } forwarding-class AF11 { loss-priority low code-point 100; } forwarding-class AF13 { loss-priority high code-point 011; } forwarding-class AF22 { loss-priority medium code-point 010; } forwarding-class AF42 { loss-priority medium code-point 110; } forwarding-class BE { loss-priority high code-point 000; } forwarding-class LBE { loss-priority high code-point 001; } } } interfaces xe-0/0/0 { unit 0 { scheduler-map CORE_UPLINK_SCHED_MAP; classifiers { exp BA_CORE_EXP_CLASSIFIER; } rewrite-rules { exp CORE_EXP_REWRITE; } } }}


分散 /プロバイダエッジの階層型のQoS設定ネットワークのエッジでは、多くの場合、特定のサービスやサービスの組み合わせを考慮することに加えて、アップリンクのコアと同様の設定が必要になるので、QoS設定は複雑です。このような場合、複数の加入者が複数のサブセットにグループ化されて割り当てられるインタフェースには、通常、階層型の QoSが適用されます。

firewall { three-color-policer 2M_VOICE_SERVICE_POLICER { two-rate { color-aware; committed-information-rate 2m; committed-burst-size 5k; peak-information-rate 2500k; peak-burst-size 5k; } action { loss-priority high then discard; } } family inet { filter UNTRUSTED_SUBSCRIBER_BLEACH_CLASSIFIER { term BLEACH_DSCP { then { forwarding-class BE; next term; } } } filter UNTRUSTED_SUBSCRIBER_MF_CLASSIFIER { term VOICE_TRAFFIC_IN { from { $match_criteria_for_voice_service$; } then { forwarding-class EF; three-color-policer 2M_VOICE_SERVICE_POLICER; accept; } } term RECLASSIFY_OUT_OF_CONTRACT_VOICE { from { $match_criteria_for_voice_service$; loss-priority high; } then { forwarding-class BE;

第4章：例 51

} } term EVERYTHING_ELSE_IN { then { forwarding-class BE; accept; } } } }}interfaces { xe-7/0/0 { description “Shared Subscriber 10GE – Static Config”; unit 1000 { family inet { filter { input { UNTRUSTED_SUBSCRIBER_MF_CLASSIFIER; } } } } unit 2000 { family inet { filter { input { UNTRUSTED_SUBSCRIBER_BLEACH_CLASSIFIER; } } } } }}class-of-service { forwarding-classes { class NC queue 7 priority high; class EF queue 5 priority high; class AF11 queue 4 priority medium-high; class AF13 queue 3 priority medium-high; class AF22 queue 2 priority medium-low; class AF42 queue 1 priority medium-low; class BE queue 0 priority low; class LBE queue 6 priority low; } classifiers { exp BA_CORE_EXP_CLASSIFIER { forwarding-class NC { loss-priority low code-points 111; } forwarding-class EF {


loss-priority low code-points 101; } forwarding-class AF11 { loss-priority low code-points 100; } forwarding-class AF13 { loss-piority high code-points 011; } forwarding-class AF22 { loss-priority medium code-points 010; } forwarding-class AF42 { loss-priority medium code-points 110; } forwarding-class BE { loss-priority high code-points 000; } forwarding-class LBE { loss-priority high code-points 001; } } dscp BA_TRUSTED_SUB_DSCP_CLASSIFIER { forwarding-class EF { loss-priority low code-points 101; } forwarding-class AF11 { loss-priority low code-points 100; } forwarding-class AF13 { loss-piority high code-points 011; } forwarding-class AF22 { loss-priority medium code-points 010; } forwarding-class AF42 { loss-priority medium code-points 110; } forwarding-class BE { loss-priority high code-points 000; } } ieee-dot1p BA_TRUSTED_DSLAM_DOT1P_CLASSIFIER { forwarding-class NC { loss-priority low code-points 111; } forwarding-class EF { loss-priority low code-points 101; } forwarding-class AF11 { loss-priority low code-points 100;

第4章：例 53

} forwarding-class AF13 { loss-piority high code-points 011; } forwarding-class AF22 { loss-priority medium code-points 010; } forwarding-class AF42 { loss-priority medium code-points 110; } forwarding-class BE { loss-priority high code-points 000; } } } schedulers { HIGH_5PC_5PC_SCHEDULER { transmit-rate percent 5; buffer-size percent 5; priority high; } HIGH_50PC_RL_20MS_SCHEDULER { transmit-rate percent 50 rate-limit; buffer-size temporal 20000; priority high; } MEDIUM_HIGH_10PC_20PC_SCHEDULER { transmit-rate percent 10; buffer-size percent 20; priority medium-high; } MEDIUM_HIGH_10PC_10PC_SCHEDULER { transmit-rate percent 10; buffer-size percent 10; priority medium-high; drop-profile-map loss-priority high protocol any drop-profile AGGRESSIVE; } MEDIUM_LOW_10PC_10PC_SCHEDULER { transmit-rate percent 10; buffer-size percent 10; priority medium-low; drop-profile-map loss-priority high protocol any drop-profile MODERATE; } LOW_5PC_20PC_SCHEDULER { transmit-rate percent 10; buffer-size percent 20; priority low; drop-profile-map loss-priority high protocol any drop-profile AGGRESSIVE; } LOW_REM_REM_SCHEDULER {


transmit-rate remainder; buffer-size remainder; priority low; drop-profile-map loss-priority any protocol any drop-profile AGGRESSIVE; } } scheduler-maps { CORE_UPLINK_SCHED_MAP { class NC scheduler HIGH_5PC_5PC_SCHEDULER; class EF scheduler HIGH_50PC_RL_20MS_SCHEDULER; class AF11 scheduler MEDIUM_HIGH_10PC_20PC_SCHEDULER; class AF13 scheduler MEDIUM_HIGH_10PC_10PC_SCHEDULER; class AF22 scheduler MEDIUM_LOW_10PC_10PC_SCHEDULER; class AF42 scheduler MEDIUM_LOW_10PC_10PC_SCHEDULER; class BE scheduler LOW_10PC_10PC_SCHEDULER; class LBE scheduler LOW_REM_REM_SCHEDULER; } } drop-profiles { AGGRESSIVE { interpolate { fill-level [25 60 80]; drop-probability [40 80 90]; } } MODERATE { interpolate { fill-level [50 75 95]; drop-probability [10 25 40]; } } } rewrite-rules { exp CORE_EXP_REWRITE { forwarding-class NC { loss-priority low code-point 111; } forwarding-class EF { loss-priority low code-point 101; } forwarding-class AF11 { loss-priority low code-point 100; } forwarding-class AF13 { loss-priority high code-point 011; } forwarding-class AF22 { loss-priority medium code-point 010; } forwarding-class AF42 { loss-priority medium code-point 110;

第4章：例 55

} forwarding-class BE { loss-priority high code-point 000; } forwarding-class LBE { loss-priority high code-point 001; } } dscp SUBSCRIBER_DSCP_REWRITE { forwarding-class NC { loss-priority low code-point cs7; } forwarding-class EF { loss-priority low code-point ef; } forwarding-class AF11 { loss-priority low code-point af11; } forwarding-class AF13 { loss-priority high code-point af13; } forwarding-class AF22 { loss-priority medium code-point af22; } forwarding-class AF42 { loss-priority medium code-point af42; } forwarding-class BE { loss-priority high code-point be; } forwarding-class LBE { loss-priority high code-point 001000; } } ieee-dot1p MSAN_DOT1P_REWRITE { forwarding-class NC { loss-priority low code-point 111; } forwarding-class EF { loss-priority low code-point 101; } forwarding-class AF11 { loss-priority low code-point 100; } forwarding-class AF13 { loss-priority high code-point 011; } forwarding-class AF22 { loss-priority medium code-point 010; } forwarding-class AF42 {


loss-priority medium code-point 110; } forwarding-class BE { loss-priority high code-point 000; } forwarding-class LBE { loss-priority high code-point 001; } } } interfaces { xe-0/0/0 { unit 0 { scheduler-map CORE_UPLINK_SCHED_MAP; classifiers { exp BA_CORE_EXP_CLASSIFIER; } rewrite-rules { exp CORE_EXP_REWRITE; } } } xe-7/0/0 { unit * { rewrite-rules { dscp SUBSCRIBER_DSCP_REWRITE; ieee-dot1p MSAN_DOT1P_REWRITE; } } } }}

ブロードバンド加入者向けの動的なQoS設定の例ブロードバンド加入者システムは、QoS設定の課題に別の側面をもたらします。加入者インタフェースは本来、動的なものです。加入者インタフェースが存在するのは、加入者が接続している期間に限定され、BNG（Broadband Network Gateway）のライフタイムにわたって、複数の異なる加入者に対して単一の論理インタフェース（ユニット）識別子を再利用できます。つまり、QoSの属性は、加入者が接続した時点で、その加入者に対して動的に割り当てる必要があります（単一の接続のライフタイム中に、変更が必要になる場合もあります）。さらに、加入者の特定のサブセットに必要な値を網羅した QoSのテンプレートを定義することは可能ですが、ユーザーの認証および承認時に RADIUSサーバーからBNGに属性が送られるようなテンプレートを定義する方が望ましいとも言えます。

第4章：例 57

このようにQoSの属性をパラメータ化することによって、加入者ごとのQoS設定に対応できる、柔軟性に優れたメカニズムが実現します。

注加入者ごとにまったく固有の QoS設定を作成することも可能ですが、このようなアプローチはお勧めしません。このようなアプローチを採用すれば、システムが信じられないほど複雑化し、設計の理解やトラブルシューティングが極めて困難になります。代わりに、個々のサービスを表す、比較的少数の設定の組み合わせを作成して、この組み合わせを加入者全体に適用することをお勧めします。

firewall { family inet { filter $input_filter_name$ { term $term_name$ { from { $match_conditions$; } then { forwarding-class $class_name$; $other_actions$; accept; } } } filter $output_filter_name$ { term $term_name$ { from { $match_conditions$; } then { forwarding-class $class_name$; $other_actions$; accept; } } } }}dynamic-profiles { $dynamic_profile_name$ { predefined-variable-defaults { $variable$ $attributes_and_values$; } interfaces {


interface-set “$junos-interface-set-name” { interface demux0 { unit “$junos-interface-unit”; } } demux0 { unit “$junos-interface-unit” { demux-options { underlying-interface “$junos-underlying-interface”; } family inet { demux-source { $junos-subscriber-ip-address; } filter { input “$junos-input-filter”; output “$junos-output-filter”; } unnumbered-address lo0.0 preferred-source-address $preferred_address$; } } } } class-of-service { traffic-control-profiles { $tcp_template_name$ { scheduler-map “$junos-cos-scheduler-map”; shaping-rate “$junos-cos-shaping-rate”; } } interfaces { demux0 { unit “$junos-interface-unit” { output-traffic-control-profile $tcp_template_name$; rewrite { ieee-802.1 $rewrite_rule_name$; } } } } } scheduler-maps { $scheduler_map_template_name$ { forwarding-class $class_name$ scheduler $scheduler_name$; } } schedulers { $scheduler_name$ { transmit-rate “$junos-cos-scheduler-tx” exact; buffer-size temporal “$junos-cos-scheduler-bs”;

第4章：例 59

priority $scheduler_priority$; } } }}

このテンプレート設定を有効にするには、RADIUSアクセス受理の Juniper Networksベンダー専用属性に戻る必要があります。RADIUSサーバー用の設定例は、以下のようになります。

Per User RADIUS VSAs required **example**

Jnpr-CoS-Parameter-Type T01 BB_SUB_COSJnpr-CoS-Parameter-Type T02 20mJnpr-CoS-Scheduler-Pmt-Type EF T01 2mJnpr-CoS-Scheduler-Pmt-Type EF T02 100Jnpr-CoS-Scheduler-Pmt-Type AF11 T01 10mJnpr-CoS-Scheduler-Pmt-Type AF11 T02 15Jnpr-CoS-Scheduler-Pmt-Type AF42 T01 7mJnpr-CoS-Scheduler-Pmt-Type AF42 T02 35Jnpr-CoS-Scheduler-Pmt-Type BE T01 1mJnpr-CoS-Scheduler-Pmt-Type BE T02 40Unisphere-Egress-Policy-Name subscriber_output_policyUnishpere-Ingress-Policy-Name subscriber_input_policyUnishpere-Qos-Set-Name demux-set

ハイエンドセキュリティノード向けのQoS設定SRXシリーズサービスゲートウェイのハイエンドセキュリティデバイスは、QoS設定について、他のあらゆる Junosデバイスと同様のモデルを採用しています。このようなハイエンドセキュリティデバイスでは、通常、非セキュリティ指向のデバイスでは考慮が不要な項目についても、考慮が必要になる場合があります。IPsec VPNトンネルの入口および出口で、DSCPビットはデフォルトで元の（トンネリングされた）パケットから ESPヘッダーの DSCPにコピーされます。したがって、通信事業者側で透過的な操作が必要な場合、リライトの規則は必要ありません。別のマーキングが必要な場合は、通常のリライトの規則を適用できます。ただし、カプセル化 /非カプセル化後に、パケットは正しい転送クラスに割り当てられません（以下の注を参照）。したがって、パケットを正しい転送クラスに割り当てて、正しい動作が行われるようにするため、送信側のMF分類が必要になります。


注本書の作成時点では、SPCは QoSに対応していません。したがって、SPCがオーバーサブスクライブの状態になった場合、CoS設定に適合していない方法でパケットをドロップします。

firewall { filter $filter_name$ { term SEND_TO_EF { from { dscp ef; } then { log; forwarding-class EF; accept; } } term SEND_TO_AF11 { from { dscp cs2; } then { forwarding-class AF11; accept; } } term SEND_TO_AF41 { from { dscp [cs3 cs6]; } then { forwarding-class AF41; accept; } } term DEFAULT_PERMIT { then accept; } }}class-of-service { forwarding-classes { queue 2 AF11; queue 3 AF41; queue 1 EF; queue 0 BE; } interfaces { reth0 { scheduler-map $scheduler_map_name$; unit * {

第4章：例 61

rewrite-rules { dscp $rewrite_rule_name$; } } } } scheduler-maps { $scheduler_map_name$ { forwarding-class EF scheduler HIGH_50PC_RL_10MS_SCHEDULER; forwarding-class AF11 scheduler MEDIUM_HIGH_20PC_20PC_SCHEDULER; forwarding-class AF41 scheduler MEDIUM_LOW_20PC_40PC_SCHEDULER; forwarding-class BE scheduler LOW_REM_REM_SCHEDULER; } } schedulers { HIGH_50PC_RL_10MS_SCHEDULER { transmit-rate percent 50 rate-limit; buffer-size temporal 10000; priority high; } MEDIUM_HIGH_20PC_20PC_SCHEDULER { transmit-rate percent 20; buffer-size percent 20; priority medium-high; drop-profile-map loss-priority high protocol any drop-profile MODERATE; } MEDIUM_LOW_20PC_40PC_SCHEDULER { transmit-rate percent 20; buffer-size percent 40; priority medium-low; } LOW_REM_REM_SCHEDULER { transmit-rate remainder; buffer-size remainder; priority low; drop-profile-map loss-priority any protocol any drop-profile AGGRESSIVE; } } rewrite-rules { dscp $rewrite_rule_name$ { forwarding-class EF { loss-priority low code-point ef; } forwarding-class AF11 { loss-priority low code-point cs2; } forwarding-class AF41 { loss-priority low code-point cs6; loss-priority high code-point cs3; } forwarding-class BE {


loss-priority high code-point be; } } }}interfaces { reth0 { vlan-tagging; redundant-ether-options { redundancy-group 1; } unit 10 { description “trust”; vlan-id 10; family inet { filter { output $filter_name$; } address $ip_address$/$prefix_length$; } } unit 20 { description “untrust”; vlan-id 20; family inet { filter { output $filter_name$; } address $ip_address$/$prefix_length$; } } }}

64

次に参照すべき資料およびサイト

http://www.juniper.net/dayoneDay Oneシリーズの書籍は、PDF形式で無償でダウンロード可能です。特定のタイトルには、コピー＆ペースト対応版も用意されており、Junosの設定として直接、流用できます（ライブラリは、Apple iBookstore から iPad および iPhone 用の eBook 形式のデータ、Kindle Store から Kindle、Android、Blackberry、Mac、および PC版のデータをそれぞれ入手できます。さらに、印刷版は、Amazonまたはwww.vervante.comで販売されています）。

http://www.juniper.net/books『QoS Enabled Networks：Tools and Foundations』、ピーター・ルンドクヴィストとミゲル・バレイロス共著。ジュニパーネットワークスの 2人のエキスパートが、理論的なレベルから、動作を操作できるツールについての理解、最終的にはツールの応用に至るまで、テーマを掘り下げて解説しています。

http://forums.juniper.net/jnetジュニパーネットワークスがスポンサーである J-Net Communitiesフォーラムは、ジュニパー製品、テクノロジー、およびソリューションに関する情報、ベストプラクティス、質問を共有するための場です。この無料のフォーラムに参加するには、登録が必要です。

www.juniper.net/techpubs/ジュニパーネットワークスのテクニカルマニュアルには、MPLSを含む、Junosのあらゆる部分を理解して設定する上で必要なすべての情報が含まれています。一連のマニュアルはあらゆる情報を網羅しているとともに、ジュニパーネットワークスのエンジニアリング担当者によって徹底的なレビューが行われています。

www.juniper.net/training/fasttrackオンライン、オンサイト、または世界中のパートナートレーニングセンターで受講できるコースをご用意しています。JNTCP（ジュニパーネットワークス技術認定資格プログラム）では、ジュニパー製品の設定およびトラブルシューティングに関する能力認定を行っています。短い期間でエンタープライズ向けルーティング、スイッチング、またはセキュリティでの認定を受けるには、提供されているオンラインコース、受講ガイド、およびラボガイドをご利用ください。

junos 基本シリーズ - juniper networks...本書を読む前に知っておくべきこと...

Documents