Day One IOSエンジニア向けJunos QoS6 Day One ：IOSエンジニア向けJunos QoS 自宅で、ハイビジョンのNetflix ムービーをラップトップで観ながら、

Day One：IOSエンジニア向けJunos QoS

著者：ベンカテッシュ・クリシュナン

Junos®ネットワーキングテクノロジー

第1章 : はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

第2章 : IOSとJunosのサービスクラス機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

第3章 : 基本ステップに沿ったIOSとJunosの比較 . . . . . . . . . . . . . . . . . . . . . . . . 29

第4章: ポリシングとシェーピング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

第5章: 輻輳回避 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

第6章: トラブルシューティング. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

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

ジュニパーネットワークスは、本書中の誤りに対して何ら責任を負いません。ジュニパーネットワークスは、予告なく本書を変更、修正、転載、または改訂する権利を留保します。ジュニパーネットワークスが製造、販売する製品、あるいはその部品は、ジュニパーネットワークスが保有する、あるいはライセンスを受けた以下の米国特許のうち 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コミュニティ管理者：ジュリー・ワイダー

著者の紹介ベンカテッシュ・クリシュナンは、エンタープライズネットワークおよびサービスプロバイダーネットワークの設計および実装を専門とする、ジュニパーネットワークスのプロフェッショナルサービス部門のネットワークコンサルタントです。ジュニパーネットワークスへの入社前に、Cisco Systems社のアドバンストサービスチームに所属し、サービスプロバイダーチームでネットワークコンサルティングエンジニアとして活躍していました。Cisco社およびジュニパーネットワークスの両社のデバイスに関して顧客に向けた QoSソリューション設計を支援し、10年以上に渡るネットワーキングおよびセキュリティ分野の経験があります。また、CCIE-R&S #24243の取得者でもあります。

著者の謝辞本書の制作にご協力いただいた多くの方々に感謝を申し上げます。本書の制作中、辛抱強く支えてくれた家族、激励し指導してくださったマネージャーのクレイグ・サーキン氏、そして根気強く作業してくださったパトリック・エイムズとDay One制作チームにお礼を申し上げます。最後に、同僚であるジャック・パークス氏に感謝いたします。彼が与えてくれたアイデア、ヒント、アドバイスは情報を書籍という形にするうえで大いに役立ちました。

ISBN：978-1-936779-56-7（書籍）印刷：Vervante Corporation（米国）

ISBN：978-1-936779-57-4（電子書籍）

改訂：初版、2012年 12月 2 3 4 5 6 7 8 9 10 #7100159-en

本書は、さまざまな形式で http://www.juniper.net/dayoneから入手できます。本書についてのご意見・ご感想は、電子メールで [email protected]宛にお寄せください。

ii

Day Oneへようこそ

本書は、Juniper Networks Booksが制作、出版するDay Oneシリーズの1つであり、このライブラリのブックレットは次々に出版されています。

Day Oneシリーズは、作業の初日に必要となる情報だけをまとめ、提供することを目的に考案されました。このシリーズでは、Junos OSおよびジュニパーネットワークスのネットワーキングの基礎について、分かりやすく説明し、ステップごとの手順を示し、実際に役立つ理解しやすい例を掲載しています。

この他、Day Oneライブラリには、これより多少分量が多く長い This Weekシリーズもあります。このシリーズで扱っている概念とテストベッド例は、1週間のセミナーにより近い内容になっています。

これらのシリーズは、以下の形式で入手できます。 � 無料の PDF版を http://www.juniper.net/dayoneからダウンロード。

� iPhoneおよび iPad用の電子書籍版を iTunesストアから入手。Juniper Networks Booksを検索してください。

� Kindleアプリが稼働するデバイス（Android、Kindle、iPad、PC、またはMac）用の電子書籍版を、デバイスの Kindleアプリを起動して Kindle Storeにアクセスして入手。Juniper Networks Booksを検索してください。

� 印刷版を Vervante Corporation（www.vervante.com）または Amazon（www.amazon.com）から、ページ数に応じて$12～ 28で購入。

� Nook、iPad、およびさまざまな Androidアプリでは、PDFファイルも表示できます。

� ご使用のデバイスまたは電子書籍アプリが .epubファイルを使用し、Apple製品でない場合は、iTunesを起動し、iTunesストアから .epubファイルをダウンロードしてください。これにより、iTunesからデスクトップにこのファイルをドラッグアンドドロップし、.epubデバイスと同期させることができます。

本書を読む前に知っておくべきこと

本書を読む前に、Junosオペレーティングシステムの基本的な管理機能について理解しておいてください。例えば、操作コマンドを操作したり、Junosの設定を読み取り、理解し、変更したりできる必要があります。Day Oneライブラリ（www.juniper.net/dayone）には、Junosについて探求し、知識を身に付けることのできる複数のブックレットがあります。

iii

iv

本書では、読者が以下の条件を満たしていることを前提としています。 � IOSデバイスでのQoSの実装に精通していること

� IOSデバイスでの QoSの問題をトラブルシューティングする基礎知識があること

� Junosに関する基礎知識があること

本書の学習目標 � ネットワーク内の JunosデバイスでQoSを設計して導入する � Junosのトラブルシューティング手順に従ってQoSの基本的な問題をトラブルシューティングする

� QoS固有の Junosの showコマンドを実行する � 導入用のQoS設定テンプレートを作成する

IOSと Junos

IPネットワークで送受信されるビデオおよび音声トラフィックの増加に伴い、QoSはネットワーク設計に不可欠な要素になっています。多くの顧客ネットワークでは、Cisco社とジュニパーネットワークスの機器が混在しています。どちらの機器でも、基本的にはそれぞれのプラットフォームで QoSがサポートされていますが、これから説明するように、その実装方法や捉え方にはいくつか違いがあります。IOSの設定ファイルは長いため、あるインタフェースに関連付けられた特定の QoS 設定について調べようとしても、容易には見つけられません。一方、Junosでは、QoSに別の階層が割り当てられ、QoSの実行時に特定の順序に従って実装されます。

また、Junosには、QoSの問題をスピーディに解決するためのトラブルシューティングメカニズムがあります。本書では、これらについても触れていきます。本書では、QoSの概念や特定のプラットフォームに関連するトラブルシューティングまで掘り下げた説明は行いません。読者が IOSの経験を基に、Junosで QoS設定を行えるように手順を説明し、さらにJunosと IOS の実装方法の違いを示します。

第1章

はじめに

6 Day One：IOSエンジニア向けJunos QoS

自宅で、ハイビジョンの Netflixムービーをラップトップで観ながら、VoIP電話で話をしたりインターネットを閲覧したりしている状況を想像してみてください。近所の住人はもとより、同じ市内のすべての人が、同じことをしていたとしたらどうでしょう。ムービーは高品質のハイビジョンストリーミングビデオかつ VoIP電話は明瞭な音声品質でなければなりません。その上、どのインターネットページも閲覧中に警告が表示されてはいけません。インターネットに対する要求が高まるほど、各パケットを効果的に識別し、それに応じて適切に処理することが不可欠になるのです。

特定のパケットを識別し、各パケットをその識別情報に応じて処理する機能が、サービスクラスまたは QoS（Quality of Service：サービス品質）の基本です。トラフィックの品質を左右する要素には、遅延、ジッター、パケットロス、帯域幅要件、およびレイテンシがあります。QoSは、トラフィックフローを制御および操作して、より優れたパフォーマンスを実現するためのツールです。

さらに詳しくは QoSの簡潔な説明については、『Day One：基本的なQoSの導入』を参照してください（http://www.juniper.net/dayone）。

図 1.1 インターネットの利用

基本的な QoS機能は、以下の 5つの基本ステップに分けることができます。本書の残りの部分では、このステップに従って説明を進めます。

第1章：はじめに 7

� クラス分類 – このステップでは、パケットのタイプを識別します。パケットの識別基準は、送信元および宛先の IP アドレス、DSCP、MPLS EXP ビットから、レイヤー 4ポート、プロトコルなどまでさまざまです。クラス分類により、ネットワーク内の異なるタイプのトラフィックパターンを認識できるようになります。トラフィックタイプを明確に定義してクラス分類することにより、ネットワークにおいて各トラフィックをどのように処理するかをより厳密に制御できるようになります。

� キューイング – パケットをクラス分類したら、各クラスの処理方法を決定するステップを定義できます。最初のステップでは、各クラスをインタフェースのハードウェアキューに割り当てます（ハードウェアキューの数は、使用可能なプラットフォームによって異なります）。

� スケジューリングと優先度設定 – 定義されたキューに各クラスを割り当てたら、次のステップでは、インタフェースを通してパケットを送信するときに、各キューをどのように処理するか、また各キューからどの程度のパケットを取り出す必要があるかを定義します。また、優先度設定では、どのキューを最初に処理するか、またどのような順序で処理するかを定義します。

� 帯域の割り当て – 帯域は、各キューに定義されたスケジューリングメカニズムに従い割り当てられます。

� マーキング – 必須ではありませんが、受信したマーキングのままトラフィックを転送するか、パケットのマーキングを書き換えるか、マーキングがない場合にパケットにマーキングを設定することができます。マーキングでは、DSCP/802.1Q/IP PrecedenceまたはMPLS EXPビット値を変更します。以降のネットワークデバイスがそのマーキングに従ってパケットを受け入れ、処理できるように、パケットに特定のマーキングを定義するのが望ましい場合がほとんどです。

現代の多くのネットワークは、Cisco社やジュニパーネットワークスなど複数のベンダー機器で構成されています。Junosのコマンドラインが IOSのものとは異なると感じますが、同じ機能を実行するようJunosデバイスを設定できます。異なるコマンドラインでの運用に変更するのは困難な場合もありますが、エンジニアにとっては対応しがいのある困難でもあるでしょう。本書では、この移行をスムーズに行えるように、IOSと Junosの両方についてQoSの設定方法を比較しながら解説します。

最初に IOSの設定を示し、続いてそれに相当する Junosの設定を示します。また、IOSエンジニアに向けたヒントや要点も示します。


さらに詳しくは『Day One:IOSエンジニア向け Junos解説』は、Junosとの微妙な差異についての理解を深めることのできる優れた参考資料です。また『Day One：Junosの基本設定』は、任意のデバイス用に Junosを設定するための第一歩として役立ちます。これらのブックレットおよびJunosに関するその他の Day Oneシリーズのブックレットを読むことで、これまで IOSを使用してきたエンジニアも容易に Junosへと切り替えることができます。完全な Day Oneライブラリについては、http://www.juniper.net/dayoneを参照してください。

第2章

IOSとJunosのサービスクラス機能

Cisco IOSのサービスクラス機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Junosのサービスクラス機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27


この章では、IOSと Junosの 2つの OSのサービスクラス機能を比較します。最初に IOSのサービスクラス機能について説明し、その後 Junosと比較します。そのための準備として、まず単純な QoS設定を作成します。この設定を基に以降の章で説明の範囲を広げていくことで、読者が理解を深められるように構成されています。便宜上、IOSの QoS（Quality of Service）は、Junos における CoS（Class-of-Service：サービスクラス）として解釈し、本書では、これらの用語を区別せずに使用します。

