某局点反馈,一台AC 部署在总部,各分支机构的AP 通过专线跨越公网注册到总部AC 上。一分支局点的AP 断电掉线后出现再也无法注册上AC 的现象。此时AP可以获取到IP地址,可以Ping通7000字节的大包,但是无法注册上线。
无
AP跨越公网注册无法上线,分别在AC 和AP Debug收集信息
<ac>debugging wlan lwapp all
<ap>debugging wlan lwapp error
AP侧Debug信息来看,AP 注册AC 流程已经完成了Discovery、Join的过程,然后AP 发起了配置请求
*Jun 9 22:18:35:084 2017 WA2620E-F LWPC/7/Pkt_Send:
Sent Configuration Request to 117.136.240.219 port 2005 (Length: 1356)
从AC 侧来看,AC侧收到了AP 的Configuration Request,同时也调用了相应的AP的配置信息。
*Jun 9 22:10:28:789 2017 ZQ-BJXXG-WLAN-AC09-H3C6112E LWPS/7/Pkt_Rcvd:
Received Configuration Request from 183.238.87.210 (Length: 1439)(to 172.16.7.19)
……
*Jun 9 22:10:28:791 2017 ZQ-BJXXG-WLAN-AC09-H3C6112E LWPS/7/Event: [APID: 342 State: JoinAck] Configuration Request received
*Jun 9 22:10:28:791 2017 ZQ-BJXXG-WLAN-AC09-H3C6112E LWPS/7/FSM : [APID: 342] JoinAck -> Config
*Jun 9 22:10:28:792 2017 ZQ-BJXXG-WLAN-AC09-H3C6112E LWPS/7/Event: [APID: 342] LWAPP to WMAC : Get/Update 802.11 binding configuration
……
*Jun 9 22:10:28:793 2017 ZQ-BJXXG-WLAN-AC09-H3C6112E LWPS/7/Event: [APID: 342] LWAPP to WMAC : Get/Update 802.11 binding configuration //获取ap的配置信息
*Jun 9 22:10:28:793 2017 ZQ-BJXXG-WLAN-AC09-H3C6112E LWPS/7/Event: [AC LWAPP Get VendorTLV From App Module] APId: 342; Message Type: Configuration Response; TLV ElementId: 26628
……
*Jun 9 22:10:28:798 2017 ZQ-BJXXG-WLAN-AC09-H3C6112E LWPS/7/Event: [AC LWAPP Get VendorTLV From App Module] APId: 342; Message Type: Configuration Response; TLV ElementId: 2100
可以看出AC收到配置请求后已经从相应模块获取了AP的配置信息,并封装成了Configuration Response报文。
从AP 侧来看
Sent Configuration Request to 117.136.240.219 port 2005 (Length: 1356)
…
*Jun 9 22:18:38:478 2017 WA2620E-F LWPC/7/Error:
Retransmit failed, count reach max [1], MsgType:10, TunnelStrongFlag:0. //重传失败,重传报文数达到上限,定时器超时。从AC和AP Debug信息来看,AP未收到配置响应的回包,导致定时器超时。怀疑AP注册时配置响应报文丢失在了中间公网链路中,为了佐证猜想,还是需要在AP的上连口抓包,证明AP确实没有收到回包。
在该分支局点的出口路由器上抓包。由于LWAPP隧道协议是一个私有协议,用Wireshark不能完全解析出LWAPP隧道控制报文,此时可以根据相应的字段进行判断。例如04 00 00 08 00 00这个字段。04是表示控制报文,一般都是04 00 XX XX 00 00 六个字节之后就是具体的报文类型了。
LWAPP控制报文标准如下
Description Value
Discovery Request 1
Discovery Response 2
Join Request 3
Join Response 4
Join ACK 5
Join Confirm 6
Unused 7-9
Configure Request 10
Configure Response 11
Configuration Update Request 12
Configuration Update Response 13
WTP Event Request 14
WTP Event Response 15
Change State Event Request 16
Change State Event Response 17
Unused 18-21
Echo Request 22
Echo Response 23
Image Data Request 24
Image Data Response 25
Reset Request 26
Reset Response 27
Unused 28-29
抓包报文中有这样一个字段
04 00 05 46 00 00
0a 04 05 3e 5a 2c //0a,Configure Request 10号报文。
AP发送Config request,但没有收到0b,Config resonse 11号的报文。通过抓包进一步佐证了AC 回应的报文丢在了公网链路中。Config配置响应报文丢失在公网链路可能的原因是中间设备大包分片不过或者分片报文再路由、FW设备上重组因为报文过大被丢弃了。
由于现场组网原因无法修改AC 注册VLAN下的MTU值,也无法新增注册VLAN,给AP更换IP地址和城域网网关后,AP 能跨越公网注册上AC 了。
如果AP 跨越公网注册不上时,需要考虑公网链路对报文传输的影响。即使Ping包测试ICMP大包能过,也不能证明UDP大包能过。此时需要在AC和AC 侧两边同时Debug隧道控制报文,并结合AC 和AP侧抓包,明确注册报文中断在哪一个环节。如果确定是大包报文是丢在了公网链路中,可尝试做以下调整。
1. AC的注册VLAN接口下修改MTU值,MTU值默认为1500,可以改小点为1300或者1200。
2. 如果有的局点的组网环境不能对VLAN接口下的MTU值做更改,可以试试把AP下的配置全部删除,只留序列号,看AP是否能注册上。
3. 如果以上操作都不行,可以尝试更换公网出口地址或者网关,让AP 从另外一个出口跨越公网注册。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作