Cisco Connect Japan 2014:安定した無線 LAN 上でビジネスクリティカルなアプリケーションを利用するには？

安定した無線 LAN 上でビジネスクリティカルなアプリケーションを利用するには? CC5-4

大崎秀行テクニカルサービス

テクニカルアシスタンスセンターシニアカスタマーサポートエンジニア

Cisco and/or its affiliates. All rights reserved. CC5-4 Cisco Public 3

Cisco and/or its affiliates. All rights reserved. CC5-4 Cisco Public

企業無線 LAN に出現した新たなアプリケーションリアルタイムトラフィックアプリケーション : Real-Time Traffic over WLAN

4

§  XaaS アプリケーション / サービス - 日常業務で利用

§ 音声通話 (Voice over WLAN : VoWLAN) - 携帯電話料金の削減

§ テレプレゼンス, Cisco Webex - 迅速な会議と意思決定の実現

§ ビデオストリーミング - 社内外の情報発信品質の向上

§ 仮想デスクトップ - データの安全な運用と端末コストの削減

§  BYOD - 従業員の機動性向上と満足度の向上

§ 旧来のアプリケーション以上の持続性とリアルタイム性能の要求 –  どこでも使える –  より小さな遅延、ジッタ –  より低いパケット再送率 –  より少ないパケットロス

売上の向上 / 生産性の向上 / コストの削減

これを実現できればアプリは安定する


セッションの内容

5

§  企業無線 LAN 上に出現した新たなアプリケーション §  無線 LAN のデザイン o  求められる品質と技術条件 o  RF デザイン o  CleanAir テクノロジー o  レーダの影響と　DFS o  セルデザイン

§  ローミング時に途切れさせないために §  QoS と Cisco Prime Infrastructure の活用 §  推奨設定一覧 §  参考図書および文書

リアルタイムトラフィック : RToWLAN

Cisco and/or its affiliates. All rights reserved. CC5-4 Cisco Public 7

RToWLAN 運用に対するユーザの期待値は高い

§ ユーザが有線から無線に “引っ越し” てくる場合 –  有線環境で実現していたことを無線 LAN でも再現させることが求められる –  再現されていない = 障害発生 –  可能な限り期待値に沿った運用が求められる

§ Real-Time Traffic over WLAN (RToWLAN) に期待される具体的な条件 –  パケットロスは 1% 以内 –  エンドツーエンドの遅延（ジッタ）は 30 ミリ秒以内 –  片道で 150 ミリ秒以内のネットワーク遅延 –  パケット再送率は 20% 以内 –  どこでも使えるようなカバレッジ –  3G / LTE 携帯電話網や、家庭内の電話子機で体験しているような使い勝手 –  非同期データ通信では許容されるような一時的な切断やパケットロスは認められない


RToWLAN の基本技術要素

8

§ 基本的には Voice over WLAN (VoWLAN) と似た設計方針

§  VoWLAN で扱う有線上のプロトコル –  呼制御 : SCCP / SIP –  音声転送 : RTP over UDP (再送機構無し、低信頼性) –  QoS 制御 : TOS, IP Precedence, DSCP (PHB), COS

§ RToWLAN で扱う有線上のプロトコル –  ビデオ (H.264 等) –  マルチキャストその他アプリに依存したプロトコル (Keep-alive 等)

§ 企業向けの RToWLAN で特に注意するべきこと –  電波の物理的な性質 –  チャネルの帯域、キャパシティとセルデザイン –  QoS (WMM-AC) –  スニファが容易なため、暗号化が必須要件 –  AP から AP へのシームレスなローミング –  端末とアプリの多様性 = 実装の多様性


無線品質が全体の品質を左右する


無線環境設計 (RF デザイン)

§ 物理的な制限事項

§ 品質を決める指標 –  信号対雑音比 : Signal to Noise Ratio (SNR) –  チャネル占有率

§ CleanAir テクノロジーの活用 –  SE-Connect モード –  Cisco Prime Infrastructure (CPI) との連携

§ レーダの影響と Dynamic Frequency Selection (DFS)

§ セルデザイン –  机上検討 –  サイトサーベイ

ファーストホップが品質を左右する

10


物理的なメディアの制限

11

§ 無線 LAN は小電力データ通信無線局として免許不要の周波数帯を使う –  電波出力の上限値が法で定められており、携帯電話等の無線通信よりもずっと短い距離しか

電波が届かない (電力は距離の二乗に反比例して減衰する)

§  メディアが共有されているため、次のような事象が発生する –  他の無線 LAN の電波による干渉 –  無線 LAN 以外の機器（ノイズ）からの干渉 –  利用可能な帯域に制限を受ける

§  AP は限られた範囲しかカバーできない –  送信電力の法定上限設定 –  利用可能なアンテナの法定制限 –  物理・地理的な環境要因 (反射、吸収、透過、回折、マルチパス)

2.4GHz 5GHz


RF デザインの基本

§  SNR (信号対雑音比: Signal-to-Noise Ratio) の確保

