驗證CMX位置限制和硬體要求

簡介

本檔案介紹互連行動體驗(CMX)位置的硬體需求、其軟體限制以及超出這些限制時的潛在後果。 

採用元件

• 映像版本為8.8.120的3504無線LAN控制器(WLC)
• MSE 3375物理裝置上安裝的CMX 10.6.1-47

本文中描述的所有命令、要求和限制都適用於在VMware ESXi(vSphere)或物理裝置Mobility Service Engine(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硬碟	SSD或SAS硬碟	SSD或SAS硬碟

表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
儲存	4個600GB SAS硬碟	2個960GB SATA固態硬碟
外形規格	1U	1U

表2. MSE裝置硬體規格

CMX限制

CMX位置可以處理的資料量在很大程度上取決於節點大小。下限、標準和高端節點的軟體限制可在表3中找到：

限制	低端	標準	高端
最大AP	2,000	5,000	10,000
每天跟蹤的最大唯一MAC地址（無論是否使用Hyperlocation）	25,000	50,000	90,000
Hyperlocation支援	否	否	是
最大唯一活動客戶端數（啟用Hyperlocation）	X	X	9,000
每月最大唯一MAC地址數（請參閱註釋*）	400,000	400,000	400,000
最大區域數	150	600	900
最大對映元素數	200	750	1000
每秒最大MAC位置API V3請求數	1	10	60
每秒最大NMSP消息數	750	1300	2500
每秒最大北向通知數	10	50	300
北向通知接收方的最大數量	5	5	5
每秒最大CMX連線數	10	10	10

表3. CMX位置限制

附註：在一個月的持續時間內，唯一mac地址的數量超過400,000個後，CMX停止無法區分返回的新訪問者和訪問者。除非超出其他限制，否則其他服務將繼續運行。

資源不足和超出限制時的後果

如果超出表3中提到的限制，可能會對CMX節點產生致命的影響。在安裝CMX節點之前，請確保估計部署規模，並確定適合您需求的部署規模。

如果部署規模過大（即使對於多個CMX節點），請考慮遷移至DNA Spaces（思科新的基於雲的分析平台，可取代CMX）。使用DNA Spaces，所有計算都將被解除安裝到雲基礎設施，在此根據負載動態分配資源。

下面的所有症狀和建議的解決方法都基於技術支援中心(TAC)以前在部署方面的經驗，部署範圍從單個低端節點到覆蓋數百個位置的多個高端節點。

有關如何處理超載CMX的其他資訊，請參閱文檔：https://www.cisco.com/c/en/us/support/docs/wireless/connected-mobile-experiences/214894-optimize-cmx-performance.html

每月超過400,000個唯一MAC地址

症狀：

• CMX停止對新訪問者和返回訪問者的區分。除非超出其他限制，否則其他位置服務將繼續工作
  

因應措施:

• 禁用探測客戶端跟蹤
• 如果網路由多個控制器組成並且一個高端節點不夠，請考慮從多個控制器到多個CMX節點的負載分佈
• 如果對單個控制器而言，一個高端配置是不夠的，請考慮將WLC升級到8.8或更高版本以及使用特殊的CMX分組功能，該功能允許單個WLC將資料部分解除安裝到多個CMX節點
  
• 考慮遷移到DNA Spaces，這是一種取代CMX的基於雲的分析服務。所有工作負載都分流到可動態擴展的雲基礎設施

超過每天唯一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節點的大小（低端 — >標準 — >高端），或部署其他CMX節點以重新分配負載
• 考慮遷移到DNA Spaces，這是一種取代CMX的基於雲的分析服務。所有工作負載都分流到可動態擴展的雲基礎設施
• 如果向單個CMX中新增了多個控制器，請在監控每日裝置總數時，刪除所有這些控制器，並嘗試每天逐個將它們重新新增回來

超過對映元素的數量

症狀：

• 慢速Web介面，特別是「檢測和定位」頁籤
• 崩潰的CMX服務
• 丟失分析資料

因應措施:

• 增加CMX節點的大小（低端 — >標準 — >高端），或部署其他CMX節點
  
• 刪除一些對映元素

超過每秒的NMSP消息數

將大量負載較重的控制器新增到單個CMX節點時，通常會出現此問題。

症狀：

• 慢速Web介面
• 丟失分析資料
• CPU和記憶體使用率高
• 崩潰或無法啟動的CMX服務
• techsupport日誌捆綁包的analyticsserver.log中的錯誤消息顯示： 

  Notification queue is full  - incoming notifications are being rejected. Please increase more processing capacity

因應措施:

• 部署額外的CMX節點以分擔負載
• 考慮遷移到DNA Spaces，這是一種取代CMX的基於雲的分析服務。所有工作負載都分流到可動態擴展的雲基礎設施

超出每秒北向通知的數目

將CMX配置為向大量伺服器傳送通知時，通常會出現此問題。CMX 10.6.3引入了5個北向通知接收者的限制

症狀：

• 通知丟棄會導致接收通知的伺服器上資料不準確/不完整
  

因應措施:

• 刪除一些已配置的通知接收器
  
• 增加CMX節點（低端 — >標準 — >高端）或部署更多節點

探查使用者端的MAC隨機化和追蹤

MAC隨機化

在關聯到無線網路之前，無線裝置首先需要傳送探測請求。裝置可以探查以前與之關聯的特定SSID，也可以傳送「常規」探測請求，也稱為萬用字元。 

任何偵聽探測請求的無線裝置都可以「偵聽」探測，注意裝置的存在，如果可能，以多達幾米的準確程度記錄裝置的位置。

由於隱私問題日益增多，2014年Cisco IOS 8發佈後，智慧手機製造商開始實施一項名為MAC隨機化的功能，裝置在每次傳送探測請求時使用隨機生成的新MAC地址。 

當製造商生成用於傳送探測請求的隨機mac地址時，它們可以使用通用或本地管理的mac地址。 

本地管理的mac地址將地址第一個二進位制八位數中第二最低有效位設定為1。此位充當標誌，用於宣佈mac地址實際上是一個隨機生成的地址。

本地管理的MAC地址有四種可能的格式（x可以是任何十六進位制值）

• 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地址的前三個八位組稱為組織唯一識別符號(OUI)，它們特定於製造商。

每個製造商都分配了特定數量的唯一OUI。 

在運行IOS 12.3（傳送探測請求）的iPhone的無線捕獲中，我們可以看到，如果裝置螢幕開啟，探測請求每隔幾秒鐘傳送一次；如果裝置螢幕關閉，每隔幾分鐘傳送一次。

我們看到本地管理的位設定為1。隨著IOS 14和Android 10的發佈，當裝置與網路關聯時，也會使用隨機mac地址。裝置通常使用每個SSID的一個隨機本地管理MAC地址。

CMX和探測客戶端跟蹤

CMX能夠跟蹤僅探測的客戶端。預設情況下啟用此選項。

若要排除使用本地管理MAC地址的客戶端，請選中System > Settings > Filtering下的「Enable Locally Managed MAC Filtering」選項。

此欄位存在於CMX 10.5.x中，但已從10.6.x Web介面中刪除，並且預設情況下已啟用。

某些製造商在探測時決定不使用本地管理的地址。CMX無法區分隨機非本地管理的MAC地址與裝置的實際實際MAC地址。 這意味著此類客戶端裝置每次傳送新的探測請求時，都可以記錄為新客戶端。在使用過程中，在1分鐘內，普通智慧手機會探測幾次。在CMX上，此類裝置每次被記錄為多個不同的客戶端。這完全扭曲了CMX分析，有時會導致幾乎無法使用的分析資料。 

當裝置關聯到同一個SSID時，始終使用一個MAC地址，該地址從不改變（該地址可以是實際的，也可以是本地管理的隨機MAC）。 關聯客戶端的數量始終小於或等於僅傳送探測的客戶端的數量。

不應將僅探測的客戶端跟蹤用作訪問者計數器。不過，它可以用來跟蹤每日趨勢（例如，如果星期三比星期二繁忙），但即使如此，資料也可能因極大的變化而不準確。 

Cisco TAC通常處理大型部署（機場、商場、開放公共區域）的問題，在這些大型部署中，僅通過探測的客戶端跟蹤每天都會引入非常大量的唯一MAC地址，即使高端CMX節點也無法處理（每天超過90,000個）。

如果只跟蹤關聯的客戶端，則會減少記錄的客戶端總數，但使收集的分析資料準確。

Cisco TAC強烈建議啟用「排除僅探測客戶端」選項。

相關錯誤

• 思科錯誤ID CSCvq25953 — 啟用位置SSID過濾將禁用排除本地管理的MAC，反之亦然
• 思科漏洞ID CSCvo43574 - CMX會過濾掉與本地管理的MAC地址關聯
• 思科漏洞ID CSCvs85182 - Cmxos verify命令錯誤，無法判斷硬碟最低要求