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

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

1车内覆盖APAP530-I(S2)单台掉线故障现象AP530-I(S2)单台掉线。网络环境 上海地铁网络环境排查过程AC上pingS2的IP地址，如果能通，telnet到S2上打开log，查看capwap建立的log提示。如果AC无法ping通S2，则telnet到此S2所在的工业交换机，查看该S2对应的接口状态以及供电状态。查看主AC和备AC上的这个AP配置是否一致；解决方法问题：主备AC下ap-group或者ript的配置不一致导致，会出现AP的capwap震荡现象解决方法：将主备AC的配置恢复一致问题：AP上提示ap名冲突解决方法：在AC上showap-configrunap_name保存配置，之后删除这个ap-config，待AP上线后，将之前保存的ap-config配置刷如此AP的ap-config中，并对AP重命名。问题：工业交换机连接故障AP的接口down解决方法：将此交换机接口的poe关闭再开启，查看接口1-2min后是否会up，如果还不会up，则申请进车库用串口连接AP排查问题，并检查网线是否有损坏。问题：工业交换机连接故障AP的接口up，但是交换机学不到AP的mac解决方法：暂无故障总结 AP掉线问题本质上是AP与AC通路的问题以及AP是否能在AC上上线的原则问题。 通路好理解，上线原则目前主要为：主备AC的ap-config配置是否一致、AP名是否冲突、AP版本与AC版本是否兼容。 通过这两大点进行逐步排查分析，大部分AP掉线问题都可以定位出来。2车内大约一半的覆盖APAP530-I(S2)掉线故障现象多台AP530-I(S2)掉线。网络环境 上海地铁网络环境排查过程AC上查看该列车车头和车尾NONROOT的在线情况查看车头和车尾NONROOT是否配置上行链路检测功能查看这些掉线AP在主AC和备AC上的配置是否一致查看工业交换机链路问题解决方法问题：NONROOT信道错误解决方法：在AC能通故障NONROOT时，telnet到NONROOT上查看是否是调头失败导致信道错误，如果是，则修改信道，等待掉线S2上线；问题：NONROOT天线故障解决方法：在AC能通故障NONROOT时，进入NONROOT上多次showdotwds2/0查看桥接的RSSI，多次show的结果中桥接RSSI都是很低的，需要入库检查S3的天线及接口等硬件问题。问题：非桥接自身问题导致的NONROOT桥接通路故障解决方法： 登录交换机将故障的NONROOT的物理接口进行shutdown，过一会儿掉线的S2即可上线，待故障NONROOT的capwap建立后，ap-config下配置上行链路检测功能，不保存到预配置中，该列车的另一台NONROOT也进行配置。问题：工业交换机链路故障或VSU断开解决方法： 入车库检查工业交换机故障。故障总结 大约一半的车内覆盖AP掉线的情况，几乎99%的概率是其中一台S3出现桥接链路问题，将排查关键点放在这台故障S3上，如果S3的桥接故障并非信道错误等可以立刻修正的问题导致的，则需要检测S3的收发信号是否受到影响。3车头车尾AP530-I(S3)掉线故障现象AP530-I(S3)掉线。网络环境上海地铁排查过程S3与AC之间的ping有无丢包查看S3的信道查看工业交换机对应的接口状态解决方法 问题：NONROOT信道错误解决方法：在AC能通故障NONROOT时，telnet到NONROOT上查看是否是调头失败导致信道错误，如果是，则修改信道，等待上线；问题：工业交换机与S3之间通讯问题解决方法：入库检查网线问题；问题：S3与AC之间ping丢包问题解决方法：找到ping丢包的规律，是固定轨旁区间丢包或是始终都有间歇性丢包S3上shell下（run-system-shell）开启桥接调试wlwdsmsglevel0x64（关闭调试为wlwdsmsglevel0x0），之后退出shell，长时间pingAC，收集log（CRT的log设置需要每一行都有系统时间，如：[%Y-%M-%D%h:%m:%s]）并发给研发进一步排查；故障总结 S3的掉线多半与桥接通路有关，先排查浅显的问题，如信道、流量过大等，再检查网桥ping丢包情况。4网桥上数据不通故障现象车内用户没法通讯或：所有车内覆盖AP都没上线，只有车头车尾AP在线，车内无wifi信号网络环境上海地铁排查过程AC与S3是否能通检查轨旁AP和车头车尾AP的bridgevlan配置；解决方法问题：轨旁AP和车头车尾AP的bridgevlan未配置解决方法：在没有配置bridgevlan的地方加上配置，等待S2上线或车内用户上线；问题：S3与AC之间ping丢包问题解决方法：找到ping丢包的规律，是固定轨旁区间丢包或是始终都有间歇性丢包S3上shell下（run-system-shell）开启桥接调试wlwdsmsglevel0x64（关闭调试为wlwdsmsglevel0x0），之后退出shell，长时间pingAC，收集log（CRT的log设置需要每一行都有系统时间，如：[%Y-%M-%D%h:%m:%s]）并发给研发进一步排查；故障总结 网桥通路问题在于是S3自身通路问题或者使用这个通路的vlan无法通讯的问题。5用户关联失败故障现象用户终端提示“无法连接”。网络环境 上海地铁排查过程AP上开启log，查看对应的用户logAC上查看对应的AP用户数是否已达上限查看wids配置查看Response-RSSI配置值解决方法问题：用户已达上限解决方法：从ACtelnet到问题AP上，打开log查看日志；根据需要，修改sta-limit的值，建议每个radio配置为64个用户，根据不同地方的人流量的不同，有些站台或者列车上需要配置为最大值128每个radio。问题：wids配置白名单解决方法：AC与AP上都做wids配置检查，查看是否配置了白名单，并删除白名单配置；问题：response-rssi配置过高解决方法：AC上telnet到问题AP是上，打开log，查看是否有如下logAC上查看问题AP的showap-configrun配置，是否response-rssi配置过高。故障总结 用户无法上线的问题，最主要的是log信息的查看，第一步就要登录AP上查看用户log，否则都不知道发生了什么事情。6用户获取地址失败故障现象用户关联成功，但是终端一直获取不到IP地址。网络环境上海地铁排查过程查看N18K的地址池是否已满AP上查看是否配置了DHCPSNOOPINGAP上开启debug，查看是否收到问题用户的DHCP报文解决方法问题：N18K地址池已满解决方法：扩充地址池。问题：AP上配置DHCPSNOOPING解决方法：AC上关闭DHCPSNOOPING功能，或者将AP上的NFPP阈值水线提高，提高的配置如下：nfppdhcp-guardrate-limitper-src-mac1500dhcp-guardrate-limitper-port1500dhcp-guardattack-thresholdper-src-mac1500dhcp-guardattack-thresholdper-port1500问题：DHCP报文在路径上被丢弃解决方法：DHCPServer设备上查看是否收到终端的DHCP报文并回应报文开启dhcpdebug过滤：debugipdhcpfiltermacxxxx.xxxx.xxxxdebugipdhcpserall如果DHCPSERVER上有看到回复用户的DHCP报文，那么AP上进行debug：Debugpacketfunctionallprocotol0x10print-pktcount50xxxx.xxxx.xxxx通过对应的字节查找是否发出或者收到DHCP报文：DHCPDiscover报文： 关注下图红框部分内容可知这个报文是否是DHCPDISCOVER。DHCPOffer报文： 关注下图红框部分内容可知这个报文是否是DHCPOFFER。DHCPRequest报文： 关注下图红框部分内容可知这个报文是否是DHCPREQUEST。DHCPAck报文： 关注下图红框部分内容可知这个报文是否是DHCPACK。 如果AP上没看到Server回应的DHCP报文，很可能是AP设备端上方的设备链路问题导致，需要排查有线端问题； 如果AP上看到了Server回应的DHCP报文，那就把log保存下来，发给研发进一步排查；故障总结 用户获取DHCP的问题，需要从通路、DHCPSERVER、AP的转发、空口干扰这几个角度出发进行问题排查。7用户很难获取地址故障现象用户关联成功，但是很难获取到IP地址,需要等很长时间,或者需要多次重连才能获取到IP地址。网络环境上海地铁排查过程查看AP是否配置DHCPSNOOPING找出获取不到IP地址的时机是否有规律解决方法问题：DHCPSNOOPING解决方法：AC上关闭DHCPSNOOPING功能，或者将AP上的NFPP阈值水线提高，提高的配置如下：nfppdhcp-guardrate-limitper-src-mac1500dhcp-guardrate-limitper-port1500dhcp-guardattack-thresholdper-src-mac1500dhcp-guardattack-thresholdper-port1500问题：高峰期用户过多导致的空口竞争解决方法：使用WIS进行网优问题：RRM配置导致解决方法：主备AC上关闭RRM配置（advanced802.11a/bmonitormodeenable）之前在重庆地铁出现用户获取不到IP地址的情况。 现象：用户在两个SSID之间切换，很容易出现获取IP地址要很久的问题。 原因：因为advanced802.11a/bmonitormodeenable导致AP会自动扫描信道；