注 Cisco用語では、CoSはレイヤー 2のみのビット操作を指します。一方、Junosでは、このタスクを簡素化し、すべての変更をサービスクラスで処理します。これには、レイヤー 2およびレイヤー 3、MPLS EXPビットが含まれます。

図2.1は、ネットワークでQoSによって処理される要素の全体図です。

図 2.1 ネットワークのQoS

Cisco IOSのサービスクラス機能MQC（Modular QoS CLI）に注目した場合、CiscoデバイスでQoSを設定および導入するための基本ステップは 3つです。このステップをたどってみましょう。

クラスマップの定義と設定

クラスマップは、matchステートメントで制御されるクラシファイアルールに従ってパケットを分類するために使用されます。matchコマンドでは、 DSCP、MPLS EXPビット、送信元 /宛先 IPアドレス、および送信元 /宛先MACアドレスから、入力インタフェースおよびプロトコルまで、パケットヘッダーのさまざまなフィールドを照合できます。

さらに詳しくは http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfmcli2.htmlでは、matchステートメントの完全なリストが公開されています。最新の更新については、Cisco社ウェブサイトで確認してください。

クラスマップには、match-allまたはmatch-anyオプションを指定します。デフォルトはmatch-allです。match-allキーワードは、すべての条件が満たされなければならない場合に使用します。一方、match-anyは、多くの条件のうち 1つのみ満たされていればパケッ

第2章：IOSとJunosのサービスクラス機能 11

トをそのトラフィッククラスに分類できる場合に使用します。

パケットがそのクラスのメンバーとして分類されないように、一致してはならない条件を指定する場合には、match not オプションを使用します。下記 6つの例を見ていきましょう。

例 1例 1は、アクセスリストを使用して、IPアドレスのクラスマップを作成する方法を示しています。

Router(config)# class-map match-any voice Router(config-cmap)# match protocol ip Router(config-cmap)# match access-group 101

Router(config)# access-list 101 permit 10.10.10.0 0.0.0.255 Router(config)# access-list 101 permit 10.10.20.0 0.0.0.255 Router(config)# access-list 101 permit 172.16.31.0 0.0.0.255

例 2例 2は、IPアドレスとMACアドレスの組み合わせの使用方法を示しています。

Router(config)# class-map match-any class2Router(config-cmap)# match protocol ipRouter(config-cmap)# match access-group 2Router(config-cmap)# exit

Router(config)# class-map match-all class1Router(config-cmap)# match class-map class2Router(config-cmap)# match destination-address mac 00.00.00.00.00.00 Router(config-cmap)# exit

Router(config)# access-list 2 permit 10.10.0.0 0.0.255.255 Router(config)# access-list 2 permit 192.168.0.0 0.0.0.255

例 3例 3は、「match not」オプションの使用方法にスポットを当てています。

Router(config)# class-map noipRouter(config-cmap)# match not protocol ip Router(config-cmap)# exit

例 4例 4および例 5は、クラスマップでの IP Precedence、DSCP、および RTPポートの使用方法を示しています。また、例 6は、ネストされたクラスマップの使用方法にスポットを当てています。

Router(config)# class-map match-all ex-4Router(config-cmap)# match ip rtp 16384 16383


Router(config-cmap)# match precedence 5Router(config-cmap)# exit

例 5 Router(config)# class-map match-any ex-5Router(config-cmap)# match dscp 0Router(config-cmap)# match dscp 1Router(config-cmap)# exit

例 6Router(config)# class-map match-any class-2Router(config-cmap)# match ip rtp 16384 16383Router(config-cmap)# match precedence 5Router(config-cmap)# exit

Router(config)# class-map match-any class-1Router(config-cmap)# match class-map class-2Router(config-cmap)# match cos 5Router(config-cmap)# exit

ポリシーマップの定義と設定

各ポリシーマップでいくつかのクラスマップを呼び出し、各クラスマップに対して帯域幅、バッファサイズ、および優先度を定義することができます。最後のクラスを「デフォルト」として定義し、このクラスに特定の帯域幅を割り当て、このクラスに分類されなかったすべてのトラフィックを割り当てることをお奨めします。コードおよびプラットフォームでサポートされていれば、ネストされたポリシーを設定することも可能です。パケットマーキングもこの段階で設定します。priorityコマンドは、トラフィックに対する帯域保証を設定します。このオプションは、音声やビデオなど遅延の影響を受けるトラフィックに対して有効です。bandwidthコマンドは、そのトラフィッククラス用に帯域幅を予約し、queue limitは、そのトラフィッククラスについてキューに保持できる最大パケット数を指定します。帯域幅をパーセントで指定すると、使用可能な帯域幅はインタフェースの帯域幅に基づいて計算されるか、interface で設定された「bandwidth」に対するパーセントとして計算されます。以降の例では、ポリシーマップのいくつかの作成方法にスポットを当てています。

注 Junosでは、階層的なスケジューリングを使用できますが、これについては本書の範囲外であるため説明しません。ダグラス・ハンクスおよびハリー・レイノルド著『The Juniper MX Series』（O’ Reilly Media出版、2012年）の H-CoSに関する章全体を参照してください（http://www.juniper.net/books）。

例 1

例 1は、複数のトラフィッククラスに DSCP値を設定する方法を示しています。


Router# show run

policy-map voipclass voip-rtpset dscp efclass class-defaultset dscp default

例 2例2は、各クラスに対して、bandwidthやqueue-limitなどのオプションを定義する方法を示しています。

Router(config)# policy-map policy1Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth 1000 Router(config-pmap-c)# queue-limit 20 Router(config-pmap)# exit

Router(config-pmap)# class class2 Router(config-pmap-c)# bandwidth 2000 Router(config-pmap)# exit

例 3例 3は、ネストされたポリシーと、priorityオプションの使用方法を示しています。

Router(config)# policy-map childRouter(config-pmap)# class voiceRouter(config-pmap-c)# priority 50

Router(config)# policy-map parentRouter(config-pmap)# class class-defaultRouter(config-pmap-c)# service-policy child

サービスポリシーの設定

パケットを分類し、各トラフィッククラスに適切な帯域幅とマーキングを割り当てたら、最後のステップでは、サービスポリシーをインタフェースに適用します。interfaceで「bandwidth」コマンドを指定し、bandwidth-percentを使用した場合、ここで設定する値は、各クラスの実際の帯域幅を計算するために使用されます。サービスポリシーは、入力方向または出力方向のいずれかに適用できます。

Router(config)# interface g1/0/0 Router(config-if)# service-policy output policy1 Router(config-if)# exit

この例は、サービスポリシーの導入方法を示しています。


キューイングとスケジューリング

これまでに、パケットがどのように分類され、マーキングされるかについて説明しましたが、パケットが送信されるまでの間にどのように処理されるかについては明確に説明していません。マーキングされているパケットはどのように送り出されるのでしょうか。また、音声やビデオなど遅延の影響を受けるパケットの処理は他のパケットとどのように異なるのでしょうか。処理されたパケットは、送信インタフェースから送信できるようになるまで、メモリに保存されます。IOSでは、インタフェースからの送信待ちパケットを管理するためにキューが作成されます。基本的なキューイングスキームでは、FIFO（First In, First Out）スケジューリングが使用され、パケットはその順序に従って処理されます。この方法では遅延、ジッター、およびレイテンシを考慮できないため、パケットを保持するためのキュー長に限りがある場合は、パケットロスが問題になります。キューの長さを変更することにより、パケットロスを最小限に抑えることもできますが、これにはレイテンシや遅延の操作を伴うため、複数のキューと、特定時点にどのキューをどのように処理するかを決定するためのメカニズムが必要になります。IOSでは、パケットがインタフェースからどのように出て行くかを決定するさまざまなキューイングおよびスケジューリング手法が提供されています。これを表 2.1にまとめます。

表 2.1 IOSのキューイングとスケジューリングの特性

キューイング方法最大キュー数分類機能処理方法

FIFO 1 デフォルト最初に到着したパケットが最初に処理されます。

PQ（Priority Queuing）

4 アクセスリスト常に、優先度がより高いキューがより低いキューより先に処理されます。

CQ（Custom Queuing）

16 アクセスリストラウンドロビン方式により順番に各キューで、キューあたり設定されたバイト数が処理されます。

WFQ（Weighted Fair

Queuing）

4096 自動（送信元 /宛先アドレス、ポート番号、およびプロトコルで識別されたフローに基づく）

フローごとに異なるキューが作成され、低容量で IP Precedence が高いキューが、高容量で IP Precedence が低いキューより優先的に処理されます。

CBWFQ（Class-Based Weighted Fair Queuing）

64 アクセスリスト /クラスマップ

帯域幅の特定パーセントが各キューに割り当てられます。


LLQ（Low Latency Queuing）

N/A CBWFQと同じ CBWFQと同様ですが、「priority」として設定された一部のキューは、常に他のキューより先に処理されます。他のキューが処理待ちのまま待機し続けることがないように、priority帯域幅が設定されたトラフィックが調整されます。

MDRR（Modified

Deficit Round Robin）

8 IP Precedence CQと同様ですが、設定値を超えて処理されているキューは、次回処理されるときに、より少ないデータがキューから取り出されます。

ベストプラクティスキューの深さの変更は、ベンダー固有の問題ではありません。使用デバイスに関わらず、ネットワークトラフィックに影響します。そのため、ネットワークトラフィックパターンを学習し、それに応じてキューの深さを割り当てることが不可欠です。

一部のルーターインタフェースでは、FIFOおよびWFQがデフォルトのキューイング方法です。遅延の影響を受けるトラフィックに高い優先度を割り当てる手法は、LLQ、MDRR、および PQのみです。また、一般に、MQCによって設定する手法は、CBWFQおよび LLQのみです。すべての Ciscoプラットフォームですべてのキューイング方法を使用できるわけではありません。

例 1：FIFOinterface serial0/0ip address 192.168.10.1 255.255.255.0no fair-queuehold-queue 20 out

例 2：LLQaccess-list 101 permit udp any any range 16384 32767access-list 102 permit tcp any any eq 23

class-map data match access-group 102

class-map voice match access-group 101

policy-map llq class voice priority percent 50 class data bandwidth percent 25 class class-default fair-queue interface se0/0 ip address 172.16.18.77 255.255.255.0 service-policy output llq


ここで説明したキューは、ルーターのソフトウェアにより作成されます。次に送信する必要のあるパケットがスケジューラまたはスケジューリングアルゴリズムによって決定される場合、そのパケットはインタフェースから直接送信されません。代わりに、インタフェースのソフトウェアキューから、各インタフェースの小規模な FIFOキューである送信キューに移動されます。送信キューはハードウェアキュー、TXキュー、または TXリングと呼ばれます。ハードウェアキューの主な目的は、パケットがインタフェースからの送信待ちのときのリンク使用率を 100パーセントにすることです。

注複数のキューイング手法を使用すれば、自動的に柔軟性が向上するわけではありません。これは、すべてのプラットフォームまたはすべてのバージョンのコードですべてのキューイング方法を使用できるわけではないからです。複数のキューイング方法の存在は、キューイング方法が長い期間を経てどのように進化してきたかを示しているに過ぎません。Junosでは、優先度およびWRRによってキューが処理され、Strict-Highに最高の特権が与えられます。Strict-High（設定されている場合）は LLQと同様です。

