topic Re: RFS4000 adopts AP7562 and unadopts it instantly in ExtremeWireless (WiNG)

RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Mon, 26 Aug 2019 07:09:51 GMT

Hello guys!
Can you help me with this question?
Im running RFS4000 and adopt 1 AP7562 as Root directly connected to RFS. When I try to adopt another AP via Mesh network, I see it adopted for 1 second and then it unadopts back. It happens continiously. AP doesn't even upload config from RFS. First AP works as usual.

Thank you!

Re: RFS4000 adopts AP7562 and unadopts it instantly

ckelly — Mon, 26 Aug 2019 21:14:00 GMT

First, I'm making as assumption here that because you refer to the 7562 as "root" that you are talking about Meshconnex and the 7562 is configured as a root node. Correct?

Also, please confirm that when you try to adopt another AP "via Mesh network" that you are manually configuring the other AP and then wanting it to form a mesh connection with the root node 7562 so that it can adopt.

When the AP adopts for 1 second and then unadopts- and then this happens continuously, are you saying that it continuously adopts and unadopts on its own? Or that it adopts and then unadopts....and then you have to reconfigure it again so that it has a mesh configuration?

Version of WiNG?

Re: RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Mon, 26 Aug 2019 21:46:47 GMT

Hello Chris!
Yes, first AP7562 ("Office" on screen) is directly connected to the RFS and working in root mode.
Second one ("VMMtest" on screen) is non-root and trying to connect through first one to RFS.

Second AP configured manually by downloading config of first AP.

When AP try to adopts I can see it on RFS for a few seconds.
Here is screen.

WiNG 5.9.2.5
Thank you!

Re: RFS4000 adopts AP7562 and unadopts it instantly

ckelly — Mon, 26 Aug 2019 21:52:58 GMT

Can you show the configuration of the 2nd AP?

Are you able to console into the 2nd AP?

Re: RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Mon, 26 Aug 2019 21:57:55 GMT

config of AP

!
! Configuration of AP7562 version 5.9.2.5-001R
!
!
version 2.6
!
!
client-identity-group default
load default-fingerprints
!
ip access-list BROADCAST-MULTICAST-CONTROL
permit tcp any any rule-precedence 10 rule-description "permit all TCP traffic"
permit udp any eq 67 any eq dhcpc rule-precedence 11 rule-description "permit DHCP replies"
deny udp any range 137 138 any range 137 138 rule-precedence 20 rule-description "deny windows netbios"
disable deny ip any 224.0.0.0/4 rule-precedence 21 rule-description "deny IP multicast"
deny ip any host 255.255.255.255 rule-precedence 22 rule-description "deny IP local broadcast"
permit ip any any rule-precedence 100 rule-description "permit all IP traffic"
!
mac access-list PERMIT-ARP-AND-IPv4
permit any any type ip rule-precedence 10 rule-description "permit all IPv4 traffic"
permit any any type arp rule-precedence 20 rule-description "permit all ARP traffic"
!
ip snmp-access-list default
permit any
!
wlan ShougangWiFi
ssid ShougangWiFi
vlan 50
bridging-mode local
encryption-type ccmp
authentication-type none
no answer-broadcast-probes
wireless-client inactivity-timeout 600
wpa-wpa2 psk 0 Shoug@ngWiFi20!9
no wing-extensions wing-load-information
no client-load-balancing allow-single-band-clients 5ghz
no client-load-balancing allow-single-band-clients 2.4ghz
ip arp trust
shutdown on-unadoption
!

