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

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

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

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

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

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

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

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

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

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

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

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ヘッダーにコピーされます。