WLC2504 AP1815 客戶端掉線丟包排錯「日誌」

 2020年，Corona Virus 席捲全球。 阿聯酋這個海灣小國也沒能倖免。許多公司開啓了遠程辦公模式，同屬一棟樓的DELL EMC早已執行輪班制，我司仍是飽和狀態辦公模式，直至政府禁令出臺，公司無可奈何安排員工work from home， 在這段時間，做爲公司ICT部門技術支持小謝接到了一個Case，這個Case困擾了我兩週。現分享一些排錯「日誌」與你們，但願能幫到有須要的人，也但願藉助這個平臺與各位多多交流。

某央企銀行迪拜分行客戶第一次反饋問題爲：12 樓無線網絡存在閃斷現象。11樓無線網絡正常，因爲11樓爲競爭對手安置，12樓爲我司安置，引發公司中層關注，客戶經理與個人Team Leader 微信，電話通知。讓我儘快解決這個問題，否則丟人又丟單。首先沒有拓撲圖，客戶也是急於解決問題目的，不禁分說，直接提供兩臺遠程客戶機供遠程Troubleshooting。

Anydesk 上線， 鏈接12樓電腦，電腦鏈接12樓的無線。

Day1

在12樓進行ping 8.8.8.8 丟5個包

在12樓同時對8.8.8.8 192.168.0.1進行ping測試， 發現到網關丟包。現象有了。那看架構，那就開始定位問題點。

起初我對無線配置不是很熟悉，但知道11樓和12樓都屬於一個AP group， 可能12樓AP配置問題，與11樓AP直接同步下說不定能解決，可能我喜歡賭，由於以爲網絡排錯中賭能節約不少時間。

這是11樓的AP， 沒記錄是什麼型號。在線時間是62天

這是12樓的AP， 型號是AIR-AP1815I-E-K9。把General ，Advance的配置同步了下，以11樓正常的爲基準。

11樓。

12樓。

11樓和12樓不一樣之處是11樓支持Cisco clean air。這個11樓開了就沒取消了，以爲沒啥。

修改完後等待現場客戶反饋，問題依舊。

Day2

好吧，賭翻車了。慢慢來分析把，問幾個問題，搞清網絡拓撲。

繪製網絡拓撲：

因爲基於以前的對WLC的持續排錯。AC中對不一樣樓層的交換機下掛的AP在上週已同步，包含Time out ，AP Retransmit Config Parameters，Statistics Timer。問題點先從物理層進行排除，首先TPlink做爲企業網網關，國內淘寶價89RMB,這個是十分不合理的存在，我後面找朋友們開會說到這個點的時候他們都笑了：D  在和客戶溝通的羣裏，建議更換企業路由器，推薦了型號CISCO ISR 4321,下掛的交換機屬於Dlink廠商設備，和TPlink一個樣， 不支持Console配置，支持Web配置。安裝的供應商提供了IP地址， 因爲無線是嘗試使用相同子網段進行Telenet 或Ping 沒法通訊，後面能夠理解， DHCP是WLC下發， 192.168.0.1/23，CAPWAP隧道應該是直接到WLC， 我天然也上不去那個管理地址。交換機鏈接WLC, 用的是光轉電，網線距離不夠，只能用單模光纖，你能夠理解爲。WLC電轉光→光轉電 DLINK switch ，，故障點從1個變成了3個，後期預替換，換光模塊，這個在微信羣裏說了下，客戶急着直接對11樓至12樓進行光纖更換，建造的時候冷備了鏈路還能夠。用電腦直接接DLINK ，在DLink側發現管理地址掩碼爲24位，同時修改成23位，後期然客戶進行上網體驗，因爲當地時間13:00了。客戶也急着回家了，疫情期間銀行這種相當重要的行業也只能上到14：00. 體驗後說沒問題了

一個插曲，當我在客戶羣說TP-link的存在風險，個人Team Leader 和客戶經理彷佛嗅到了商機的味道，催着客戶買了臺ISR在路上。

