Reaching out here as I'm at a loss to explain. Not sure if this is a Mikrotik or UBNT issue... Also cross-posted in Mikrotik forum.

Setup:

High-site has a UBNT radio (rocket AC also tested with ISO Station now) Connected to a Mikrotik Router (MPLS / VPLS) There are multiple UBNT radios connected to the Mikrotik Router. This site is remote and not easily accessible.

Have multiple clients per radio +/- 15 each.

Clients also have UBNT radio (M5 Powerbeam) connected to a Mikrotik Router.

Issue: Without any warning the high-site Radio becomes unresponsive. (no ping / no response) The UNBT radio reboots (ping watchdog checking local IP on Mikrotik). Highsite Radio restores.This looked like hardware issue. As clients connect when one specific client re-connects the same re-occurs and all clients lose connectivity.

Troubleshooting so far.

It seemed to be a failed High-site radio. After replacing the radio the same occurred. Also replaced the POE, verified power input and swapped the Mikrotik router. Same issue.

On the Mikrotik router, the port stays up but isn't running, which makes it appear to be a failed LAN on the radio. Plugged the high-site radio directly into a laptop and we maintained connection to the High-site radio and clients. All stable.

We then we moved clients one-by-one to another high-site UBNT radio until the issue occurred on the other radio, identifying a specific client connection causing the issue.

We isolated the client on a radio and sequentially started all equipment, radio = all good, Mikrotik, all good. Internal clients one by one until one user's device which caused the high-site radio to stop responding. We did a number of re-runs with the same result every time the specific user reconnected to their internal network.

There is nothing showing up on the high-site Mikrotik router logs and the IsoStation reboots from watchdog timeout and nothing else in the logs.

Any ideas identifying the cause will be greatly appreciated. Is there perhaps any logging we can activate that will assist in identifying he reason?

Is spanning tree protocol enabled on the Mikrotik? Could it be that the client sends an STP BPDU making Mikrotik stop forwarding on that port? Or that it sends back a frame with Mikrotik's own MAC address? Sniffing on that port (with hw=no) into a file, ideally when only that client is connected, while arp-pinging a non-existing IP address over that port should show you which frame from the client causes the broadcast ARP packets not to be sent out any more.

You could as well try setting the port as Edge port so that it will not send any BPDUs and ignore the received ones...