!
firewall-policy default
no ip dos smurf
no ip dos twinge
no ip dos invalid-protocol
no ip dos router-advt
no ip dos router-solicit
no ip dos option-route
no ip dos ascend
no ip dos chargen
no ip dos fraggle
no ip dos snork
no ip dos ftp-bounce
no ip dos tcp-intercept
no ip dos broadcast-multicast-icmp
no ip dos land
no ip dos tcp-xmas-scan
no ip dos tcp-null-scan
no ip dos winnuke
no ip dos tcp-fin-scan
no ip dos udp-short-hdr
no ip dos tcp-post-syn
no ip dos tcphdrfrag
no ip dos ip-ttl-zero
no ip dos ipspoof
no ip dos tcp-bad-sequence
no ip dos tcp-sequence-past-window
no ip-mac conflict
no ip-mac routing conflict
dhcp-offer-convert
no stateful-packet-inspection-l2
no virtual-defragmentation
!
!
mint-policy global-default
mtu 1460
!
meshpoint-qos-policy default
accelerated-multicast autodetect classification trust
!
radio-qos-policy default
!
meshpoint ShougangMine
description MeshConnex_Network
meshid ShougangMine
beacon-format mesh-point
control-vlan 40
allowed-vlans 40,50
neighbor inactivity-timeout 60
security-mode none
no root
!
smart-rf-policy SmartRF
sensitivity high
assignable-power 5GHz max 20
assignable-power 5GHz min 20
assignable-power 2.4GHz max 20
assignable-power 2.4GHz min 10
channel-list 5GHz 136
channel-width 5GHz auto
smart-ocs-monitoring frequency 5GHz 3
smart-ocs-monitoring frequency 2.4GHz 3
smart-ocs-monitoring sample-count 5GHz 3
smart-ocs-monitoring sample-count 2.4GHz 3
smart-ocs-monitoring extended-scan-frequency 5GHz 0
smart-ocs-monitoring extended-scan-frequency 2.4GHz 0
interference-recovery client-threshold 255
interference-recovery channel-switch-delta 5GHz 5
interference-recovery channel-switch-delta 2.4GHz 5
select-shutdown
neighbor-recovery power-threshold 5GHz -65
neighbor-recovery power-threshold 2.4GHz -65
select-shutdown cci-high-threshold -82
select-shutdown cci-low-threshold -95
select-shutdown frequency-limiter 5
select-shutdown frequency 30
coverage-hole-recovery interval 5GHz 15
coverage-hole-recovery interval 2.4GHz 15
coverage-hole-recovery coverage-interval 5GHz 5
coverage-hole-recovery coverage-interval 2.4GHz 5
interference-recovery channel-hold-time 180
!
!
management-policy default
no telnet
no http server
https server
rest-server
no ftp
ssh
user admin password 1 30edda66b744603adcdcebcf392eeff35f4b4f975891a2b413e579b84a6d3261 role superuser access all
no snmp-server manager v3
snmp-server community 0 private rw
snmp-server community 0 public ro
snmp-server user snmptrap v3 encrypted des auth md5 0 motorola
snmp-server user snmpmanager v3 encrypted des auth md5 0 motorola
!
profile ap7562 AP7562-Root
no mint mlcp ipv6
ip igmp snooping querier query-interval 2
bridge vlan 40
bridging-mode local
ip igmp snooping
ip igmp snooping querier
ipv6 mld snooping
ipv6 mld snooping querier
area ShougangMine
autoinstall configuration
no autoinstall firmware
device-upgrade count 5
crypto ikev1 policy ikev1-default
isakmp-proposal default encryption aes-256 group 2 hash sha
crypto ikev2 policy ikev2-default
isakmp-proposal default encryption aes-256 group 2 hash sha
crypto ipsec transform-set default esp-aes-256 esp-sha-hmac
crypto ikev1 remote-vpn
crypto ikev2 remote-vpn
crypto auto-ipsec-secure
crypto remote-vpn-client
interface radio1
channel 13
rate-selection opportunistic
placement outdoor
rts-threshold 1
wlan ShougangWiFi bss 2 primary
meshpoint ShougangMine bss 1
non-unicast tx-rate lowest-basic
antenna-mode 3x3
no dynamic-chain-selection
antenna-diversity
antenna-downtilt
interface radio2
channel 136
rate-selection opportunistic
placement outdoor
rts-threshold 1
meshpoint ShougangMine bss 1
antenna-mode 3x3
no dynamic-chain-selection
interface radio3
shutdown
placement outdoor
interface ge1
switchport mode trunk
switchport trunk native vlan 1
no switchport trunk native tagged
switchport trunk allowed vlan 1,40,50
use ip-access-list in BROADCAST-MULTICAST-CONTROL
ip arp trust
interface ge2
switchport mode access
switchport access vlan 40
use ip-access-list in BROADCAST-MULTICAST-CONTROL
ip arp trust
interface vlan1
ip address zeroconf
interface vlan40
ip address dhcp
ip dhcp client request options all
interface wwan1
interface pppoe1
use event-system-policy SNMP
use firewall-policy default
ntp server 10.10.1.6
no events on
logging forward critical
controller hello-interval 60 adjacency-hold-time 180
no cdp run
no lldp run
misconfiguration-recovery-time 0
critical-resource monitor interval 120
critical-resource CRM monitor direct all sync-adoptees 169.254.254.254 169.254.70.92 arp-only vlan 1 port ge1
critical-resource retry-count 5
service pm sys-restart
meshpoint-device ShougangMine
root
monitor critical-resource action no-root
monitor primary-port-link action no-root
path-method uniform
hysteresis period 60
exclude wired-peer mint-level-1
acs priority-meshpoint 5GHz ShougangMine
acs priority-meshpoint 2.4GHz ShougangMine

