發布時間:2019-03-20
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隧道無法建立的流程圖(高清版請關注“銳捷無線百科”回復“隧道無法建立”獲取!):

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