第二天早上，電話響了，客戶經理說仍是有問題。仍是老樣子。繼續遠程兩臺電腦。

故障現象， 遠程Laptop是使用12樓的wifi進行上網，上網過程當中會出現Session Down狀況，再次重連發現，Unreachable 與Team out消息，

15：00 -17：00  WLC :Debug Mac Address 無異常反饋。Ping一系列正常 ，無丟包狀況。

分析 ：15:00- 17：00 屬於無人辦公狀態，測試機運行正常， Ping 2000個包無丟包。

上次客戶認爲問題解決實際上是由於終端少因素所致使。

今日並未實際從12樓交換機作Ping測試到網關，保留12F交換機至WLC故障點因素。緣由是laptop鏈接DLINK交換機在沒法獲取DHCP的狀況下，配置靜態IP沒法訪問網關以及互聯網，這也DHCP由AC產生的。暫未在12F交換機找到PING命令。

和Team Leader 反饋建議明日DLINK工程師能在Dlink交換機進行ping測試。Note：這個系統是他交付的：（， 並且，DLINK那套實在搞不來。

建議明日在人流狀況大的狀況下。一臺筆記本在11樓，console  wlc 。 另一臺終端在12F使用WIFI流量進行互聯網訪問。Debug 12F筆記本的網絡狀況。應爲今天一臺電腦鏈接12樓， SSH WLC Debug， 當斷線的Debug也抓不到日誌。

經過昨日發現。推測AP是在人流量大的狀況下電腦失去Connection。物理層面：是CPU以及內存利用率高物理層面佔用致使：例如交換機TCAM表滿或廣播泛洪狀況致使。歸結硬件性能不足。2 是軟件層面， 未開STP XXX （無需再此環境開啓STP）。DHCP 空間不足（待考量?  

客戶在12樓開啓測試機， MAC地址爲84-EF-18-49-60-79 此電腦的Mac地址 。

Day3 

補充：昨日測試機associated 的AP：

AP500F.8089.E9B4

APA093.511D.DE58

APA093.511D.DE58

AP780C.F0DB.83A0（漫遊過多！！！）

AP780C.F0DB.7990 漫遊偏多。客戶AP屬於自行安裝，沒作前期較完善上的無線環境勘測

Ping包不丟包，詢問客戶測試機所屬樓層很少， 對測試機進行流量測試。打開Youtube進行視頻流量傳輸。期間出現屢次斷線。

執行Debug命令

Debug Client 84-EF-18-49-60-79

Debug Mobility Handoff enable

抓到如下內容

(Cisco Controller) >*spamApTask0: Apr 20 01:27:30.625: 84:ef:18:49:60:79 Cleaning up state for STA 84:ef:18:49:60:79 due to event for AP a0:93:51:b6:a4:60(0)
*apfReceiveTask: Apr 20 01:27:30.627: 84:ef:18:49:60:79 apfSendDisAssocMsgDebug (apf_80211.c:3731) Changing state for mobile 84:ef:18:49:60:79 on AP a0:93:51:b6:a4:60 from Associated to Disassociated
 