!
rf-domain ShougangMine
location Marcona
country-code ru
use smart-rf-policy SmartRF
channel-list dynamic
channel-list 5GHz 136
channel-list 2.4GHz 13
override-wlan CosapiWiFI ssid CosapiWiFi
controller-managed
!
rf-domain default
no country-code
!
ap7562 94-9B-2C-2A-BA-64
use profile AP7562-Root
use rf-domain ShougangMine
hostname VMM1-2ABA64
adoption-site ShougangMine
!
!
end

Yes, I have console access to AP's

Re: RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Mon, 26 Aug 2019 22:25:07 GMT

No, I made no changes, AP adopted and unadopted by itself.

Re: RFS4000 adopts AP7562 and unadopts it instantly

ckelly — Mon, 26 Aug 2019 22:33:56 GMT

Roman,

The issue appears to come from that you copied the full config from the existing root node.
The WMM non-root node will not be connected via the wired connection and thus the meshpoint-device configuration in the non-root AP's main Profile needs to be setup to indicate that.

Current, it looks like this:
meshpoint-device ShougangMine
root <--This is what needs to change on the *non-root* node APs
monitor critical-resource action no-root
monitor primary-port-link action no-root
path-method uniform
hysteresis period 60
exclude wired-peer mint-level-1
acs priority-meshpoint 5GHz ShougangMine
acs priority-meshpoint 2.4GHz ShougangMine

Change that entry to "no root". commit write. Then try again.
Mesh APs that are setup as root nodes only accept mesh connections from other non-root nodes. They don't form mesh connections with other root nodes.
So what's happening here is that the AP is acting as a root node and therefore won't form a mesh connection with your first root node AP.

Re: RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Tue, 27 Aug 2019 03:46:02 GMT

Chris,
thank you for your answer!
Im assign new profile with no-root settings In RFS and changing settings on AP - nothing happened, mint link still active, but no adoption yet. If AP fails to detect controller on its port, it became non-root?

Re: RFS4000 adopts AP7562 and unadopts it instantly

ckelly — Tue, 27 Aug 2019 04:02:29 GMT

Roman,

"If AP fails to detect controller on its port, it became non-root?"
There is a way to create a single AP Profile that will automatically switch a node from a root to non-root and vice-versa, but I'm trying to keep things simple here just to get the mesh connection to work.

Run these commands on both the root and non-root AP and paste the results: (Indicate which AP you are designating as the root node)

#show wireless meshpoint
#show wireless meshpoint config
#sh wireless meshpoint neighbor statistics rf

Re: RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Tue, 27 Aug 2019 23:59:04 GMT

Hello Chris!

Here is outputs of the commands:

Office - Root
Office-2ABA94#sh wireless meshpoint
NAME | ShougangMine @ 94-9B-2C-2A-BA-94 (Office-2ABA94)
MPID | 94-9B-2C-65-9E-81
ROOT | Yes
IFID 1 | 94-9B-2C-65-B1-40 on 94-9B-2C-2A-BA-94:R2
IFID 2 | 94-9B-2C-65-9E-81 on 94-9B-2C-2A-BA-94:R1

Total number of meshpoint displayed: 1
Office-2ABA94#sh wireless meshpoint config
--------------------------------------------------------------------------------
NAME ENABLE MESHID
--------------------------------------------------------------------------------
ShougangMine Y ShougangMine
--------------------------------------------------------------------------------
Office-2ABA94#sh wireless meshpoint neighbor statistics rf
----------------------------------------------------------------------------------------------------------------------------
Retry AVG : Average retransmissions per packet
ERRORS : Error Rate of rx errors and retries over good packet per second
Q-INDEX : RF Quality Index, higher value means better quality
(I) : RF matrix index where 0,1,2,3,4,5 maps to N/A,Poor,Fair,Average,Good,Excellent respectively
----------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------
AP-HOSTNAME RADIO-ID NEIGHBOR-IFID SIGNAL NOISE SNR TX-RATE RX-RATE RETRY ERRORS Q-INDEX
(dbm)(I) (dbm) db(I) (Mbps)(I) (Mbps)(I) AVG (pps) (I)
----------------------------------------------------------------------------------------------------------------------------
94-9B-2C-2A-BA-94 94-9B-2C-2A-BA-94:R1 94-9B-2C-65-8C-D1 -82 -91 9 48 65 0.49 0 2
----------------------------------------------------------------------------------------------------------------------------
Total number of neighbors displayed: 1

