轨道交通地铁无线解决方案故障一本通v1.0.docx

轨道交通地铁无线解决方案
故障一本通v1.0

1 车内覆盖AP AP530-I(S2)单台掉线
l 故障现象
AP530-I(S2) 单台掉线。
l 网络环境
上海地铁网络环境
l 排查过程
1、 AC上ping S2的IP地址，如果能通，telnet到S2上打开log，查看capwap建立的log提示。
2、 如果AC无法ping通S2，则telnet到此S2所在的工业交换机，查看该S2对应的接口状态以及供电状态。
3、 查看主AC和备AC上的这个AP配置是否一致；
l 解决方法
1、 问题：主备AC下ap-group或者ript的配置不一致导致，会出现AP的capwap震荡现象
解决方法：将主备AC的配置恢复一致
2、 问题：AP上提示ap名冲突
解决方法：在AC上show ap-config run ap_name保存配置，之后删除这个ap-config，待AP上线后，将之前保存的ap-config配置刷如此AP的ap-config中，并对AP重命名。
3、 问题：工业交换机连接故障AP的接口down
解决方法：将此交换机接口的poe关闭再开启，查看接口1-2min后是否会up，如果还不会up，则申请进车库用串口连接AP排查问题，并检查网线是否有损坏。
4、 问题：工业交换机连接故障AP的接口up，但是交换机学不到AP的mac
解决方法：暂无
l 故障总结
AP掉线问题本质上是AP与AC通路的问题以及AP是否能在AC上上线的原则问题。
通路好理解，上线原则目前主要为：主备AC的ap-config配置是否一致、AP名是否冲突、AP版本与AC版本是否兼容。
通过这两大点进行逐步排查分析，大部分AP掉线问题都可以定位出来。

2 车内大约一半的覆盖AP AP530-I(S2)掉线
l 故障现象
多台AP530-I(S2) 掉线。
l 网络环境
上海地铁网络环境
l 排查过程
1、 AC上查看该列车车头和车尾NONROOT的在线情况
2、 查看车头和车尾NONROOT是否配置上行链路检测功能
3、 查看这些掉线AP在主AC和备AC上的配置是否一致
4、 查看工业交换机链路问题
l 解决方法
1、 问题： NONROOT信道错误
解决方法：
在AC能通故障NONROOT时，telnet到NONROOT上查看是否是调头失败导致信道错误，如果是，则修改信道，等待掉线S2上线；
2、 问题：NONROOT天线故障
解决方法：
在AC能通故障NONROOT时，进入NONROOT上多次show dot wds 2/0查看桥接的RSSI，多次show的结果中桥接RSSI都是很低的，需要入库检查S3的天线及接口等硬件问题。
3、 问题：非桥接自身问题导致的NONROOT桥接通路故障
解决方法：
登录交换机将故障的NONROOT的物理接口进行shutdown，过一会儿掉线的S2即可上线，待故障NONROOT的capwap建立后，ap-config下配置上行链路检测功能，不保存到预配置中，该列车的另一台NONROOT也进行配置。
4、 问题：工业交换机链路故障或VSU断开
解决方法：
入车库检查工业交换机故障。
l 故障总结
大约一半的车内覆盖AP掉线的情况，几乎99%的概率是其中一台S3出现桥接链路问题，将排查关键点放在这台故障S3上，如果S3的桥接故障并非信道错误等可以立刻修正的问题导致的，则需要检测S3的收发信号是否受到影响。

