YAMAHA RTX の QoS 設定｜queue による優先制御と帯域制御

はじめに

YAMAHA RTX シリーズは、拠点や小規模拠点のルータとして広く使われています。QoS を設定する場合、RTX では queue コマンドを中心とした独自の体系を用います。

つまずきやすいのは、優先制御（priority）・CBQ・シェーピング（shaping）のどの方式を選ぶか、queue class filter でどう分類するか、という点です。さらに、利用できる方式はインタフェース（LAN / PP）や機種によって異なるため、設定例をそのまま流用すると意図どおりに動かないことがあります。本記事では、RTX の QoS の全体像を整理したうえで、設定方法と、効かないときの確認までを扱います。

なお、QoS そのものの全体像（分類・マーキング・キューイング・帯域制御の役割や、優先制御の設計の考え方）は、関連記事『QoS とは｜優先制御の仕組みと製品共通で押さえる設計のポイント』で扱っています。本記事は、その考え方を RTX の設定に落とし込む位置づけです。

YAMAHA RTX の QoS（優先制御）の全体像

RTX の QoS は、「パケットをクラスに分類する」ことと「インタフェースごとに処理方式を選ぶ」ことの組み合わせで構成されます。まずはこの 2 つの軸を整理します。

queue による QoS の考え方（type と class filter）

RTX の QoS 設定は、おおむね次の 2 段階で組み立てます。

クラス分け（分類）

queue class filter でパケットをクラスに振り分け、queue interface class filter list でそのフィルタをインタフェースに適用します。

処理方式の選択

queue interface type で、優先制御・帯域制御・単純 FIFO などの処理アルゴリズムをインタフェースごとに選びます。

参考: YAMAHA — RTX シリーズ コマンドリファレンス（優先制御／帯域制御）
「パケットの処理アルゴリズムは、queue interface type コマンドにより、優先制御、帯域制御、単純 FIFO の中から選択します」
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/queue/queue_chapter.html

クラスは番号で識別し、利用できる数は機種により異なります。多くのモデルでは 1〜16、RTX5000・RTX3500 では 1〜100、RTX3510 では 1〜250 です。クラスは番号が大きいほど優先順位が高くなる点に注意します。なお、分類は IP アドレスやプロトコルなどの条件のほか、precedence（TOS）や DSCP に基づいても行えます（後述）

「queue class filter で分類し、queue interface type で処理方式を選ぶ」という 2 段構成を押さえておくと、次のセクション以降の設定が整理しやすくなります。

priority / CBQ / shaping の違いと選び方

queue interface type で選べる主な処理方式は、次のとおりです。

優先制御（priority）

優先順位の高いクラスのパケットを先に送出し、そのキューが空になると次の順位のキューを送出します。VoIP など遅延に弱い通信を優先したい場合に適しています。

CBQ（帯域制御）

クラスごとに帯域を割り当てる方式です。queue interface class property で各クラスに割り振る帯域を設定します。

シェーピング（shaping）

帯域に上限を設けて送出を整える方式です。シェーピング指定時は、保証帯域と上限帯域を指定する Dynamic Traffic Control（動的トラフィック制御）も利用できます。

利用できる方式は、インタフェース（LAN / PP）や機種によって異なります。一般に、LAN インタフェースでは優先制御やシェーピング、PP インタフェースでは優先制御や CBQ が利用できます。対応はモデル・ファームウェアにより異なるため、対象機種の公式ドキュメントでの確認を推奨します。

方式の選び方について、YAMAHA の FAQ では、VoIP を他のトラフィックより優先したいだけであれば優先制御が適切で、帯域制御を使う場合は「他のトラフィックに割り当てる帯域に上限を与える」設定が有効、という指針が示されています。多くの場合は優先制御（priority）で十分で、特定の通信に帯域の上限を設けたい場合にシェーピングや CBQ を検討する、という整理がわかりやすいです。

なお、RTX5000・RTX3510・RTX3500 などの上位機種では、クラス構造を 2 階層にし、1 階層目に帯域制御または優先制御、2 階層目に優先制御を組み合わせることもできます。

queue による優先制御の設定（priority queuing）

RTX で最もよく使われるのが優先制御（priority）です。「queue class filter で分類 → queue interface type priority で方式を指定 → queue interface class filter list で適用」という流れで設定します。

queue type priority の設定

優先制御は、クラスごとに優先順位をつけ、優先順位の高いキューから順にパケットを送出する方式です。

参考: YAMAHA — RTpro QoS ドキュメント（優先制御）
「優先制御では、リアルタイム性が重視されるデータやロスを最小限に抑えたいデータを、その他のデータよりも優先して送ることができます」
https://www.rtpro.yamaha.co.jp/RT/docs/qos/priority.html

設定の骨格は次のとおりです（LAN2 を WAN 側、優先制御の対象とする例）。speed で回線速度を指定しておくと、制御の基準が明確になります。

speed lan2 100m
queue lan2 type priority
queue lan2 class filter list 1 2 3