無線 LAN の受信電力 > ノイズ&干渉波の受信電力

12

受信機のノイズフロア

信号対雑音比 SNR

無線 LAN 信号

受信電力

周波数(チャネル)

高

低

干渉波


SNRと伝送レート

§  802.11a の場合 §  絶対下限値は Cisco 7925G/7925G-EX/7926G、SNR は Cisco Aironet カードのハードウェア仕様値から算出 §  使用するクライアントのハードウェア仕様値を確認 §  マージンは人体の移動、電話/スマートフォンの位置変動、障害物等による影響のふらつきを考慮して、多めに 15dB で考える

13

達成したい伝送レート (Mbps)

デコードに必要な SNR (dB) = クライアントの値 +

15 dB (マージン)

受信強度の絶対下限値 = クライアントの受信感度 (dBm) + 15dB (マージン)

6 (Disabled) 23 -91 + 15 = -76

9 (Disabled) 25 -90 + 15 = -75

12 (Mandatory) 25 -88 + 15 = -73

18 27 -86 + 15 = -71

24 (目標値) 27 -82 + 15 = -67

36 33 -80 + 15 = -65

48 40 -77 + 15 = -62

54 40 -75 + 15 = -60 厳

緩

高

低

高

低

速

遅

速

遅

良

悪

電波環境


RF デザインの基本

§  100% - チャネル占有率 ≒ そのチャネルで無線 LAN に使える帯域(時間) –  物理的なノイズ、干渉に加えて仮想キャリアセンスした結果も反映されている

チャネル占有率 VS 無線 LAN 帯域

14

残り 4% の帯域しか利用できない

‟ 無線が混雑していると言われても、無線ってどこに何があるか見えないんだから、どうしようもないよね？”

•  通りすがりの IT 管理者のぼやき

CleanAir の活用

15


NO! 見えます!

§  SE Connect モードの CleanAir AP

§  Spectrum Expert (Windows)

CleanAir テクノロジーの活用

16

周波数、時間、出現パターンを特定

周波数(チャネル)

時間

の経

過

電波

の強

さ

強

弱

過去

現在


CleanAir の凄いところ高解像度解析で正確に識別

17

Cisco CleanAir の高解像度解析 (78 - 156 KHz 幅)

この動きは電子レンジ！

これは Bluetooth !

何かあるなぁ？

（たぶん）BlueTooth ?

Pow

er

Pow

er

?

既製品の Wi-Fi チップセットでの干渉源の認識

時間軸の細かい分析

周波

数軸

の細

かい

解析


CleanAir の凄いところ詳細なレポート機能 – Cisco Prime Infrastructure (CPI) との組み合わせ

18

Air Quality

影響度の判定


そして場所、影響範囲までわかる！(自動)対処できる！ Mobility Service Engine (MSE) との連携も

19

例え AP から遠い干渉源であっても、影響範囲内部にクライアントが存在する場合は、Event Driven RRM (ED-RRM) 機能により速やかに別チャネルへ自動的に移行することも可能


レーダと DFS : Dynamic Frequency Selection Wi-Fi 電波は既存のレーダ施設に“配慮”する義務がある

20

観測を混乱させる恐れあり (5 GHz W53, W56 バンド)

パルスの往復時間、受信電力、ドップラー周波数等から位置、雨量、速度等を算出

もし AP がレーダのパルス電波を検知した場合、ただちに所定の時間内に電波を止め、別の周波数へ移動しなければならない

微弱な反射波

直接波

DFS 動作

積乱雲発生


身の回りに存在するレーダ

21

全国にある 5GHz 帯で動作する雨量測定レーダ http://www.river.go.jp/ (国土交通省 “川の防災情報” より)

羽田空港内の空港気象ドップラーレーダ http://www.jma-net.go.jp/haneda-airport/　

(東京航空地方気象台 “羽田空港 WEATHER TOPICS” より)


港区赤坂9丁目の場合

22

スペアナ + 指向性アンテナ

§ 終業後の東京ミッドタウンタワーから南南東の方角を臨むと・・・


観測された電波の一例

§ 約5280MHz において、何らかのパルス状(広帯域)の電波が高いレベルで照射されていることがわかる –  レーダ(*) による DFS 動作がチャネル 56 で発生する恐れがある(かもしれない)

*ただし、レーダの観測は非常に難しく、判別にはスペアナ等専用の機材と深いレベルの解析が必要です。上記の例の電波がレーダであることを示すものではありません。

23


Spectrum Expert でも広帯域パルスは観測可能

24


DFS の履歴は WLC と CPI で確認可能

25

(WLC) > show ap auto-rf 802.11a {AP_name} Radar Information Channel 124.................................. 267 seconds ago Channel 128.................................. 267 seconds ago

Trap ログ (show traplog)


DCA リストの適化の例 (RF Profile)

26

予めチャネル 56 を排除したうえで、自動チャネル設定

37階南側会議室の AP が所属する AP グループに適用

