軌道交通地鐵無(wú)線解決方案故障一本通v1.0

軌道交通地鐵無(wú)線解決方案故障一本通v1.0

1車內(nèi)覆蓋APAP530-I(S2)單臺(tái)掉線故障現(xiàn)象AP530-I(S2)單臺(tái)掉線。網(wǎng)絡(luò)環(huán)境 上海地鐵網(wǎng)絡(luò)環(huán)境排查過(guò)程AC上pingS2的IP地址，如果能通，telnet到S2上打開(kāi)log，查看capwap建立的log提示。如果AC無(wú)法ping通S2，則telnet到此S2所在的工業(yè)交換機(jī)，查看該S2對(duì)應(yīng)的接口狀態(tài)以及供電狀態(tài)。查看主AC和備AC上的這個(gè)AP配置是否一致；解決方法問(wèn)題：主備AC下ap-group或者ript的配置不一致導(dǎo)致，會(huì)出現(xiàn)AP的capwap震蕩現(xiàn)象解決方法：將主備AC的配置恢復(fù)一致問(wèn)題：AP上提示ap名沖突解決方法：在AC上showap-configrunap_name保存配置，之后刪除這個(gè)ap-config，待AP上線后，將之前保存的ap-config配置刷如此AP的ap-config中，并對(duì)AP重命名。問(wèn)題：工業(yè)交換機(jī)連接故障AP的接口down解決方法：將此交換機(jī)接口的poe關(guān)閉再開(kāi)啟，查看接口1-2min后是否會(huì)up，如果還不會(huì)up，則申請(qǐng)進(jìn)車庫(kù)用串口連接AP排查問(wèn)題，并檢查網(wǎng)線是否有損壞。問(wèn)題：工業(yè)交換機(jī)連接故障AP的接口up，但是交換機(jī)學(xué)不到AP的mac解決方法：暫無(wú)故障總結(jié) AP掉線問(wèn)題本質(zhì)上是AP與AC通路的問(wèn)題以及AP是否能在AC上上線的原則問(wèn)題。 通路好理解，上線原則目前主要為：主備AC的ap-config配置是否一致、AP名是否沖突、AP版本與AC版本是否兼容。 通過(guò)這兩大點(diǎn)進(jìn)行逐步排查分析，大部分AP掉線問(wèn)題都可以定位出來(lái)。2車內(nèi)大約一半的覆蓋APAP530-I(S2)掉線故障現(xiàn)象多臺(tái)AP530-I(S2)掉線。網(wǎng)絡(luò)環(huán)境 上海地鐵網(wǎng)絡(luò)環(huán)境排查過(guò)程AC上查看該列車車頭和車尾NONROOT的在線情況查看車頭和車尾NONROOT是否配置上行鏈路檢測(cè)功能查看這些掉線AP在主AC和備AC上的配置是否一致查看工業(yè)交換機(jī)鏈路問(wèn)題解決方法問(wèn)題：NONROOT信道錯(cuò)誤解決方法：在AC能通故障NONROOT時(shí)，telnet到NONROOT上查看是否是調(diào)頭失敗導(dǎo)致信道錯(cuò)誤，如果是，則修改信道，等待掉線S2上線；問(wèn)題：NONROOT天線故障解決方法：在AC能通故障NONROOT時(shí)，進(jìn)入NONROOT上多次showdotwds2/0查看橋接的RSSI，多次show的結(jié)果中橋接RSSI都是很低的，需要入庫(kù)檢查S3的天線及接口等硬件問(wèn)題。問(wèn)題：非橋接自身問(wèn)題導(dǎo)致的NONROOT橋接通路故障解決方法： 登錄交換機(jī)將故障的NONROOT的物理接口進(jìn)行shutdown，過(guò)一會(huì)兒掉線的S2即可上線，待故障NONROOT的capwap建立后，ap-config下配置上行鏈路檢測(cè)功能，不保存到預(yù)配置中，該列車的另一臺(tái)NONROOT也進(jìn)行配置。問(wèn)題：工業(yè)交換機(jī)鏈路故障或VSU斷開(kāi)解決方法： 入車庫(kù)檢查工業(yè)交換機(jī)故障。故障總結(jié) 大約一半的車內(nèi)覆蓋AP掉線的情況，幾乎99%的概率是其中一臺(tái)S3出現(xiàn)橋接鏈路問(wèn)題，將排查關(guān)鍵點(diǎn)放在這臺(tái)故障S3上，如果S3的橋接故障并非信道錯(cuò)誤等可以立刻修正的問(wèn)題導(dǎo)致的，則需要檢測(cè)S3的收發(fā)信號(hào)是否受到影響。3車頭車尾AP530-I(S3)掉線故障現(xiàn)象AP530-I(S3)掉線。網(wǎng)絡(luò)環(huán)境上海地鐵排查過(guò)程S3與AC之間的ping有無(wú)丟包查看S3的信道查看工業(yè)交換機(jī)對(duì)應(yīng)的接口狀態(tài)解決方法 問(wèn)題：NONROOT信道錯(cuò)誤解決方法：在AC能通故障NONROOT時(shí)，telnet到NONROOT上查看是否是調(diào)頭失敗導(dǎo)致信道錯(cuò)誤，如果是，則修改信道，等待上線；問(wèn)題：工業(yè)交換機(jī)與S3之間通訊問(wèn)題解決方法：入庫(kù)檢查網(wǎng)線問(wèn)題；問(wèn)題：S3與AC之間ping丟包問(wèn)題解決方法：找到ping丟包的規(guī)律，是固定軌旁區(qū)間丟包或是始終都有間歇性丟包S3上shell下（run-system-shell）開(kāi)啟橋接調(diào)試wlwdsmsglevel0x64（關(guān)閉調(diào)試為wlwdsmsglevel0x0），之后退出shell，長(zhǎng)時(shí)間pingAC，收集log（CRT的log設(shè)置需要每一行都有系統(tǒng)時(shí)間，如：[%Y-%M-%D%h:%m:%s]）并發(fā)給研發(fā)進(jìn)一步排查；故障總結(jié) S3的掉線多半與橋接通路有關(guān)，先排查淺顯的問(wèn)題，如信道、流量過(guò)大等，再檢查網(wǎng)橋ping丟包情況。4網(wǎng)橋上數(shù)據(jù)不通故障現(xiàn)象車內(nèi)用戶沒(méi)法通訊或：所有車內(nèi)覆蓋AP都沒(méi)上線，只有車頭車尾AP在線，車內(nèi)無(wú)wifi信號(hào)網(wǎng)絡(luò)環(huán)境上海地鐵排查過(guò)程AC與S3是否能通檢查軌旁AP和車頭車尾AP的bridgevlan配置；解決方法問(wèn)題：軌旁AP和車頭車尾AP的bridgevlan未配置解決方法：在沒(méi)有配置bridgevlan的地方加上配置，等待S2上線或車內(nèi)用戶上線；問(wèn)題：S3與AC之間ping丟包問(wèn)題解決方法：找到ping丟包的規(guī)律，是固定軌旁區(qū)間丟包或是始終都有間歇性丟包S3上shell下（run-system-shell）開(kāi)啟橋接調(diào)試wlwdsmsglevel0x64（關(guān)閉調(diào)試為wlwdsmsglevel0x0），之后退出shell，長(zhǎng)時(shí)間pingAC，收集log（CRT的log設(shè)置需要每一行都有系統(tǒng)時(shí)間，如：[%Y-%M-%D%h:%m:%s]）并發(fā)給研發(fā)進(jìn)一步排查；故障總結(jié) 網(wǎng)橋通路問(wèn)題在于是S3自身通路問(wèn)題或者使用這個(gè)通路的vlan無(wú)法通訊的問(wèn)題。5用戶關(guān)聯(lián)失敗故障現(xiàn)象用戶終端提示“無(wú)法連接”。網(wǎng)絡(luò)環(huán)境 上海地鐵排查過(guò)程AP上開(kāi)啟log，查看對(duì)應(yīng)的用戶logAC上查看對(duì)應(yīng)的AP用戶數(shù)是否已達(dá)上限查看wids配置查看Response-RSSI配置值解決方法問(wèn)題：用戶已達(dá)上限解決方法：從ACtelnet到問(wèn)題AP上，打開(kāi)log查看日志；根據(jù)需要，修改sta-limit的值，建議每個(gè)radio配置為64個(gè)用戶，根據(jù)不同地方的人流量的不同，有些站臺(tái)或者列車上需要配置為最大值128每個(gè)radio。問(wèn)題：wids配置白名單解決方法：AC與AP上都做wids配置檢查，查看是否配置了白名單，并刪除白名單配置；問(wèn)題：response-rssi配置過(guò)高解決方法：AC上telnet到問(wèn)題AP是上，打開(kāi)log，查看是否有如下logAC上查看問(wèn)題AP的showap-configrun配置，是否response-rssi配置過(guò)高。故障總結(jié) 用戶無(wú)法上線的問(wèn)題，最主要的是log信息的查看，第一步就要登錄AP上查看用戶log，否則都不知道發(fā)生了什么事情。6用戶獲取地址失敗故障現(xiàn)象用戶關(guān)聯(lián)成功，但是終端一直獲取不到IP地址。網(wǎng)絡(luò)環(huán)境上海地鐵排查過(guò)程查看N18K的地址池是否已滿AP上查看是否配置了DHCPSNOOPINGAP上開(kāi)啟debug，查看是否收到問(wèn)題用戶的DHCP報(bào)文解決方法問(wèn)題：N18K地址池已滿解決方法：擴(kuò)充地址池。問(wèn)題：AP上配置DHCPSNOOPING解決方法：AC上關(guān)閉DHCPSNOOPING功能，或者將AP上的NFPP閾值水線提高，提高的配置如下：nfppdhcp-guardrate-limitper-src-mac1500dhcp-guardrate-limitper-port1500dhcp-guardattack-thresholdper-src-mac1500dhcp-guardattack-thresholdper-port1500問(wèn)題：DHCP報(bào)文在路徑上被丟棄解決方法：DHCPServer設(shè)備上查看是否收到終端的DHCP報(bào)文并回應(yīng)報(bào)文開(kāi)啟dhcpdebug過(guò)濾：debugipdhcpfiltermacxxxx.xxxx.xxxxdebugipdhcpserall如果DHCPSERVER上有看到回復(fù)用戶的DHCP報(bào)文，那么AP上進(jìn)行debug：Debugpacketfunctionallprocotol0x10print-pktcount50xxxx.xxxx.xxxx通過(guò)對(duì)應(yīng)的字節(jié)查找是否發(fā)出或者收到DHCP報(bào)文：DHCPDiscover報(bào)文： 關(guān)注下圖紅框部分內(nèi)容可知這個(gè)報(bào)文是否是DHCPDISCOVER。DHCPOffer報(bào)文： 關(guān)注下圖紅框部分內(nèi)容可知這個(gè)報(bào)文是否是DHCPOFFER。DHCPRequest報(bào)文： 關(guān)注下圖紅框部分內(nèi)容可知這個(gè)報(bào)文是否是DHCPREQUEST。DHCPAck報(bào)文： 關(guān)注下圖紅框部分內(nèi)容可知這個(gè)報(bào)文是否是DHCPACK。 如果AP上沒(méi)看到Server回應(yīng)的DHCP報(bào)文，很可能是AP設(shè)備端上方的設(shè)備鏈路問(wèn)題導(dǎo)致，需要排查有線端問(wèn)題； 如果AP上看到了Server回應(yīng)的DHCP報(bào)文，那就把log保存下來(lái)，發(fā)給研發(fā)進(jìn)一步排查；故障總結(jié) 用戶獲取DHCP的問(wèn)題，需要從通路、DHCPSERVER、AP的轉(zhuǎn)發(fā)、空口干擾這幾個(gè)角度出發(fā)進(jìn)行問(wèn)題排查。7用戶很難獲取地址故障現(xiàn)象用戶關(guān)聯(lián)成功，但是很難獲取到IP地址,需要等很長(zhǎng)時(shí)間,或者需要多次重連才能獲取到IP地址。網(wǎng)絡(luò)環(huán)境上海地鐵排查過(guò)程查看AP是否配置DHCPSNOOPING找出獲取不到IP地址的時(shí)機(jī)是否有規(guī)律解決方法問(wèn)題：DHCPSNOOPING解決方法：AC上關(guān)閉DHCPSNOOPING功能，或者將AP上的NFPP閾值水線提高，提高的配置如下：nfppdhcp-guardrate-limitper-src-mac1500dhcp-guardrate-limitper-port1500dhcp-guardattack-thresholdper-src-mac1500dhcp-guardattack-thresholdper-port1500問(wèn)題：高峰期用戶過(guò)多導(dǎo)致的空口競(jìng)爭(zhēng)解決方法：使用WIS進(jìn)行網(wǎng)優(yōu)問(wèn)題：RRM配置導(dǎo)致解決方法：主備AC上關(guān)閉RRM配置（advanced802.11a/bmonitormodeenable）之前在重慶地鐵出現(xiàn)用戶獲取不到IP地址的情況。 現(xiàn)象：用戶在兩個(gè)SSID之間切換，很容易出現(xiàn)獲取IP地址要很久的問(wèn)題。 原因：因?yàn)閍dvanced802.11a/bmonitormodeenable導(dǎo)致AP會(huì)自動(dòng)掃描信道；

