はじめに
GREやIPsecといったトンネルリングを行う際にQoSを併用すると、既存パケットの情報に基づきクラス分けをすることができない といった弊害を伴います。
これはqos pre-classifyを使用することで回避できます。
qos pre-classifyとは、カプセル化する前の情報をコピー(保存)しておくことで、その情報を基にクラス分けが可能となる設定です。
今回はqos pre-classifyの設定有無における動作の差異と、設定箇所における動作の差異を検証していきます。
構成図
Pre-Config
検証内容
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