AC組網最基礎，AP上線不能少。上線不穩最困擾，且看小銳來支招。

一陣急促的電話聲響起，小銳接到報障，AP無法在AC上穩定上線。AP上show capwap state顯示隧道狀態已經running，但是在AC上show capwap state顯示隧道狀態處于Datacheck狀態，過30S后AC和AP的隧道自動斷開。

現場摸排

該網絡拓撲中無線AP和AC是同一內網上線，AP的dhcp和網關都在友商核心上。

抽絲剝繭

AP和AC上capwap狀態不一致，隧道無法建立，小銳結合已有信息進行了如下分析：

1、確認AP和AC的通訊、配置情況

2、確認AP和AC交互流程

通過上述排查，發現相關信息都正常，此時故障陷入僵局。小銳繼續思考AP上線的幾個狀態機變化：Discover->Join->Image Date->Configuration->Date check->Run，關于AC上Date check狀態如何才能切換到Run狀態的狀態機變化如下：

從上述原理來分析，應該是AP進入Run狀態后，AC沒有收到AP發出的第一個Keep-Alive報文，導致AC狀態一直在Datacheck狀態，所以才會有30S后AC和AP隧道自動斷開的故障現象。

水落石出

小銳和現場工程師進一步溝通確認，網絡中友商核心自帶了一張AC板卡且無法關閉，可能是被友商核心將Keep-Alive報文丟棄了。為了進一步核實，小銳分別在友商核心的連接AC的接口和下聯AP的接口抓包分析。

通過過濾udp.port==5247，下圖第一張為友商核心下聯AP接口的抓包，第二張為友商核心連接AC的接口抓包：

此時很明確通過抓包對比發現，AP有發送Keep-Alive報文上來，但是路過友商核心時被丟棄了，沒有轉發給AC，導致AC上狀態一直是Datacheck，過30S隧道自動斷開。

明確故障原因后，同步給客戶，尋找友商工程師協助處理，調整友商交換機配置后問題解決。

小貼士：如果AP和AC間報文交互異常，需要中間線路抓包分析定位丟包點，以及有線環網的排查。

相關知識推薦

AP和AC的隧道無法建立時，可以通過AC查看拒絕原因：

AP和AC的隧道無法建立的情況下，假如通路正常的情況下，AP的報文已經送到AC，但是隧道無法建立的情況下，AC上可以通過show ap-config summary deny-ap查看隧道無法建立的具體原因或者結合AC上的log提示信息。

Ruijie#show ap-config summary deny-ap

Deny ap num: 0

Mac Address    AP Name                                Reason

詳細解釋如下：

附截圖為capwap隧道無法建立的流程圖（高清版請關注“銳捷無線百科”回復“隧道無法建立”獲取！）：

更多趣文，請關注“銳捷無線百科”公眾號，在“有料”-“大話無線”欄目查看。