在MM架構下，Controller稱為MD。一般使用MM架構，下方會部署兩台控制器。
客戶反應自己連不上，結果仔細看，是自己連的AP的Active Controller在MD1、Standby Controller 為0.0.0.0(理論上要在MD2)，而他自己使用者是分到MD2。
透過「show ap client trail-info <MAC>」在MM上可以看到使用者斷線原因寫著「UAC DOWN」。(在MD1、MD2上使用相同指令看不到相同訊息)
因此判斷，是基於某種因素，導致AP可以跟MD1建立連線，而跟MD2無法建立連線。
AP有很多個，並不是全部AP都這樣子。
於是先嘗試AP重新開機，數次無果。
透過「show ap tech-support ap-name <name>」，可以看到LOG為AP有嘗試與MD2建立ISAKMP但失敗的訊息。而在各台(MM、MD1、MD2)使用「show log all | include <ap mac>」是無訊息的。
稍早有重做一次Controller的Cluster，確定資料有正常同步，用指令檢查狀態正常。但也不能排除有部分資料沒有同步，因此我覺得應該是AP的憑證訊息沒有同步到MD2上，所以MD2不認得，不放行。
環境有啟用「CPSEC」。
因此，想一想IPSEC建不起來的狀況與環境參數，想到的方法可能要重做一邊CPSEC啟用下的AP報到。
由於AP已經裝定位，CPSEC啟用在AP設定的只是一個參數，為了改掉那個參數，我打算先設好AP參數再使用「provision-ap reprovision ap-name <ap-name>」去調整。之前有想過這樣做但沒有做過，所以就先拿自己的LAB機練習。
為了還原在CPSEC啟用下的AP報到，我刪掉Allowlist。
發現曾經報到過的AP，Allowlist不用填，即使在CPSEC啟用下也能順利報到。
嘗試幾次修改不成，AP都會自動加回來，沒有詢問沒有Alert。算了，搞不好直接刪除Allowlist中的AP MAC，再次重加回來，也許AP憑證就能被MD2識別到。
打算從真實環境中做，有刪沒有刪Allowlist，AP都會報到，所以來試試看。畢竟快沒招了，下一招就是重開MD2。
最後有個驚人的發現「那些AP的MAC不在Allowlist內」。
加回去之後，有問題的AP就能與MD2報到了，連線正常，指令檢查也正常了。
至於為什麼AP的MAC會在Allowlist內被刪掉？這我就不想知道了。
(一般SE都會認為要加到Allowlist才會正常，在建置時會弄好這一塊，然後就不會改動這一塊。所以應該是…….小精靈作祟！)