目录
4、AP和AC跨公网上线，同一个网点的AP，部分可以上线成功，部分无法上线成功。
5、 AC、AP版本相同，但却无法在AC上正常上线，卡在join状态
7、 大部分AP无法上线成功，且已经上线的AP经常出现掉线情况，隧道状态反复
1、capwap隧道建立不成功
1)、AP与AC之间通信异常
ap 没有获取到ip地址
ap 没有获取到option 138字段
ap 无法ping通ac 建立隧道地址
capwap udp 5246、5247端口被中间设备丢弃或过滤
2) AC、AP状态异常
ac cpu 高无法处理AP上线
show cpu
ac license 不够
show ac-config
show license
show ap-config summary
命令显示举例
Ruijie#show ac-c
AC Configuration info:
max_wtp :320 // AC允许接入的最大授权数量，如果ac-c下面有做过wtp limit 限制，就是wtp limit配置的允许AP上线数
sta_limit :10240
license wtp max :32
license sta max :10240
single wtp max :320
virtual ac max :4
whole wtp max :320
serial auth :Disable
password auth :Disable
certificate auth :Disable
Bind AP MAC :Disable
AP Priority :Disable
supp_psk_cer :Disable
ac_name :Ruijie_Ac_20726a
ac location :AC_LOCATION
AC State info:
sta_num :0
act_wtp :1
localIpAddr :5.5.5.5
localIpAddr6 :::
current wtp max :320
used wtp :1.0(0 four 0 two 1 normal 0 half 0 zero) //已使用的license数量，这里已使用1个license
remain wtp :7 four 15 two 31 normal 62 half 639 zero //剩余的license数量，这里还剩余31个license
HW Ver :1.01
SW Ver :AC_RGOS 11.1(5)B9P5, Release(04230306)
Mac address :5869.6c20.726a
Product ID :WS6108
NET ID :9876543210012345
NAS ID :5869.6c20.726a
Ruijie#show license // 查看当前的license
Serial Number : G1J115100013A
No. Activation Key AP Number
-----------------------------------------------------------------------
-----------------------------------------------------------------------
Total 32 access points are supported, old version 0, new version 0. //该设备当前没有导入license，默认license为32。
WS#show ap-config summary
========= show ap status =========
Radio: E = enabled, D = disabled, N = Not exist
Current Sta number
Channel: * = Global
Power Level = Percent
Online AP number: 1 //当前的上线AP数
Offline AP number: 0
AP Name IP Address Mac Address Radio 1 Radio 2 Up/Off time State
---------------------------------------- --------------- -------------- ------------------- ------------------- ------------- -----
001a.a94e.d529 192.168.100.3 001a.a94e.d529 E 0 11* 100 E 0 157* 100 0:03:09:17 Run
ac 与ap 版本跨度大（2b15、2b117与1b19p2 ,10.x与11.x)
ap名称重名
19 16:37:19: CD-AC4 %APMG-6-AP_ADD: Add AP(1414.4b5d.03af) fail. Online-AP(1414.4b5d.097f) with same name(XS10A4-1) has exist in this AC---修改已经上线ap名称
收集以下信息，并联系4008111000
1）在AC上收集如下信息：
show version
show running
show ac-config
show license
show ap-config summary
show capwap sta
show cpu
show memory
show ip route
show ip interface brief
2）在AP上收集如下信息：
show version
show ap-mode
show capwap sta
show ip route
show log
show capwap client state (11.x， 查看ap获取option 138地址）
2、 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: 1
Mac Address AP Name Reason
-------------- ---------------------------------------- -----------------
1414.4b71.98a1 By conflict
By bind-ap-mac //AP-MAC绑定拒绝，AC上开启MAC白名单bind-ap-mac功能，但该AP的MAC不在ap-config中
By wtp-limit //在线AP数达到上限，一般是license不足、在线AP容量上限、极少可能wtp-limit配置限制掉
By conflict //AP名字、MAC有冲突，AC端已经有该AP名字、MAC的其它AP在线或配置的
By deny-flag //AC上主动配置拒绝该AP加入，一般组网调试阶段采用deny-join限制
By ap-auth //AP认证限制，AC上开启证书、序列号、密码形式的认证，而AP未携带认证信息
By user-class //不同行业的AP产品，比如SMB-AP只能与SMB-AC对接、不能对接普通AC
By overdue-ap //AC上存在过期AP，一般是临时状态，此时AC端会自动清除过期AP信息，AP会再次申请加入并成功
By master-ap-mac //卫星ap没有携带主ap mac，一般是临时状态，卫星AP刚启机时太快加入导致
By unknown //未知原因
By radio num //AP射频口太多不支持对接，比如B7版本AC不支持AM5528
By vendor id //其它厂商AP不支持对接
By new-ap-limit //新品AP上限，比如WS5708仅支持100个B9新品wave2的AP
By local-limit //VAC场景下单AC设备保护，限制接入本机AP数，可能交换机负载不均衡、工作AC过少等情况
By hot-backup //热备限制，比如该AP使用AP虚拟化技术，而AP虚拟化不支持热备功能，配置上却将该AP划入热备中
By total-ap-num //AP总数（在线+离线）、AP隧道数达到上限，删除不需要的离线AP配置
By none-radio //AP不携带radio被拒绝，一般是临时状态，AP刚启机时太快加入导致
如果AP和AC间报文交互异常，需要中间线路抓包分析定位丢包点，及前期提到的有线环网的排查。
3、AC无法下发配置给AP
【故障现象】
AC无法下发配置给AP
【故障环境】
AP为跨公网上线到AC中。
【故障可能的原因】
（1）AP未正常上线
（2）软件版本不一致
（3）外网环境限制
（4）设备软件故障(版本跨度大等)
【故障分析】
（1）远程查看AP版本与AC版本一致，并且成功上线
（2）show ap-conf run 查看故障ap已成功加入对应组，并检查配置是否有问题（主备配置是否一致）
（4）通过ap上ping ac，包大小设置1500Byte发现无法ping通，通过二分法测试最大能通的包大小为1410Byte；通过修改控制隧道mtu为1410后故障解决：
ac-controller
capwap ctrl-mtu 1410
【故障总结及注意事项】
跨NAT上线环境，出现AC配置无法下发、反复建立隧道、隧道无建立、终端无法正常接入情况，建议在基本排查后查看AP与AC隧道地址大包通讯是否正常，对于反复建立隧道的，可以查一下出口设备的NAT表项老化时间是否太短，可以通过隧道保活时间测试。
4、AP和AC跨公网上线，同一个网点的AP，部分可以上线成功，部分无法上线成功。
【故障现象】
AP和AC跨公网上线，同一个网点的AP，部分可以上线成功，部分无法上线成功。
【排查步骤】
1） 检查确认对应的网络拓扑，及对应的无线的配置和版本情况；
A、跨公网AP和AC部署，无主备场景，单个AC部署。（如涉及热备情况需要核实主备配置是否一致），正常AP和故障AP的配置完全一致，排除配置差异问题，且没有bind-ap-mac的相关配置。
B、无线用户本地转发，AP和无线用户的网关及dhcp地址池在本地汇聚交换机上，需进一步本地排查核对。
C、AC和正常AP及异常AP的版本均是当前最新版本，且当前存在正常AP上线，型号一致，排除版本因素及公网运营商线路问题。
2） 登录故障AP检查AP模式及是否获取到地址，测试AP ping AC的隧道地址大包是否存在通信问题。
现场检查发现故障AP瘦模式，地址获取正常且和AC的隧道地址大包通信正常。
3） 检查接入交换机上配置对比连接正常和异常AP接口配置未发现差异，交换机状态正常。
4） 收集故障AP和AC上的log信息和相关的debug。
发现故障AP一直在发discovery request请求报文，但是AC上通过show capwap statistics并没有对应的discovery request的received数值增长，怀疑是AP的discovery request的报文在中间链路上丢弃，因该点是公网上线，有正常AP也有不正常AP，排除了公网运营上线路问题，怀疑是本地设备上存在问题。
5） 检查本地设备拓扑，出口EG-----汇聚------接入------AP，进行汇聚上联抓包发现有对应的故障AP的discovery request请求报文，怀疑报文丢弃在出口EG设备。因出口无法直接抓包分析，初步分析怀疑应用识别存在问题或者是AP到AC的相关报文流量过大导致报文丢弃，造成AP和AC部分隧道建立不成功。
6） 测试将AP的网段加入到出口的免审计和免流控中，并且将对应的AP网段用户的资源放入到EG的关键通道中优先转发，测试使用故障AP上线正常。移出关键通道之后，过段时间发现AP存在掉线情况，并无法继续上线。
【故障原因】
出口流控设备关键通道数量流量过大，导致AP和AC建立隧道的交互报文丢弃。
【解决方案】
将AP的地址段的流量加入EG出口的关键通道中，保证优先转发AP的数据报文。
【其他操作命令】
AC上可通过debug apmg join看是否有收到discovery报文。
AP上可通过debug capwap client fsm看到报文发送等是否成功。
AP上 debug capwap packet可查看discover是否有应答（需要稍等一会，才可看到提示）
如果没有应答到ac上看：
debug efmp packet filter ipv4_sport range 5246 5247 counter 30
AP隧道无法建立成功，可通过AC上操作如下命令，查看是否有相关提示信息：
debug efmp packet filter ipv4_sip host APIP地址 ipv4_sport eq 10000 counter 10
run-system-shell
dmesg
AC上通过show capwap ap隧道编号id detail，查看如下信息
如果data port经常变化，存在流表老化的问题，建议修改通道保活时间改小。
ap-config xxx
echo-interval xx（默认30s，最小5s，最大255s）
5、 AC、AP版本相同，但却无法在AC上正常上线，卡在join状态
【故障现象】
AC、AP版本相同，但却无法在AC上正常上线；
【故障分析】
1、通过日志查看确认AP的capwap状态，发现AP已经与AC通信，到join状态后状态变为
DTLS Teardown；
*Jan1 00:01:10: %CAPWAP-6-STATE_CHANGE: (peer - 1) [1.1.1.1] capwap state changed, from <DTLS Setup> to <Join>
*Jan1 00:01:10: %CAPWAP-6-STATE_CHANGE: (peer - 1) [1.1.1.1] capwap state changed, from <Join> to <DTLS TearDown>
2、确认ac/ap间链路无问题后，通过show ap-config summary deny-ap发现对应的reason为By conflict，即ap的名称与系统中其他ap存在同名的情况，导致ap无法正常加入到ac中；
3、将上线失败的ap恢复出厂设置（或改个名称）后，AP正常上线；
【故障总结】
正常上线的AP，capwap状态分为idle-->discover-->DTLS Setup-->Join-->config-->Data Check-->Run；当capwap状态到达run时，说明ap已经完成上线流程正常上线；
Capwap状态卡在Join状态可以通过show ap-config summary deny-ap查看拒绝接入的原因（AC为11.x，AP为10.x的可能不会显示，原因为版本跨度太大）；
capwap隧道状态到Join后断开，常见的原因有：
（1）ap名称冲突；
（2）版本不一致；
（3）license问题；
（4）线路故障；
（5）AC上做了安全限制，如bind-ap-mac等；
6、 AP掉线后在ac上还是长时间显示在线
【故障现象】
AP掉线后，AC上显示ap还是在线状态。
【故障分析】
1、查看show run，show ap-config run配置，确认echo-interval是否被修改(该值默认为30s)；
2、检查配置发现该参数未被修改均为默认值；通过AC上show capwap index detail发现多次查看的输出中keepalive的值无变化，初步怀疑是否是因为保活被关闭导致ap状态在ac上未更新。通过命令show capwap [ip addr] detail | inc Echo发现echo-interval 为0.
AC-branch(config-ap)#show capwap 10.121.121.129 detail | in Echo
Echo interval is 0 secs, Dead interval is 0 secs Expire 4294967237 secs
3、通过show cli record命令查看AC的历史命令记录发现对应AP的ap-group中被误配置了echo-interval disable，导致故障的发生，通过在对应的ap-group中删除该配置(no echo-interval)后现场观察恢复正常；
【故障总结】
该故障是由于误配置隐藏命令导致的问题，echo-interval disable作用为关闭capwap隧道保活，即配置该命令后，ap保活被关闭，ap掉线后在ac上显示的状态还是run的。且echo-interval disable在show run中不会被显示出来。
AP与AC之间保活时间
AP与AC之间echo-interval值默认为30s，即30s内如果AC没收到保活报文即认为AP掉线。
AP通过发送echo request来保活隧道，AP每隔30s发送一次echo request，AC收到echo request后回复echo response，若AP在一段时间没收到response报文，则对Request进行重传。重传时间及次数为AP从第3s开始重传，到echo interval的一半即认为隧道断开。如默认30s的echo interval时间内AP会进行五次重传，分别为3s,6s,12s,15s,15s。
将echo interval配置为其他值是重传时间及次数计算方式还是一样。echo interval时间的设置区间为5-255s之间。 配置方式为在AP配置模式或AP组配置模式下使用echo-interval *命令配置。
7、 大部分AP无法上线成功，且已经上线的AP经常出现掉线情况，隧道状态反复
【故障现象】
大部分AP无法上线成功，且已经上线的AP经常出现掉线情况，隧道状态反复。
【排查步骤】
1） 检查确认对应的网络拓扑，及对应的无线的配置和版本和log情况；
版本配置一致
Oct 16 00:24:27: %CAPWAP-5-RETRANS_MAX: (*2) (peer - 47) [172.17.6.30 : 10000] reach maximum retransmit count [5], msg is [configuration update request], seq is [1], elem length is [34].
Oct 16 00:24:27: %CAPWAP-6-PEER_NOTIFY_DOWN: (*2) Peer <172.17.6.30 : 10000 : 5869.6cea.d18d> DOWN, reason <Retransmit MAX>.
怀疑中间线路存在问题。
2） 登录故障AP检查AP模式及是否获取到地址，测试AP ping AC的隧道地址大包是否存在通信问题。
AP上ping AC基本不存在丢包情况，怀疑中间线路存在环路或者广播流量过大情况。
3） 登录AC使用clear counters清除接口流量统计信息之后，连续3次收集show int counters summary信息发现下图互联口广播增长较快；
4） 登录互联核心设备使用clear counters清除接口流量统计信息之后，连续3次收集show int counters summary信息发现：
对应的Te1/3/20的接口存在大量的广播流量报文增长，怀疑是存在环路情况。
5） 确认Te1/3/20接口连接的设备是接入交换机下挂的AP，将Te1/3/20接口down之后，观察除Te1/3/20口下的AP陆续全部上线，网络恢复正常。
6） 登录接入交换机开启RLDP操作，发现对应的其中一个接口出现接口down的情况，核实下联设备的连接情况，发现是个私接交换机，并且存在环路情况。
【故障原因】
接入交换机下连接入交换机存在单端口环路情况。
【解决方案】
将环路接口down掉。
1)、出现部分AP的隧道建立不成功，或者是部分AP的隧道反复建立的情况，可能存在环路情况存在；即使有环路情况，但是AP上ping AC的地址可能不存在丢包的情况；
2)、类似故障情况出现之后，需核实对应的故障范围和是否存在主备配置（保证主备配置一致）；
3)、VAC场景中如果没有配置正确的负载均衡策略，也会存在AP反复上下线或无法上线的情况；
4)、针对环路情况可以通过开启生成树或RLDP及查询对应的交换机的log日志信息核实环路的故障端口。
8、 AP故障无法建立隧道排查思路及故障信息收集操作
AP故障无法建立隧道排查思路及故障信息收集操作
1）、检查确认AP和AC的型号及版本，确定组网拓扑及方案情况；
2）、确认AP和AC的loopback0（或者capwap ctrl-ip x.x.x.x）的地址通信是否正常，如下测试方式：
ping x.x.x.x length 1500 ntimes 20
3）、检查AP和AC上的log，及AP和AC上相关debug信息收集
登录AP：
show log //收集ap上log信息
more ap_down.txt //查看ap的掉线原因
show capwap statistic //收集ap的隧道建立状态信息，多收集几次，可连续收集3次
show capwap client state
ap不识别efmp的情况下，需要在run-system-shell下配置，保证debug efmp操作识别
run-system-shell cd sbin
./efmp_demo &
exit
相关debug信息收集
terminal monitor
debug capwap client fsm
debug capwap packet
debug efmp packet filter ipv4_sport range 5246 5247 count 30
登录AC：
show log
show ap-config summary deny-ap
terminal monitor
debug capwap [apip] packet
debug apmg join
debug efmp packet filter ipv4_sport eq 5247 ipv4_sip host [apip] count 10
4）、如设备端无任何日志和debug信息提示，将排查中间线路情况；AP上跟踪一下隧道地址记录路径：traceroute ip 隧道地址 source [apip]，确认ap的报文经过哪些设备。
5）、采用二分法的方式，进行分段抓包，确认ap和ac建立隧道的收发包的情况，确认丢包点位。
PS：AP反复上下线的故障案例介绍
11.x的B9P2之前版本AC上默认开启mac检测，如果出现交换机处理机制问题，会出现报文延迟发送，使得有些discover隔了5秒才给AC，但5秒AC上已经run了，这个时候交换机把discover转给AC，AP的log上就出现了rediscover的相关提示，mac地址一样，收到rediscover的时候，AC会把ap下线。
需要关闭时，隐藏的操作命令：
ac-controller下面，apmg-support test ap-same-mac-join disable
B9P2版本及之后版本，默认关闭mac检测，mac地址一样，收到rediscover的时候，不会把ap下线。需要开启的时候，操作命令：ac-controller下面，no ap-same-mac-join enable
9、WS 十几个AP接入提示dtls down状态
【故障现象】
WS 十几个AP接入提示dtls down状态
【故障排查】
1）、确认这几个故障AP软件版本跟AC版本一致
2）、查看AClicense足够
3）、登入AP查看隧道建立状态为jion状态后直接变成dtls
4）、查看发现show cap st 其不在线mac，在show ap-con su上无任何信能息，但如果将该故障mac-1后show ap-con su有对应信息====》show ap-con su deny-ap后查看配置重复，检查重名导致，更改后问题解决。
10、AP不上线，AC上显示隧道状态为Datacheck
【故障现象】
AP上show capwap state显示隧道状态已经running，但是在AC上show capwap state显示隧道状态处于Datacheck状态，过30S后AC和AP的隧道自动断开。
【故障排查】
无线AP和AC是同一局域网内，AC单线旁挂华为核心交换机，AP的dhcp和网关都在华为核心上。
1）、AP上隧道可以到running这个状态，说明正常通讯是没有问题，后续测试从AP上ping大包测试丢包延迟均正常。
2）、检查AC和AP版本均为目前RTR最新，且查看AC无特殊配置。
3）、在AC上show ap-config summary deny-ap没有任何回显，说明非AC上配置等原因造成的故障现象。
4）、此时故障陷入僵局，思考AP上线的几个状态机变化：Discover->Join->Image Date->Configuration->Date check->Run，查阅文档看到如下截图定义Date check状态如何才能切换到Run状态：
a、AP会直接<从DataCheck>进入<Run>状态，开始创建数据通道，并每隔30秒发送1个数据通道保活报文（Keep-Alive报文）。
b、AC收到第1个保活报文（Keep-Alive报文）, 如果当前是Data Check状态，则进入<Run>状态，并回应Data Channel 保活报文。如果AC在发出Change State Event Response后，30秒内没有收到第1个Data Channel 保活报文，则状态转DTLS Teardown。
c、AP和AC收到保活报文后，如果60秒内没有收到第1个数据通道保活报文，则认为数据通道断掉，状态转DTLS Teardown。
d、当AP或者AC检测到数据通道断掉后，CAPWAP状态机更新到DTLS Teardown。
5）、从上述原理来分析，应该是AP进入Run状态后，AC没有收到AP发出的第一个Keep-Alive报文，导致AC状态一直在Datacheck状态，所以才会有30S后AC和AP隧道自动断开的故障现象。
6）、和现场工程师沟通，华为核心自带了一张AC板卡且无法关闭，可能是被华为核心将Keep-Alive报文丢弃了，分别在华为核心的连接AC的接口和下联AP的接口抓包分析。
7）、通过过滤udp.port==5247，下图第一张华为核心下联AP接口的抓包，第二张为华为核心连接AC的接口抓包：
此时很明确通过抓包对比发现，AP有发送Keep-Alive报文上来，但是路过华为核心时被丢弃了，没有转发给AC，导致AC上状态一直是Datacheck，过30S隧道自动断开。
8）、明确故障原因后，同步给客户，寻找华为工程师协助处理，问题解决。
【故障总结】
1）、网络中有其他厂家设备时可能要考虑其他厂家设备影响。
2）、要第一时间结合原理进行分析。
4446
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