查看配置时发现主没配置这条命令，但是备AC上却配置了。理论上AS热备下主AC的配置才会生效，但分析之前的升级事件，发现升级14号版本那天晚上，是先升级所有AP，从backup_AC和master_AC的起机时间来看（backup_AC早master_AC

4分钟49秒的时间），所以当时现场应该是backup_AC比master_AC早升级，

顺序如下：AP升级完后起机，起机48分钟后与backup_AC建立capwap由于backup_AC配置了advanced802.11a/bmonitormodeenable导致AP会自动扫描信道；master_AC起来后，过10min时间master_AC会成为AP的主AC，但是不会下发配置。这时AP上已经开启了扫描功能，就不会停下了，如果重启AP，则master_AC没有advanced802.11a/bmonitormodeenable的配置，所以AP重启后不会去扫描信道；解决办法：

backup_AC上把monitor配置去掉：

AC2(config)#advanced802.11amonitormodedisable

AC2(config)#advanced802.11bmonitormodedisable

master_AC上把monitor配置加上

AC1(config)#advanced802.11amonitormodeenable

AC1(config)#advanced802.11bmonitormodeenable

可以等个1-2min，之后删除monitor配置

AC1(config)#advanced802.11amonitormodedisable

AC1(config)#advanced802.11bmonitormodedisable之后登录AP上打开调试查看AP不会再扫描信道，用户获取IP地址恢复正常。故障总结 用户DHCP获取慢时，需要先找出故障的时间或者条件的规律，并检查是否配置DHCPSNOOPING（DHCPSNOOPING默认将超过10pps的DHCP报文源mac列为黑名单），之后再逐步排查。8大范围AP于不同时间掉线故障现象某个时间段（如早晚高峰期），出现大范围AP掉线。网络环境上海地铁排查过程查看掉线AP之间的规律登录刚上线不久的AP查看掉线原因，并长时间pingAC查看丢包情况查看AP的mac及收发报速率情况解决方法问题：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的报文。案例 之前上海出现过一例在高峰期出现随机性的大量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实例见如下:40permitarpVID3011anyanyanyanyany50permitipVID3012anyanyanyany60permitarpVID3012anyanyanyanyany70permitipVID3013anyanyanyany80permitarpVID3013anyanyanyanyany90permitipVID3014anyanyanyany100permitarpVID3014anyanyanyanyany110denyipany5869.6c00.00000000.00ff.ffffanyany120denyarp5869.6c00.00000000.00ff.ffffanyanyanyany130denyipany1414.4b00.00000000.00ff.ffffanyany140denyarp1414.4b00.00000000.00ff.ffffanyanyanyany150denyipanyany224.0.0.015.255.255.255any160permitipanyanyanyany170permitarpanyanyanyanyanyexpertaccess-listextendedno_poe_switch_acl10permitipanyhost1414.4b81.f609anyany20permitipanyhost1414.4b81.f608anyany30permitarphost1414.4b81.f609anyanyanyany40permitarphost1414.4b81.f608anyanyanyany50permitipanyhost1414.4b82.4edeanyany60permitipanyhost1414.4b82.4eddanyany70permitarphost1414.4b82.4edeanyanyanyany80permitarphost1414.4b82.4eddanyanyanyany90permitipany0000.5e00.00000000.0000.ffffanyany100permitarp0000.5e00.00000000.0000.ffffanyanyanyany110denyipVID3011anyanyanyany120denyarpVID3011anyanyanyanyany130denyipVID3012anyanyanyany140denyarpVID3012anyanyanyanyany150denyipVID3013anyanyanyany160denyarpVID3013anyanyanyanyany170denyipVID3014anyanyanyany180denyarpVID3014anyanyanyanyany190permitipany5869.6c00.00000000.00ff.ffffanyany200permitarp5869.6c00.00000000.00ff.ffffanyanyanyany210permitipany1414.4b00.00000000.00ff.ffffanyany220permitarp1414.4b00.00000000.00ff.ffffanyanyanyany(13170245packetsfiltered)ipv6access-listv6-list10denyipv6anyany故障总结 通过观察掉线AP之间的规律可以判断出问题的点。轨旁和站台都出现不规律掉线，则很大可能是链路中出现大量广播报文或未知名单播导致。部分AP同一时间掉线，大概率为中间设备或中间链路或AC出现故障仅轨旁AP出现不规律掉线，而站台AP正常，大概率为列车内出现环路导致。9大量AP几乎同时掉线故障现象早晨的日常检查时发现大部分的AP的在线时长不正常。网络环境上海地铁排查过程查看掉线AP之间的关系根据掉线AP之间的关系排查其他设备问题解决方法问题：AC是否故障排查方法：登录到AC上，showversion查看起机时长；如果起机时长相对昨天变短，说明AC重启过，可能是AC宕机、AC重启、N18K机框断电、N18K重启。Showap-configsummary查看所有AP的在线时长；AC故障，则这台AC上的所有AP在线是时长都会相对昨天短了很多，且在线时长几乎相同。问题：接入交换机掉电或者往汇聚的链路出现问题排查方法：登录对应的交换机查看起机时间，并查看通往汇聚的接口的光衰是否正常。该故障原因下，掉线的AP都在这台交换机下。问题：汇聚交换机掉电或者往核心的链路出现问题排查方法：查看汇聚交换机的起机时间，并查看汇聚交换机上所有接口的光衰情况。该故障原因下，掉线AP为整条线的AP，并且掉线时间很接近故障总结 通过观察掉线AP之间的规律可以判断出问题的点。轨旁和站台都出现不规律掉线，则很大可能是链路中出现大量广播报文或未知名单播导致。部分AP同一时间掉线，大概率为中间设备或中间链路或AC出现故障仅轨旁AP出现不规律掉线，而站台AP正常，大概率为列车内出现环路导致。10用户上下车SSID切换后体验丢包严重故障现象用户上车或者下车之后，会发现网络断开又重连甚至过好久才重连的现象。网络环境上海地铁排查过程查看上下车用户经过的AP所分配的用户vlan是否有变化查看掉线的log查看相关漫游关闭的命令是否配置解决方法1、查看AC上是否开启了2层漫游关闭功能：roaminglocal-layer2direct 2、查看AC上是否关闭了3层漫游IP检测功能 noroaminglayer3-movecheck-ip用户关联在8号线列车车内AP上时，vlan为308，用户下车后，会漫游到站台AP上，vlan为408，对于AC来说，用户的vlan变化了，而因为vlan308和vlan408都在N18K的supervlan下，用户虽然vlan变了，但是IP地址不会改变。正常的用户3层漫游，用户的vlan和IP都不会改变，但现在已经关闭了漫游功能，用户的vlan产生了变化，对应的IP理论上也会变化，如果用户IP不变，AP就会认为这个用户获取IP地址失败，会多次踢用户下线，从而导致用户体验不佳。3、解决办法：AC上配置noroaminglayer3-movecheck-ip，有备AC的场景，备AC也要配置。故障总结 用户上下线相关的问题，第一步都是先查看对应的AP上的log，并对切换前后的用户vlan是否相同，用户切换的具体情况进行分析来逐步排查。11站台AP与AC无法建立capwap隧道问题处理1）查看AP的工作模式，showap-mode查看，是否工作在胖AP模式（发现少量）；2）AP是否获取到IP地址，如果不能获取，检查交换机配置和链路（可在AP上showipinterbr查看）3）AP获取地址后，在AP上ping网关地址和AC的Loopback测试连通性；4）连通性正常，showcapwapsta查看AP建立隧道的状态，停滞在jion状态，查看license是否占满、该AP是否有重复命名；5）连通性正常，隧道状态停滞在imagedata状态，查看AP的版本配置是否正确；6）更换新AP后无法上线，默认AC没