リリース 8.0 からの新機能

なお DCA リスト内のチャネルで直近 30分間にレーダ検知されたものについては、自動的に DCA の候補から外れます


セルデザイン

§ 離れると減衰する

§  SNR

§ チャネル占有率

§ 反射される、吸収される、回り込む、透過する

電波の物理的な性質で決まる

27


RToWLAN のセルデザインの基本 (1/2)

§  5GHz の使用を前提として考える –  2.4GHz には多数の干渉源が存在し、チャ

ネル占有率が高い傾向にある §  電子レンジ, Bluetooth, ワイヤレスマイク、ワイ

ヤレスカメラ等 –  同一伝送レートでも 2.4GHz の方がセル

が広くなるため、高密度に設置できない –  重ならないチャネルを多く使える –  Band Select 機能の活用

§ 低伝送レートを無効にする –  12Mbps を Mandatory にして 6, 9 Mbps

は Disabled に –  802.11n の MCS0 ( 低 6.5Mbps) も場

合によっては Disabled に §  MCS0 必須のクライアントもいるので注意！

28

0

500

1000

1500

2000

2500

3000

3500

6 12 36 54 130 173.3 300 540

64 Bytes

128 Bytes

256 Bytes

512 Bytes

1024 Bytes

2048 Bytes

伝送

に要

する

時間

(マイ

クロ

秒)

伝送レート (Mbps)

ここをカット

スループットへの影響

干渉源の種類近距離 (8 m)

遠距離 (23 m)

コードレス電話 100% 100%

監視カメラ 100% 57%

別の Wi-Fi 90% 75% 電子レンジ 63% 53%

Bluetoothアクセサリ 20% 17%

DECT フォン 18% 10%


§ ユーザの利用場所と期待値をしっかり把握する –  休憩所、廊下、階段、エレベータホール、屋外、etc.

§ サイトサーベイを実施する –  机上検討と実際では異なることがほとんど

§ クライアントのデザインガイドをよく読む –  ローミングに関する情報等が載っている

§ 設置後も実際のクライアントとアプリを使って問題無いことを確認する –  クライアントの癖を理解する

RToWLAN のセルデザインの基本 (2/2)

29

EV

EV EV

EV EV

EV EV

EV


AP 配置の机上検討

§ 隣接セルで異なるチャネルにする § 重なる部分はセルの 20%以上にする § セルの末端は -67dBm § 同一チャネルのセルとは 19dB 離す § 上下階で立体的に考える

30

同一チャネル: 19dB 乖離

セルの末端: -67dBm

Ch 36 Ch 116 Ch 52 Ch 100

Ch 60 Ch 108 Ch 44 Ch 124


サイトサーベイ

§ 利用を想定している位置で、要件を満たしているか –  パケットロスは 1% 以内 –  エンドツーエンドの遅延（ジッタ）は 30 ミリ秒以内 –  片道で 150 ミリ秒以内のネットワーク遅延 –  パケット再送率は 20% 以内 –  アプリの要求する伝送レート

§ アンテナの向きや AP の置き方に問題は無いか

§ 電波を吸収する障害物は無いか

§ どこかに第三者の無線 LAN は無いか

§ どこかにノイズの発生源は無いか

§ DFS の発生頻度はどのチャネルでどの程度か

机上検討及び期待値とのギャップはここで把握して改善

31


VoWLAN 環境適合性を Prime Infrastructure で確認

32

Bad!

Good!

Inspect Voice Readiness 機能


ローミング時に途切れさせないために


ローミング動作

34

§ RToWLAN クライアントは良好なビデオ、音声品質を保つため、モバイルユーザの移動に合わせて接続する AP を切り替える必要がある –  暗号化による安全性は保つ –  ローミングは AP から得られる多くの情報を基にクライアントが判断する – ビーコン、パケット

再送率、パケットロス、受信電力値 (RSSI)、信号対雑音比 (SNR)、チャネル占有率 (QBSS)

(会話中に移動)

①

②


高速セキュアローミング

§ どうやって安全性を保ったまま短時間で受け入れるか、という問題 –  一時的な切断やパケットロスは認められない（ユーザの高い期待値） –  ローミング時に暗号化鍵、暗号化セッションを作成し直す –  鍵の生成には認証通信とコンピューティング処理が必要（時間を要する）

§ 許容される通信断の時間 –  一般的な VoWLAN の要件 : 大 150 ミリ秒以内の通信断まで –  RToWLAN のエンドツーエンドの遅延（ジッタ）は 30 ミリ秒以内

–  Microsoft Lync : 大 50 ミリ秒以内 (しきい値に設定) http://www.microsoft.com/en-us/download/details.aspx?id=36494

§ 暗号化鍵のキャッシング (Key Caching) 技術 –  CCKM, PMKID (Sticky, Opportunistic), IEEE 802.11r (Fast Transition : FT) –  WPA2 対応端末であれば Key Caching により RADIUS 通信を含む Network EAP を使っ