*apfReceiveTask: Apr 20 01:27:30.627: 84:ef:18:49:60:79 Sent Disassociate to mobile on AP a0:93:51:b6:a4:60-0 on BSSID a0:93:51:b6:a4:62(reason 1, caller apf_ms.c:7735)
*apfReceiveTask: Apr 20 01:27:30.627: 84:ef:18:49:60:79 Scheduling deletion of Mobile Station:  (callerId: 45) in 10 seconds
*apfOpenDtlSocket: Apr 20 01:27:32.357: 84:ef:18:49:60:79 Recevied management frame ASSOCIATION REQUEST  on BSSID a0:93:51:9d:7c:40 destination addr a0:93:51:9d:7c:42
*apfMsConnTask_3: Apr 20 01:27:32.358: 84:ef:18:49:60:79 Processing assoc-req station:84:ef:18:49:60:79 AP:a0:93:51:9d:7c:40-00 ssid : ALFATTAN0 thread:1b77da40
*apfMsConnTask_3: Apr 20 01:27:32.358: 84:ef:18:49:60:79 Station:  84:EF:18:49:60:79  trying to join WLAN with RSSI 0. Checking for XOR roam conditions on AP:  A0:93:51:9D:7C:40  Slot: 0
*apfMsConnTask_3: Apr 20 01:27:32.358: 84:ef:18:49:60:79 Station:  84:EF:18:49:60:79  is associating to AP  A0:93:51:9D:7C:40  which is not XOR roam capable
*apfMsConnTask_3: Apr 20 01:27:32.358: 84:ef:18:49:60:79 Association received from mobile on BSSID a0:93:51:9d:7c:42 AP APA093.511D.CAD0
*apfMsConnTask_3: Apr 20 01:27:32.358: 84:ef:18:49:60:79 Station:  84:EF:18:49:60:79  trying to join WLAN with RSSI 0. Checking for XOR roam conditions on AP:  A0:93:51:9D:7C:40  Slot: 0
*apfMsConnTask_3: Apr 20 01:27:32.358: 84:ef:18:49:60:79 Station:  84:EF:18:49:60:79  is associating to AP  A0:93:51:9D:7C:40  which is not XOR roam capable
*apfMsConnTask_3: Apr 20 01:27:32.358: 84:ef:18:49:60:79 Global 200 Clients are allowed to AP radio

關鍵信息：

spamApTask0: Apr 20 01:27:30.625: 84:ef:18:49:60:79 Cleaning up state for STA 84:ef:18:49:60:79 due to event for AP a0:93:51:b6:a4:60(0)

所屬AP的事件致使這次STA關係被重置。

找Google：順便分享一個排錯文檔。

https://www.ciscolive.com/c/dam/r/ciscolive/apjc/docs/2019/pdf/BRKEWN-3081.pdf

經過這個文檔找到的是

There are normal radio resets: Channel changes, etc----Refer to Cisco Live Docs

AP的Channel存在重置。 相似信道。建議：

Show cont D0 | b Rest

明日補充

Check Radio Resets

show dhcp proxy

很好，找到了問題點了。和客戶約了時間明天現場見了。沒和Team Leader 說找到問題了，只是說去現場確認下，避免幹了一天沒幹好回來很被動。同時準備下出門的文件，那時疫情影響出門是須要公司寫說明書以及總經理簽字的。

同時通過一天的檢查，DHCP也是頗有問題的， WLC開了DHCP地址池也開了dhcp中繼，TPlink也開了DHCP地址池。因爲12樓客戶老闆在，爲了保障老闆的體驗，也從出口的TPlink單獨拉了根網線到12樓，又接了個TPlink 。這網絡真糟糕。

Day 4

前往客戶現場進行調查排錯。

Check Radio Resets 爲AP命令， 因爲AP吊頂沒法進行console檢查。根據上日所瞭解文檔。問題我的歸結爲射頻，信道問題。

現場人工修正信道。無效果，現場觀察300m 樓層加裝了足足有8個AP，10步不到一個，這屬於不合理的。 修改射頻Power值，關了幾個相鄰過近的AP，測試了半個小時。暫未發現問題。

ping了8000多個包，沒有連續丟包的狀況。

客戶到點下班。在離開的最後一刻，出現丟包狀況。我當時差點暈過去了.沒截上圖。

回到家後，繼續遠程， 把12樓的AP關的還剩下1個，仍是丟包。

Day5

昨天和客戶說了AP設計不合理的問題，客戶現場移除8個AP中4個AP，很顯然問題依舊

回過頭看DHCP問題。

這是全網的DHCP圖。 左上角是老闆的TPLINK。客戶遠程機1號分別鏈接了12樓老闆的TP-link 也可切換至12樓的Cisco AP，遠程機2號鏈接11樓的AP。