test2 (non-Root) instead of VMM, but the same config.
test2-2ABC84#sh wireless meshpoint
NAME | ShougangMine @ 94-9B-2C-2A-BC-84 (test2-2ABC84)
MPID | 94-9B-2C-65-8C-D1
ROOT | 94-9B-2C-65-9E-81 @ 1 hops with metric 329
ROOT BOUND TIME | 0 days 00:07:24 ago
NEXT HOP IFID | 94-9B-2C-65-9E-81
NEXT HOP USE TIME | 0 days 00:07:24 ago
IFID 1 | 94-9B-2C-65-8C-D1 on 94-9B-2C-2A-BC-84:R1
IFID 2 | 94-9B-2C-65-9F-80 on 94-9B-2C-2A-BC-84:R2

Total number of meshpoint displayed: 1
test2-2ABC84#sh wireless meshpoint config
--------------------------------------------------------------------------------
NAME ENABLE MESHID
--------------------------------------------------------------------------------
ShougangMine Y ShougangMine
--------------------------------------------------------------------------------
test2-2ABC84#sh wireless meshpoint neighbor statistics rf
----------------------------------------------------------------------------------------------------------------------------
Retry AVG : Average retransmissions per packet
ERRORS : Error Rate of rx errors and retries over good packet per second
Q-INDEX : RF Quality Index, higher value means better quality
(I) : RF matrix index where 0,1,2,3,4,5 maps to N/A,Poor,Fair,Average,Good,Excellent respectively
----------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------
AP-HOSTNAME RADIO-ID NEIGHBOR-IFID SIGNAL NOISE SNR TX-RATE RX-RATE RETRY ERRORS Q-INDEX
(dbm)(I) (dbm) db(I) (Mbps)(I) (Mbps)(I) AVG (pps) (I)
----------------------------------------------------------------------------------------------------------------------------
94-9B-2C-2A-BC-84 94-9B-2C-2A-BC-84:R1 94-9B-2C-65-9E-81 -80 -92 12 67 43 1.41 0 2
----------------------------------------------------------------------------------------------------------------------------
Total number of neighbors displayed: 1

Re: RFS4000 adopts AP7562 and unadopts it instantly

ckelly — Wed, 28 Aug 2019 00:36:01 GMT

Roman,

