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

[Phil_storey]

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 )

[Andrew_Webster]

What you are seeing is offers to adopt to the APs.

link_level=1 refers to the mint level, in this case think of level1 = layer2

preferred = 0, no specific preference, not even sure if that flag is used.

capacity=1024 is the maximum (not licensed) capacity that the appliance will support.

[Phil_storey]

Hi Andrew

I will shut the backup unit down and see what happens

I have run the show mint mlcp history again and it shows the following where it shows link_level=1, preferred=0 what does this relate to ?

2017-07-04 15:54:15:Sending MLCP Offer to 19.6B.76.C0 (link_level=1, preferred=0, capacity=1024)
2017-07-04 15:53:34:Sending MLCP Offer to 4D.80.C5.F4 (link_level=1, preferred=0, capacity=1024)

[Andrew_Webster]

Phil,

If you shut off the backup RFS, does the system start working properly again?

If it does, then its pretty simple to factory default the backup unit and have it rejoin the cluster.

[Phil_storey]

This gets stranger by the second, so when I look at the rfdomain it indicates there are 8 devices online, when you select the pie chart it show 8, but when you select the rfdomain from the tree view
it shows 6 and two of those are the RFS7k.
If I go to statistics and offline devices it show the units that are offline with one ap connected to a device that I believe is a wired IP polycom phone , I conneted to the AP with a serial cable, and logged in, it then started scrolling messages about IPSpoof
and then showing IPs that are in our Range
"st Mac: 01-00-5E-00-00-FB, Proto = 17.
Jul 04 13:41:17 2017: %DATAPLANE-4-DOSATTACK: IPSPOOF ATTACK: Source IP is Spoo fed : Src IP : 172.17.152.31, Dst IP: 224.0.0.251, Src Mac: F4-F5-D8-AA-DB-66, D st Mac: 01-00-5E-00-00-FB, Proto = 17.
Jul 04 13:41:17 2017: %DATAPLANE-4-DOSATTACK: IPSPOOF ATTACK: Source IP is Spoo fed : Src IP : 172.17.150.53, Dst IP: 224.0.0.251, Src Mac: 50-65-F3-46-48-62, D st Mac: 01-00-5E-00-00-FB, Proto = 17.
Jul 04 13:41:17 2017: %DATAPLANE-4-DOSATTACK: IPSPOOF ATTACK: Source IP is Spoo fed : Src IP : 172.17.146.137, Dst IP: 224.0.0.252, Src Mac: 00-15-5D-90-CA-61,"

The AP is now powered off.
The syslog is still showing %dataplane-4-DOSATTACK:ipspoof attack : source ip is spoofed 10.0.0.138 then mac etc

I have a know working config from the RFS taken on the 26/5/17 when wifi bridge was setup and working, although the bridge is not in place at present.

I'm not sure what to do now, default the primary and backup, fire the config back in then set the cluster back up ?

[Phil_storey]

Hi, this is the output from the the sh adoption history.

the RFS units are up and can see each other, they have ge1 set as a trunk port with Vlan 1 as the native vlan ( currently not tagged ) and allowed vlans are 1 & 10
the network switches have only 2 vlans 1 & 10 and the ports are allowed ( tagall )

The AP/s have the Ge1 set as a trunk port with allowed vlans 1 & 10 ( native vlan untagged ) then there is wlan to vlan map in the wireless for the two wifi networks

The network switches are Nortel currenly ( hoping to move to extreme in the very near future )
but for now its nortel. This has all become a mistry as to what has gone wrong, Myself I think its the network switches, but its proving it. I suppose the other thing I could do is get a spare switch default
then connect the rfs and some AP's in and see what happens ?

-------------------------------------------------------------------------------- --------------------
MAC TYPE EVENT TIME-STAMP REASON
-------------------------------------------------------------------------------- --------------------
00-15-70-81-BE-8E RFS7000 un-adopted 2017-07-04 06:25:17 Adopter 70.81.BE.8E is no longer reachable
00-15-70-81-BE-8E RFS7000 adopted 2017-07-04 06:24:53 N.A.
00-15-70-81-BE-8E RFS7000 un-adopted 2017-07-04 06:24:42 Adopter 70.81.BE.8E is no longer reachable
00-15-70-81-BE-8E RFS7000 adopted 2017-07-04 06:23:50 N.A.
00-15-70-81-BE-8E RFS7000 un-adopted 2017-07-04 06:17:36 Adopter 70.81.BE.8E is no longer reachable
00-15-70-81-BE-8E RFS7000 adopted 2017-07-04 06:17:15 N.A.
00-15-70-81-BE-8E RFS7000 un-adopted 2017-07-04 06:17:10 Receive d reset from switch 70.81.BE.8E, {'reason': 'controller cfgd is not your adopte r due to misadoption'}
00-15-70-81-BE-8E RFS7000 adopted 2017-07-04 06:15:58 N.A.
00-15-70-81-BE-8E RFS7000 un-adopted 2017-07-04 06:09:36 Adopter 70.81.BE.8E is no longer reachable
00-15-70-81-BE-8E RFS7000 adopted 2017-07-04 06:09:20 N.A.
00-15-70-81-BE-8E RFS7000 un-adopted 2017-07-04 06:09:07 Adopter 70.81.BE.8E is no longer reachable
00-15-70-81-BE-8E RFS7000 adopted 2017-07-04 06:08:15 N.A.
00-15-70-81-BE-8E RFS7000 un-adopted 2017-07-04 06:01:58 Adopter 70.81.BE.8E is no longer reachable
00-15-70-81-BE-8E RFS7000 adopted 2017-07-04 06:01:36 N.A.
00-15-70-81-BE-8E RFS7000 un-adopted 2017-07-04 06:01:24 Adopter 70.81.BE.8E is no longer reachable
00-15-70-81-BE-8E RFS7000 adopted 2017-07-04 06:00:33 N.A.
--------------------------------------------------------------------------------