問題會致使了前期規劃的192.168.0.1/23位網段與192.168.1.1/24位網段衝突。且，網絡出口TPlink 開了DHCP地址池， 後來發現WLC也存在Internal DHCP地址池，這麼看這個小型辦公網存在3個DHCP地址池。，查看出口路由器 ,WLC 地址分配狀況。 AP下的IP 地址都是WLC分配的， 可是觀察WLC還啓用的DHCP Proxy。這個功能其實又是讓終端去找真實的TPlink DHCP。

回顧Debug client 報文。 發現連續5個DHCP信息。

選擇中繼的消息不少，能夠看到DHCP Gateway是在去到TPlink，可是服務器是192.168.0.222（WLC）

鑑於這種狀況。準備修改DHCP地址池，因爲遠程操做。修改DHCP可能會致使遠程機沒法通訊。也有可能會致使客戶全網斷網而沒法繼續遠程修復。固然我也能夠冒險，萬一崩了明天敢在客戶上班前去客戶現場改回來。

可是。如果存在DHCP衝突，那部分客戶機應該直接提示IP地址衝突。可是連續5個DHCP信息報文時間間隔也符合這次丟包時間。隨後回補RFC 2132，未發現問題所在。

再次轉移關注點。在11樓測試時竟然也發現丟包狀況。深刻研究WLC配置。修改數個參數問題依舊。可是12樓掉線狀況遠比11樓嚴重的多，11樓問題歸結於TPlink .嘗試TP-Link 長ping 8.8.8.8  . 結果只能ping 100個包 。（待ISR到貨替換）

5^th day

時間愈來愈緊迫，也給我帶來了不少焦慮。Team Leader屢次致電與我，詢問具體狀況，問我有沒有定位問題，我說沒有，他說怎麼可能，排查了這麼久。我只能解釋可能WLC AP,L2switch 都有問題了。「買的路由器也要快到貨。路由器到貨那天必須解決問題」。我忽然以爲這是在給我挖坑。其實我當天只是說TPLINK是個不合理的存在，並不說一眼看出問題就在TPlink上。也多是我在給本身挖坑，

隨後開始尋找外部力量了。首先就是給Cisco 發Case，WLC過了延保，AP系統查不到銷售渠道。Cisco婉拒了。

郵件微信拉會了上海DD和HK的同事進行三場會議討論。 

得出如下結論以及下次去現場解決思路

1排除DHCP 地址池問題，排除STP問題，雖然架構很糟糕， 但並未產生影響。

2 信道衝突疑點較大。「12樓大多數的AP，可是若是樓層的水泥層不是特別的厚，11樓的AP信號同樣能夠上到12樓」測試終端安裝Inssider，觀察是否有信道衝突。關閉2.4G的WiFi信號，只放5G信號出來，固然是全部終端都支持5G的狀況。

3 11樓設備開啓Clean Air 功能，12樓設備未開啓，此功能具有Noise 消除功能

上海DD: 關閉Clean Air嘗試 ， 存在可能 11 樓把12無線幹了，可是Cisco應該不會自相傷害。

HK同事： 開啓全部Clean Air 嘗試，消除12樓潛在干擾源。微波爐 電冰箱等。

4, 12樓交換機現場查看web界面是否有存在瓶頸，查詢交換機型號 POE供電爲7.5w per port MAX

5 將12，11樓交換機互換， 將12 ，11 樓AP互換。測試.

當天遠程客戶機就安裝了inssider，沒有看到信道衝突的狀況，12樓AP保留一個只開啓5.0GHZ仍然沒用。

2樓AP無Clean Air 功能，隨關閉11樓Clean Air功能，問題依舊。

而後一塊上了設備瞅瞅。

查詢WLC 日誌：

AP Disassociated. Base Radio MAC:a0:93:51:90:42:a0 ApName - APA093.511D.ACE8

802.1 a 802.1b

AP's Interface:1(802.11a) Operation State Up: Base Radio MAC:a0:93:51:9d:b0:a0 Cause=Unknown Reset Status:NA