查看配置時(shí)發(fā)現(xiàn)主沒(méi)配置這條命令，但是備AC上卻配置了。理論上AS熱備下主AC的配置才會(huì)生效，但分析之前的升級(jí)事件，發(fā)現(xiàn)升級(jí)14號(hào)版本那天晚上，是先升級(jí)所有AP，從backup_AC和master_AC的起機(jī)時(shí)間來(lái)看（backup_AC早master_AC

4分鐘49秒的時(shí)間），所以當(dāng)時(shí)現(xiàn)場(chǎng)應(yīng)該是backup_AC比master_AC早升級(jí)，

順序如下：AP升級(jí)完后起機(jī)，起機(jī)48分鐘后與backup_AC建立capwap由于backup_AC配置了advanced802.11a/bmonitormodeenable導(dǎo)致AP會(huì)自動(dòng)掃描信道；master_AC起來(lái)后，過(guò)10min時(shí)間master_AC會(huì)成為AP的主AC，但是不會(huì)下發(fā)配置。這時(shí)AP上已經(jīng)開(kāi)啟了掃描功能，就不會(huì)停下了，如果重啟AP，則master_AC沒(méi)有advanced802.11a/bmonitormodeenable的配置，所以AP重啟后不會(huì)去掃描信道；解決辦法：