た完全な再認証を省略することが可能となり、短時間で AP を切り替えることができる

–  CCKM は Cisco Compatible Extensions Program : CCX Version 2 以降に対応したクライアントが実行できる Cisco 独自の高速セキュアローミング方式

35


802.1x を使った完全な認証 - 時間がかかる

CPU 処理速度が PC より遅い場合もある

Probe Request Probe Response

Auth Request Auth Response

Association Request Association Response

EAP Start EAP ID Request

EAP ID Response

EAP Method

EAP Success

EAPoL 4 way handshake

DATA

AP WLC Radius

2 – 10+ 往復 CPU 処理と時間を要する

RADIUS


スマートフォンで PEAP 認証時の無線フレームキャプチャ

802.11 Authentication

Association 交渉

EAP, RADIUS 交渉 170ms

4-way Handshake

210ms


Key Caching を使ったローミング - EAP 部分を短縮

38


Reassociation Request　- PMKID Reassociation Response

EAPoL 4 way handshake

RTP

PMKID を基にキャッシュされたキーを参照して合否判定

ローミング先AP WLC RADIUS

170ms 短縮 – 40ms でローミング完了かろうじて 100ms 以内

Wi-Fi 認定スマートフォン



IEEE 802.11r の事前認証を使ったローミング

39

AP1 から AP2, 3, 4 へ移動

事前認証情報 (WLC 有線経由)

AP1 から AP2, 3, 4 へ移動

この人が今からそっちに行くよ


IEEE 802.11r を使ったローミング - 事前認証で短縮

40


Reassociation Request – Fast BSS Transition (SNonce + ANonce)

RTP キャッシュされたキーを参照して合否判定


Authentication と 4-way handshake の分をさらに短縮

802.11r 対応端末 Action frame - Fast BSS Transition : FT (SNonce)

Action frame - Fast BSS Transition : FT (SNonce + ANonce)

Reassociation Response – Fast BSS Transition (SNonce + ANonce)

事前認証情報


IEEE 802.11r 対応スマートフォンでローミング時の無線フレームキャプチャ (Over the DS ローミング)

Action Frame - FT

FT (802.11r) で ReAssociation 交渉

11ms でローミング完了

Probe Request / Probe Response

ただし、Authentication フレーム構造が変更されたため、登場当初は 802.11r 対応と非対応端末が同一 SSID に所属することができなかった。 CUWN 8.0 から同時に所属することが可能になった (802.11r Mixed mode)。一部の古いクライアントは接続できないため、その場合は 2つの SSID を用意する必要がある。


Reassociation Request に追加された新要素

Reassociation Request (FT) の中身 §  RSNIE : PMKID を含み、AKM が FT over IEEE 802.1X §  Mobility Domain IE : 端末の Over the DS ローミング可否 §  Fast BSS Transition IE : MIC, ANonce, SNonce, PMK-R1

KH-ID と PMK-R0 KH-ID を含む

トラブルシューティング時のリファレンスとして


IEEE 802.11r FT Mixed-mode 動作実績 (2014年 11月現在)

メーカー / 製品名 OS / ドライバ / ユーティリティ 802.11r Mixed-mode Association 動作テスト結果

Apple iPad, iPad2, iPad3, Air iOS 6, iOS7.1.1, iOS6.1.3, iOS7.0 OK

Apple iPhone5S iOS 7.1.2 OK

Apple iPod iOS 6.1.3 OK

Apple MacBookPro11,2 OSX 10.9.5 OK



Samsung Galaxy SII Android 2.3.3 OK

Samsung Galaxy S4 Android (詳細不明) OK

Cisco 7921 Firmware 1.4.5 OK



Cisco CIUS-7 Android 2.2.2 NG

Apple MacBookPro (詳細不明) OSX 10.9 NG

Apple MacBookPro (詳細不明) OSX 10.7.4 NG

Netgear (詳細不明) 6.30.145.30 NG

Juniper Odyssey (詳細不明) (詳細不明) NG

43

クライアントの動作(非動作)を保証するものではなく、弊社独自の簡易テスト結果を共有するものです。実際の動作は実機検証にて確認してください。


IEEE 802.11r (FT) の特徴的なログ出力(成功時 1/3)