3 车头车尾AP530-I(S3)掉线
l 故障现象
AP530-I(S3) 掉线。
l 网络环境
上海地铁
l 排查过程
1、 S3与AC之间的ping有无丢包
2、 查看S3的信道
3、 查看工业交换机对应的接口状态
l 解决方法
1、 问题： NONROOT信道错误
解决方法：
在AC能通故障NONROOT时，telnet到NONROOT上查看是否是调头失败导致信道错误，如果是，则修改信道，等待上线；
2、 问题： 工业交换机与S3之间通讯问题
解决方法：
入库检查网线问题；
3、 问题： S3与AC之间ping丢包问题
解决方法：
找到ping丢包的规律，是固定轨旁区间丢包或是始终都有间歇性丢包
S3上shell下（run-system-shell）开启桥接调试wl wdsmsglevel 0x64（关闭调试为wl wdsmsglevel 0x0），之后退出shell，长时间ping AC，收集log（CRT的log设置需要每一行都有系统时间，如：[%Y-%M-%D %h:%m:%s]）并发给研发进一步排查；
l 故障总结
S3的掉线多半与桥接通路有关，先排查浅显的问题，如信道、流量过大等，再检查网桥ping丢包情况。
4 网桥上数据不通
l 故障现象
车内用户没法通讯
或：
所有车内覆盖AP都没上线，只有车头车尾AP在线，车内无wifi信号
l 网络环境
上海地铁
l 排查过程
1、 AC与S3是否能通
2、 检查轨旁AP和车头车尾AP的bridge vlan配置；
l 解决方法
1、 问题：轨旁AP和车头车尾AP的bridge vlan未配置
解决方法：在没有配置bridge vlan的地方加上配置，等待S2上线或车内用户上线；
2、 问题： S3与AC之间ping丢包问题
解决方法：
找到ping丢包的规律，是固定轨旁区间丢包或是始终都有间歇性丢包
S3上shell下（run-system-shell）开启桥接调试wl wdsmsglevel 0x64（关闭调试为wl wdsmsglevel 0x0），之后退出shell，长时间ping AC，收集log（CRT的log设置需要每一行都有系统时间，如：[%Y-%M-%D %h:%m:%s]）并发给研发进一步排查；
l 故障总结
网桥通路问题在于是S3自身通路问题或者使用这个通路的vlan无法通讯的问题。
5 用户关联失败
l 故障现象
用户终端提示“无法连接”。
l 网络环境
上海地铁
l 排查过程
1、 AP上开启log，查看对应的用户log
2、 AC上查看对应的AP用户数是否已达上限
3、 查看wids配置
4、 查看Response-RSSI配置值
l 解决方法
1、 问题：用户已达上限
解决方法：
从AC telnet到问题AP上，打开log查看日志；

根据需要，修改sta-limit的值，建议每个radio 配置为64个用户，根据不同地方的人流量的不同，有些站台或者列车上需要配置为最大值128每个radio。
2、 问题：wids配置白名单
解决方法：
AC与AP上都做wids配置检查，查看是否配置了白名单，并删除白名单配置；
3、 问题：response-rssi配置过高
解决方法：
AC上telnet到问题AP是上，打开log，查看是否有如下log

AC上查看问题AP的show ap-config run配置，是否response-rssi配置过高。
l 故障总结
用户无法上线的问题，最主要的是log信息的查看，第一步就要登录AP上查看用户log，否则都不知道发生了什么事情。

6 用户获取地址失败
l 故障现象
用户关联成功，但是终端一直获取不到IP地址。
l 网络环境
上海地铁
l 排查过程
1、 查看N18K的地址池是否已满
2、 AP上查看是否配置了DHCP SNOOPING
3、 AP上开启debug，查看是否收到问题用户的DHCP报文
l 解决方法
1、 问题：N18K地址池已满

解决方法：
扩充地址池。
2、 问题：AP上配置DHCP SNOOPING
解决方法：AC上关闭DHCP SNOOPING功能，或者将AP上的NFPP阈值水线提高，提高的配置如下：
nfpp
dhcp-guard rate-limit per-src-mac 1500
dhcp-guard rate-limit per-port 1500
dhcp-guard attack-threshold per-src-mac 1500
dhcp-guard attack-threshold per-port 1500
3、 问题：DHCP报文在路径上被丢弃
解决方法：
DHCP Server设备上查看是否收到终端的DHCP报文并回应报文
开启dhcp debug 过滤：
debug ip dhcp filter mac xxxx.xxxx.xxxx
debug ip dhcp ser all
如果DHCP SERVER上有看到回复用户的DHCP报文，那么AP上进行debug：
Debug packet function all procotol 0x10 print-pkt count 50 xxxx.xxxx.xxxx
通过对应的字节查找是否发出或者收到DHCP报文：
DHCP Discover报文：
关注下图红框部分内容可知这个报文是否是DHCP DISCOVER。

DHCP Offer报文：
关注下图红框部分内容可知这个报文是否是DHCP OFFER。

DHCP Request报文：
关注下图红框部分内容可知这个报文是否是DHCP REQUEST。

DHCP Ack报文：
关注下图红框部分内容可知这个报文是否是DHCP ACK。

如果AP上没看到Server回应的DHCP报文，很可能是AP设备端上方的设备链路问题导致，需要排查有线端问题；
如果AP上看到了Server回应的DHCP报文，那就把log保存下来，发给研发进一步排查；

