Wireless Access

Running 6.4.3.5

Controller and locals

Hi,

We've been having some fun with a point to point mesh (AP-274s) we set up recently, we've had a few issues making it run reliably:

Firstly client APs on the point side of the mesh were unable to DHCP, this was fixed by upgrading to 6.4.3.5.

Since then the mesh had been going up and down every few hours. We disabled Very High Throughput in the dot11a radio profile (g radio is disabled) and this seemed to have fixed it. But strangely we noticed that this setting had reverted to 'Enabled' and the mesh had become unstable again (after about 2 weeks of running fine). Under what circumstances could this happen?

Could someone also explain the output of 'show ap mesh neighbors <ap-name>'? Output from our mesh portal:

MAC                Portal             Channel  Age  Hops  Cost  Relation                 Flags  RSSI  Rate Tx/Rx  A-Req  A-Resp  A-Fail  HT-Details        Cluster ID
---                ------             -------  ---  ----  ----  -----------------        -----  ----  ----------  -----  ------  ------  ----------        ----------
ac:a3:1e:80:a1:30  ac:a3:1e:80:9f:51  132+     0    1     6.00  C 2m:30s                 VLK    51    400/270     5      5       0       VHT-40MHzsgi-3ss  cs-guild
ac:a3:1e:80:a1:31  ac:a3:1e:80:9f:51  132+     0    1     7.00  N 1h:2m:44s              HLK    51    -           0      0       0       HT-40MHzsgi-3ss   cs-guild

and the point:

MAC                Portal  Channel  Age  Hops  Cost  Relation                 Flags  RSSI  Rate Tx/Rx  A-Req  A-Resp  A-Fail  HT-Details       Cluster ID
---                ------  -------  ---  ----  ----  -----------------        -----  ----  ----------  -----  ------  ------  ----------       ----------
ac:a3:1e:80:9f:51  Yes     132+     0    0     4.00  P 5m:49s                 HLK    48    405/400     5      5       0       HT-40MHzsgi-3ss  cs-guild

The portal MAC ac:a3:1e:80:a1:30 appears in output such as 'show ap details wired-mac...' as one of the APs' radio MACs, but ac:a3:1e:80:a1:31 does not. So what is this MAC address? Similarly ac:a3:1e:80:9f:51 is not one of the radios for the point AP (but ac:a3:1e:80:9f:50 is).

Also what is the difference between (N)eighbor and (C)hild in this output?

Lastly (and apologies for the vagueness of the question) what kinds of things could mean VHT would make the mesh link unstable? For instance I did notice in ourARM profile 80MHz support is disabled (and was disabled even when the radio profile had VHT enabled), could this have been any effect?

Thanks for your help.

The portal has a 'recovery mesh profile' so chances are those are the two MACs you see in the portal's show neighbors command (each MSSID is seeing the point, etc). The recovery profile is very basic and so may not have VHT or other high throughput features enabled.

You do want to make sure that if VHT is enabled if you are running HT80. You may want to open a TAC case to let them see your before/after and any logs of the mesh point crashing but in general, you want the mesh config and radio configs to match.No idea WHY that would make it actually drop the link though, TAC would have to investigate.

---

@jhoward wrote:

The portal has a 'recovery mesh profile' so chances are those are the two MACs you see in the portal's show neighbors command (each MSSID is seeing the point, etc). The recovery profile is very basic and so may not have VHT or other high throughput features enabled.

 

You do want to make sure that if VHT is enabled if you are running HT80. You may want to open a TAC case to let them see your before/after and any logs of the mesh point crashing but in general, you want the mesh config and radio configs to match.No idea WHY that would make it actually drop the link though, TAC would have to investigate.

---

Thanks Jerrod,

We do have a case open so hopefully we'll resolve this. It is odd that the mesh ran fine for 2 weeks and then started dropping again. 

It now seems as if it may not be VHT causing the problem (though I guess it could have been contributing), on Friday I disabled ARM (well, actually I set it to 'maintain'), and disabled 'reselection', this seems to have had a positive effect... but...

It ran over the weekend fine, all looked good. However  this morning the Uplink Age for the Point AP (shown in 'show ap mesh topology') was back down to 5 mins - usually this seems to indicate that the mesh link has been recently lost and subsequently recovered, however in this case Airwave reported the mesh as being up for 3 days (and currently being up), also the switch which is downstream of the mesh usually reports ports with the Point and downstream client APs going Down and then Up again as the mesh reestabilshes... but these events were not in the logs. Obviously I take that as a good sign, but it does lead me to question what Uplink Age actually indicates if it isn't an indication of how long the mesh has been up. Any ideas?

Thank you

Is your mesh on the exact same channel (you mentioned you disabled ARM and all that). I notice in the above your mesh is in the DFS channels, you could have had a Radar event. You can look and see if maybe the 5Ghz radio reset due to a radar event, or maybe some other reason (maybe the portal changed channels and ARM wasn't really disabled, etc). 

'Show ap ARM history' against the portal should give you some output to look at. 

Sorry for the late response - yes I wonder if somehow they weren't synchronised and this event was them matching channels. The link has been completely stable since we set it to maintain-arm and disabled VHT so we're letting sleeping dogs lie for now!

Sounds like ARM was flipping channels, there's no logic to prevent mesh from flapping when the 5Ghz radios are used for Mesh. so in general it's a good practice to use a static 5Ghz channel on radios doing Mesh.

Ok thanks - we know for the next one!