今回は久しぶりのSystems Managerに絡む話をしたいと思います。
Cisco社はApple社と連携してFast Laneと呼ばれる技術的な取り組みを行っています。
このFast LaneですがInternet上を検索してもイマイチはっきりとは分かりません。
Ciscoの技術情報といえばCisco Liveの資料となるのですが、これまた腹に落ちるような技術資料を見つけることができていません。
こうなってしまっては仕方ないので実際に設定を行い動作確認をしてみることにしました。
無線アクセスポイントとしてMeraki MRを使用しています。
そもそも無線LAN環境におけるQoSとは？
まずは無線LANにおけるQoSに関して簡単にまとめておきます。
1.Downstream
無線APからクライアント方向への通信(Downstream)はWMM(Wireless Multimedia)と呼ばれる機能を使ってQoSが提供されています。
このWMMはIEEE802.11eの一部として標準化をされていますので、どのようなメーカーの製品であっても(サポートされていれば)同様に動作する機能となっています。
もちろんCiscoおよびMerakiの各無線APはWMMをサポートしていいます。
無線APは無線で送信するパケットのDSCP値を参照し、4つのアクセス・カテゴリ(AC)に分類します。
| RFC4594 | DSCP | WMM AC |
| Voice + DSCP-Admit | EF + 44 | Voice AC (AC_VO) |
| Broadcast Video | CS5 | Video AC (AC_VI) |
| Multimedia Conferencing | AF4n | Video AC (AC_VI) |
| Realtime Interactive | CS4 | Video AC (AC_VI) |
| Multimedia Streaming | AF3n | Video AC (AC_VI) |
| Signaling | CS3 | Video AC (AC_VI) |
| Transactional Data | AF2n | Best Effort AC (AC_BE) |
| OAM | CS2 | Best Effort AC (AC_BE) |
| Bulk Data | AF1n | Background AC (AC_BK) |
| Scavenger | CS1 | Background AC (AC_BK) |
| Best Effort | DF | Best Effort AC (AC_BE) |
「AC_VO > AC_VI > AC_BE > AC_BK」の順に帯域が割り当てられます。
2.Upstream
一方でクライアントから送信される通信(Upstream)に関してはクライアント側の実装によるとしか言えません。
iPhoneにWebexアプリをいれてWebex Callingにて通話を行い、Packcet Captureを行いUpstream方向のパケットを見てみます。
Webex CallingによるRTPはDSCP EFとしてマーキングされていることがわかります。
MRにて無線部分のキャプチャも行っておきます。
WMMのQoSとしてVoice(AC_VO)がマーキングされています。
Default設定においては正しいAC値でマーキングされないと言う話もあるようですが、私の検証では正しくVoiceとしてマーキングされているように見えました。
これはMeraki MRでは自動でFast Laneが有効になっているためです。
詳細は後述しますが、iOSはデフォルトではDSCPマーキングを行わないのですが、Cisco(Meraki)とApple Deviceが連携することによってQoSマーキングがされるようになrます。
Windows OSでDSCP値をマーキングする場合はGPOでDSCPのマーキングを許可する必要があります。
残念ながら私の環境でWindowsを用意することがすぐには出来そうに無いのでここでは参考として記述のみしておきます。
また、AndroidにおいてもDSCP値はマーキングされるようです。
Fast Laneとは？
上記の結果から自動でFastLaneが有効になるためiOSデバイスに関してはAppが意図したDSCP値で正しくマーキングして送信されるので一見何の問題も無いと思います。
スマートフォン(ここではiPhone)はユーザ自身が簡単にAppをダウンロード、インストールして利用することが可能です。
企業NWにおいてIT部門が認識していないAppをユーザ(社員)がインストールして使うことも多いと思います。
このようなIT部門が認識していないAppがそれぞれでDSCP値をマーキングしてNetwork上にPacketを送信してしまっては企業Network内のQoS設定が正しく機能しなくなる可能性が発生し、本来優先したかったトラフィックに影響が出てしまう場合があります。
そのようなことを回避するために本当に優先させたいAppの通信のみ最優先(Fast Lane)とし、残りのトラフィックに関してはプライオリティを下げて通信させる機能をCisco社とApple社はFast Lane機能として実装をしたのです。
Systems Managerの設定
Fast Lane機能を有効にするために、今回はMeraki Systems Managerを使いました。
「システムマネージャ > 管理 > 設定」へ移動します。
今回は新たにProfileを作成します。
「Wi-Fi Settings」を追加し設定を行います。
Fast Laneを有効にしたいSSID名およびPSK等設定を行います。
設定画面一番下の「シスコ高速レーン」から設定を行います。
まずは「QoSマーキングを制限」に設定してみます。
今回はFast Laneの検証となりますので、この設定の後のデバイスへの適用設定に関しては割愛します。
作成したProfileがiPhoneに反映されているか確認を行います。
iPhoneの「設定 > 一般 > VPNとデバイス管理」からインストールされたProfileの情報を確認します。
「Wifi Settings」の中では「QoSマーキングポリシー」が「いいえ」(無効)となっています。
再びWebex Callingでの通話でDSCP値を確認してみます。
まさかのDSCP Unknown(11)としてマーキングされています。
私の予想ではCS0となっているのかと想像していましたが、一般的に規定されていない11(10進)となっていました。
下手にCS0にしてしまうのではなく、意図的に変えた11にしているのではないでしょうか。
この設定ではiPhoneから送信されるすべてのPacketのDSCP値がクリアされたことになります。
無線部分も確認してみます。
何故かWMMにおいてVoiceが適用されています。
本来であればAC_VOとなるはずでは無いので謎ですが、本件に関して再試験も含めて継続して確認したいと思っています。
Webex Appの通信のみFast Laneで優先する
次にWebex Appのみ優先を行う設定を行います。
これはITが意図的に優先度を上げて通信させたいAppとしてWebexが挙げられていることを想定しています。
Systems ManagerのFast Lane設定にWebexを追加します。
Webexアプリを選択するためには事前にアプリリストに登録しておく必要がありますが、ここでは割愛します。
端末にProfileが適用されていることを確認します。
先程は表示されていなかなったWebex App(表記上はsquared)が「トラフィックマーキングされたApp」として追加されています。
この状態で再び確認を行います。
今度は再びDSCP値EFとして確認することができました。
無線部分のキャプチャも確認しておきます。
WMMのACはVoiceとして扱われています。
まとめ
今回の検証によりiOSデバイスによるFast Laneを使ったDSCP値の挙動の変化を確認することができました。
WMMのマーキングに関してはFast Lane設定でOFFにしたにも関わらずAC_VOとして扱われている件に関してはこれで正しいのかは裏どりができていません。
DownstreamにおいてはLAN Switchや無線APにてDSCP値を操作しIT管理者が意図するQoS設定を行うことが可能ですが、無線部分の意図しないトラフィックによる優先トラフィックへの妨げを防止するためにFast Laneによる操作は有効な機能であることが確認できました。
しかし、残念ながらこのFast Laneを有効にできるのはApple社のデバイスのみとなりますのでオフィスで一般的に使われているWindows端末や、Android端末のことも考えると実際どれくらいメリットがあるのかは何とも言えません。