I forgot to mention one particular item originally. If this is in fact a VMM deployment, you want to configure the PATH method to "mobile-snr-leaf" (default value is "uniform". This alternate path setting adjust the characteristics of the mesh formations using different metrics and also prevents a non-root from going through another non-root.

mobile-snr-leaf

SnR based routing
Turns on mobility bit
Turns on leaf bit (leaf AP’s cannot hop through each other)
Uses SnR in auto channel selection

The change is here in the main AP Profile (Applies to any non-root APs)

meshpoint-device ShougangMine
no root
monitor critical-resource action no-root
monitor primary-port-link action no-root
path-method uniform <-- Change this to "mobile-snr-leaf"
hysteresis period 60
exclude wired-peer mint-level-1
acs priority-meshpoint 5GHz ShougangMine
acs priority-meshpoint 2.4GHz ShougangMine

Now regarding the results:
The radios are seeing each other. The SNR is a little weak, but they should still be able to form a link.
I think the problem has to do with an unsupported mode on these .11ac model APs. Was supported on previous generation .11n APs.

Change this setting on each radio...on all APs.

interface radio1
channel 13
rate-selection opportunistic <-- Change to "standard"

interface radio2
channel 136
rate-selection opportunistic <-- Change to "standard"

#commit write

Even if this still doesn't resolve the issue, these changes needed to be made anyway.

Re: RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Wed, 28 Aug 2019 20:05:01 GMT

Thank you Chris!
All changes implemented! Waiting for further instructions!

Re: RFS4000 adopts AP7562 and unadopts it instantly

ckelly — Wed, 28 Aug 2019 20:28:00 GMT

At this point, I would hope that the mesh connection has formed between the non-root and root nodes.

#show wireless meshpoint statistics

Re: RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Wed, 28 Aug 2019 21:40:25 GMT

test2-2ABC84#show wireless meshpoint statistics
--------------------------------------------------------------------------------
MESHPOINT TX RX TX RX TX RX
bytes bytes pkts pkts kbps kbps
--------------------------------------------------------------------------------
ShougangMine 264 395716 3 55019 0 k 0 k
--------------------------------------------------------------------------------
Total number of meshpoint displayed: 1

Re: RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Wed, 28 Aug 2019 21:46:15 GMT

test2-2ABC84#sh wireless meshpoint neighbor statistics rf
----------------------------------------------------------------------------------------------------------------------------
Retry AVG : Average retransmissions per packet
ERRORS : Error Rate of rx errors and retries over good packet per second
Q-INDEX : RF Quality Index, higher value means better quality
(I) : RF matrix index where 0,1,2,3,4,5 maps to N/A,Poor,Fair,Average,Good,Excellent respectively
----------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------
AP-HOSTNAME RADIO-ID NEIGHBOR-IFID SIGNAL NOISE SNR TX-RATE RX-RATE RETRY ERRORS Q-INDEX
(dbm)(I) (dbm) db(I) (Mbps)(I) (Mbps)(I) AVG (pps) (I)
----------------------------------------------------------------------------------------------------------------------------
94-9B-2C-2A-BC-84 94-9B-2C-2A-BC-84:R1 94-9B-2C-65-9E-81 -79 -92 13 10 7 0.00 0 2
----------------------------------------------------------------------------------------------------------------------------
Total number of neighbors displayed: 1

Office-2ABA94#sh wireless meshpoint neighbor statistics rf
----------------------------------------------------------------------------------------------------------------------------
Retry AVG : Average retransmissions per packet
ERRORS : Error Rate of rx errors and retries over good packet per second
Q-INDEX : RF Quality Index, higher value means better quality
(I) : RF matrix index where 0,1,2,3,4,5 maps to N/A,Poor,Fair,Average,Good,Excellent respectively
----------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------
AP-HOSTNAME RADIO-ID NEIGHBOR-IFID SIGNAL NOISE SNR TX-RATE RX-RATE RETRY ERRORS Q-INDEX
(dbm)(I) (dbm) db(I) (Mbps)(I) (Mbps)(I) AVG (pps) (I)
----------------------------------------------------------------------------------------------------------------------------
94-9B-2C-2A-BA-94 94-9B-2C-2A-BA-94:R1 94-9B-2C-65-8C-D1 -75 -92 17 44 61 0.13 0 2
----------------------------------------------------------------------------------------------------------------------------
Total number of neighbors displayed: 1

Re: RFS4000 adopts AP7562 and unadopts it instantly

ckelly — Wed, 28 Aug 2019 21:56:27 GMT

Are either of the APs getting adopted to the controller?
If yes, then it would seem that the controller is pushing out its version of the AP's configuration once adopted....and that controller's config is not correct...and then breaks the mesh.

When you updated the configs on the APs, have you been doing this by logging into the APs directly? Or have you been modifying the configs on the controller? I suspect you have been updating the configs directly on the APs.

Based on the below output, the mesh connection is forming. But then is being 'broken' after adoption. So there's something wrong with the AP profiles that are being pushed out from the controller.

test2-2ABC84#show wireless meshpoint statistics
--------------------------------------------------------------------------------
MESHPOINT TX RX TX RX TX RX
bytes bytes pkts pkts kbps kbps
--------------------------------------------------------------------------------
ShougangMine 264 395716 3 55019 0 k 0 k
--------------------------------------------------------------------------------
Total number of meshpoint displayed: 1

If you still have a copy of the config on the root and non-root APs when it worked, keep that. Now, copy the config directly from each AP (log onto each AP) as it exist right NOW (broken) and compare it to the config that worked. Look for any differences. When you find them, that will show you what you need to change on the controller for those AP's setup.

Re: RFS4000 adopts AP7562 and unadopts it instantly

Roman_Yusupov — Fri, 30 Aug 2019 22:18:23 GMT

Hello Chris!
Thank you for your assistanse!

I checked and aligned all the configurations and it helped! Both Root and nonRoot profiles now working properly.
It was all about my carelessness(

Re: RFS4000 adopts AP7562 and unadopts it instantly

ckelly — Fri, 30 Aug 2019 22:23:20 GMT

Glad to hear, Roman!
Takes a little getting used to, but you're doing well.