backup_AC上把monitor配置去掉：

AC2(config)#advanced802.11amonitormodedisable

AC2(config)#advanced802.11bmonitormodedisable

master_AC上把monitor配置加上

AC1(config)#advanced802.11amonitormodeenable

AC1(config)#advanced802.11bmonitormodeenable

可以等個(gè)1-2min，之后刪除monitor配置

AC1(config)#advanced802.11amonitormodedisable

AC1(config)#advanced802.11bmonitormodedisable之后登錄AP上打開(kāi)調(diào)試查看AP不會(huì)再掃描信道，用戶獲取IP地址恢復(fù)正常。故障總結(jié) 用戶DHCP獲取慢時(shí)，需要先找出故障的時(shí)間或者條件的規(guī)律，并檢查是否配置DHCPSNOOPING（DHCPSNOOPING默認(rèn)將超過(guò)10pps的DHCP報(bào)文源mac列為黑名單），之后再逐步排查。8大范圍AP于不同時(shí)間掉線故障現(xiàn)象某個(gè)時(shí)間段（如早晚高峰期），出現(xiàn)大范圍AP掉線。網(wǎng)絡(luò)環(huán)境上海地鐵排查過(guò)程查看掉線AP之間的規(guī)律登錄剛上線不久的AP查看掉線原因，并長(zhǎng)時(shí)間pingAC查看丟包情況查看AP的mac及收發(fā)報(bào)速率情況解決方法問(wèn)題：Mac地址表滿，AP3220有1K的mac表容量，AP530系列產(chǎn)品有4K的mac表容量。（一旦出現(xiàn)mac地址表滿的情況，說(shuō)明環(huán)境中有環(huán)路或者二層廣播隔離失敗。ARP的等級(jí)和CAPWAP報(bào)文等級(jí)一樣，所以AP處在大量ARP報(bào)文的環(huán)境中，會(huì)將CAPWAP報(bào)文被丟棄，從而導(dǎo)致高峰期大面積AP掉線。）解決方法： 查看mac的vlan，找出不應(yīng)該出現(xiàn)在表中的mac，之后登錄對(duì)應(yīng)的接入交換機(jī)，查看交換機(jī)的ACL過(guò)濾配置是否過(guò)濾了不應(yīng)該有的報(bào)文，并做相應(yīng)修改。 接入交換機(jī)連接AP的接口，在IN方向，不允許以N18K和AC的MAC為源MAC的所有報(bào)文，在OUT方向，僅允許以N18K和AC的MAC為源MAC的報(bào)文。案例 之前上海出現(xiàn)過(guò)一例在高峰期出現(xiàn)隨機(jī)性的大量AP掉線問(wèn)題。 現(xiàn)象：早晨7-8點(diǎn)左右，AC上看到100多臺(tái)AP的隧道斷開(kāi)又重建。 排查：1、分段ping，發(fā)現(xiàn)高峰期AC到匯聚的ping出現(xiàn)30s的丟包，懷疑AC到匯聚網(wǎng)絡(luò)有問(wèn)題，；2、通過(guò)AP和AC上查看CPU發(fā)現(xiàn)，AC的CPU有時(shí)會(huì)升到70%，可能是高峰期流量大導(dǎo)致AC的CPU過(guò)高，從而導(dǎo)致ping丟包；3、AP上查看mac地址表發(fā)現(xiàn)mac地址表滿，懷疑出現(xiàn)環(huán)路。4、得知有線端未配置ACL過(guò)濾廣播，高峰期用戶數(shù)多，ARP報(bào)文會(huì)在整個(gè)大二層內(nèi)擴(kuò)散，從而導(dǎo)致AP的mac地址表滿； 原因：ARP的等級(jí)和CAPWAP報(bào)文等級(jí)一樣，所以AP處在大量ARP報(bào)文的環(huán)境中，會(huì)將CAPWAP報(bào)文被丟棄，從而導(dǎo)致高峰期大面積AP掉線。解決辦法：