IOSのまとめ

IOSでQoSを設定する大まかなステップは、以下の 4つです。 � 第 1ステップで、キューイング方法を決定します。 � 第 2ステップで、クラスマップを定義して設定します。 � 第 3ステップで、ポリシーマップを定義して設定します。 � 第 4ステップで、サービスポリシーをインタフェースに適用します。

クラスマップでは、パケットを分類するためにアクセスリスト、プロトコル、DSCP値などさまざまな手法を使用できます。ご存知のように、最善の結果を得るには、適切なキューイング方法を選択することが重要です。

Junosのサービスクラス機能まず、Junosは構造化コマンドラインを備えています。デバイスの設定や本書に掲載している設定を見れば、階層構造が組み込まれていることに気付くでしょう。このコマンドラインは、interfaces、protocols、system configuration、chassisなどのセクションで構成されており、各セクションには多数のサブセクションがあります。QoSは、メインセクションであるClass-of-Serviceにあります。定義および設定が必要な QoS設定のほとんどは、このセクションで行います。これにはいくつか例外がありますが、最終的には Class-of-Serviceに関連付けられています。


さらに詳しくは Junosの詳細については、本書の巻末に掲載されているリソースを参照してください。

ここでは、第 1章で説明した、QoSの定義と設定のために必要な基本ステップに沿って説明を進めます。各セクションでは、必要な手順を詳しく説明し、最後にトラフィックを分類してマーキングするための設定を作成します。

それでは、Junosでサービスクラスを設定するためのステップに取り掛かりましょう。

フォワーディングクラスの定義と設定

フォワーディングクラスは、定義して分類しようとしている各トラフィックパターンが従うクラスです。フォワーディングクラスの主な機能は、特定のキューに割り当てるパケットを決定することです。フォワーディングクラスは、キューを表す設定要素として考えることもできます。デフォルトでは、4つのフォワーディングクラスが定義されています。同じキューに対して複数のフォワーディングクラスを定義し、割り当てることもできます。すなわち、フォワーディングクラスの数とキューの数は必ずしも同じである必要はないということです。キューの最大数は、プラットフォームによって異なります。

注サポートされるキューの数とフォワーディングクラスの最大数はプラットフォームによって異なります。これらの情報は、デバイスの仕様で確認することができます。

user@R1> show class-of-service forwarding-class Forwarding class ID Queue Restricted queue Fabric priority best-effort 0 0 0 low expedited-forwarding 1 1 1 low assured-forwarding 2 2 2 low network-control 3 3 3 low

フォワーディングクラスの設定

フォワーディングクラスをキューに割り当てることに加え、PLP（Packet Loss Priority）の定義が必要です。PLPでは、パケットのドロップ優先度を定義します。この設定によって、自動的にパケットが破棄されることはありませんが、輻輳が生じた場合にどのパケットを破棄するかを制御するためのメカニズムとして機能します。ネットワークが輻輳状態のときは、PLPが高いパケットから破棄されます。

[edit]user@R1#class-of-service { forwarding-classes { class NC6 queue-num 3 priority high; class NC7 queue-num 3 priority high;


class EF queue-num 1 priority high; class AF3 queue-num 2 priority low; class AF4 queue-num 2 priority low; class AF2 queue-num 2 priority low; class BE queue-num 0 priority low; class SCV queue-num 4 priority low; }

パケットの分類の定義と設定

分類は、以下の 3通りの方法で行えます。 � 固定（Fixed）クラシファイア – この方法では、各インタフェースまたは VLANに対して 1つのフォワーディングクラスを割り当てることができるため、受信パケットを分類する最も単純な方法です。隣接機器からのすべての受信トラフィックを特定のキューに割り当てる必要がある場合に便利です。

� BA（Behavior Aggregate）クラシファイア – 隣接機器からのトラフィックにすでに CoSマーキングが行われている場合、このマーキングを基にパケットを分類できます。照合できるCoSマーキングには、DSCP、802.1p、MPLS EXP、IP Precedence、および 802.1adドロップ適性インジケータ（DEI）ビットがあります。この方法では、必要となるパケット分析が少なくて済むため、大容量のトラフィック、特にネットワークコアで効率的に機能します。

� MF（Multi-field）クラシファイア – MFクラシファイアでは、パケットの分類時に最もきめ細かい制御が可能です。パケットヘッダーの 1つ以上のフィールドを照合できます。MF分類方法では、送信元 /宛先 IPアドレス、宛先ポート番号、プロトコルなどのフィールドを使用できます。MF分類は、ファイアウォールフィルタを定義してインタフェースまたは VLANに適用することによって行います。

インタフェースに BAクラシファイアとMFクラシファイアが設定されている場合、BA分類が最初に実行されます。ただし、両方のクラシファイアがトラフィックに一致する場合は、MFクラシファイアが BAクラシファイアより優先されます。

注注意しなければならないもう 1 つの要素として、TCAMエントリーの数があります。TCAMエントリーは、MF クラシファイアで複数のポートが定義され、フィルタがインタェースに適用されるときに消費されます。ローエンドのデバイスの多くは TCAM 容量に制限があるため、プラットフォームによっては、不整合が生じることがあります。

固定クラシファイアの設定[edit]user@R1#


class-of-service { interfaces { ge-0/0/0 { unit 0 { forwarding-class assured-forwarding; } } }}

BAクラシファイアの設定

カスタムクラシファイアを作成する際、同じCoSタイプの関連するデフォルトクラシファイアを使用すると、数個の設定を変更するだけで済むため便利です。以下のコード断片には、コードポイント、デフォルトDSCPクラシファイアに関連付けられているフォワーディングクラス、およびデフォルトで定義されているPLPのリストが示されています。

user@R1> show class-of-service classifier Classifier: dscp-default, Code point type: dscp, Index:7 Code point Forwarding class Loss priority 000000 best-effort low 000001 best-effort low 000010 best-effort low 000011 best-effort low 000100 best-effort low 000101 best-effort low 000110 best-effort low 000111 best-effort low 001000 best-effort low 001001 best-effort low 001010 assured-forwarding low 001011 best-effort low 001100 assured-forwarding high 001101 best-effort low 001110 assured-forwarding high 001111 best-effort low 010000 best-effort low 010001 best-effort low 010010 best-effort low 010011 best-effort low 010100 best-effort low 010101 best-effort low 010110 best-effort low 010111 best-effort low 011000 best-effort low 011001 best-effort low 011010 best-effort low 011011 best-effort low 011100 best-effort low 011101 best-effort low 011110 best-effort low


011111 best-effort low 100000 best-effort low 100001 best-effort low 100010 best-effort low 100011 best-effort low 100100 best-effort low 100101 best-effort low 100110 best-effort low 100111 best-effort low 101000 best-effort low 101001 best-effort low 101010 best-effort low 101011 best-effort low 101100 best-effort low 101101 best-effort low 101110 expedited-forwarding low 101111 best-effort low 110000 network-control low 110001 best-effort low 110010 best-effort low 110011 best-effort low 110100 best-effort low 110101 best-effort low 110110 best-effort low 110111 best-effort low 111000 network-control low 111001 best-effort low 111010 best-effort low 111011 best-effort low 111100 best-effort low 111101 best-effort low 111110 best-effort low 111111 best-effort low

show class-of-service classifierコマンドでは、802.1p、 IP Precedence、および EXPのリストも表示されます（ただし、この出力では省略しています）。

そのため、必要な条件のみを変更してデフォルトクラシファイアと組み合わせることにより、分類の範囲を広げることができます。以下のコードでは、「import default」セクションを設定しています。

[edit]user@R1#class-of-service { classifiers { dscp VOICE-BA-CLASSIFIER { import default; forwarding-class expedited-forwarding { loss-priority low code-points [ cs5 ef ]; } forwarding-class assured-forwarding { loss-priority low code-points [ cs1 af11 af12 af13 cs2 af21 af22 af23 ]; loss-priority high code-points [ cs3 af31 af32 af33 cs4 af41 af42 af43 ]; }


forwarding-class best-effort { loss-priority low code-points be; } forwarding-class network-control { loss-priority low code-points cs7; loss-priority high code-points cs6; } } } interfaces { ge-0/0/0 { unit 0 { classifiers { dscp VOICE-BA-CLASSIFIER; } } }}

MFクラシファイアの設定

ファイアウォールフィルタを設定し、レイヤー 3インタフェース（IPアドレス設定済み）またはレイヤー 2インタフェース（IPアドレス未設定）に適用することができます。

[edit]user@R1#firewall { family ethernet-switching { filter VOICE-MF-CLASSIFIER-L2 { term ACCEPT-VOICE { from { protocol udp; destination-port 10000-65000; } then { accept; forwarding-class expedited-forwarding; loss-priority low; } } term ACCEPT-VOICE-CONTROL { from { destination-port [ 5060 5070-5074 5400-5800 32768-65535 ]; } then { accept; forwarding-class assured-forwarding; loss-priority low; } } term ACCEPT-ALL-BE { then { accept;


forwarding-class best-effort; loss-priority low; } } } }}

interfaces { ge-0/0/0 { unit 0 { family ethernet-switching { filter { input VOICE-MF-CLASSIFIER-L2; } } } }}

スケジューリングの定義と設定

パケットを分類し、キューに割り当てたら、次のステップでは、以下の内容を決定しなければなりません。

� 優先度の定義 � 帯域幅の定義 � 重み付けラウンドロビン

これらを行うために、まずスケジューラを設定し、そのスケジューラにスケジューラマップを関連付け、最後にスケジューラマップをインタフェースに適用する必要があります。

スケジューラの設定

帯域幅とバッファサイズの指定は、schedulerで定義します。transmit rateは、キューに割り当てられる帯域幅の量、buffer-sizeは、輻輳時に保存できるデータ量を示します。WRR（Weighted Round Robin）は、各キューをどのように処理するかを定義するアルゴリズムです。このアルゴリズムでは、重要性の高いキューが先に処理されますが、より優先度の低いキューに帯域幅が割り当てられない状態が続かないようにもします。これにより、デバイスを通してパケットを転送するときのバランスが保たれます。キュー優先度は、他のキューに対するキューの相対的な重要度を示します。各キューは、そのキューに割り当てられた優先度に従って処理されます。サポートされる優先度には、高いものから順に以下の 5つがあります。


� Strict-high

� High

� Medium-high

� Medium-low

� Low

Strict-Highは最高の優先度で、LLQでは最初に処理されるため、音声トラフィックに最適です。ただし、Strict-Highは特殊な設定であり、インタフェース全体の帯域幅を消費することもできるため、使用する際は注意が必要です。また、Strict-HighとHighでは、基礎となるハードウェアキューが共有されるため、結果的にパケットの送信において優先度が共有されます。

注キュー優先度とPLP（Packet Loss Priority）は異なることに注意してください。キュー優先度は、特定のキューに与えられる、他のキューに対する相対的な重要度を表すのに対し、PLPは、輻輳が生じた場合にパケットが破棄される可能性を指します。PLPは、輻輳制御の一部として使用されます。

注当然ながら、輻輳をどのように定義するか、という疑問を抱くでしょう。輻輳は、すべてのネットワークのオペレータが定義し、設定できます。第 5章で説明するドロッププロファイルにより、その方法についての理解を深めることができるでしょう。

