トンネルインターフェースでのQoS

はじめに

GREやIPsecといったトンネルリングを行う際にQoSを併用すると、既存パケットの情報に基づきクラス分けをすることができない といった弊害を伴います。

これはqos pre-classifyを使用することで回避できます。

qos pre-classifyとは、カプセル化する前の情報をコピー(保存)しておくことで、その情報を基にクラス分けが可能となる設定です。

今回はqos pre-classifyの設定有無における動作の差異と、設定箇所における動作の差異を検証していきます。

構成図

Pre-Config

RT1

RT2

RT3

検証内容

RT2では以下のpolicy-mapを定義し、Eth0/1にoutboundで適用しています。

RT1(1.1.1.1/32)からRT3(3.3.3.3/32)に対してpingを実行し、どのクラスで処理されるかを3つの方法で検証します。

・qos pre-classifyなし

・qos pre-classifyをTunnel I/Fに設定

・qos pre-classifyをcrypto mapに設定

qos pre-classifyなし

RT1からRT3にpingを実行します。

RT2で確認すると、クラス espに分類されていることがわかります。

qos pre-classifyをTunnel I/Fに設定

RT2のTunnel 0にpre-classifyを設定します。

RT1からRT3にpingを実行します。

RT2で確認すると、クラス icmpに分類されていることがわかります。

qos pre-classifyをcrypto mapに設定

RT2のTunnel I/Fからqos pre-classifyを削除し、crypto mapに設定します。

また、SAを確率した後にcrypto mapの設定を変更した場合は、設定を反映させるためにSAを再確立する必要があります。

RT1からRT3にpingを実行します。

RT2で確認すると、クラス greに分類されていることがわかります。

まとめ

3つのパターンでそれぞれ期待した結果を得ることができました。

今回の構成では、GREでカプセル化された後にESPでカプセル化(暗号化)されます。

Tunnel I/Fでqos pre-classifyを設定した場合はGREでカプセル化される前のパケットの情報(icmp)をコピー(保存)し、その情報に基づきクラス分けを行います。そのため、クラス icmpに分類されていました。

crypto mapでqos pre-classifyを設定した場合はESPでカプセル化される前のパケット情報(gre)をコピーし、その情報に基づきクラス分けを行います。そのため、クラス greに分類されていました。

一般的なQoSはGREでカプセル化する前のオリジナルパケットの情報に基づき分類し、QoSを適用することが多いかと思いますので、この結果にある通りTunnel I/Fにqos pre-classifyを適用いただくことが良いかと思います。

また補足ですが、ToS(IP PrecedenceやDSCP)は既存IPヘッダーからqos pre-classifyの設定に関係なくカプセル化の際に付与されるIPヘッダーにコピーされます。

Reference

Troubleshooting TechNotes : Quality of Service Options on GRE Tunnel Interface

シェアする

フォローする

関連コンテンツ