queue lan2 type priority で処理方式を優先制御にし、queue lan2 class filter list で適用するフィルタ（次項で定義）を並べます。PP インタフェースに適用する場合は、pp select 1 のうえで queue pp class filter list ... を用います。

class filter による分類と優先度の割り当て

クラス分けは queue class filter で定義します。基本の構文は次のとおりです。

参考: YAMAHA — RTX シリーズ コマンドリファレンス（クラス分けのためのフィルター設定）
「queue class filter num class1[/class2] [cos=cos] ip src_addr [dest_addr [protocol [src_port [dest_port]]]]」
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/queue/queue_class_filter.html

num はフィルタ番号、class1 はクラス番号です。クラスは番号が大きいほど優先順位が高く、queue class filter で明示されないパケットは既定でクラス 2 に入ります。VoIP（SIP）を高い優先度（クラス 5）に、それ以外を既定（クラス 2）にする例は次のとおりです。

queue class filter 1 5 ip * * udp 5060 *
queue class filter 2 5 ip * * udp * 5060
queue class filter 3 2 ip * *

この 3 つのフィルタを、前項の queue lan2 class filter list 1 2 3 で LAN2 に適用します。なお、queue class filter 3 2 ip * *（既定クラスの明示）は動作上は必須ではありませんが、設定として明記しておくと管理上わかりやすくなります。precedence や DSCP に基づく分類は、後続のセクションで扱います。

CBQ・shaping による帯域制御

特定の通信に帯域の上限や保証を与えたい場合は、CBQ またはシェーピング（shaping）を用います。利用できる方式はインタフェースにより異なり、CBQ は PP インタフェース、シェーピングは LAN インタフェースで設定します。

CBQ（クラスごとの帯域配分）

CBQ（Class-Based Queueing）は、クラスごとに帯域の割合（または絶対値）を割り当てる方式です。優先制御と異なりクラス間に優先順位はなく、制御できるのは出力トラフィックのみです。特定のホスト群に回線の 70% を与え、その他を 30% にする例は次のとおりです。

queue class filter 1 1 ip 192.168.1.0/24 * * * *
pp select 1
queue pp type cbq
queue pp class property 1 bandwidth=70%
queue pp class property 2 bandwidth=30%
queue pp class filter list 1
pp select none

クラス 2 は既定クラスで、フィルタにマッチしない通信が入ります。帯域を借りない設定（borrow=off）を加えると、そのクラスの最大速度は bandwidth の値に固定され、特定の通信の帯域を抑えたい場合に有効です。bandwidth は 70% のような割合のほか、5m のような絶対値でも指定できます。

shaping による帯域制限

シェーピングは、LAN インタフェースで帯域を整える方式です。queue interface type shaping を指定した場合、保証帯域と上限帯域を扱う Dynamic Traffic Control（動的トラフィック制御）が利用できます。

参考: YAMAHA — RTX シリーズ コマンドリファレンス（クラスの属性の設定）
「Dynamic Traffic Control を行うためには、bandwidth パラメータに「,」（コンマ）でつないだ 2 つの速度を指定することで、保証帯域と上限帯域を設定する」
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/queue/queue_interface_class_property.html

設定例は次のとおりです。bandwidth=30m,50m は保証帯域 30 Mbps・上限帯域 50 Mbps を表します（記述順に関係なく、小さい方が保証帯域）

speed lan2 100m
queue lan2 type shaping
queue lan2 class filter list 1 2
queue lan2 class property 1 bandwidth=30m,50m
queue lan2 class property 2 bandwidth=20m,50m
queue class filter 1 1 ip 192.168.10.0/24 * * * *
queue class filter 2 2 ip * *

保証帯域の合計が回線全体の帯域を超えないように設定する点に注意します。なお、Dynamic Traffic Control の対応は機種・ファームウェアにより異なるため、対象機種の公式ドキュメントでの確認を推奨します。整理すると、優先したいだけなら優先制御（priority）、特定の通信に帯域の上限や保証を与えたい場合に CBQ やシェーピングを選ぶ、という使い分けになります。

DSCP / TOS の扱い

RTX では、IP ヘッダの precedence（TOS）や DSCP を使ってクラス分けを行えます。これにより、上流や下流の機器が付与したマーキングに応じた優先制御が可能になります。

precedence / DSCP の参照とマーキング

クラス分けは、queue class filter の CLASS パラメータに、クラス番号の代わりに precedence または dscp を指定して行います。precedence を用いる方式は TOS ベース QoS、DSCP を用いる方式は DiffServ ベース QoS と呼ばれます。

参考: YAMAHA — RTpro QoS ドキュメント（TOS ベース QoS）
「TOSベースQoSは、転送するパケットのIPヘッダのTOSフィールド中の3ビットのprecedence値を参照し、precedence値に応じてパケットをクラス分けするQoSです」
https://www.rtpro.yamaha.co.jp/RT/docs/qos/tos_qos.html

