cancel
Showing results for 
Search instead for 
Did you mean: 

wing 5.8.5 reports AP's as down but they are not

wing 5.8.5 reports AP's as down but they are not

Phil_storey
Contributor
Hi All
We had a power outage last week, some parts of the network stayed up on the UPS and others the UPS's failed after 20 mins. since then the RFS shows that some of the AP's are down, but they have clients connected, I can get onto the AP's being shown as down via the AP's ip address, I have reset the units, but the RFS ( wing 5.8.5 ) still shows as down ?
I have also restarted the RFS units as well.
now Im confused ( Oh no I'm always confused , thats normal )

27 REPLIES 27

RobertZ
Extreme Employee
Can you login to one of the APs and provide output of CLI command 'sh addoption history'

Andrew_Webster
New Contributor III
Phil,

Don't worry about IPv6.

The config looks ok, except the port speed setting. As a general rule, gigabit networks should not use forced speed/duplex settings, in fact the standard mandates auto negotiation.

Your original post mentioned that all this started after a power failure, so I'm guessing some unsaved config changes got lost.

Check AP 7131 vs AP 7532 config differences, as well as the switch-port config of the respective switches they are connected to. The mint MLCP output clearly shows APs getting adopted then dropping immediately afterward, indicating something about the config is breaking the connectivity.

Beyond this, I think some one-on-one troubleshooting and/or opening a case with GTAC is in order.

Phil_storey
Contributor
Looking at the syslog I also see this
%DATAPLANE-4-RAGUARD: RA-GUARD: router advertisement/redirect from/to untrusted port/wlan 0, vlan 1 : Src IP : fe80:0:0:0:217:c5ff:fe99:67a0, Dst IP: ff02:0:0:0:0:0:0:1, Src Mac: 00-17-C5-99-67-A0, Dst Mac: 33-33-00-00-00-01, ICMP type = 134, ICMP code = 0, Proto = 58.

Here its saying untrusted port/wlan 0 - there is no wlan 0 or port 0 i believe

It looks like IP6 which we do not use, is it worth turning the IP6 stuff off ?

Phil_storey
Contributor
Hi, this is the output from the rfs ( show run deveice ) the last block
I'm not sure what bit I should be looking at.

interface ge1
speed 1000
switchport mode trunk
switchport trunk native vlan 1
no switchport trunk native tagged
switchport trunk allowed vlan 1-10
no cdp receive
no cdp transmit
no lldp receive
no lldp transmit
interface ge2
shutdown
interface vlan1
ip address dhcp
ip address zeroconf secondary
ip dhcp client request options all
interface wwan1
interface pppoe1
use event-system-policy AP-Down
use firewall-policy default
ntp server 172.17.144.150 prefer version 3
ntp server 172.17.144.151 version 3
use role-policy RBFW
email-notification host
email-notification recipient
logging on
controller hello-interval 60 adjacency-hold-time 180
service pm sys-restart
no upgrade opcode auto
no upgrade opcode path
no upgrade opcode reload
traffic-shape enable

It looks OK

Andrew_Webster
New Contributor III
Phil,

Looking at your dump, it appears as if the config being pushed out the APs once they are adopted is "breaking" the connectivity with the RFS. I can clearly see the AP is actually adopting, but then going into Waiting to retry state because it lost contact with the RFS.

The Backup RFS is also doing the adoption, which seems to differ from your show cluster members output of the other day.

Have a close look at the configuration going into the APs with the following command from the RFS:

show run device device_name

This will show you the final, complete, config that is going to be sent to the device when it adopts, and the profiles are folded down, so you can actually see what the AP is going to get.

Pay close attention to the last block of configuration which will be the device itself, and particularly interface ge1 and vlan 1 configuration, then compare it with the configuration going out to the 7532s using the same command. I suspect that something may have been modified in the 7131's profile hence the breakage you're experiencing.

GTM-P2G8KFN