How to block gratuitous arp from open-mesh APs

[scrapiron]

Client is small hotel with 40 rooms. Since the building is a 5 story solid concrete (literally all walls and floors are 6" thick) building, they have a Open-Mesh AP in each room. They were having problems and hired me help improve things so I tossed the crappy unmanaged switches and installed 4 MS-120 24P switches and MX65. 

Within an hour, the dashboard showed over 10k mac addresses on the network mostly due to the APs sending constant gratuitous arps which enable the APs to "mesh". I have disabled the mesh feature in cloud-trax (their cloud manger) but they still continue to do it and Open-Mesh said it can't be shut off and to control it from the switches.

Anybody know how I could prevent these from hitting the MX? I was thinking about creating a MAC whitelist for each port containing the address of the AP it powers. The APs are doing NAT for wireless/wired guests but bridging to operations VLAN for staff, IoT devices and corp traffic on the second SSID. 

I've already pitched replacing them with 45 MR-30H's which didn't go over very well.  🙂

thanks. 

[PhilipDAth]

If you had the next model switch up (MS210 or better), I would suggest you enable broadcast storm control ...

https://documentation.meraki.com/MS/Other_Topics/Storm_Control_for_MS

How many of these MESH AP's are wired?  Can the AP's be broken up into more VLANs?  Such as a VLAN per floor? You would need to handle this on the MX65.

[scrapiron]

There are 45 APs total and all are wired into ms-120 switches. I have disabled the mesh feature on cloud-trax as we don't use it but the gratuitous arps keep coming. Creating VLANS is no problem but the MX will still list the arps as separate clients in the dashboard. I don't think the traffic they produce is a problem and wouldn't really consider it to be a storm although I could be wrong. It just fills up the arp table and skews the reporting. It also makes viewing the dashboard clients incredibly slow as it builds the list of 50K clients to display. 

It's not too late to send the 120s back and upgrade if you think it would help. I'm just really trying to stop the arps at the switch port from making it to the MX. 

Open-Mesh said it was a problem with Meraki as they should be able to ignore gratuitous arps. 

[PhilipDAth]

I can't say that the MS210's would help - but if you had the option to upgrade to them - I would.  For what you are doing they add worthwhile extra features, like broadcast storm control.

Dynamic Arp Inspection is another interesting feature.  This wont help this specific issue - but can be usefull to try and stop one guest stealing another guests data (and yes - we have been involved in helping accomodation providers - more than once - where there has been a theft of information from one guest by another guest).

https://documentation.meraki.com/MS/Other_Topics/Dynamic_ARP_Inspection

[scrapiron]

I opened a case with Meraki and they provided a detailed response with some suggestions about using ACLs on the switch to try to block but in the end said there wasn't much I could do as it would have profound effects on wireless clients. 

Open-Mesh suggested turning off Mesh since I am not using it (which I had done) and they also were kind enough to disable the bluetooth presence reporting on the back end which really hasn't made much difference. I eliminated the second SSID which cut it in half.

But the best thing to do is restrict the view to restrict the network clients to just  "Security appliance clients only" which removes them and returns the view refresh back to normal snappiness. It was then I realized these Arps are not making it to the MX; just the switches. 

Woo Hoo!!