概要

    このドキュメントでは、Connected Mobile Experience(CMX)ロケーションのハードウェア要件、そのソフトウェアの制限、および超過した場合の潜在的な影響について説明します。 

    使用するコンポーネント

    • 3504 Wireless LAN Controller(WLC)、イメージバージョン8.8.120
    • MSE 3375物理アプライアンスにインストールされたCMX 10.6.1-47

    この記事で説明されているすべてのコマンド、要件、および制限は、VMware ESXi(vSphere)または物理アプライアンスのモビリティサービスエンジン(MSE)3365/3375で実行されるCMX 10.5以降に適用されます。

    このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

    低、標準、およびハイエンドノードのハードウェア要件

    使用可能なリソースの量によって決定され、展開されたCMXノードは、ローエンド、標準、ハイエンドのいずれかです。MSE 3365および3375アプライアンスで実行されるCMXは、デフォルトではハイエンドです。 

    表1に、3つすべてのノードタイプのハードウェア要件(プロセッサ(CPU)/メモリ(RAM)/ディスク)を示します。

    ハードウェア要件 ローエンド 標準 ハイエンド
    CPUコア 8 vCPU/4物理コア 16 vCPU/8物理コア 20 vCPU/10物理コア
    最小CPUベース周波数 2.3 GHz   2.3 GHz   2.3 GHz 
    RAM 24 GB 48 GB 64 GB
    ストレージ 550 GB 550 GB 1 TB
    ストレージタイプ SSDまたはSAS HDD SSDまたはSAS HDD SSDまたはSAS HDD

    表1. CMXハードウェア要件

    MSE 3365およびMSE 3375のハードウェア仕様

    MSE 3365および3375アプライアンスには、ハイエンドCMXノードの導入に十分なリソースがあります。ハードウェアの仕様は、表2を参照してください。

    ハードウェア仕様 MSE 3375 MSE 3375
    CPU 10コアIntel E5-2650 v3 @2.4 GHz 12コアIntel Xeon Gold 5118 @2.4 GHz
    ストレージ 600 GB SAS HDD X 4 960 GB SATA SSD X 2
    フォーム ファクタ 1U 1U

    表2. MSEアプライアンスのハードウェア仕様

    CMXの制限事項

    CMXロケーションが処理できるデータ量は、ノードサイズによって大きく異なります。Low、Standard、およびHigh-endノードのソフトウェア制限は、表3に示されています。

    制限 ローエンド 標準 ハイエンド
    最大AP数 2,000 5,000 10,000
    1日ごとに追跡される一意の最大MACアドレス（ハイパーロケーションあり/なし） 25,000 50,000 90,000
    ハイパーロケーションサポート No No Yes
    最大の一意のアクティブクライアント（ハイパーロケーションが有効） X X 9,000
    1ヵ月あたりの一意なMACアドレスの最大数（注*を参照） 400,000 400,000 400,000
    最大ゾーン 150 600 900
    最大マップ要素 200 750 1,000
    1秒あたりの最大MACロケーションAPI V3要求 1 10 60
    1秒あたりの最大NMSPメッセージ数 750 1300 2500
    1秒あたりのノースバウンド通知の最大数 10 50 300
    ノースバウンド通知レシーバの最大数
    		 5 5 5
    1秒あたりの最大CMX接続数 10 10 10

    表3. CMXロケーションの制限

    注：1ヵ月の間に一意のMACアドレスの数が400,000を超えると、CMXの停止は新しい訪問者と戻ってくる訪問者を区別できません。他のサービスは、他の制限を超えない限り機能し続けます。

    リソースが不足し、制限を超えた場合の結果

    表3に示されている制限を超えると、CMXノードに重大な影響を及ぼす可能性があります。CMXノードをインストールする前に、導入の規模を見積もり、ニーズに合った導入サイズを決定してください。

    複数のCMXノードに対しても導入サイズが大きすぎる場合は、CMXの代わりに使用できるシスコの新しいクラウドベース分析プラットフォームであるDNA Spacesへの移行を検討してください。DNA空間では、すべての計算がクラウドインフラストラクチャにオフロードされ、負荷に基づいてリソースが動的に割り当てられます。

    次に示すすべての症状と提案された回避策は、単一のローエンドノードから数百のロケーションをカバーする複数のハイエンドノードに至る展開におけるTechnical Assistance Center(TAC)の以前の経験に基づいています。

    過負荷のCMXの処理方法の詳細については、次のドキュメントを参照してください。https://www.cisco.com/c/en/us/support/docs/wireless/connected-mobile-experiences/214894-optimize-cmx-performance.html

    1ヵ月あたり400,000を超える一意のMACアドレス

    症状：

    • CMXは、新しい訪問者と戻ってくる訪問者を区別する能力を停止します。他の制限を超えない限り、他のロケーションサービスは引き続き動作します

    回避策：

    • プローブするクライアントの追跡を無効にする
    • ネットワークが複数のコントローラで構成され、1つのハイエンドノードでは十分でない場合は、複数のコントローラから複数のCMXノードへの負荷の分散を考慮してください
    • 1つのハイエンドコントローラで十分でない場合は、WLCを8.8以降のバージョンにアップグレードし、単一のWLCで複数のCMXノードにデータの一部をオフロードできる特別なCMXグループ化機能を使用することを検討してください
    • CMXに代わるクラウドベースの分析サービスであるDNA Spacesへの移行を検討してください。すべてのワークロードを動的に拡張可能なクラウドインフラストラクチャにオフロード

    1日ごとの一意なMACアドレスの最大量の超過

    症状：

    • 非常に遅い、または壊れたWebインターフェイス
    • CPUおよびメモリの高使用率
    • 分析データの損失
    • クラッシュするか、起動できないCMXサービス
    • 再インストールが必要なデータの回復不能な破損
    • techsupportログバンドルのlocationserver.log内に次のエラーメッセージが表示されます。  
      Cleaning up element counts, unique devices 347684, locally administered macs 0 as partof daily midnight job

    回避策：

    • 少なくともCMXが安定するまで、クライアントのプローブの追跡を停止します
    • CMXノードのサイズを大きくするか([Low-end] -> [Standard] -> [High-end])、追加のCMXノードを導入して負荷を再配分します
    • CMXに代わるクラウドベースの分析サービスであるDNA Spacesへの移行を検討してください。すべてのワークロードを動的に拡張可能なクラウドインフラストラクチャにオフロード
    • 1つのCMXに複数のコントローラが追加されている場合は、すべてのコントローラを削除し、毎日のデバイス総数をモニタしながら、1日に1つずつ追加し直してみます

    マップ要素の数の超過

    症状：

    • 低速Webインターフェイス、特に[Detect & Locate]タブ
    • クラッシュするCMXサービス
    • 分析データの損失

    回避策：

    • CMXノードのサイズを大きくするか([Low-end] -> [Standard] -> [High-end])、追加のCMXノードを導入します
    • マップ要素の一部を削除します

    1秒あたりのNMSPメッセージ数の超過

    この問題は通常、負荷の高いコントローラが1つのCMXノードに大量に追加されたときに発生します。

    症状：

    • 低速Webインターフェイス
    • 分析データの損失
    • CPUおよびメモリの高使用率
    • クラッシュするか、起動できないCMXサービス
    • techsupportログバンドルのanalyticsserver.log内に次のエラーメッセージが表示されます。  
      Notification queue is full  - incoming notifications are being rejected. Please increase more processing capacity

    回避策：

    • 負荷を分割するための追加CMXノードの導入
    • CMXに代わるクラウドベースの分析サービスであるDNA Spacesへの移行を検討してください。すべてのワークロードを動的に拡張可能なクラウドインフラストラクチャにオフロード

    1秒あたりのノースバウンド通知の数の超過

    この問題は通常、CMXが多数のサーバに通知を送信するように設定されている場合に発生します。CMX 10.6.3では5つのノースバウンド通知レシーバの制限が導入されています

    症状：

    • 通知を受け取るサーバ上のデータが不正確または不完全になる通知ドロップ

    回避策：

    • 設定された通知レシーバの一部を削除します
    • CMXノードのサイズ(ローエンド – > [標準(Standard)] -> [ハイエンド(High-end)])または追加ノードの導入を拡大します。

    プローブするクライアントのMACランダム化とトラッキング

    MACランダム化

    無線ネットワークへの関連付けを行う前に、無線デバイスはまずプローブ要求を送信する必要があります。デバイスは、以前に関連付けられた特定のSSIDをプローブするか、ワイルドカードとも呼ばれる「一般」プローブ要求を送信できます。 

    プローブ要求をリッスンするワイヤレスデバイスは、プローブを「聞く」ことができ、デバイスの存在をメモし、可能であれば、デバイスの場所を数メートルまでの精度で記録できます。

    プライバシー上の懸念の増大に伴い、2014年にCisco IOS 8がリリースされ、携帯電話のメーカーは、プローブ要求を送信するたびにデバイスがランダムに生成された新しいMACアドレスを使用するMACランダム化という機能をを実装しを開始しました。 

    プローブ要求の送信に使用されるランダムMACアドレスを生成する場合、メーカーはユニバーサルまたはローカルで管理されるMACアドレスを使用することができます。 

    ローカルに管理されるMACアドレスは、アドレスの最初のオクテットの2番目の最下位ビットが1に設定されます。このビットは、MACアドレスが実際にランダムに生成されたものであることを通知するフラグとして機能します。

    ローカルに管理されるMACアドレスには、4つの形式があります（xは任意の16進値にすることができます）

    • x2-xx-xx-xx-xx-xx
    • x6-xx-xx-xx-xx-xx
    • xA-xx-xx-xx-xx-xx
    • xE-xx-xx-xx-xx-xx

    他のすべてのMACアドレスは、ユニバーサルに管理されるものと見なされます。ユニバーサルに管理されるMACアドレスの最初の3つのオクテットはOrganizational Unique Identifier(OUI)と呼ばれ、これらはメーカー固有のものです。

    各メーカーは、特定の数の一意のOUIを割り当てています。 

    プローブ要求を送信するIOS 12.3を実行するiPhoneの地上波キャプチャでは、デバイスの画面がオンの場合は数秒ごとにプローブ要求が送信され、デバイスの画面がオフの場合は数分ごとに送信されます。

    ローカル管理ビットが1に設定されていることがわかります。IOS 14およびAndroid 10のリリースでは、ランダム化されたMACアドレスが、デバイスがネットワークに関連付けられたときに使用されます。通常、デバイスはSSIDごとに1つのランダム化されたローカル管理MACアドレスを使用します。

    iphone probe

    CMXおよびプローブするクライアントのトラッキング

    CMXには、プローブのみを実行するクライアントを追跡する機能があります。このオプションは、デフォルトで有効です。

    ローカルに管理されたMACアドレスを使用するクライアントを除外するには、[System] > [Settings] > [Filtering] の[Enable Locally Managed MAC Filtering]オプションをオンにします。

    このフィールドはCMX 10.5.xにありますが、10.6.x Webインターフェイスから削除され、デフォルトで有効になっています。

    CMX Filtering Parameters

    一部のメーカーでは、プローブ時にローカルで管理されたアドレスを使用しないことを決定しています。CMXには、ランダムでローカルに管理されていないMACアドレスと、デバイスの実際のMACアドレスを区別する方法はありません。 つまり、新しいプローブ要求を送信するたびに、そのようなクライアントデバイスが新しいクライアントとして記録されます。使用中は、1分間に携帯電話の平均プローブが数回使用されます。CMXでは、このようなデバイスは毎回複数の異なるクライアントとして記録されます。これにより、CMX分析が完全に歪み、時にはほとんど使用できない分析データが生じます。 

    デバイスが同じSSIDに関連付けられている場合、デバイスは常に1つのMACアドレスを使用します。このアドレスは変更されません（このアドレスは、実際のMACアドレスでもローカルに管理されるランダムMACでも構いません）。 関連付けられたクライアントの数は、プローブだけを送信するクライアントの数と常に同じか、または少なくなります。

    プローブのみのクライアントのトラックはビジターカウンターとして使用されるはずがありません。ただし、日次の傾向を追跡するために使用できます（たとえば、水曜日が火曜日より忙しい場合）。ただし、そのデータは非常に大きな変動のために不正確になる可能性があります。 

    Cisco TACは、プローブのみのクライアントのトラックが1日に非常に多くの一意のMACアドレスを導入し、ハイエンドのCMXノードでも処理できない大規模な導入（空港、モール、オープンパブリックエリア）の問題を扱います。

    関連付けられたクライアントのみを追跡する場合は、記録されたクライアントの総数を減らしますが、収集された分析データは正確になります。

    Cisco TACでは、[Exclude Probing Only clients]オプションを有効にすることを強く推奨します。

    関連するバグ

    • Cisco Bug ID CSCvq25953 - Location SSID Filteringを有効にすると、ローカルで管理されるMACの除外が無効になり、その逆も無効になります
    • Cisco Bug ID CSCvo43574 - CMXは関連するローカルで管理されたMACアドレスを除外します
    • Cisco Bug ID CSCvs85182 - Cmxos verifyコマンドがHDDの最小要件に関して正しくない