Hi, as the official Mikrotik Support is not answering since 1.5 Month (maybe to many tickets or similar), I will poste my current issue here.
Problem Summary
I'm experiencing drastic internet latency spikes (>10,000 ms ping) over my LHG LTE 18 connection when a specific company-managed Windows 11 notebook (with OneDrive) connects to the UniFi UCG MAX. This affects all devices behind the UCG MAX and Winbox access to the Mikrotik. Only rebooting the Mikrotik resolves it—UCG MAX reboot does not. Another Windows 11 notebook with OneDrive (private, not company managed), can reproduce it partially (latecy to 1000ms) with random opening pictures.
Setup Details
Router: UniFi UCG MAX (Firmware 4.4.9 tested and 5.0.12 latest; LAN: 10.0.162), using eth0/WAN port
LTE Modem: Mikrotik LHG LTE 18 (latest RouterOS 7.20.2 tested, 7.20.6 tested and now 7.21.2 + LTE firmware on latest)
Firewall of Mikrotik LHG LTE 18 are default
Normal Mode (Passthrough): LHG LTE 18 → DHCP WAN IP VLAN9 → UCG MAX (internet works fine)
Troubleshooting Mode (No VLAN): LHG LTE 18 → DHCP private IP → UCG MAX (internet works fine)
Access: Notebook with Winbox via UCG MAX to Mikrotik management
Issue reproducible in both modes.
Symptoms
High latency only between UCG MAX and Internet/Mikrotik when notebook is connected (no higher latency within the LAN network of UCG MAX):
Ping Test
Min RTT
Avg RTT
Max RTT
Packet Loss
Mikrotik → 1.1.1.1
18 ms
28 ms
257 ms
0%
UCG MAX → 1.1.1.1
78 ms
1743 ms
7273 ms
0.5%
Ping UCG → Mikrotik: also high
Ping Mikrotik → Internet (e.g., 1.1.1.1 or 9.9.9.9) remains normal
Impacts: Internet interruptions for all UCG devices; Winbox lag
Persistence: Latency stays high even after disconnecting notebook; UCG reboot insufficient—Mikrotik reboot required
Notebook works fine in other networks (Fritz!Box home, company LAN, hotel WiFi).
OneDrive Reproduction
Affected: 2x Win11 notebooks with OneDrive (spikes even without full sync—just opening pictures triggers downloads/metadata fetch)
Not Affected: 1x Win11 notebook without OneDrive
Trigger: Minimal OneDrive activity (e.g., view images); no drops, just latency surge. Drops starts with more OneDrive/Sharepoint Sync (e.g. company managed device)
Reproduced in no-passthrough mode with direct Mikrotik pings.
Troubleshooting Attempts
UCG firmware downgrade to 7.20.2 → No change; upgraded back to latest stable + LTE firmware
Temporarily disabled UCG firewall → No effect
Temporarily disabled Mikrotik Firewall (as far as I can) → No effect
WireGuard VPN (UCG MAX → remote site):
Route entire notebook or just OneDrive traffic via VPN → No latency issues
(VPN slows internet but confirmed OneDrive as trigger—not a solution)
Logs exists from version 7.20.6 with latency and without. For me difficult to compare.
Suspected Cause
OneDrive traffic (TLS connections to Microsoft servers) seems to overload Mikrotik LHG LTE 18. Cleared only by Mikrotik reboot. No issues in non-Mikrotik setups.
I would try putting some QOS on the lte interface.
Run a speed test with everything else on the network disconnected and record the upload speed.
(You may already have this information)
Make a cake queue type and then attach a cake queue to the lte interface using this speed value.
/queue type
add cake-nat=yes kind=cake name=qcakenat
/queue tree
add bucket-size=0.01 max-limit=UPLOAD_SPEED name=qlte1 packet-mark=no-mark parent=lte1
queue=qcakenat
You will very likely need to tweak the max_limit value and see what value gives you best results.
If you have a complex firewall and are marking packets, you may need to put all your packet marks into the above queue tree entry.
This is not OneDrive itself but LTE queue and buffer exhaustion on the LHG LTE 18. OneDrive opens many parallel TLS flows which fills LTE buffers, causing massive latency for all forwarded traffic while the modem itself still pings fine. That is why only rebooting or resetting the LTE interface clears it.
Practical fix is to reset just the LTE interface when it happens and add proper traffic shaping on the Mikrotik. Set simple queues or CAKE/FQ-CoDel on the LTE interface to cap upload and download slightly below line rate. This prevents bufferbloat and stops the latency spikes without touching OneDrive or the UCG.
Yep, but the suggestion was to try if ONLY resetting the LTE interface (as opposed to rebooting the device) is enough to get (temporarily) normal functioning.
Then you need to try implementing a queue, as rplant decribed, the issue is that you need to make experiments to find a suitable value for "UPLOAD_SPEED", which depends on the actual LTE connection and how it behaves, but also the bucket size might need to be adjusted.
Probably (IF the LTE reset actually works) it would be a good idea to add a script in netwatch, triggered by the ICMP probe (and finding the right thresholds for that is another PITA) that resets the interface if - notwithstanding the queue - the device starts being unresponsive, at least for the time you are tweaking/tuning the queue values.
For Resetting LTE interface access to Mikrotik is needed or not? - this was not possible as mentioned (tried over 15 minutes to connect to Mikrotik device).
Independently of the queue. I’m as well wondering why this is needed anyhow. The same device (notebook) is working fine in all other connections (Wifi at home, Hotel, Tethering Hotspot at the same location, …), except the current setup.
It was as well working fine, where the LHG LTE device was the “router” (no UCG Device in the network).
I’m not sure how MSS Clamping or MTU size might be an issue as well?
Yep, the idea is having a script to reset the lte interface like:
Triggered by netwatch.
If when the issue arises pings fail, it can be triggered by a "simple" netwatch probe, if ping works but have latency/delays, etc. you will need to use the more complex "ICMP" probe.
OR, if it takes an approximately constant given time (let's say 10 minutes) to reach the "overload" condition once the laptop with onedrive is connected, you could put it in a scheduler task to run every 9 minutes or so.
Just another update:
Did some Speedtests from the UCG MAX Device:
Date & Time: 11th of Feb. 2026 15:14 / 03:14pm
Smart Queues are for Speed-Test disabled (enabled after speed test):
Download: 47.0 Mbps
Upload: 33.0 Mbps
Date & Time: 12th of Feb. 2026 08:38 / 08:38am
Smart Queues are for Speed-Test disabled (enabled after speed test):
Download: 72.0 Mbps
Upload: 42.0 Mbps
Netwatch: name="ping 9.9.9.9" host=9.9.9.9 type=simple interval=20s timeout=1s up-script=:log warning "Netwatch: LTE back up for 9.9.9.9"\r\n down-script=:log warning "Netwatch: LTE down detected"\r\n/interface lte disable lte1\r\n:delay 10s\r\n/interface lte enable lte1 test-script="" http-codes="" status=up
Tested with the latency causing Notebook:
Ping was fine and timeout, without higher latency, few ms later, high latency and outages continued, even after the causing Notebook was switchen off.
As the Mikrotik is running in Passthrough, I changed it to try to Access, but was not possible (even no reaction to ping (UCG MAX -> Mikrotik LHG LTE). No Access -> reboot.
The Netwatch was not working (or at least I haven't seen it)
bucket size = size of data that it can potentially drop onto outbound interface.
(next device along needs to have enough buffering to handle this)
0.01 * 35M = 350k bits
Smaller means more blocks of smaller size, (smoother, but more cpu)
I am wondering if the queue is functional in passthrough mode?
In winbox (or webfig), you can look at the queues and see how much traffic is going through them in real time. And you can heavily throttle it to like 5M and see if it is actually working.
And compare the traffic going through the queue vs traffic leaving the lte interface.
On looking at how passthrough works, it seems likely that in passthrough mode any QOS needs to be on the UCG.
There might be some way to get QOS to work on the LHG in passthrough mode, but it would take some trial and error (and a fair bit of luck).
There may be another mechanism used, but it seems likely there would be a bridge between the lte interface and the ether1 vlan. If so, it is likely hardware offloaded. If this is the case, you could perhaps disable the bridge hardware offload on the lte interface.
Example Partial printout from /interface/bridge/port/print (not a lhg18)
# INTERFACE BRIDGE HW HORIZON TR FA PA IN BP EDGE POIN PVID
0 ether2 bridge yes none no no 10 10 no auto auto 1
1 ether3 bridge yes none no no 10 10 no auto auto 1
In this case to turn off hw offload on ether2
/interface/bridge/port
set [find where interface=ether2] hw=no
Thanks a lot for the hint that the QoS might not work:
I can confirm, it Looks like the Queue (name="lte-qcake", parent=lte1) is not working in passthrough.
I changed from Passthrough to DHCP (WAN of UCG MAX is getting now a DHCP IP of LGH LTE, instead of CGNAT of the Provider - one NAT more), but I'm able to Access the LHG at the same time as Internet is working.
With Passthrough, the Packets or Bytes value is not increasing - in DHCP it is.
Changed as well Queue Type: "name="qcake-lte", kind=cake" NAT to enabled.
Regarding "Bridge", as far as I can see, there is no Bridge:
NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R ether1 ether 1500 1600 9676 78:9A:18:FB:86:59
1 R Passthrough-VLAN9 vlan 1380 1596 78:9A:18:FB:86:59
2 R lo loopback 65536 00:00:00:00:00:00
3 R lte1 lte 1500
Tested again:
only differences to the Tests before:
Passthrough changed to DHCP (WAN IP is not from LHG LTE via DHCP) -> Queue is now counting packets etc.
Will test tomorrow again.
Why: I found out, that the really high latency with outages and crash of LHG only exists, if the "Company managed Notebook" was a while offline (e.g. 12hours). Like Policy updates or similar of the Company after a while (M365, AD, OneDrive, ...).
Unkown what kind of Impacts the DHCP IP to the WAN Interface of UCG MAX might have over time (double NAT).
—
Unifi Ticket is open as well (incl. pcap file of WAN interface).