設定できるPLPには以下の 4つがあります。 � Low

� Medium-low

� Medium-high

� High

buffer-sizeや transmit-rate、および priorityを設定することは、いつの時点でどのキューを処理するかを決定するうえで重要なステップです。また、キューに帯域幅が割り当てられない状況を防ぐために、特定のキューをどれくらいの時間で処理し、次のキューに移すかを確立するのに役立ちます。以下の例は、スケジューラの定義および設定例を示しています。

[edit]user@R1#class-of-service { schedulers { EF-SCHED { buffer-size percent 20; priority strict-high;


} VC-SCHED { transmit-rate remainder; buffer-size remainder; priority low; } NC-SCHED { buffer-size percent 10; priority high; } AF-SCHED { transmit-rate percent 50; buffer-size percent 50; priority low; } }}

スケジューラマップの設定

スケジューラは、特定のフォワーディングクラスのトラフィックを管理することを目的としています。このスケジューラとフォワーディングクラスを関連付けるリンクを提供するのがスケジューラマップです。

図 2.2 フォワーディングクラス、キューイング、およびスケジューリング


図 2.2は、ルーターに到着したパケットが、あらかじめ定義されているクラシファイアルールに基づいてそれぞれのフォワーディングクラスにどのようにマッピングされるかを表しています。各フォワーディングクラスにはキューが割り当てられています。その後、送信インタフェースに関連付けられたスケジューラマップにより、各スケジューラで定義された条件に基づいてパケットが送信されます。以下の設定は、スケジューラマップがどのようにスケジューラに関連付けられているかを示しています。

[edit]user@R1#class-of-service { scheduler-maps { VOICE-SCHED-MAP { forwarding-class best-effort scheduler VC-SCHED; forwarding-class network-control scheduler NC-SCHED; forwarding-class expedited-forwarding scheduler EF-SCHED; forwarding-class assured-forwarding scheduler AF-SCHED; } }}

スケジューラマップの導入

最後のステップでは、スケジューラマップをインタフェースに適用します。スケジューリングはインタフェースの出力において行われるため、スケジューラマップは暗黙的に設定インタフェースの送信方向に適用されます。以下に例を示します。

[edit]user@R1#class-of-service { interfaces { ge-0/0/0 { scheduler-map VOICE-SCHED-MAP; } }}

リライトルールの定義と設定

パケットの書き換え、すなわちマーキングの目的は、パケットの CoS情報をネクストホップルーターに効率的に伝達し、ネットワークを横断するパケットに一貫したエンドツーエンドの CoSポリシーを適用することです。パケットマーキングのオプションとして、DSCP、MPLS EXP、IP Precedence、802.1p、または 802.1adドロップ適性インジケータ（DEI）ビットがあります。import defaultは、BAクラシファイアの場合と同じように機能します。以下の抜粋は、デフォルトDCSPを示しています。

user@R1> show class-of-service rewrite-rule Rewrite rule: dscp-default, Code point type: dscp, Index:31 Forwarding class Loss priority Code point


best-effort low 000000 best-effort high 000000 expedited-forwarding low 101110 expedited-forwarding high 101110 assured-forwarding low 001010 assured-forwarding high 001100 network-control low 110000 network-control high 111000

リライトルールの設定

以下の例は、リライトルールの設定方法を示しています。各フォワーディングクラスに割り当てられたパケットに、PLP値と組み合わせてどのようなマーキングが行われるかが示されています。

[edit]user@R1#class-of-service { rewrite-rules { dscp VOICE-DSCP-REWRITE { import default; forwarding-class expedited-forwarding { loss-priority low code-point ef; } forwarding-class assured-forwarding { loss-priority low code-point cs3; loss-priority high code-point cs3; } forwarding-class network-control { loss-priority low code-point cs7; loss-priority high code-point cs6; } forwarding-class best-effort { loss-priority low code-point be; } } } interfaces { ge-0/0/0 { unit 0 { rewrite-rules { dscp VOICE-DSCP-REWRITE; } } }}


まとめJunosデバイスでのQoS設定は、以下の 4つの主要ステップで行います。

� フォワーディングクラスの定義と設定 � スケジューラの定義と設定 � スケジューラマップの定義と設定 � リライトルールの定義と設定

JunosでのQoSの処理方法を図 2.3に示します。

図 2.3 JunosでのQoS処理

Junosで QoSを処理するためには、まず要件を明確にすることが重要です。次に、フォワーディングクラスを検討して決定し、帯域幅を割り当てる前にスケジューラを定義します。最後にスケジューラマップをフォワーディングクラスに関連付け、パケットをどのように書き換えるかを定義します。

計画が明確になったら、後はその計画をデバイスに実装し、設定すればよいのです。このような方法を取ることで、やや捉えにくい QoSの概念を、より操作しやすい構造として扱えるようになります。IOSエンジニアが Junosで作業を行うと、以下のような違いが明らかになります。

� Junosでは、多くの設定がサービスクラス階層に集中しているため、特定のアクセスリストや別のクラスマップを探すために設定全体を参照する必要がありません。QoSを設定するときは、これを特に便利なことと思われないかもしれませんが、インタフェースに導入された QoS全体を理解しようとするときには非常に有効です。

� サポートされていない設定は、入力時に受け付けません。


� Junosコンフィグレーションは、インデントおよび構造化されているため、階層構造として設定を表示できます。

� インタフェースのトラフィックをリアルタイムに監視できるため、問題の特定とトラブルシューティングが容易になります。

第3章

基本ステップに沿ったIOSとJunosの比較

IOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Junos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

IOSでの作業に相当するJunosでの作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32


第 1章では、ネットワークにQoSを設計するために不可欠な 5つの基本ステップを挙げました。それでは、これらのステップが、IOSおよび Junosでどのような作業に相当するかを説明します。

IOS

第 1ステップでクラスマップを定義することにより分類します。第 2ステップでキューイング、スケジューリング、および優先度設定は、キューイングアルゴリズムを定義することにより行います。最終ステップで帯域の割り当てとマーキングを行い、ポリシーをインタフェースに適用します。

分類クラスマップを設定します。

キューイング多くの場合、CBWFQ（Class Based Weighted Fair Queuing）または LLQ（Low Latency Queuing）を使用します。特定のキューイング方法では、スケジューリング方法も重要になります。スケジューリングと優先度

設定

帯域の割り当てポリシーマップを設定します。各トラフィッククラスに対して、帯域幅を定義します。各トラフィッククラスに対して、どのようなパケットマーキングを行うかを定義します。ポリシーマップをインタフェースに適用します。

マーキング

Junos

第 1ステップで分類とキューイングを行います。このとき、フォワーディングクラスを定義し、BAクラシファイア /MFクラシファイアを使用します。次のステップでは、スケジューリング、優先度設定、および帯域の割り当てを行います。このとき、スケジューラとスケジューラマップを定義し、それをインタフェースに割り当てます。最後に、リライトルールを定義し、それをインタフェースに割り当てることによって、マーキングを行います。

分類 class-of-service配下でフォワーディングクラスを設定します。BAクラシファイアを設定し、それを class-of-service配下でインタフェースに適用するか、MFクラシファイアファイアウォールフィルタを設定し、それを物理インタフェースに適用します。

キューイング

スケジューリングと優先度設定

class-of-service配下でスケジューラを設定します。class-of-service配下でスケジューラマップを設定します。class-of-service配下でスケジューラマップをインタフェースに割り当てます。帯域の割り当て

マーキング class-of-service配下でリライトルールを設定し、それを class-of-service配下でインタフェースに適用します。

第3章：基本ステップに沿ったIOSとJunosの比較 31

IOSから Junosへの変換一連の基本ステップに JunosとCiscoの CLIがどのように関連しているかが分かりました。次に、Ciscoと同じ設定を Junosでどのように行うかを説明いたします。以下の表にまとめます。

Cisco IOS Junos

分類方法「class-map」でのオプション - access-list、protocolsなど。

第 1ステップは、フォワーディングクラスを定義するための準備です。次のステップは分類です。これは、Class-of-service | classifiersでBAクラシファイアを、またはfirewallでMFクラシファイアを使用することにより行えます。

キューイングとスケジューリング

プラットフォームおよびコードに応じて、FIFO、LLQ、CBWFQ、CQなどを使用できます。

class-of-service | schedulers配下でスケジューラを定義し、次にclass-of-service | scheduler-mapでスケジューラマップを定義します。

優先度設定「priority」帯域幅を使用して LLQを指定します。一方、他のキューの優先度は、FIFO、CBWFQ、WFQなどのアルゴリズムによって決まります。

キューの優先度は、class-of-service | schedulers配下で指定できます。

帯域の割り当て policy-mapで bandwidthまたはbandwidth percentを定義します。

class-of-service | schedulersでスケジューラを定義し、次にclass-of-service | scheduler-mapでスケジューラマップを定義し、それを class-of-service | interfacesでインタフェースに適用します。

マーキング policy-mapでの「set」コマンド。 class-of-service | rewriteでのオプション。

適用先 interfaceで受信方向または送信方向にサービスポリシーを定義します。

BAクラシファイアの場合はclass-of-service | interfacesでのオプション、またはMFクラシファイアの場合は interfacesでのオプション。


まとめJunosでは、構造化された、よりきめ細かい方法で QoSを定義し、設定することができます。使用するスケジューリング、キューイング、および優先度設定手法を詳細に指定できるため、パケットをどのように処理するかをより厳密に制御することが可能です。機能的には、Junosでは、Cisco IOSデバイスの設定と同じことができます。

第4章

ポリシングとシェーピング

ポリサー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

シェーパー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42


トラフィックの調整は、ネットワークの輻輳を管理するうえで重要なステップです。ポリシングとシェーピングは、輻輳の軽減に役立つ 2つの方法であり、データが送受信されるレートを継続的に測定することによって機能します。ポリシングでは、適合トラフィックに遅延が生じないようにしながら、過剰なパケットを破棄することにより、サービス品質保証契約（SLA）を実施します。一方、シェーピングでは、過剰なトラフィックをバッファリングし、シェーピングレートに基づいて、バッファリングしたトラフィックを開放します。

ポリサーポリシングでは、トラフィックがインタフェースに到着、またはインタフェースから出て行くレートにハードリミットを適用します。制約に適合していないパケットは、破棄されるか（ハードポリシング）、分類し直されます（ソフトポリシング）。ポリシングは、隣接するネットワークが契約帯域以上のトラフィックを送出する可能性がある状況で役立ちます。この場合、ポリシングによってレートリミットが実施されるため、過剰なトラフィックでネットワークがあふれる状況を回避できます。ポリサーは、受信方向または送信方向に適用できます。

図 4.1 トラフィックポリシング前

トラフィックポリシングの例として、4Mbpsのサービス契約をキャリアから購入した顧客について考えてみましょう。この契約では、顧客のトラフィックの上限が 4Mbpsとして取り決められています。トラフィックが 4Mbpsを超えた場合、キャリアはそのトラフィックを受け入れないようにすることで、4Mbpsの上限を保ちます。これにより、キャリアのネットワークが過剰なトラフィックで過負荷になる状況を防ぐことができます。

第4章：ポリシングとシェーピング 35

図 4.2 トラフィックポリシング後 - プロファイル外