設定例は次のとおりです。precedence 形式では precedence 値（0〜7）に応じてクラス（1〜8）へ、dscp 形式では DSCP 値が定義する PHB に応じてクラス（1〜9）へ分類します。

queue class filter 5 precedence ip 172.16.5.0/24 * tcp * *
queue class filter 10 dscp ip 172.16.10.0/24 *

precedence 値からクラスへの対応は、mapping オプションで変更できます。たとえば次の例は、precedence 値 1 をクラス 8、precedence 値 4 をクラス 3 に変換します。

queue class filter 1 precedence mapping=1:8,4:3 ip *

マーキングについては、cos= オプションを使うと、フィルタに合致したパケットに付加される IEEE 802.1Q タグの user_priority フィールド（CoS）に、指定した値を格納できます。

queue class filter 1 4 cos=5 ip * * udp 5060 *

RTX の queue 機能は、precedence / DSCP の「参照（分類）」と、CoS（レイヤ 2）の書き込みに対応します。 DSCP 値そのものの書き換え可否や、TOS / DiffServ ベース QoS の対応インタフェース（LAN、LAN 上の PPPoE・トンネルなど）は機種・ファームウェアにより異なるため、対象機種の公式ドキュメントでの確認を推奨します。

よくあるトラブルと対処

設定したのに優先制御が効かない場合、設定値よりも、適用漏れや方式・方向の前提に原因があることが少なくありません。show status qos all の出力を起点に切り分けると、原因を絞り込みやすくなります。

優先制御が効かないときの確認ポイント

代表的な原因は次のとおりです。

適用漏れ

queue interface type で方式を選んでいても、queue interface class filter list でフィルタを適用していないと分類が反映されません。両方の設定がそろっているかを確認します。

方式とインタフェースの不一致

CBQ は PP インタフェース、シェーピングは LAN インタフェース、というように、利用できる方式はインタフェースや機種により異なります。

クラス番号の優先順位の誤解

クラスは番号が大きいほど優先順位が高く、明示しないパケットは既定でクラス 2 に入ります。

そもそも輻輳していない

優先制御は輻輳時にはじめて効くため、平常時の確認では差が現れません。

制御方向の前提

RTX が制御できるのは出力方向です。

参考: YAMAHA — RT シリーズ FAQ（Queue / CBQ）
「制御できるのは出力トラフィックだけです。入力トラフィックを制御することはできませんので、そのような場合には接続相手のルータを設定する必要があります」
https://www.rtpro.yamaha.co.jp/RT/FAQ/Queue/queue-type-cbq.html

このため、ダウンロード方向（WAN → LAN）の通信を制御したい場合は、対向側の機器での設定が必要になります。自機を通過して出ていく方向（LAN → WAN）の制御が中心になる点を踏まえて設計します。

show コマンドでの確認

キューイングの状態は、show status qos all で確認します。インタフェースごとのキューイングタイプ、クラスごとの設定帯域・使用帯域・ピーク、キュー長（エンキュー回数の成功／失敗、デキュー回数など）が表示されます。

> show status qos all
LAN2  キューイングタイプ: priority  インタフェース速度: 1g
 [帯域]
 クラス  設定帯域  使用帯域(%)   ピーク   記録日時
   1       -       1.03k(<1%)   187m    ...
   2       -       5.91k(<1%)   90.6m   ...
 [キュー長]
 クラス  上限   エンキュー回数(成功/失敗)  デキュー  現在  ピーク
   1     600    25326/0                  25326     0    83

エンキュー回数の「失敗」がキュー溢れによる廃棄の目安になります。優先したいクラスで失敗が増えている場合は、クラス分けや帯域配分を見直します。あわせて、実際にパケットへ付与された DSCP / CoS 値をパケットキャプチャで確認すると、分類と配分のどちらに原因があるかを切り分けられます。キャプチャでの絞り込み方法は、関連記事『Wireshark のフィルタ書き方と複数条件の使い分け｜TCP 再送と HTTP エラーの追跡』で扱っています。

まとめ

• RTX の QoS は queue コマンドで、「queue class filter で分類 → queue interface type で方式選択 → class filter list で適用」の流れで設定します。
• 処理方式は優先制御（priority）・CBQ・シェーピングがあり、利用できるものはインタフェースや機種により異なります。
• クラスは番号が大きいほど優先順位が高く、明示しないパケットは既定でクラス 2 に入ります。
• 多くの場合は優先制御で十分で、帯域に上限・保証を与えたい場合に CBQ やシェーピング（Dynamic Traffic Control）を用います。
• precedence / DSCP による分類（TOS・DiffServ ベース QoS）や、cos= による CoS マーキングに対応します。
• 制御できるのは出力方向で、下り方向は対向機器側での設定が必要です。
• 効かないときは適用漏れ・方式・方向を確認し、show status qos all でキューの状態と廃棄を確認します。

以上、最後までお読みいただきありがとうございました。