#ローミングの概要
##ローミングのフロー
- チャネルをスキャンしたり、802.11 プローブリクエストフレームを送信
- オープンシステム認証または共有鍵認証を使用して、BSSID アドレスで特定の AP に自分自身を認証
- アソシエーション要求フレームを AP に送信して AP とアソシエーションを行う
- WPA2 または WPA3 を使用しており、事前共有鍵（PSK）または 802.1Xで保護されている場合は、クライアントは PSK または EAP および RADIUS を使用して自身を認証する
###理想的なローミングとは？
クライアントは、ローミングが発生する前に元のAPとの通信が使用不能にならないように、かなり前にアソシエーションを実施する。
⇒つまり、**一度ローミング先とアソシエーションを実施し、必要になった際に再アソシエーション**する。
####コントローラ内ローミング( レイヤ2)
- 関連付けは**同一コントローラー内**で行われる。
####コントローラ間ローミング( レイヤ2)
- **同一モビリティグループ内**である必要
- **同一SSID、サブネット**に限る
####コントローラ間ローミング( レイヤ 3)
- **同一モビリティグループ内**である必要
- **サブネット**が異なる場合
- アンカーコントローラー：POPと呼ばれ、外部コントローラーとCAPWAPトンネルを確立する。
- 外部コントローラー：POAと呼ばれ、アンカーコントローラーとCAPWAPトンネルを確立する。
##モビリティ グループを使用したローミング動作の整理
####【モビリティグループ】
- 最大WLC数：24
- 各コントローラはお互いのメンバーのリストを保持
- すべてのイベントをお互いに通知（コントローラー内ローミングも含む）
####【モビリティドメイン】
- 複数のモビリティグループをまとめたもの
- 最大グループ数：3
つまり、１モビリティドメインに参加可能なWLCは**最大72台**となる。
異なるドメイン間はシームレスなローミングは実現しない。
####【モビリティオペレーションの概要】
イベントを機にすべてのコントローラーへMobility Announceメッセージを送信
- 外部WLCからアンカーWLCへMobility Announce
- アンカーWLCから外部WLCへMobile Handoff
- 外部WLCからアンカーWLCへMobile Anchor Handshake
####【モビリティ階層の検証】
- C9800：CAPWAPトンネルは暗号化される。（クライアントトラフィックはオプション）
- レガシーコントローラー：Ethernet-over-IP (EoIP)トンネル(IPプロトコル97)とUDPポート16666上でモビリティメッセージを転送する。
※プラットフォームが混在している場合は、要検証
cping：CAPWAP 上のモビリティメッセージングをテスト
eping：EoIP 上のモビリティデータをテストする
mping：UDP ポート 16666 上のモビリティ制御メッセージングをテスト
RRMの理解(クライアンとローミングのためのAP選択の最適化)
- ローミングの決定権は基本的にはクライアント側
####【APスキャンプロセスの最適化】
-
独自のアルゴリズムを使用（RSSI,SNR,フレーム再送等のシフトを監視）
-
デバイスによっては「ローミングアグレッシブ」を設定できるものもある。
-
パッシブスキャン：任意のAPとSSIDからビーコンフレームを受信する為、短い時間待機する。受信するだけなので、バッテリー消費を抑えられる。しかし、待ち時間が長い。
-
アクティブスキャン：プローブ要求を送信し、応答フレームを受信するまで一定時間待機する。待ち時間を抑えられるがバッテリー消費は多くなる。
スキャン時間を短縮させるためにも、APで無効にしているバンドがあるならデバイス側でもスキャンを無効にすること。
####【CCX アシスタンスによる最適化】
###Cisco Compatibility Extensions (CCX)
- デバイス側のサポートが必須となる。
- クライアントがより効率的にローミングできるよう支援する。
- ローミング閾値（RSSI最小値、アクティブスキャンのトリガー閾値など）をWLC側で指定可能
- ネイバーリストの強化
- ディレクテッドローミングリクエスト：WLCがクライアントに対し、ローミング提案する機能
###【802.11k アシストによる最適化】
- APとコントローラは、ローミングの必要性やローミング先として知られている候補APのリストを提案するために、クライアントと対話することができる。
- 802.11k は、クライアントではなく AP にローミングの判断を委ねていることに注意。
#####[アシストローミングプロセス]
- APはクライアントのRSSI減少から移動を推測
- APはクライアントに近々ローミングするように通知
- クライアントは関連するAPに近隣APのリストを要求
- APはクライアントに同じSSIDを提供する近隣APのリストをチャネル番号とともに送信
- 近隣リストの中で最も優れた AP に再アソシエーション
- 近隣APリスト＋チャネルを通知しているので、クライアントはチャンネルスキャンが必要ない。
- つまり、デバイス側でスキャンチャネルを手動で調整する必要がない。
###ローミングのためのセキュリティプロセスの最適化
####【ロバストセキュリティネットワーク（RSN）】
- アソシエーション後、マスターセッションキー(MSK）を作成
⇒WPA2パーソナルなら事前共有鍵があるので必要なし。 - MSKからぺアワイズマスターキー(PMK)を作成
PMK：ユニキャスト通信に使用 - コントローラーはグループマスターキー(GMK)を作成しすべての許可クライアントに配布
GMK：ブロードキャスト、マルチキャストに使用 - ４ウェイハンドシェイクを行う
####【高速セキュアローミングの必要性】
- 完全な再認証を行う際に1秒以上かかる場合もある→シームレスではなくなる
- クライアントの一斉移動によりRADIUSサーバがリソース不足となる
- つまり、キーをキャッシュし再利用する仕組みが必要！
####【PMKIDキャッシングまたはSKCキャッシング】
- ローミング効果を向上させるため802.11iの改正で導入された。
- 一度接続したAPでは再接続時にPMKの再生成の必要がなくなる。
- 局所的な機能なので、グローバルなソリューションではない。
- キャッシュ数の上限が決まっているので大量のクライアントに対応できない。
####【Opportunistic Key Caching (OKC) 】
- Proactive Key Caching (PKC)ともいう
- PMKIDに似ているが、WLCを介しAP同士でキャッシュを共有できる
- 標準化されていないのでプラットフォームのサポートが制限されている
####【事前認証】
- 802.11改正で導入されたが、Ciscoでは全くサポートされていない
- ローミング前から近隣APを介し認証しておくソリューション
- クライアントが複数のAPで事前認証を行うのでRADIUSの負荷が高い
####【CCKM Cisco Centralized Key Management (CCKM)】
- Cisco独自の高速で安全なローミング方法
- ワイヤレスクライアントは、EAP認証と4ウェイハンドシェイクを経て、コントローラがクライアントのPMKを1時間キャッシュする。
- 同一モビリティグループ内でキャッシュの共有可能
####【802.11r: 高速 BSS 移行（FT）】
- 802.11r改正で高速セキュアローミングの標準として定義される。
- PMKが２つに分割されている。
- MSK⇒PMK-R0⇒PMK-R1の順で派生。
- R0はコントローラーで保持、R1はAPで保持？？
####【FT4ウェイハンドシェイクへの参加方法】
- オーバーザエア：次期AP に直接連絡
- オーバーザDS交換：DS または有線ネットワークを介して次期APに連絡
####【802.11rの機能要件】
- 独自のハンドシェイクとキー構造の為、クライアント・コントローラー両者でサポートされている必要がある。
####【FT非対応デバイスへの対策】
- 混合モードやハイブリッドモードが定義されているが万能ではない。
- Ciscoでは独自にアダプティブモードを設けて対策されている。