IOS

Cisco IOSでは、ポリシングは以下の 2つの方法で行えます。 � CAR（Committed Access Rate） � クラスベースのポリシング

注 CARのサポートについては、該当するプラットフォームタイプおよびIOS コードのバージョンを参照してください。

例 1は、クラスベースのポリシングを使用した場合です。例 2は、CARを使用した場合です。

例 1：クラスベースのポリシングRouter(config)# policy-map policeRouter(config-pmap)# class c2Router(config-pmap-c)# police 8000 2000 4000 conform-action transmit exceed-action set-qos-transmit 4 violate-action dropRouter(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# interface fastethernet 0/0Router(config-if)# service-policy input police

例 2：CARRouter# show run

interface Hssi0/0/0 rate-limit input 15000000 2812500 2812500 conform-action transmit exceed-action drop ip address 192.168.24.1 255.255.255.252 rate-limit output 15000000 2812500 2812500 conform-action transmit exceed-action drop


Junos

Junosにおけるポリシングの動作モードには、以下の 3つがあります。1. シングルレート 2カラー – 1つのレートしきい値（CIR）と 1つのバーストサイズ（CBS）から成ります。2. シングルレート 3カラーマーキング – 1つのレートしきい値（CIR）と 2つのバーストサイズ（CBSおよび PBS）から成ります。3. 2レート 3カラーマーキング – 2つのレートしきい値（CIRおよび PIR）と 2つのバーストサイズ（CBSおよび PBS）から成ります。

ポリシングは、以下のいずれかの方法で実行できます。 � インタフェースに直接設定する � ファイアウォールフィルタによって設定し、インタフェースに適用する

Junosの 3カラーマーキングには、以下の 2つの動作モードがあります。

� カラーブラインド – ポリサーは、パケットの既存のマーキングを考慮せず、ポリサーの設定に基づいてパケットのマーキングをPLP値に書き換えます。

� カラーアウェア - ポリサーは、パケットの既存のマーキングを考慮します。PLP値は、既存の値と、特定ポリサーを通過した結果の組み合わせに基づきます。

また、ファイアウォールフィルタを使用したポリシングでは、以下の 2つのバリエーションを使用できます。

� 2カラーマーキングの集約ポリサー – firewallで複数の条件が定義され、各条件によってポリサーが呼び出される場合、デフォルトでは、各条件の bandwidth-limitとburst sizeが関連付けられます。ただし、すべての条件をまとめて同じポリサーに適合させ、bandwidth-limitの合計を関連付ける必要がある場合は、policerで「filter-specific」キーワードを指定します。

� 2カラーまたは 3カラーマーキングの集約ポリサー - 1つのインタフェースに複数のプロトコルファミリーと複数のユニットが存在し、それぞれに、ポリサーが設定されたファイアウォールフィルタがある場合、これらを集約して、論理（ユニットまたはプロトコルファミリーごと）レベルではなく、物理インタフェースに対して同じ帯域幅制約を適用することをお奨めします。これを行うには、policerで「physical-interface-policer」キーワードを指定します。

インタフェースに直接適用される2カラーポリサーも、同じインタフェースの複数のプロトコルファミリーに適用する場合は一つにまとめること


ができます。これを行うには、policerで「logical-interface-policer」キーワードを指定します。インタフェースポリサーとファイアウォールフィルタポリサーは、interface配下で同時に指定することができます。これらのポリサーは、以下の順序で処理されます。

受信送信

インタフェースポリサーファイアウォールフィルタ

ファイアウォールフィルタインタフェースポリサー

ポリサーの設定

以降の例では、ポリサーのさまざまな設定方法を示します。すなわち、インタフェースに直接適用する方法、ファイアウォールフィルタを使用する方法、1 レート 3 カラーマーキングを適用する方法です。例 1では、ポリサーをインタフェースに直接適用する方法を示します。このポリサーでは、定義されているレートを超えたトラフィックをすべて破棄するように指定しています。例 2では、インタフェースへの DNSおよび ICMP（ルーターアドバタイズメントおよびリダイレクト）トラフィックの量を制限しながら、ファイアウォールフィルタをそのインタフェースに適用する方法を示します。例 3では、1レート 3カラーマーキングの使用方法を示します。

例 1：インタフェースに直接適用する場合 [edit]user@R1#firewall { policer my-2color-policer { if-exceeding { bandwidth-limit 1m; burst-size-limit 2k; } then discard; }}

interfaces { ge-1/0/0 { unit 0 { family inet { policer { input my-2color-policer; } address 172.22.54.2/24; } } }}


例 2：ファイアウォールフィルタ内で適用する場合 [edit]user@R1#firewall { policer RATE-LIMIT-PROTECT { filter-specific; if-exceeding { bandwidth-limit 2m; burst-size-limit 500k; } then discard; } filter ROUTER-PROTECT { term DNS { from { protocol udp; source-port 53; } then { policer RATE-LIMIT-PROTECT; accept; } } term ICMP { from { protocol icmp; icmp-type-except [ router-advertisement redirect ]; } then { policer RATE-LIMIT-PROTECT; accept; } }}

interfaces { ge-1/0/0 { unit 0 { family inet { filter { input ROUTER-PROTECT; } address 172.22.54.1/24; } } }}

例 3：1レート3カラーマーキング [edit]user@R1#firewall {


three-color-policer my-srTCM-policer { single-rate { color-aware; committed-information-rate 1m; committed-burst-size 5k; excess-burst-size 10k; } } filter ROUTER-PROTECT { term A { then { three-color-policer { single-rate my-srTCM-policer; } } }}

interfaces { ge-1/0/0 { unit 0 { family inet { filter { input ROUTER-PROTECT; } address 172.22.54.3/24; } } }}

class-of-service { tri-color;}

シェーパーシェーピングでも、送信できるトラフィックのレート制限を定義します。ポリシングとは異なり、シェーピングは、送信トラフィックを一時的にキューに入れることで、送信レートをコントロールします。シェーピングは、隣接ネットワークでポリシングが行われていたり、トラフィックの受け入れ速度が遅い場合に役立ちます。そのような状況下では、シェーパーはトラフィックを遅らせることで、ドロップされるのを防ぐことができます。ポリシングほど極端ではなく、副作用が少ないと言えますが、パケットをバッファリングするため、遅延の影響を受けやすい音声などのリアルタイムパケットにはマイナスの効果を及ぼす可能性がありますので、ご注意ください。なお、シェーピングは送信トラフィックのみ有効です。


図 4.3 シェーピング前のトラフィックパターン

図 4.4 シェーピング後のトラフィックパターン

IOS

Cisco IOSでは、4つのシェーピングツールがサポートされていますが、最もよく使用されているのは、クラスベースシェーピングとFRTSです。

シェーピングツールサポートされるキュー

GTS（Generic Traffic Shaping） WFQ

CB（Class Based）トラフィックシェーピング FIFO、WFQ、CBWFQ、LLQ

DTS（Distributed Traffic Shaping） FIFO、WFQ、CBWFQ、LLQ

FRTS（Frame Relay Traffic Shaping） FIFO、WFQ、CBWFQ、LLQ、PQ、CQ


注各プラットフォームでサポートされるシェーピングツールについては、プラットフォームの仕様を参照してください。

例 1では、クラスベースシェーピングの使用方法を示します。例 2では、汎用トラフィックシェーピングの使用方法を示します。

例 1：CBトラフィックシェーピングRouter(config)# policy-map shapeRouter(config-pmap)# class testRouter(config-pmap-c)# shape average 384000 15440Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# interface Serial 0/0Router(config-if)# service output shape

例 2：GTSRouter# show run

access-list 101 permit udp any anyinterface FastEthernet0/0 traffic-shape group 101 1000000 125000 125000!interface FastEthernet0/1 traffic-shape rate 5000000 625000 625000

Junos

シェーピングは、以下の方法で設定できます。 � class-of-serviceまたは class-of-serviceの schedulersで traffic-

control-profilesを定義

� 特定のインタフェースの class-of-service | interfacesで設定

シェーパーでは、設定されている PIR（シェーピングレート）までは、トラフィックの送信が許可されます。ただし、PIRを超えると、トラフィックレートが再び PIRを下回るまでパケットは送信されず、バッファに格納されます。3つのオプションのうち、traffic control profilesでシェーピングを定義する方法では、より厳密な制御が可能なだけでなく、保証レート（CIR）を指定することもできます。

それぞれ、例 1では traffic-control-profiles、例 2では class-of-service|

schedulers、例 3では class-of-service| interfacesの使用方法を示します。

例 1[edit]user@R1#class-of-service { traffic-control-profiles { my-L1-profile { shaping-rate 500m; } my-L2-profile { shaping-rate 200m; guaranteed-rate 100m; } my-L3-profile {


scheduler-map my-sched-map; shaping-rate 80m; guaranteed-rate 50m; } } interfaces { interface-set my-interface-set { output-traffic-control-profile my-L2-profile; } ge-1/0/4 { output-traffic-control-profile my-L1-profile; unit 0 { output-traffic-control-profile my-L3-profile; } unit 1 { output-traffic-control-profile my-L3-profile; } } }}

例 2[edit]user@R1# show class-of-service schedulers { test { shaping-rate 32k; }}

例 3[edit]user@R1# show class-of-service interfaces { ge-0/0/1 { shaping-rate 16k; }}

まとめトラフィックシェーピングとポリシングは、ネットワークにおける輻輳を管理するために使用できる手法です。どちらの手法も効果的ですが、それぞれにメリットとデメリットがあり、実際に顧客環境で使われています。

ポリシングシェーピング

受信設定可能転送前にパケットが格納されるため、受信モードでは適用不可

送信設定可能設定可能

第5章

輻輳回避

IOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Junos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48


大量のトラフィックを受信した場合、輻輳が起きる可能性が高まります。輻輳が生じると、キューが短時間でいっぱいになり、さらに使用可能なバッファがなくなり、パケットが破棄され始めます。このメカニズムはテールドロップと呼ばれ、どのパケットを破棄するかを制御することはできません。RED（Random Early Detection）は、バッファがいっぱいになった場合にパケットを選択的に破棄することにより、輻輳時のアクションを決定することのできるメカニズムです。

IOS

Cisco IOSデバイスのWRED（Weighted Random Early Detection）は、最小しきい値と最大しきい値を定義し、ドロップ確率デノミネータを設定することにより実行できます。輻輳が最小しきい値を下回っているときは、パケットは破棄されませんが、輻輳が定義されている最大しきい値を超えると、すべてのパケットが破棄されます。輻輳が、定義されている最小しきい値から最大しきい値までの範囲にあるときは、ドロップ確率デノミネータ数のパケットあたり 1パケットが破棄されます。また、IP Precedence/DSCP値ごとに異なるWREDプロファイルを使用することにより、パケットに対して異なる処理を適用できます。以降の例に、WREDの導入シナリオをいくつか示します。

例 1Router# show run

interface se0/0 ip address 10.200.14.250 255.255.255.252 random-detect random-detect precedence 0 32 256 100 random-detect precedence 1 64 256 100 random-detect precedence 2 96 256 100 random-detect precedence 3 120 256 100


interface se0/0 ip address 10.200.13.250 255.255.255.252 random-detect random-detect dscp-based random-detect dscp af21 24 40 random-detect dscp af23 24 40