*apfMsConnTask_6: Oct 21 19:37:38.691: ac:fd:ec:28:6b:ec Sending assoc-resp with status 0 station:ac:fd:ec:28:6b:ec AP:08:cc:68:b4:4e:f0-01 on apVapId 1 *apfMsConnTask_6: Oct 21 19:37:38.691: ac:fd:ec:28:6b:ec Including FT Mobility Domain IE (length 5) in Initial assoc Resp to mobile *apfMsConnTask_6: Oct 21 19:37:38.691: ac:fd:ec:28:6b:ec Sending R0KH-ID as:-84.23.-64.5 *apfMsConnTask_6: Oct 21 19:37:38.691: ac:fd:ec:28:6b:ec Sending R1KH-ID as 00:24:97:69:67:60 *apfMsConnTask_6: Oct 21 19:37:38.691: ac:fd:ec:28:6b:ec Including FT IE (length 98) in Initial Assoc Resp to mobile *Dot1x_NW_MsgTask_4: Oct 21 19:37:38.854: ac:fd:ec:28:6b:ec Creating a PKC PMKID Cache entry for station ac:fd:ec:28:6b:ec (RSN 2) *Dot1x_NW_MsgTask_4: Oct 21 19:37:38.854: ac:fd:ec:28:6b:ec Created PMK Cache Entry for TGr AKM:802.1x ac:fd:ec:28:6b:ec *Dot1x_NW_MsgTask_4: Oct 21 19:37:38.854: ac:fd:ec:28:6b:ec R0KH-ID:172.23.192.5 R1KH-ID:00:24:97:69:67:60 MSK Len:48 pmkValidTime:86401 *Dot1x_NW_MsgTask_4: Oct 21 19:37:38.855: ac:fd:ec:28:6b:ec PMK sent to mobility group *Dot1x_NW_MsgTask_4: Oct 21 19:37:38.860: ac:fd:ec:28:6b:ec Adding TIE for reassociation deadtime:20000 milliseconds *Dot1x_NW_MsgTask_4: Oct 21 19:37:38.860: ac:fd:ec:28:6b:ec Adding TIE for R0Key-Data valid time :86401 *Dot1x_NW_MsgTask_4: Oct 21 19:37:38.860: ac:fd:ec:28:6b:ec Sending EAPOL-Key Message to mobile ac:fd:ec:28:6b:ec state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01

debug ft events enable & debug client

44




*apfMsConnTask_6: Oct 21 19:37:51.257: ac:fd:ec:28:6b:ec Got action frame from this client. *apfMsConnTask_6: Oct 21 19:37:51.257: ac:fd:ec:28:6b:ec Doing preauth for this client over the DS *apfMsConnTask_6: Oct 21 19:37:51.257: AP MAC address Controller *apfMsConnTask_6: Oct 21 19:37:51.257: ------------------ --------------- *apfMsConnTask_6: Oct 21 19:37:51.257: 08:cc:68:b4:4e:f0 172.23.192.5 *apfMsConnTask_6: Oct 21 19:37:51.257: 0c:85:25:9e:47:80 172.23.192.5 *apfMsConnTask_6: Oct 21 19:37:51.257: 70:10:5c:e7:49:c0 172.23.192.5 *apfMsConnTask_6: Oct 21 19:37:51.257: 70:10:5c:f9:e2:30 172.23.192.5 *apfMsConnTask_6: Oct 21 19:37:51.257: a8:0c:0d:db:ba:20 172.23.192.5 *apfMsConnTask_6: Oct 21 19:37:51.257: f8:c2:88:80:4a:80 172.23.192.5 *apfMsConnTask_6: Oct 21 19:37:51.257: ac:fd:ec:28:6b:ec Doing local roaming for destination address 08:cc:68:b4:4e:ff *apfMsConnTask_6: Oct 21 19:37:51.257: ac:fd:ec:28:6b:ec Got 1 AKMs in RSNIE *apfMsConnTask_6: Oct 21 19:37:51.257: ac:fd:ec:28:6b:ec RSNIE AKM matches with PMK cache entry :0x3 *apfMsConnTask_6: Oct 21 19:37:51.257: ac:fd:ec:28:6b:ec Created a new preauth entry for AP:a8:0c:0d:db:ba:2f *apfMsConnTask_0: Oct 21 19:37:51.261: ac:fd:ec:28:6b:ec Processing assoc-req station:ac:fd:ec:28:6b:ec AP:a8:0c:0d:db:ba:20-01 thread:150e41c0 *apfMsConnTask_0: Oct 21 19:37:51.261: ac:fd:ec:28:6b:ec Reassociation received from mobile on BSSID a8:0c:0d:db:ba:24 AP FW41-AP2702E *apfMsConnTask_0: Oct 21 19:37:51.263: ac:fd:ec:28:6b:ec Marking this mobile as TGr capable. *apfMsConnTask_0: Oct 21 19:37:51.264: ac:fd:ec:28:6b:ec Roaming succeed for this client. *apfMsConnTask_0: Oct 21 19:37:51.264: ac:fd:ec:28:6b:ec Sending assoc-resp with status 0 station:ac:fd:ec:28:6b:ec AP:a8:0c:0d:db:ba:20-01 on apVapId 1 *apfMsConnTask_0: Oct 21 19:37:51.265: ac:fd:ec:28:6b:ec Including FT Mobility Domain IE (length 5) in reassociation assoc Resp to mobile *Dot1x_NW_MsgTask_4: Oct 21 19:37:51.267: ac:fd:ec:28:6b:ec reauth_sm state transition 1 ---> 0 for mobile ac:fd:ec:28:6b:ec at 1x_reauth_sm.c:53 *Dot1x_NW_MsgTask_4: Oct 21 19:37:51.267: ac:fd:ec:28:6b:ec Finishing FT roaming for mobile ac:fd:ec:28:6b:ec