l 故障总结
用户获取DHCP的问题，需要从通路、DHCP SERVER、AP的转发、空口干扰这几个角度出发进行问题排查。
7 用户很难获取地址
l 故障现象
用户关联成功，但是很难获取到IP地址,需要等很长时间,或者需要多次重连才能获取到IP地址。
l 网络环境
上海地铁
l 排查过程
1、 查看AP是否配置DHCP SNOOPING
2、 找出获取不到IP地址的时机是否有规律
l 解决方法
1、 问题：DHCP SNOOPING
解决方法：AC上关闭DHCP SNOOPING功能，或者将AP上的NFPP阈值水线提高，提高的配置如下：
nfpp
dhcp-guard rate-limit per-src-mac 1500
dhcp-guard rate-limit per-port 1500
dhcp-guard attack-threshold per-src-mac 1500
dhcp-guard attack-threshold per-port 1500
2、 问题：高峰期用户过多导致的空口竞争
解决方法：使用WIS进行网优
3、 问题：RRM配置导致
解决方法：主备AC上关闭RRM配置（advanced 802.11a/b monitor mode enable）
之前在重庆地铁出现用户获取不到IP地址的情况。
现象：用户在两个SSID之间切换，很容易出现获取IP地址要很久的问题。
原因：因为advanced 802.11a/b monitor mode enable导致AP会自动扫描信道；
       查看配置时发现主没配置这条命令，但是备AC上却配置了。
理论上AS热备下主AC的配置才会生效，但分析之前的升级事件，发现升级14号版本那天晚上，是先升级所有AP，从backup_AC和master_AC的起机时间来看（backup_AC早master_AC  4分钟49秒的时间），所以当时现场应该是backup_AC比master_AC早升级，
       顺序如下：
1、 AP升级完后起机，起机48分钟后与backup_AC建立capwap
2、 由于backup_AC配置了advanced 802.11a/b monitor mode enable导致AP会自动扫描信道；
3、 master_AC起来后，过10min时间master_AC会成为AP的主AC，但是不会下发配置。
4、 这时AP上已经开启了扫描功能，就不会停下了，如果重启AP，则master_AC 没有advanced 802.11a/b monitor mode enable的配置，所以AP重启后不会去扫描信道；
解决办法：
       backup_AC上把monitor配置去掉：
              AC2(config)# advanced 802.11a monitor mode disable
              AC2(config)# advanced 802.11b monitor mode disable
                  master_AC上把monitor配置加上
              AC1(config)# advanced 802.11a monitor mode enable
              AC1(config)# advanced 802.11b monitor mode enable
            可以等个1-2min，之后删除monitor配置
              AC1(config)# advanced 802.11a monitor mode disable
              AC1(config)# advanced 802.11b monitor mode disable
之后登录AP上打开调试查看AP不会再扫描信道，用户获取IP地址恢复正常。
l 故障总结
用户DHCP获取慢时，需要先找出故障的时间或者条件的规律，并检查是否配置DHCP SNOOPING（DHCP SNOOPING默认将超过10pps的DHCP报文源mac列为黑名单），之后再逐步排查。
8 大范围AP于不同时间掉线
l 故障现象
某个时间段（如早晚高峰期），出现大范围AP掉线。
l 网络环境
上海地铁
l 排查过程
1、 查看掉线AP之间的规律
2、 登录刚上线不久的AP查看掉线原因，并长时间ping AC查看丢包情况
3、 查看AP的mac及收发报速率情况
l 解决方法
1、 问题：Mac地址表满，AP3220有1K的mac表容量，AP530系列产品有4K的mac表容量。（一旦出现mac地址表满的情况，说明环境中有环路或者二层广播隔离失败。ARP的等级和CAPWAP报文等级一样，所以AP处在大量ARP报文的环境中，会将CAPWAP报文被丢弃，从而导致高峰期大面积AP掉线。）
解决方法：
查看mac的vlan，找出不应该出现在表中的mac，之后登录对应的接入交换机，查看交换机的ACL过滤配置是否过滤了不应该有的报文，并做相应修改。
接入交换机连接AP的接口，在IN方向，不允许以N18K和AC的MAC为源MAC的所有报文，在OUT方向，仅允许以N18K和AC的MAC为源MAC的报文。
l 案例
之前上海出现过一例在高峰期出现随机性的大量AP掉线问题。
现象：早晨7-8点左右，AC上看到100多台AP的隧道断开又重建。
排查：
1、分段ping，发现高峰期AC到汇聚的ping出现30s的丢包，怀疑AC到汇聚网络有问题，；
2、通过AP和AC上查看CPU发现，AC的CPU有时会升到70%，可能是高峰期流量大导致AC的CPU过高，从而导致ping丢包；
3、AP上查看mac地址表发现mac地址表满，怀疑出现环路。
4、得知有线端未配置ACL过滤广播，高峰期用户数多，ARP报文会在整个大二层内扩散，从而导致AP的mac地址表满；
原因：ARP的等级和CAPWAP报文等级一样，所以AP处在大量ARP报文的环境中，会将CAPWAP报文被丢弃，从而导致高峰期大面积AP掉线。
解决办法：
       在交换机上配置不同vlan的非网管mac的ARP报文过滤ACL并应用。