第5章：輻輳回避 45

policy-map Expressclass Enterprisebandwidth percent 25random-detect dscp-basedrandom-detect dscp af21 24 40 10random-detect dscp af22 28 40 10random-detect dscp af23 30 40 10

class Businessbandwidth percent 30random-detect dscp-basedrandom-detect dscp af11 22 38 10random-detect dscp af12 24 38 10random-detect dscp af13 28 38 10

class Databandwidth percent 30random-detect dscp-basedrandom-detect dscp af31 26 34 10random-detect dscp af32 28 34 10random-detect dscp af33 30 34 10

class defaultfair-queuerandom-detect dscp-based


interface Serial1/0 random-detect random-detect flow random-detect flow average-depth-factor 8 random-detect flow count 16

さらに詳しくはフローベースのWREDを使用することもできます。フローベースのWREDは、WREDを強制的に適用することで、パケットのドロップ方法に関して、インタフェース上のすべてのフローの公平性を高めることのできる機能です。詳細については http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfconav_ps1835_TSD_Products_Configuration_Guide_Chapter.html#wp1005869を参照してください。

Junos

ドロッププロファイルでは、輻輳発生時のトラフィックの破棄に関するパラメータを指定することにより、RED/WREDが実行されます。複数のドロッププロファイルを設定し、各キューに適用することができます。

ドロッププロファイルの設定は、以下の 2通りの方法で行えます。


� セグメント化 – この方法では、設定されたレベルまでバッファがいっぱいになると、ドロップ確率パーセントが段階的に増加します。

� 補間 – この方法では、設定されたレベルまでバッファがいっぱいになると、設定されている値間でドロップ確率パーセントが比例的に増加します。

図 5.1 ドロッププロファイル

ドロッププロファイルを作成し、スケジューラに関連付けます。1つのスケジューラに、トラフィックフローごとに異なる複数のドロッププロファイルを設定することもできます。また、ドロッププロファイルをスケジューラに関連付けながら、PLP（Packet Loss Priority）およびプロトコルを柔軟に指定することができます。

セグメント化ドロッププロファイルの設定[edit]user@R1#class-of-service { drop-profiles { HIGH { fill-level 25 drop-probability 25; fill-level 50 drop-probability 50; fill-level 75 drop-probability 75; fill-level 95 drop-probability 100; } LOW { fill-level 70 drop-probability 100; } } schedulers { AF-SCHED { transmit-rate percent 20; excess-rate percent 35; buffer-size temporal 15k; priority low; excess-priority high;

第5章：輻輳回避 47

drop-profile-map loss-priority high protocol any drop-profile HIGH; } BE-SCHED { transmit-rate remainder; excess-rate percent 30; buffer-size remainder; priority low; excess-priority low; drop-profile-map loss-priority low protocol any drop-profile LOW; } GENERAL-SCHED { priority low; drop-profile-map loss-priority any protocol any drop-profile LOW; } }}

補間ドロッププロファイルの設定[edit]user@R1#class-of-service { drop-profiles { HIGH { interpolate { fill-level [ 0 10 15 ]; drop-probability [ 0 90 100 ]; } } MED-HIGH { interpolate { fill-level [ 15 20 25 ]; drop-probability [ 0 90 100 ]; } } MED-LOW { interpolate { fill-level [ 50 70 ]; drop-probability [ 1 100 ]; } } LOW { interpolate { fill-level [ 70 100 ]; drop-probability [ 1 100 ]; } } } schedulers { AF-SCHED { transmit-rate percent 20; excess-rate percent 35; buffer-size temporal 15k; priority low;


excess-priority high; drop-profile-map loss-priority high protocol any drop-profile HIGH; drop-profile-map loss-priority medium-high protocol any drop-profile MED-HIGH; drop-profile-map loss-priority medium-low protocol any drop-profile MED-LOW; drop-profile-map loss-priority low protocol any drop-profile LOW; } BE-SCHED { transmit-rate remainder; excess-rate percent 30; buffer-size remainder; priority low; excess-priority low; drop-profile-map loss-priority high protocol any drop-profile HIGH; drop-profile-map loss-priority medium-high protocol any drop-profile MED-HIGH; drop-profile-map loss-priority medium-low protocol any drop-profile MED-LOW; drop-profile-map loss-priority low protocol any drop-profile LOW; } GENERAL-SCHED { priority low; drop-profile-map loss-priority any protocol any drop-profile LOW; } }}

まとめネットワークの輻輳は、いつでも発生し得る問題です。帯域幅を増やすのも 1つの選択肢ですが、この方法には常により多くのコストが伴います。どのネットワークでも輻輳が生じると、パケットが破棄されます。輻輳回避は、どのパケットを破棄してもかまわないかをより厳密に制御することのできる手法です。ネットワークが特定のしきい値に達した場合に、損失優先度がより高いパケットを破棄するようにネットワークデバイスを設定できます。これを行うための手法が RED（Random Early Detection）やWRED（Weighted Random Early Detection）です。輻輳回避を設定するには、IOSでは、interfacesで特定のユーザートラフィックに対してランダム検出を設定し、Junosでは、以下を指定します。

� セグメント化ドロッププロファイル � 補間ドロッププロファイル

各方法には、それぞれ優位性があります。

第6章

トラブルシューティング

IOSのトラブルシューティングコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

Junosのトラブルシューティングコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68


サービスクラスに関して何らかの問題が生じた場合、何が間違っているのかをどうやって調べたらよいのでしょうか。ここでは、問題が検出された場合に、その考えられる原因を絞り込むための基本ステップを示します。

IOSのトラブルシューティングコマンド多くの IOSエンジニアがQoSの問題のトラブルシューティングを行う際に従う一般手順を以下に示します。また、IOSのトラブルシューティングコマンドを表 6.1に示します。1. 影響を受けているトラフィックの送受信に関わっている主なインタフェースを特定します。2. インタフェース設定を調べ、そのインタフェースにサービスポリシーが適用されているかどうか、また受信方向と送信方向のどちらに適用されているかを確認します。3. ポリシーマップと該当するクラスマップの設定を確認します。

4. インタフェースカウンターを調べ、パケットカウントが増加しているかどうかを確認します。これは、カウンターを見れば分かります。

5. policy-mapインタフェースコマンドを調べ、インタフェースへのポリシーマップの適用後にどのキューが処理されているかを確認します。6. インタフェースのキューカウンターを調べ、パケットが適切な送信キューに移動しているか、また期待どおりに処理されているかを確認します。これは、パケットの分類または書き換えに問題があるかどうかを特定するうえで役立ちます。7. パケットカウンターが予測どおりに増加し、パケットが適切なキューに移動しているにも関わらず、パフォーマンスの問題が生じている場合は、ハードウェアに問題がある可能性があります。パケットのパスをたどり、この問題を引き起こしている可能性のある内部 ASICを特定します。この段階では、Cisco TACと協力して解決に取り組みます。

表 6.1 IOSのトラブルシューティングコマンド

Cisco IOSのコマンドどのように役立つか

Show run interface <interface-type> このコマンドは、インタフェースに適用されているサービスポリシーと、それが受信方向と送信方向のどちらに適用されているを特定するうえで役立ちます。

Show policy-map interface <interface-type> このコマンドにより、このインタフェースで送受信されているさまざまなトラフィッククラスと、一致したパケット、マーキング、シェーピング、またはポリシングされたパケットに関する情報が得られます。また、すべてのクラスのキューイング方法に関する情報も示されます。

Show interface<interface-type> このコマンドにより、送受信されたパケットと、インタフェースのキューイングタイプ（FIFOなど）、WREDが有効かどうかに関する情報が得られます。

第6章：トラブルシューティング 51

Show queue “serial 0/0” このコマンドにより、キューイング方法と、バッファドロップ、入力および出力キュー、使用可能な帯域幅などに関する情報が示されます。

Clear interface counters このコマンドにより、すべてのインタフェースについてすべてのカウンターのインタフェース統計情報がクリアされます。

Show controllers “serial 0/0” このコマンドにより、TXリングのサイズが示されます。「tx_limited」キーワードを指定すると、TXリングで保持されているパケット数が示されます。

Show queuing interface “serial 0/0” このコマンドにより、インタフェースのキューで待機中のパケット、キューイング戦略、DSCP値ごとのテールドロップ、およびWREDに関する情報が示されます。

JunosのトラブルシューティングコマンドJunosで QoSに関連する問題のトラブルシューティングを行う場合も、同様の手順を使用できます（ほとんどがclass-of-serviceセクションでの設定）。 1. 影響を受けているトラフィックの送受信に関わっている主なインタフェースを特定します。2. インタフェース設定を調べ、インタフェースに適用されているファイアウォールフィルタ、MFクラシファイア、またはポリサーがあるかどうかを確認します。3. class-of-service設定でインタフェースを調べ、設定されているBAクラシファイア、リライトルール、またはスケジューラマップがあるかどうかを確認します。4. インタフェースカウンターを調べ、パケットカウントが両方の方向で増加しているかどうかを確認します。これを行うには、カウンターを繰り返し調べるか、インタフェーストラフィックをリアルタイムに監視します。5. インタフェースのキューカウンターを調べ、パケットが適切な送信キューに移動しているか、また期待どおりに処理されているかを確認します。これは、パケットの分類または書き換えに問題があるかどうかを特定するうえで役立ちます。6. インタフェースにファイアウォールフィルタまたはMFクラシファイアが適用されている場合、ファイアウォールログを調べ、カウンターが増加しているかどうかを確認します。パケットカウントが有効になっている場合、ファイアウォールログから、どのカウンターが増加しているかが分かります。7. これらの手順を実行しても問題が解決されない場合、フォワーディングテーブル、PFE、または DPCに問題がある可能性があります。この段階では、JTACと協力して解決に取り組みます。ここでは、サービスクラス /サービス品質に関連する問題を切り分けられるように、showコマンドを表で一覧表示する代わりに、Junos


のトラブルシューティングに役立つ showコマンドを見直していきます。この章の残りの部分では、以下の必要な各 showコマンドを詳しく示します。

� monitor interface traffic

� show interfaces <interface-type> extensive

� show interfaces <interface-type> extensive | find "queue counters"

� show class-of-service forwarding class

� show configuration class-of-service

� show interfaces queue <interface-type>

� clear interfaces statistics all

� show firewall

� show configuration interface <interface-type>

� show configuration class-of-service interface

monitor interface traffic

このコマンドは、Junosが実行されているデバイスの任意のインタフェースを通過する入力および出力パケットの監視に役立ちます。このコマンドでは、パケットがインタフェースを通過するたびにカウンターが増加するため、トラフィックをリアルタイムに監視することができます。

