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到货替换）
5th 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测试。