在交換機(jī)上配置不同vlan的非網(wǎng)管mac的ARP報(bào)文過(guò)濾ACL并應(yīng)用。 配置之后觀察發(fā)現(xiàn)，高峰期大面積AP掉線的現(xiàn)象消失； 1號(hào)線接入交換機(jī)的ACL實(shí)例見(jiàn)如下: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故障總結(jié) 通過(guò)觀察掉線AP之間的規(guī)律可以判斷出問(wèn)題的點(diǎn)。軌旁和站臺(tái)都出現(xiàn)不規(guī)律掉線，則很大可能是鏈路中出現(xiàn)大量廣播報(bào)文或未知名單播導(dǎo)致。部分AP同一時(shí)間掉線，大概率為中間設(shè)備或中間鏈路或AC出現(xiàn)故障僅軌旁AP出現(xiàn)不規(guī)律掉線，而站臺(tái)AP正常，大概率為列車內(nèi)出現(xiàn)環(huán)路導(dǎo)致。9大量AP幾乎同時(shí)掉線故障現(xiàn)象早晨的日常檢查時(shí)發(fā)現(xiàn)大部分的AP的在線時(shí)長(zhǎng)不正常。網(wǎng)絡(luò)環(huán)境上海地鐵排查過(guò)程查看掉線AP之間的關(guān)系根據(jù)掉線AP之間的關(guān)系排查其他設(shè)備問(wèn)題解決方法問(wèn)題：AC是否故障排查方法：登錄到AC上，showversion查看起機(jī)時(shí)長(zhǎng)；如果起機(jī)時(shí)長(zhǎng)相對(duì)昨天變短，說(shuō)明AC重啟過(guò)，可能是AC宕機(jī)、AC重啟、N18K機(jī)框斷電、N18K重啟。Showap-configsummary查看所有AP的在線時(shí)長(zhǎng)；AC故障，則這臺(tái)AC上的所有AP在線是時(shí)長(zhǎng)都會(huì)相對(duì)昨天短了很多，且在線時(shí)長(zhǎng)幾乎相同。問(wèn)題：接入交換機(jī)掉電或者往匯聚的鏈路出現(xiàn)問(wèn)題排查方法：登錄對(duì)應(yīng)的交換機(jī)查看起機(jī)時(shí)間，并查看通往匯聚的接口的光衰是否正常。該故障原因下，掉線的AP都在這臺(tái)交換機(jī)下。問(wèn)題：匯聚交換機(jī)掉電或者往核心的鏈路出現(xiàn)問(wèn)題排查方法：查看匯聚交換機(jī)的起機(jī)時(shí)間，并查看匯聚交換機(jī)上所有接口的光衰情況。該故障原因下，掉線AP為整條線的AP，并且掉線時(shí)間很接近故障總結(jié) 通過(guò)觀察掉線AP之間的規(guī)律可以判斷出問(wèn)題的點(diǎn)。軌旁和站臺(tái)都出現(xiàn)不規(guī)律掉線，則很大可能是鏈路中出現(xiàn)大量廣播報(bào)文或未知名單播導(dǎo)致。部分AP同一時(shí)間掉線，大概率為中間設(shè)備或中間鏈路或AC出現(xiàn)故障僅軌旁AP出現(xiàn)不規(guī)律掉線，而站臺(tái)AP正常，大概率為列車內(nèi)出現(xiàn)環(huán)路導(dǎo)致。10用戶上下車SSID切換后體驗(yàn)丟包嚴(yán)重故障現(xiàn)象用戶上車或者下車之后，會(huì)發(fā)現(xiàn)網(wǎng)絡(luò)斷開(kāi)又重連甚至過(guò)好久才重連的現(xiàn)象。網(wǎng)絡(luò)環(huán)境上海地鐵排查過(guò)程查看上下車用戶經(jīng)過(guò)的AP所分配的用戶vlan是否有變化查看掉線的log查看相關(guān)漫游關(guān)閉的命令是否配置解決方法1、查看AC上是否開(kāi)啟了2層漫游關(guān)閉功能：roaminglocal-layer2direct 2、查看AC上是否關(guān)閉了3層漫游IP檢測(cè)功能 noroaminglayer3-movecheck-ip用戶關(guān)聯(lián)在8號(hào)線列車車內(nèi)AP上時(shí)，vlan為308，用戶下車后，會(huì)漫游到站臺(tái)AP上，vlan為408，對(duì)于AC來(lái)說(shuō)，用戶的vlan變化了，而因?yàn)関lan308和vlan408都在N18K的supervlan下，用戶雖然vlan變了，但是IP地址不會(huì)改變。正常的用戶3層漫游，用戶的vlan和IP都不會(huì)改變，但現(xiàn)在已經(jīng)關(guān)閉了漫游功能，用戶的vlan產(chǎn)生了變化，對(duì)應(yīng)的IP理論上也會(huì)變化，如果用戶IP不變，AP就會(huì)認(rèn)為這個(gè)用戶獲取IP地址失敗，會(huì)多次踢用戶下線，從而導(dǎo)致用戶體驗(yàn)不佳。3、解決辦法：AC上配置noroaminglayer3-movecheck-ip，有備AC的場(chǎng)景，備AC也要配置。故障總結(jié) 用戶上下線相關(guān)的問(wèn)題，第一步都是先查看對(duì)應(yīng)的AP上的log，并對(duì)切換前后的用戶vlan是否相同，用戶切換的具體情況進(jìn)行分析來(lái)逐步排查。11站臺(tái)AP與AC無(wú)法建立capwap隧道問(wèn)題處理1）查看AP的工作模式，showap-mode查看，是否工作在胖AP模式（發(fā)現(xiàn)少量）；2）AP是否獲取到IP地址，如果不能獲取，檢查交換機(jī)配置和鏈路（可在AP上showipinterbr查看）3）AP獲取地址后，在AP上ping網(wǎng)關(guān)地址和AC的Loopback測(cè)試連通性；4）連通性正常，showcapwapsta查看AP建立隧道的狀態(tài)，停滯在jion狀態(tài)，查看license是否占滿、該AP是否有重復(fù)命名；5）連通性正常，隧道狀態(tài)停滯在imagedata狀態(tài)，查看AP的版本配置是否正確；6）更換新AP后無(wú)法上線，默認(rèn)AC沒(méi)