配置之后观察发现，高峰期大面积AP掉线的现象消失；
1号线接入交换机的ACL实例见如下:
40 permit arp VID 3011 any any any any any
50 permit ip VID 3012 any any any any
60 permit arp VID 3012 any any any any any
70 permit ip VID 3013 any any any any
80 permit arp VID 3013 any any any any any
90 permit ip VID 3014 any any any any
100 permit arp VID 3014 any any any any any
110 deny ip any 5869.6c00.0000 0000.00ff.ffff any any
120 deny arp 5869.6c00.0000 0000.00ff.ffff any any any any
130 deny ip any 1414.4b00.0000 0000.00ff.ffff any any
140 deny arp 1414.4b00.0000 0000.00ff.ffff any any any any
150 deny ip any any 224.0.0.0 15.255.255.255 any
160 permit ip any any any any
170 permit arp any any any any any

expert access-list extended no_poe_switch_acl
10 permit ip any host 1414.4b81.f609 any any
20 permit ip any host 1414.4b81.f608 any any
30 permit arp host 1414.4b81.f609 any any any any
40 permit arp host 1414.4b81.f608 any any any any
50 permit ip any host 1414.4b82.4ede any any
60 permit ip any host 1414.4b82.4edd any any
70 permit arp host 1414.4b82.4ede any any any any
80 permit arp host 1414.4b82.4edd any any any any
90 permit ip any 0000.5e00.0000 0000.0000.ffff any any
100 permit arp 0000.5e00.0000 0000.0000.ffff any any any any
110 deny ip VID 3011 any any any any
120 deny arp VID 3011 any any any any any
130 deny ip VID 3012 any any any any
140 deny arp VID 3012 any any any any any
150 deny ip VID 3013 any any any any
160 deny arp VID 3013 any any any any any
170 deny ip VID 3014 any any any any
180 deny arp VID 3014 any any any any any
190 permit ip any 5869.6c00.0000 0000.00ff.ffff any any
200 permit arp 5869.6c00.0000 0000.00ff.ffff any any any any
210 permit ip any 1414.4b00.0000 0000.00ff.ffff any any
220 permit arp 1414.4b00.0000 0000.00ff.ffff any any any any
(13170245 packets filtered)

ipv6 access-list v6-list
10 deny ipv6 any any

l 故障总结
通过观察掉线AP之间的规律可以判断出问题的点。
1、 轨旁和站台都出现不规律掉线，则很大可能是链路中出现大量广播报文或未知名单播导致。
2、 部分AP同一时间掉线，大概率为中间设备或中间链路或AC出现故障
3、 仅轨旁AP出现不规律掉线，而站台AP正常，大概率为列车内出现环路导致。

9 大量AP几乎同时掉线
l 故障现象
早晨的日常检查时发现大部分的AP的在线时长不正常。
l 网络环境
上海地铁
l 排查过程
1、 查看掉线AP之间的关系
2、 根据掉线AP之间的关系排查其他设备问题
l 解决方法
1、 问题：AC是否故障
排查方法：
登录到AC上，show version查看起机时长；
如果起机时长相对昨天变短，说明AC重启过，可能是AC宕机、AC重启、N18K机框断电、N18K重启。
Show ap-config summary查看所有AP的在线时长；
AC故障，则这台AC上的所有AP在线是时长都会相对昨天短了很多，且在线时长几乎相同。
2、 问题：接入交换机掉电或者往汇聚的链路出现问题
排查方法：登录对应的交换机查看起机时间，并查看通往汇聚的接口的光衰是否正常。
该故障原因下，掉线的AP都在这台交换机下。
3、 问题：汇聚交换机掉电或者往核心的链路出现问题
排查方法：查看汇聚交换机的起机时间，并查看汇聚交换机上所有接口的光衰情况。
该故障原因下，掉线AP为整条线的AP，并且掉线时间很接近
l 故障总结
通过观察掉线AP之间的规律可以判断出问题的点。
1、 轨旁和站台都出现不规律掉线，则很大可能是链路中出现大量广播报文或未知名单播导致。
2、 部分AP同一时间掉线，大概率为中间设备或中间链路或AC出现故障
3、 仅轨旁AP出现不规律掉线，而站台AP正常，大概率为列车内出现环路导致。

