Wireless Access

Hello,

We are testing a mesh before deployment. At the moment it drops out every few mins. We had the same problem with a mesh we previously set up and in the end, after getting advice from AirHeads, we disabled VHT & set ARM to 'maintain' which stabilised things. 

The g-radio is disabled on both Portal and Point.

When setting up the new mesh I cloned the existing groups from our first mesh, but it seems as if some of the settings haven't taken hold. When the mesh is up this is the output of 'show ap mesh top':

Name Mesh Role Parent Path Cost Node Cost Link Cost Hop Count RSSI Rate Tx/Rx Last Update Uplink Age #Children
---- --------- ------ --------- --------- --------- --------- ---- ---------- ----------- ---------- ---------
f0:5c:19:c3:32:1c Portal (N) - 0 1 0 0 0 - 54s 48m:54s 1
f0:5c:19:c3:32:2a Point (N) f0:5c:19:c3:32:1c 4 0 3 1 53 6/450 10s 53s 0

and this is the output of 'show ap mesh neighbors ap-name f0:5c:19:c3:32:1c':

MAC Portal Channel Age Hops Cost Relation Flags RSSI Rate Tx/Rx A-Req A-Resp A-Fail HT-Details Cluster ID
--- ------ ------- --- ---- ---- ----------------- ----- ---- ---------- ----- ------ ------ ---------- ----------
f0:5c:19:b3:22:b0 f0:5c:19:b3:21:d1 128- 20 1 4.00 C 1m:12s VLK 50 450/450 1 1 0 VHT-40MHzsgi-3ss gravel-hill
f0:5c:19:b3:22:b1 f0:5c:19:b3:21:d1 128- 20 1 4.00 N 1m:5s HLK 51 - 0 0 0 HT-40MHzsgi-3ss gravel-hill

As you can see VHT is still listed under HT-Details. Also what are the two entries here, obviously one is the MAC of the portal, I'm assuming the two listed under MAC are the Point, but why are there 2?

The mesh currently only stays up for a short time (a few minutes), it's possible we also have the APs rather close together which may not be helping, currently 4 metres or so (is there a minimum distance you recommend?). 

I've attached the config of the mesh groups and radio groups, let me know if you need any others.

Thanks in advance

Attachment(s)

gravel-mesh-groups_output.txt   9 KB 1 version

Those radios are high powered and are too close together.  If you are testing, try to put them into a different room if possible.

To find out why they drop out, type "show log wireless all" to see if you can get a clue.  Mesh radios don't scan, so they don't necessarily change channels often or at all.

I cannot really see anything wrong with your configuration and the defaults should work just fine.  Enabling or disabling VHT would not really have a material affect on dropouts.  It is possible that distortion at that close distance has a greater effect on dropouts.

Thanks Colin,

I moved it further away, which also meant I used a power brick on the Point AP instead of the switch to provide power, this seems to be stable (well, for the short time I've had it running). Then I switched to using the switch (an HP 2920 that does do PoE+) and the instability returned - the AP boots then reboots due to 'change in power', it just keeps doing that. I set it to use poe by value rather than usage and it is stable again. So could this be LLDP issues?

Guy

"by Value" seems to avoid the LLDP issue.  There are a number of people who have deployed both ways and have made it work and I will let them weigh in...

Is the switch your point is plugged in to connected to the same L2 network as the portal? On your HP switch, it will help to set by value to 33 just for testing and then you can play around with the port settings. Also make sure your HP switch is running 16.01 or later (earlier version had some LLDP negotiation issues that seem to have been resolved in 16). But setting by value will force max power.

Thanks Jerrod,

The switch the point AP is connected to is not on the network (well, it is once the mesh is up!). This seems to work fine with the PoE adjustments so we are deploying it. The real deployment uses more modern Cisco switches so hopefully this will resolve any issues and need for bodging.