user@R1> monitor interface trafficBytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^DR1 Seconds:27 Time:19:11:19Interface Link Input packets (pps) Output packets (pps) lc-0/0/0 Up 0 0 pfh-0/0/0 Up 0 0 xe-0/0/0 Down 0 (0) 0 (0) xe-0/0/1 Down 0 (0) 0 (0) xe-0/0/2 Down 0 (0) 0 (0) xe-0/0/3 Down 0 (0) 0 (0) ge-1/0/0 Up 35761707 (11) 35312140 (11) ge-1/0/1 Up 77976 (0) 737191 (0) ge-1/0/2 Up 8 (0) 442317 (0) ge-1/0/3 Down 0 (0) 0 (0) ge-1/0/4 Down 0 (0) 0 (0) ge-1/0/5 Down 0 (0) 0 (0) ge-1/0/6 Up 238472 (0) 238440 (0) ge-1/0/7 Down 0 (0) 0 (0) ge-1/0/8 Up 238440 (0) 238472 (0) ge-1/0/9 Down 0 (0) 0 (0) ge-1/0/10 Up 0 (0) 0 (0) ge-1/0/11 Down 0 (0) 0 (0) ge-1/1/0 Up 0 (0) 0 (0) ge-1/1/1 Down 0 (0) 0 (0)


ge-1/1/2 Down 0 (0) 0 (0) ge-1/1/3 Down 0 (0) 0 (0) ge-1/1/4 Down 0 (0) 0 (0) ge-1/1/5 Down 0 (0) 0 (0) ge-1/1/6 Down 0 (0) 0 (0) ge-1/1/7 Down 0 (0) 0 (0) ge-1/1/8 Down 0 (0) 0 (0) ge-1/1/9 Down 0 (0) 0 (0) ge-1/1/10 Down 0 (0) 0 (0) ge-1/1/11 Down 0 (0) 0 (0)

Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^D

show interfaces <interface-type> extensive

このコマンドは、入力 /出力パケットを調べる場合に便利です。

user@R1> show interfaces ge-1/0/0 extensive Physical interface: ge-1/0/0, Enabled, Physical link is Up Interface index:144, SNMP ifIndex:512, Generation:147 Link-level type:Ethernet, MTU:1514, Speed:1000mbps, BPDU Error:None, MAC-REWRITE Error:None, Loopback:Disabled, Source filtering:Disabled, Flow control:Enabled, Auto-negotiation:Enabled, Remote fault:Online, Speed-negotiation:Disabled, Auto-MDIX:Enabled Device flags :Present Running Interface flags:SNMP-Traps Internal:0x0 Link flags :None CoS queues :8 supported, 8 maximum usable queues Hold-times :Up 0 ms, Down 0 ms Current address:5c:5e:ab:00:cd:60, Hardware address:5c:5e:ab:00:cd:60 Last flapped :2012-09-05 19:47:21 UTC (1w4d 23:26 ago) Statistics last cleared:Never Traffic statistics: Input bytes : 1865678156 4600 bps Output bytes : 1849565880 4392 bps Input packets: 35763065 11 pps Output packets: 35313479 10 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Dropped traffic statistics due to STP State: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Input errors: Errors:0, Drops:0, Framing errors:0, Runts:0, Policed discards:0, L3 incompletes:0, L2 channel errors:0, L2 mismatch timeouts:0, FIFO errors:0, Resource errors:0 Output errors:


Carrier transitions:3, Errors:0, Drops:0, Collisions:0, Aged packets:0, FIFO errors:0, HS link CRC errors:0, MTU errors:0, Resource errors:0 Egress queues:8 supported, 4 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 2906 2906 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 35310568 35310568 0 Queue number: Mapped forwarding classes 0 best-effort 1 expedited-forwarding 2 assured-forwarding 3 network-control Active alarms :None Active defects :None MAC statistics: Receive Transmit Total octets 2509372810 2477853994 Total packets 35763067 35313481 Unicast packets 35394125 34944569 Broadcast packets 1434 1470 Multicast packets 367508 367442 CRC/Align errors 0 0 FIFO errors 0 0 MAC control frames 0 0 MAC pause frames 0 0 Oversized frames 0 Jabber frames 0 Fragment frames 0 VLAN tagged frames 0 Code violations 0 Filter statistics: Input packet count 35763055 Input packet rejects 0 Input DA rejects 0 Input SA rejects 0 Output packet count 35313470 Output packet pad count 0 Output packet error count 0 CAM destination filters:0, CAM source filters:0 Autonegotiation information: Negotiation status:Complete Link partner: Link mode:Full-duplex, Flow control:Symmetric/Asymmetric, Remote fault:OK Local resolution: Flow control:Symmetric, Remote fault:Link OK Packet Forwarding Engine configuration: Destination slot:1 CoS information: Direction :Output CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 best-effort 95 950000000 95 0 low none 3 network-control 5 50000000 5 0 low none Interface transmit statistics:Disabled


Logical interface ge-1/0/0.0 (Index 330) (SNMP ifIndex 561) (Generation 139) Flags:SNMP-Traps 0x0 Encapsulation:ENET2 Traffic statistics: Input bytes : 1865678156 Output bytes : 1847343804 Input packets: 35763065 Output packets: 35313479 Local statistics: Input bytes : 25260720 Output bytes : 30300888 Input packets: 370422 Output packets: 370346 Transit statistics: Input bytes : 1840417436 4600 bps Output bytes : 1817042916 4392 bps Input packets: 35392643 11 pps Output packets: 34943133 10 pps Protocol inet, MTU:1500, Generation:160, Route table:0 Flags:Sendbcast-pkt-to-re Addresses, Flags:Is-Preferred Is-Primary Destination:10.254.254.0/30, Local:10.254.254.1, Broadcast:10.254.254.3, Generation:142 Protocol multiservice, MTU:Unlimited, Generation:161, Route table:0 Flags:Is-Primary Policer:Input:__default_arp_policer__

show interfaces <interface-type> extensive | find "queue counters"

このコマンドは、パケットが適切な送信キューにあるかどうかを調べるうえで役立ちます。

user@R1> show interfaces ge-1/0/0 extensive | find "queue counters" Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 2906 2906 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 35311240 35311240 0 Queue number: Mapped forwarding classes 0 best-effort 1 expedited-forwarding 2 assured-forwarding 3 network-control Active alarms :None Active defects :None MAC statistics: Receive Transmit Total octets 2509420312 2477900586 Total packets 35763744 35314145 Unicast packets 35394795 34945226 Broadcast packets 1434 1470 Multicast packets 367515 367449 CRC/Align errors 0 0 FIFO errors 0 0


MAC control frames 0 0 MAC pause frames 0 0 Oversized frames 0 Jabber frames 0 Fragment frames 0 VLAN tagged frames 0 Code violations 0 Filter statistics: Input packet count 35763732 Input packet rejects 0 Input DA rejects 0 Input SA rejects 0 Output packet count 35314134 Output packet pad count 0 Output packet error count 0 CAM destination filters:0, CAM source filters:0 Autonegotiation information: Negotiation status:Complete Link partner: Link mode:Full-duplex, Flow control:Symmetric/Asymmetric, Remote fault:OK Local resolution: Flow control:Symmetric, Remote fault:Link OK Packet Forwarding Engine configuration: Destination slot:1 CoS information: Direction :Output CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 best-effort 95 950000000 95 0 low none 3 network-control 5 50000000 5 0 low none Interface transmit statistics:Disabled

Logical interface ge-1/0/0.0 (Index 330) (SNMP ifIndex 561) (Generation 139) Flags:SNMP-Traps 0x0 Encapsulation:ENET2 Traffic statistics: Input bytes : 1865713264 Output bytes : 1847378386

Input packets: 35763738

show class-of-service forwarding class

このコマンドでは、使用可能なすべてのフォワーディングクラス（デフォルトおよびユーザー定義）に関する情報が得られます。

user@R1> show class-of-service forwarding-class Forwarding class ID Queue Restricted queue Fabric priority Policing priority best-effort 0 0 0 low normal expedited- forwarding 1 1 1 low normal assured- forwarding 2 2 2 low normal network- control 3 3 3 low normal


show configuration class-of-service –

このコマンドでは、デバイスのサービスクラス設定全体が示されます。class-of-serviceの後にキーワードを指定することにより、個々のセクションを表示できます。キーワードとして、classifiers、rewrite-rulesなどを使用できます。

user@R1> show configuration class-of-service classifiers { dscp VOICE-BA-CLASSIFIER { import default; forwarding-class VOICE-EF-CLASS { loss-priority low code-points [ cs5 ef ]; } forwarding-class assured-forwarding { loss-priority low code-points [ cs1 af11 af12 af13 cs2 af21 af22 af23 ]; loss-priority high code-points [ cs3 af31 af32 af33 cs4 af41 af42 af43 ]; } forwarding-class best-effort { loss-priority low code-points be; } forwarding-class network-control { loss-priority low code-points cs7; loss-priority high code-points cs6; } }}forwarding-classes { queue 5 VOICE-EF-CLASS;}interfaces { ge-* { scheduler-map VOICE-SCHED-MAP; unit 0 { classifiers { dscp VOICE-BA-CLASSIFIER; } rewrite-rules { dscp VOICE-DSCP-REWRITE; } } }}rewrite-rules { dscp VOICE-DSCP-REWRITE { import default; forwarding-class VOICE-EF-CLASS { loss-priority low code-point ef; } forwarding-class assured-forwarding { loss-priority low code-point cs3;


loss-priority high code-point cs3; } forwarding-class network-control { loss-priority low code-point cs7; loss-priority high code-point cs6; } forwarding-class best-effort { loss-priority low code-point be; } }}scheduler-maps { VOICE-SCHED-MAP { forwarding-class best-effort scheduler CONTROL; forwarding-class network-control scheduler NC; forwarding-class VOICE-EF-CLASS scheduler EF; forwarding-class assured-forwarding scheduler AF; }}schedulers { EF { buffer-size percent 20; priority strict-high; } CONTROL { transmit-rate remainder; buffer-size { remainder; } priority low; } NC { buffer-size percent 15; priority high; } AF { transmit-rate percent 40; buffer-size percent 40; priority low; }

}

show interfaces queue <interface-type>

このコマンドでは、キューイングおよび送信されたパケット数やバイト数、REDにより破棄されたパケットなど、インタフェースに関連付けられている特定キューの詳細が示されます。

user@R1> show interfaces queue ge-1/0/0 Physical interface: ge-1/0/0, Enabled, Physical link is Up Interface index:144, SNMP ifIndex:512


Forwarding classes:16 supported, 4 in useEgress queues:8 supported, 4 in useQueue:0, Forwarding classes: best-effort Queued: Packets : 2906 0 pps Bytes : 191844 0 bps Transmitted: Packets : 2906 0 pps Bytes : 191844 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bpsQueue:1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bpsQueue:2, Forwarding classes: assured-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps Transmitted: Packets : 0 0 pps Bytes : 0 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps


Medium-high : 0 0 bps High : 0 0 bpsQueue:3, Forwarding classes: network-control Queued: Packets : 35312968 11 pps Bytes : 3184095280 8216 bps Transmitted: Packets : 35312968 11 pps Bytes : 3184095280 8216 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps

show firewall

Junosでは、ファイアウォールフィルタに「count」が有効になっている条件がある場合、そのカウンターが示されます。また、ファイアウォールに countキーワードを持つポリサーが含まれている場合は、すべてのポリサーカウンターが有効になり、show firewallの下に表示されます。以下に例を示します。

ファイアウォールフィルタの設定例 filter CoS-count--ge-1/1/4_inbound { term 00 { from { dscp 000000; } then count dscp-00; } term 01 { from { dscp 000001; } then count dscp-01; } term 02 { from { dscp 000002; } then count dscp-02; } term 03 { from {


dscp 000003; } then count dscp-03; } term 04 { from { dscp 000004; } then count dscp-04; } term 05 { from { dscp 000005; } then count dscp-05; } term else-accept { then accept; } }