debug ft events enable & debug client

45




(CT5508) >show client detail ac:fd:ec:28:6b:ec Client MAC Address............................... ac:fd:ec:28:6b:ec Client Username ................................. hosaki AP MAC Address................................... a8:0c:0d:db:ba:20 AP Name.......................................... FW41-AP2702E

Policy Type...................................... WPA2 Authentication Key Management.................... FT-802.1x Encryption Cipher................................ CCMP (AES) Protected Management Frame ...................... No Management Frame Protection...................... No EAP Type......................................... PEAP

Fast BSS Transition Details: Reassociation Timeout...................... 20 Total Preauth APs.......................... 1 Preauth AP................................. a8:0c:0d:db:ba:2f

show client detail {MAC of client}

46



IEEE 802.11k

§  IEEE 802.11k –  クライアントがローミングする場合、ローミング先を探す必要がある –  Action Frame を使ってクライアントは AP にローミング先の候補をリクエストする –  AP は WLC から情報を受け取り、そのクライアント付近の実際の電波状況の統計値を基に、

適な候補 AP を応答として返す –  クライアントがローミングをする判断をしたときに、新たなローミング先を探す必要がなく、滞り

無くローミング動作に移ることができる –  IEEE 802.11r (FT) と組み合わせることで、ローミング発生前に候補 AP と事前認証を済ま

せておくことも可能 –  探すための Probe Request / Response が不要になるので、無線帯域を節約できる –  対応するクライアントは限られる –  iPhone (4S以降)、iPad (2以降)、iPad Mini の iOS6 等は対応している

周囲の AP の情報を事前に把握して更に短縮

47

近くにいい AP ないかな？

こことここがおススメです

この人の履歴と現受信電力から総合的に考えると、こことここです。


IEEE 802.11k の特徴的なログ出力

*apfMsConnTask_6: Oct 21 19:37:38.695: ac:fd:ec:28:6b:ec Got action frame from this client. *apfMsConnTask_6: Oct 21 19:37:38.695: ac:fd:ec:28:6b:ec Received a 11k Action frame with code 4 from mobile station AC:FD:EC:28:6B:EC *apfMsConnTask_6: Oct 21 19:37:38.695: Received NEIGH_REQ from ms ac:fd:ec:28:6b:ec ap WLAN 1, wlc WLAN 12, d.token 16

*apfMsConnTask_6: Oct 21 19:37:38.695: apf80211KNeighborRequestProcessSubElements: Decoding payload, size 9 *apfMsConnTask_6: Oct 21 19:37:38.695: apf80211KNeighborRequestProcessSubElements: Decoding SSID SUBIE, voiceft, 7 *apfMsConnTask_6: Oct 21 19:37:38.695: apf80211KQMsgNeighReqPost: posting msg for ms (dialog token: 16) ac:fd:ec:28:6b:ec lradmac 08:cc:68:b4:4e:f0 slotmac 00:00:00:00:00:00 slot 1, vapid 12 *apf80211KTask: Oct 21 19:37:38.696: ac:fd:ec:28:6b:ec Sending 802.11K Neighbor Report ACTION to station on BSSID

debug 11k all enable & debug client

48



CCX 対応の CP7921 で CCKM ローミング – Cisco 独自

49



Reassociation Request Reassociation Response

RTP キャッシュされたキーを参照して合否判定


4-way handshake が無いのでさらに短縮

CCX v2 以降


CP7921 で CCKM ローミング時の無線フレームキャプチャ

802.11 Authentication

CCKM で ReAssociation 交渉

わずか 6ms でローミング


CCKM ローミング時の特徴的なログ出力 (1/2)

*apfMsConnTask_6: Oct 21 18:51:55.727: 00:21:55:3d:e8:2c Association received from mobile on BSSID 08:cc:68:b4:4e:f4 AP FW45-AP3702

*apfMsConnTask_6: Oct 21 18:51:55.728: 00:21:55:3d:e8:2c Processing RSN IE type 48, length 22 for mobile 00:21:55:3d:e8:2c

*apfMsConnTask_6: Oct 21 18:51:55.728: 00:21:55:3d:e8:2c CCKM: Mobile is using CCKM

*Dot1x_NW_MsgTask_4: Oct 21 18:51:55.895: 00:21:55:3d:e8:2c Creating a PKC PMKID Cache entry for station 00:21:55:3d:e8:2c (RSN 2)

*Dot1x_NW_MsgTask_4: Oct 21 18:51:55.895: 00:21:55:3d:e8:2c CCKM: Create a global PMK cache entry

*Dot1x_NW_MsgTask_4: Oct 21 18:51:55.911: CCKM: Data used to compute KRK and BTK: (76)

*Dot1x_NW_MsgTask_4: Oct 21 18:51:55.911: CCKM: Data used to compute PTK: (10)