7              Thu Apr 23 05:43:20 2020             AP's Interface:0(802.11b) Operation State Up: Base Radio MAC:a0:93:51:9d:b0:a0 Cause=Unknown Reset Status:N

30           Thu Apr 23 05:37:36 2020             AP 'APA093.511D.CAD0', MAC: a0:93:51:9d:7c:40 disassociated previously due to Link Failure. Uptime: 1 days, 07 h 02 m 27 s . Reason: Capwap Discovery Request.

Cisco Community 查看相同問題，暫未有Solved

AP 斷線，可是WLC web界面顯示AP保持在線 ，時長31天。

Day6 

路由器到了。Teamleader下午來電要我去現場，上午我從當地二手市場600大洋購買了一臺3750 100MB的15.4W POE，包郵，疫情期間能作到這樣仍是很感激了.

二次前往現場， 設置ISR,  替換TPLINK ，設置ISR爲WLC地址池， 關閉WLC Internal DHCP ，排除掉TP link 問題。問題依舊。 替換11 與12樓的樓宇光纖，問題依舊。替換12樓交換機爲Cisco L3 PoE switch ，問題依舊。上天花板直接拆除11 12 樓AP進行互換測試。

11 樓AP到12 樓運行正常，

12樓AP到11樓問題依舊。

再次上天花板拆12樓AP到11樓測試。問題依舊。很明顯 AP的問題了!

Console  AP

0 21:15:23.2899] ess_edma c080000.edma: wired0: GMAC Link is down

[04/25/2020 21:15:25.3499] ess_edma c080000.edma: wired0: GMAC Link is up with phy_speed=100

[*04/25/2020 21:15:36.4699] Failed to get ARP entry for WLC 192.168.0.222

[*04/25/2020 21:15:44.0799] Failed to get ARP entry for WLC 192.168.0.222

AP 隨後進入重啓。

此問題。Cisco Bug: 有相同問題，且型號類似一致：

雖然TAC對此回答是升級OS. 但其實早在昨日我已所有升級WLC aes版本（AIR-CT2500-K9-8-5-161-0)，下推到了全部AP 。仔細看了下，原來是底層OS的問題。

來此Cisco 的work around:

Symptom:
An AP may be unable to join its WLC or ME controller. Messages similar to the following may be logged
repetitively on the AP console:

[*08/02/2016 15:39:20.5741] Failed to get ARP entry for WLC 192.168.6.108
[*08/02/2016 15:39:28.1767] Failed to get ARP entry for WLC 192.168.6.108

or

[*08/09/2016 05:06:38.4767] WTP Message Send Failed for CAPWAP_WTP_EVENT_REQUEST(msgType 9 msgLevel 3 msgId 24 len 559)
[*08/09/2016 05:07:20.3336] CAPWAP msg queue already full. Discard new msg(type 9, CAPWAP_WTP_EVENT_REQUEST).

Conditions:
AP-COS AP

Workaround:
reload the AP

重灌AP的固件。

頓時恍然大悟，以前一直漫遊也是由於有AP在不斷重啓的時候致使，還有雖然AP會重啓，可是回看以前對AP的截圖他的在網時間是31天，總結仍是當時沒注意到當時WLC的Summary日誌，其實早點看那個或許時間會縮短不少。

滑稽的事出現了。個人Teamleader：「這麼簡單的事，爲啥不早點發現」

是啊 爲何不早點發現，最後我要吐點苦水了。設備上線就一直有這個問題，持續了大半年，並且是一個央企的在中東金融中心的辦公網絡，並且12樓坐的是他們的老闆。我很想反問一句UAT測試去哪了？能持續大半年也是靠着客戶經理作的關係，以及每次出故障就重啓WLC的方式來解決，如同解決電腦死機同樣。

下班後，一我的抱着3750回去的出租車上，看着閃耀的迪拜塔深深嘆了口氣。

郵件結尾：

結論：建議供應商重裝AP OS，建議交付期間必須有完整的UAT測試。