前回は簡単にMeraki MXのQoS設定についてまとめてみました。
DSCP値EFが付いているパケットは自動でLow-Latency Queue(LLQ)に割り当てられるのですが、トラフィックシェーピングルールで上書きする設定がされた場合にどのように動作するのかを確認してみます。
Webex Callingを使って確認
今回の検証はWebex Callingを使って行ってみます。
Webex Callingにおける音声通信(RTP)はDSCP値はEFでマーキングされる(はず)ので、Meraki MXのトラフィックシェーピングルールでDSCP値をリマークして確認してみます。
まずは通常のフローを確認してみます。
Meraki MXを通過し、WAN側のポートでPacket Captureを行いました。
RTPに関してはDSCP値がEFとしてマーキングされていることが分かります。
DSCP値をトラフィックシェーピングルールでリマーク
Webex CallingのRTPのDSCP値をリマークする設定を行います。
まずはWebex Callingの通信要件を確認しておきます。
Meraki MXのトラフィックシェーピングルールではDest IP、Port#で設定が可能なのですが、Portのレンジでは設定できないのでDest IPにて設定するしかないようです。
Webex Callingで指定されているサブネットをMeraki MXに設定を行います。
「セキュリティ&SD-WAN > 設定 > SD-WAN&トラフィクシェーピング」へ移動し設定を行います。
上記Webex Callingの全てのサブネットを設定し、検証用途としてDSCP値をAF42に設定します。
この設定の状態で再びRTPパケットを確認してみます。
上記で設定したDSCP値AF42に変更となっていることが確認されました。
これによりトラフィックシェーピングルールで設定されたルールにおいては自動で適用されるLLQよりも優先されるということになりました。
まとめ
残念ながらMeraki管理者はMXのどのキューがどれくらい使われているのかを確認する方法はありません。
しかしながら今回の検証でDSCP値EFを持ったパケットにおいても「トラフィックシェーピング」ルールで上書き設定を行うことによってLLQを使わない設定にすることが可能であると判断して良いと思います。
これにより企業にて認められていないアプリケーションがDSCP値EFを使って通信を行っているような場合は優先順位を下げるために今回のような設定を行うことにより本当に優先したいRTPパケットの帯域を確保することが可能になると思います。