*Dot1x_NW_MsgTask_4: Oct 21 18:51:55.911: 00:21:55:3d:e8:2c CCKM: RN used to compute PTK: 01000000

*Dot1x_NW_MsgTask_4: Oct 21 18:51:55.911: 00:21:55:3d:e8:2c CCKM: Computed PTK from BTK

debug cckm detailed enable & debug client

51



CCKM ローミング時の特徴的なログ出力 (2/2)

*apfMsConnTask_0: Oct 21 18:57:13.808: 00:21:55:3d:e8:2c CCKM: Received REASSOC REQ IE

*apfMsConnTask_0: Oct 21 18:57:13.808: 00:21:55:3d:e8:2c Processing assoc-req station:00:21:55:3d:e8:2c AP:a8:0c:0d:db:ba:20-01 thread:150e41c0

*apfMsConnTask_0: Oct 21 18:57:13.808: 00:21:55:3d:e8:2c Reassociation received from mobile on BSSID a8:0c:0d:db:ba:24 AP FW41-AP2702E

*apfMsConnTask_0: Oct 21 18:57:13.809: 00:21:55:3d:e8:2c Processing RSN IE type 48, length 22 for mobile 00:21:55:3d:e8:2c

*apfMsConnTask_0: Oct 21 18:57:13.809: 00:21:55:3d:e8:2c CCKM: Mobile is using CCKM

*apfMsConnTask_0: Oct 21 18:57:13.809: 00:21:55:3d:e8:2c Received RSN IE with 0 PMKIDs from mobile 00:21:55:3d:e8:2c

*apfMsConnTask_0: Oct 21 18:57:13.810: 00:21:55:3d:e8:2c CCKM: Processing REASSOC REQ IE

*apfMsConnTask_0: Oct 21 18:57:13.810: 00:21:55:3d:e8:2c CCKM: using HMAC SHA1 to compute MIC

*apfMsConnTask_0: Oct 21 18:57:13.810: 00:21:55:3d:e8:2c CCKM: Received a valid REASSOC REQ IE

*apfMsConnTask_0: Oct 21 18:57:13.812: CCKM: Data used to compute PTK: (10)

*apfMsConnTask_0: Oct 21 18:57:13.812: [0000] 02 00 00 00 a8 0c 0d db ba 2f

*apfMsConnTask_0: Oct 21 18:57:13.812: 00:21:55:3d:e8:2c CCKM: RN used to compute PTK: 02000000

*apfMsConnTask_0: Oct 21 18:57:13.812: 00:21:55:3d:e8:2c CCKM: Computed Reassoc PTK from BTK

*apfMsConnTask_0: Oct 21 18:57:13.812: 00:21:55:3d:e8:2c CCKM: Initializing PMK cache entry with a new PTK

*apfMsConnTask_0: Oct 21 18:57:13.812: CCKM: Encrypted GTK: (24)

*apfMsConnTask_0: Oct 21 18:57:13.812: CCKM: Data used to compute MIC for REASSOC RESP IE: (76)

*apfMsConnTask_0: Oct 21 18:57:13.812: 00:21:55:3d:e8:2c CCKM: using HMAC SHA1 to compute MIC

*apfMsConnTask_0: Oct 21 18:57:13.812: CCKM: MIC for REASSOC RESP IE: (8)

*apfMsConnTask_0: Oct 21 18:57:13.812: 00:21:55:3d:e8:2c Including CCKM Response IE (length 54) in Assoc Resp to mobile

*apfMsConnTask_0: Oct 21 18:57:13.812: 00:21:55:3d:e8:2c Sending Assoc Response to station on BSSID a8:0c:0d:db:ba:2f (status 0) ApVapId 1 Slot 1

debug cckm detailed enable & debug client

52



QoS を有線と無線で有効に

トラフィック (再) マーキング §  エンタープライズ QoS はエ

ンドポイントのトラフィックの DSCP / PHB, UP 値に基づいて動作する。

§  (再)マーキングはアプリ、エンドポイント、あるいはネットワークで実施される。

キューイング §  エンタープライズ QoS には

ボイスおよびリアルタイムトラフィックに対するエンドツーエンドの専用帯域が必要。

§  QoS マーキングによってどのキューを使うかが決まる。

エンドポイントトラスト §  エンタープライズ QoS はアプ

リ / エンドポインとのトラスト状態に依存する。そのエンドポイントがトラストできない場合は再マーキングしてやる。

§  トラストはエンドポイント / アプリとトラフィックのプロファイルに依存する。

§  制限や不確定要素があるような複雑なアプリは、非トラスト

53

§  音声通話のようにリアルタイムかつ再送されないトラフィックを使うアプリには、エンタープライズ QoS は必須

§  無線区間は WMM を使って QoS をかけることで、期待通りの応答時間、高品質なボイス / ビデオが展開できる

§  WLAN の QoS 設定 (Platinum, Gold, Silver, Bronze) を実施する

? X P

AF41 EF

AF41

BE