10 用户上下车SSID切换后体验丢包严重
l 故障现象
用户上车或者下车之后，会发现网络断开又重连甚至过好久才重连的现象。
l 网络环境
上海地铁
l 排查过程
1、 查看上下车用户经过的AP所分配的用户vlan是否有变化
2、 查看掉线的log
3、 查看相关漫游关闭的命令是否配置
l 解决方法
1、查看AC上是否开启了2层漫游关闭功能：
roaming local-layer2 direct
2、查看AC上是否关闭了3层漫游IP检测功能
no roaming layer3-move check-ip
用户关联在8号线列车车内AP上时，vlan为308，用户下车后，会漫游到站台AP上，vlan为408，对于AC来说，用户的vlan变化了，而因为vlan 308和vlan 408都在N18K的supervlan下，用户虽然vlan变了，但是IP地址不会改变。
正常的用户3层漫游，用户的vlan和IP都不会改变，但现在已经关闭了漫游功能，用户的vlan产生了变化，对应的IP理论上也会变化，如果用户IP不变，AP就会认为这个用户获取IP地址失败，会多次踢用户下线，从而导致用户体验不佳。
3、 解决办法：AC上配置no roaming layer3-move check-ip，有备AC的场景，备AC也要配置。
l 故障总结
用户上下线相关的问题，第一步都是先查看对应的AP上的log，并对切换前后的用户vlan是否相同，用户切换的具体情况进行分析来逐步排查。

11站台AP与AC无法建立capwap隧道问题处理
1）查看AP的工作模式，show ap-mode 查看，是否工作在胖AP模式（发现少量）；
2）AP是否获取到IP地址，如果不能获取，检查交换机配置和链路（可在AP上show ip inter br 查看）
3）AP获取地址后，在AP上ping 网关地址和AC的Loopback测试连通性；
4）连通性正常，show capwap sta 查看AP建立隧道的状态，停滞在jion状态，查看license是否占满、该AP是否有重复命名；
5）连通性正常，隧道状态停滞在image data状态，查看AP的版本配置是否正确；
6）更换新AP后无法上线，默认AC没有开启自动升级，可能AP是10.X版本，版本与AC版本不匹配导致没有上线，后续需做升级操作；
7）同站台、轨旁多台AP同时掉线，可检查是否是站台掉电问题；
8）车厢覆盖AP全部掉线，可检查列车是否出库、列车交换机是否上电、车头车尾AP是否桥接成功；
9）轨旁AP掉线，可到接入交换机上查看接口状态和MAC地址表信息，如果接口down或MAC地址表没信息，说明是链路问题或者AP故障，需现场处理；
10）如果列车AP多数AP没有上线，检查车头车尾AP是否桥接成功，列车内VSU组建是否正常，AP是否单点故障。

12无线用户搜不到SSID问题处理
1）AP与AC是否建立capwap隧道；
2）检查wlan-config的配置；
3）检查ap-group 是否映射了wlan id 和用户vlan id ；
4）AP是否关联了对应的ap-group组；
5）telnet登陆到AP上show dot mbssid 查看是否有信号放出，如果确认1-4步骤都正常，在AP上show不到信息，请联系锐捷工程师处理。

13 限速功能不生效的处理
1）检查限速配置是否正确，是否是针对上行下行都做了限速配置；
2）注意限速单位为8K，例如配置250，实际下载是2M；
3）telnet到测试的AP上，show run 查看配置是否下发到AP上；
4）更换测试终端或者APP测试；

14车头车尾AP信道不切换问题处理
1）检查车头车尾AP的信道配置是否正确，车头36、车尾52信道，配置命令：wds head-chan 36 tail-chan 52 radio 2；
2）车控室尝试用钥匙启动测试插钥匙的一端是否信道变为36，如果不变化，说明继电器的问题；
3）继电器问题需要银谷工程师主导处理。

15 trap功能部署不生效故障处理
1）检查AC的配置是否正确，注意trap有两种格式区别；
2）从AC上ping trap服务器测试是否ping通，如果不通，检查连通性问题。
3）连通性没问题，在trap服务器上抓包，是否收到源地址为AC发送的Snmp报文。
4）如果有收到报文，排查服务器问题。如果没有收到报文，需要逐段抓包分析丢包位置。

16探针功能部署不生效故障处理
1）检查AP的探针功能配置是否正确，上海每条线探针服务器地址和端口不一样，注意配置；
2）从AP上ping 探针服务器测试是否ping通，如果不通，检查连通性问题；
3）连通性没问题，可在探针服务器上抓包，UDP对应探针端口的报文；
4）如果有收到报文，排查服务器问题。如果没有收到报文，需要逐段抓包分析丢包问题。