Wireless Access

I am setting up a lab to test AOS outdoor Mesh before a live deployment and have a couple questions. 

The Lab consists of two Mesh Portals and two Mesh points. One child/Point connects to each portal via single hop and very low path cost (1).  

I setup redundant Mesh Portals in the same cluster for redundancy. To test, I powered down one of the Portals and after a couple minutes the previosly associated Child node created a link to another node to reach the other redundant portal. Great! After powering the original Portal back up, the 5 Ghz radio chose a different channel. The original Child node never moved back to its original parent/portal and continues to use a much higher cost path (13). I understand that this is by design and that it will only discover (or re-discover) the Portal if it is on the same Backhaul channel. So my questions...

- Should I set ALL Backhaul channels to the same 5 Ghz Channels so they can discover and choose the best path in case of an outage like the simulated in the lab?

- Should I not allow Client connections on the Backhaul links (disable the radio)?

- Should I configure ARM to only allow Max power on the Backhaul radios (I read this recomendation in another post)? These are using external omni.. i would hate to cause increased co-channel, seems ARM Power would be prefered here. 

I do plan to disable all DFS in the Regulatory Domain. 

Thanks!

You will need to have the portals on different channels for best operation. Ideally, each portal is in it's own group, and you configure the two mesh clusters to prioritize accordingly (see below). 

As for your questions, the default configuration is that the point will not come back until it's manually rebooted, or the point is blocked/dropped to force it to re-scan (that's the default for most all mesh configs regardless of vendor). You can configure it to 'reselect anytime', but be aware that this requires that the mesh point occasionally scan and will take approx 5min (scanning interval is 4-5 min). When it goes off to scan, it will disrupt the backhaul, so it's usually not done. Failover should be rare so it's usually not an issue.

1. Backhaul channels should be separate.

2. Best practice is to disable any ESSID on backhaul radios, yes.

3. Your backhaul radio TX power should be high enough such that the mesh links are in the 30-40 RSSI range, if they are over 40, back off the power. If it's under 30 and you can get more TX power out, raise it up.

######

Multi-Cluster AOS Mesh[edit]

• In this use case, for mesh redundancy there will be two portals and points, each portal/point pair are in their own cluster.
• Also created in each mesh cluster, as part of the cluster priority, that the other cluster is configured as a failover (or Priority2) of the other cluster.
• If Portal-1 goes down, because the 'Redundant-Mesh-1' cluster has 'Redundant-Mesh-2' as a secondary cluster to fail to, Point 1 will fail over to Portal 2.

ap wired-ap-profile "redundant-mesh-1"
   wired-ap-enable
   trusted
   forward-mode bridge
   switchport mode trunk
   switchport trunk native vlan 201
   switchport trunk allowed vlan 202-203
!
ap wired-ap-profile "redundant-mesh-2"
   wired-ap-enable
   trusted
   forward-mode bridge
   switchport mode trunk
   switchport trunk native vlan 201
   switchport trunk allowed vlan 202-203
!
ap mesh-cluster-profile "redundant-mesh-1"
   cluster "redundant-mesh-1"
   opmode wpa2-psk-aes
   wpa-passphrase <WPA2-Mesh-Passphrase>
!
ap mesh-cluster-profile "redundant-mesh-2"
   cluster "redundant-mesh-2"
   opmode wpa2-psk-aes
   wpa-passphrase <WPA2-Mesh-Passphrase>
!
ap wired-port-profile "redundant-mesh-1"
   wired-ap-profile "redundant-mesh-1"
!
ap wired-port-profile "redundant-mesh-2"
   wired-ap-profile "redundant-mesh-2"
!
rf arm-profile "arm-disable"
   assignment disable
!
rf dot11a-radio-profile "ch157"
   channel 157
   tx-power 3
   arm-profile "arm-disable"
!
rf dot11a-radio-profile "ch161"
   channel 161
   tx-power 3
   arm-profile "arm-disable"
!
ap-group "redundant-mesh-1"
   dot11a-radio-profile "ch157"
   enet0-port-profile "redundant-mesh-1"
   mesh-cluster-profile "redundant-mesh-1" priority 1
   mesh-cluster-profile "redundant-mesh-2" priority 2
!
ap-group "redundant-mesh-2"
   dot11a-radio-profile "ch161"
   enet0-port-profile "redundant-mesh-2"
   mesh-cluster-profile "redundant-mesh-2" priority 1
   mesh-cluster-profile "redundant-mesh-1" priority 2
! 

Jerod,

Thank you very much for the answers, they all make sense.

Phil