EF CS3 EF CS3 BE AF41


実際に QoS が効いているかを確認する

§ WLC で Traffic Stream Metrics 機能を有効にしておく

Cisco Prime Infrastructure と CCX の活用

54


Voice Diagnostics で音声通話を実測 (CCXv2 以上)

55

音声トラブル発生時の状態を再現


問題を自動的に発見

§ ローミングに 596ミリ秒かかっていることを発見 –  AP を特定、無線品質、高速セキュアローミングの状態をチェック

56


視覚的に音声通話を把握

§ 音声通話の発生を確認 § クライアント発の音声パケットが WMM にて UP 6 (Voice) としてマーキングされてい

ることを確認

57


視覚的に音声通話を把握

§ QoS の状態は良い (Normal) §  90%以上のパケットが 10ミリ秒以内のジッタに収まっている § 平均遅延もおよそ 10ミリ秒以下に全て収まっている

58


CCX 非対応でもローミングの履歴と理由は確認可能

59


Summary

§  有線 LAN 環境や従来アプリの無線環境から移行する場合 –  リアルタイムトラフィックを扱うユーザの期待値はとても高い –  使用場所、帯域、クライアントやアプリの実装について事前に合意 –  RF デザインの見直し

§  RF デザインとセルデザイン –  ファーストホップとなる無線区間で品質が決まる –  CleanAir, Band Select, RF Profile, CCX, CPI, MSE 等 Cisco の機能を大限活用 –  机上検討とサイトサーベイを併用し、条件に変更があった場合は微調整を実施

§  RToWLAN では QoS が必須 –  有線: PHB, CoS –  無線: WMM-AC, Load Base Call Admission Control (LB-CAC) for Voice and Video –  アプリの識別と QoS 制御は Cisco Application Visibility and Control (AVC) を活用

§  高速セキュアローミングを実装する –  PMK Key Caching, 802.11r, CCKM : クライアントの実装状態と動作は必ず確認

§  VoWLAN 環境 ≒ RToWLAN 環境 –  差分はアプリとクライアントの多様性 –  ローミング時の通信断許容時間が厳しい場合を考慮

60


冗長構成 (AP / Client SSO) 有効プリイメージダウンロード有効 AP フェールオーバープライオリティ有効 AVC 有効 NetFlow 有効ローカルプロファイリング (DHCP と HTTP) 有効 VLAN Pooling 有効 NTP 有効 FlexConnect グループ有効 “FlexConnect AP アップグレード” 有効

802.1x + WPA/WPA2 有効 EAP タイマーを認証動作遅延に応じて変更 SSH と SNMPv3 有効　　　　　　　DHCP proxy 有効 11w / 11k および 11v 有効　クライアント exclusion 有効 Rogue classification 有効 LSC (Logically Significant Certificate) 有効 IDS / WiPS 有効 WSSI / Security モジュールを設置して全チャネル監視 “Max Concurrent Logins for a user name” 有効ストロングパスワードポリシー有効　LAN での ACL 適用

11b データレート無効　WLAN / SSID の数を 3以下に制限チャネルボンディング有効 – 40 / 80 MHz バンドセレクト有効　　　AP グループと RF グループの利用 RF プロファイルできめ細かく制御 RSSI Low チェック設定　　 RRM (DCA & TPC) を Auto 設定 Auto-RF グループリーダ設定 Cisco CleanAir と EDRRM 有効全チャネルでノイズ & Rogue 監視クライアントロードバランス有効

ゲストアンカー WLC への EoIP 有効ゲストユーザは Web 認証　　 OEAP でスプリットトンネル有効ファスト SSID チェンジ有効　　 per-user 帯域制限有効 WMM 有効　　　　　　　　　　　 WLAN で QoS 有効

大規模環境ではマルチキャストモビリティ有効 802.1x AP 認証利用

ネッ

トワ

ーク

デザ

イン

セキュリティ

ネ

ット

ワー

クイ

ンフ

ラ

無線

環境

参考 : その他の CUWN 推奨設定一覧

http://www.cisco.com/c/en/us/td/docs/wireless/technology/wlc/82463-wlc-config-best-practice.html

61


推薦図書および参考文書

エンタープライズモビリティデザインガイド

http://www.cisco.com/cisco/web/support/JP/docs/WL/WLLANCntrller/5500WLCntrllers/IDG/002/emob73.html

Cisco Unified Wireless IP Phone 7925G, 7925G-EX, and 7926G Deployment Guide

http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7925g/7_0/english/deployment/guide/7925dply.pdf

Real-Time Traffic over Wireless LAN Solution Reference Network Design Guide

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/RToWLAN/CCVP_BK_R7805F20_00_rtowlan-srnd.html

62

63

Thank you!

Cisco Connect Japan 2014:安定した無線 LAN 上でビジネス クリティカルなアプリケーションを利用するには？

Technology

Cisco Connect Japan 2014:安定した無線 LAN 上でビジネスクリティカルなアプリケーションを利用するには？