Output

user@R1> show firewall

Filter:__default_bpdu_filter__

Filter:CoS-count--ge-1/1/4_inbound Counters:Name Bytes Packetsdscp-00 14000 100dscp-01 0 0dscp-02 0 0dscp-03 0 0dscp-04 0 0dscp-05 0 0

Filter:TCM_PLP-count--ge-1/0/4_outbound Counters:Name Bytes PacketsPLP-high 0 0PLP-low 15180 114PLP-med-high 0 0

Filter:FC_PLP-count--ge-1/0/4_outbound Counters:Name Bytes PacketsBE-data-high 0 0BE-data-low 0 0Pri-data-high 0 0Pri-data-low 0 0Voice-high 0 0Voice-low 0 0


Filter: my_MF_filter-ge-1/0/0.0-i Counters:Name Bytes Packetstcp-count-ge-1/0/0.0-i 0 0tcp80-count-ge-1/0/0.0-i 14000 100udp-count-ge-1/0/0.0-i 0 0Policers:Name Packets my-2color-policer-tcp-ge-1/0/0.0-i 0

show configuration interface <interface-type>

このコマンドでは、特定のインタフェースで設定されているファイアウォールフィルタ、MFクラシファイア、またはポリサーが示されます。

user@R1>show configuration interface ge-1/0/0 { unit 0 { family inet { filter { input RTP-INPUT-FILTER; } address 10.254.20.1/30; } }}

show configuration class-of-service interfaces

このコマンドは、インタフェースに適用されているBAクラシファイア、リライトルール、またはスケジューラマップを調べるうえで役立ちます。

user@R1> show configuration class-of-service interfaces ge-1/0/6 { scheduler-map scheduler-map-core; unit 0 { classifiers { dscp DSCP-BA; exp EXP-BA; } rewrite-rules { dscp DSCP-BA; exp EXP-BA; } }}


clear interfaces statistics all

このコマンドにより、読み取り前にすべてのインタフェースカウンターがクリアされます。

user@R1> show interfaces ge-2/0/0 extensive Physical interface: ge-2/0/0, Enabled, Physical link is Up Interface index:134, SNMP ifIndex:1730, Generation:137 Link-level type:Ethernet, MTU:1514, Speed:1000mbps, BPDU Error:None, MAC-REWRITE Error:None, Loopback:Disabled, Source filtering:Disabled, Flow control:Enabled, Auto-negotiation:Enabled, Remote fault:Online Device flags :Present Running Interface flags:SNMP-Traps Internal:0x4000 Link flags :None CoS queues :8 supported, 8 maximum usable queues Hold-times :Up 0 ms, Down 0 ms Current address:00:1d:b5:49:b3:fc, Hardware address:00:1d:b5:49:b3:fc Last flapped :2010-07-07 07:44:37 PDT (4w6d 11:28 ago) Statistics last cleared:2010-08-10 19:10:48 PDT (00:02:24 ago) Traffic statistics: Input bytes : 112972 7408 bps Output bytes : 114162 6848 bps Input packets: 1610 13 pps Output packets: 1627 12 pps IPv6 total statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Ingress traffic statistics at Packet Forwarding Engine: Input bytes : 113198 7104 bps Input packets: 1613 12 pps Drop bytes : 0 0 bps Drop packets: 0 0 pps Input errors: Errors:0, Drops:0, Framing errors:0, Runts:0, Policed discards:0, L3 incompletes:0, L2 channel errors:0, L2 mismatch timeouts:0, FIFO errors:0, Resource errors:0 Output errors: Carrier transitions:0, Errors:0, Drops:0, Collisions:0, Aged packets:0, FIFO errors:0, HS link CRC errors:0, MTU errors:0, Resource errors:0 Ingress queues:8 supported, 4 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 1613 1613 0 Egress queues:8 supported, 4 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 1615 1615 0 Queue number: Mapped forwarding classes


0 best-effort 1 expedited-forwarding 2 assured-forwarding 3 network-control Active alarms :None Active defects :None MAC statistics: Receive Transmit Total octets 112972 114162 Total packets 1610 1627 Unicast packets 1593 1610 Broadcast packets 0 0 Multicast packets 17 17 CRC/Align errors 0 0 FIFO errors 0 0 MAC control frames 0 0 MAC pause frames 0 0 Oversized frames 0 Jabber frames 0 Fragment frames 0 VLAN tagged frames 0 Code violations 0 Filter statistics: Input packet count 1610 Input packet rejects 0 Input DA rejects 0 Input SA rejects 0 Output packet count 1627 Output packet pad count 0 Output packet error count 0 CAM destination filters:0, CAM source filters:0 Autonegotiation information: Negotiation status:Complete Link partner: Link mode:Full-duplex, Flow control:Symmetric/Asymmetric, Remote fault:OK Local resolution: Flow control:Symmetric, Remote fault:Link OK Packet Forwarding Engine configuration: Destination slot:2 CoS information: Direction :Output CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 best-effort 95 950000000 95 0 low none 3 network-control 5 50000000 5 0 low none Direction :Input CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 best-effort 95 950000000 95 0 low none 3 network-control 5 50000000 5 0 low none

Logical interface ge-2/0/0.0 (Index 69) (SNMP ifIndex 1733) (Generation 134) Flags:SNMP-Traps Encapsulation:ENET2 Traffic statistics: Input bytes : 112904


Output bytes : 114024 Input packets: 1610 Output packets: 1626 Local statistics: Input bytes : 1156 Output bytes : 1394 Input packets: 17 Output packets: 17 Transit statistics: Input bytes : 111748 7408 bps Output bytes : 112630 6848 bps Input packets: 1593 13 pps Output packets: 1609 12 pps Protocol inet, MTU:1500, Generation:145, Route table:0 Flags:Sendbcast-pkt-to-re Addresses, Flags:Is-Preferred Is-Primary Destination:10.254.254.0/30, Local:10.254.254.2, Broadcast:10.254.254.3, Generation:144 Protocol multiservice, MTU:Unlimited, Generation:146, Route table:0 Flags:Is-Primary Policer:Input:__default_arp_policer__

{master}

user@R1> clear interfaces statistics all

{master}user@R1> show interfaces ge-2/0/0 extensive Physical interface: ge-2/0/0, Enabled, Physical link is Up Interface index:134, SNMP ifIndex:1730, Generation:137 Link-level type:Ethernet, MTU:1514, Speed:1000mbps, BPDU Error:None, MAC-REWRITE Error:None, Loopback:Disabled, Source filtering:Disabled, Flow control:Enabled, Auto-negotiation:Enabled, Remote fault:Online Device flags :Present Running Interface flags:SNMP-Traps Internal:0x4000 Link flags :None CoS queues :8 supported, 8 maximum usable queues Hold-times :Up 0 ms, Down 0 ms Current address:00:1d:b5:49:b3:fc, Hardware address:00:1d:b5:49:b3:fc Last flapped :2010-07-07 07:44:37 PDT (4w6d 11:29 ago) Statistics last cleared:2010-08-10 19:13:54 PDT (00:00:02 ago) Traffic statistics: Input bytes : 1540 6160 bps Output bytes : 1540 6720 bps Input packets: 22 11 pps Output packets: 22 12 pps IPv6 total statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0


Ingress traffic statistics at Packet Forwarding Engine: Input bytes : 1906 6064 bps Input packets: 27 10 pps Drop bytes : 0 0 bps Drop packets: 0 0 pps Input errors: Errors:0, Drops:0, Framing errors:0, Runts:0, Policed discards:0, L3 incompletes:0, L2 channel errors:0, L2 mismatch timeouts:0, FIFO errors:0, Resource errors:0 Output errors: Carrier transitions:0, Errors:0, Drops:0, Collisions:0, Aged packets:0, FIFO errors:0, HS link CRC errors:0, MTU errors:0, Resource errors:0 Ingress queues:8 supported, 4 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 27 27 0 Egress queues:8 supported, 4 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 14 14 0 Queue number: Mapped forwarding classes 0 best-effort 1 expedited-forwarding 2 assured-forwarding 3 network-control Active alarms :None Active defects :None MAC statistics: Receive Transmit Total octets 1540 1540 Total packets 22 22 Unicast packets 22 22 Broadcast packets 0 0 Multicast packets 0 0 CRC/Align errors 0 0 FIFO errors 0 0 MAC control frames 0 0 MAC pause frames 0 0 Oversized frames 0 Jabber frames 0 Fragment frames 0 VLAN tagged frames 0 Code violations 0 Filter statistics: Input packet count 22 Input packet rejects 0 Input DA rejects 0 Input SA rejects 0 Output packet count 22 Output packet pad count 0 Output packet error count 0


CAM destination filters:0, CAM source filters:0 Autonegotiation information: Negotiation status:Complete Link partner: Link mode:Full-duplex, Flow control:Symmetric/Asymmetric, Remote fault:OK Local resolution: Flow control:Symmetric, Remote fault:Link OK Packet Forwarding Engine configuration: Destination slot:2 CoS information: Direction :Output CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 best-effort 95 950000000 95 0 low none 3 network-control 5 50000000 5 0 low none Direction :Input CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 best-effort 95 950000000 95 0 low none 3 network-control 5 50000000 5 0 low none

Logical interface ge-2/0/0.0 (Index 69) (SNMP ifIndex 1733) (Generation 134) Flags:SNMP-Traps Encapsulation:ENET2 Traffic statistics: Input bytes : 1540 Output bytes : 1540 Input packets: 22 Output packets: 22 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 1540 6096 bps Output bytes : 1540 6648 bps Input packets: 22 10 pps Output packets: 22 11 pps Protocol inet, MTU:1500, Generation:145, Route table:0 Flags:Sendbcast-pkt-to-re Addresses, Flags:Is-Preferred Is-Primary Destination:10.254.254.0/30, Local:10.254.254.2, Broadcast:10.254.254.3, Generation:144 Protocol multiservice, MTU:Unlimited, Generation:146, Route table:0 Flags:Is-Primary Policer:Input:__default_arp_policer__


まとめどのネットワークでも、QoSを設計するときは、入念なプランニングが不可欠です。すべての要件を収集したら、後はそれをデバイスに実装するだけです。これまでの章で説明してきたステップは典型的なもので、EX、M、MX、SRXシリーズのデバイスなどあらゆる Junosプラットフォームで使用できます。また、トラブルシューティングに使用できる強力なツールも多数用意されており、ネットワークにQoSを導入する際にはこれらのツールが役立つはずです。最後に、Junos CLIはCisco CLIとは異なりますが、設定を調整することにより、QoSに関して同様の結果を得ることができます。


70

次のステップと参照 URL

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コミュニケーションフォーラムは、ジュニパー製品、テクノロジー、およびソリューションに関する情報、ベストプラクティス、および疑問点を共有するための場です。この無料のフォーラムに参加するには、登録が必要です。

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

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

Documents

Day One IOSエンジニア向けJunos QoS6 Day One ：IOSエンジニア向けJunos QoS 自宅で、ハイビジョンのNetflix ムービーをラップトップで観ながら、