wing 5.8.5 reports AP's as down but they are not
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎06-29-2017 09:28 AM
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 )
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎07-04-2017 01:45 AM
Can you login to one of the APs and provide output of CLI command 'sh addoption history'
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎07-03-2017 12:50 PM
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.
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎07-03-2017 11:22 AM
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 ?
%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 ?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎07-03-2017 06:33 AM
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
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎07-02-2017 08:00 PM
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.
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.