If you think the title sounds like a complaint post, then you’re probably right, this probably is just that, but I also think it sparks some discussion.
More creators, including Tom himself (for his home network only) have been moving over to Unifi for their networks, sometimes just for the home network and lab network other times for production setups. I’m seeing more MSPs use them, etc…
As someone who likes Unifi and likes the single pane of glass, I keep trying to go back, but each time I do it I deeply regret it. More often than not this regret is nearly instant, other times it takes like 2-3 weeks.
I have a Netgate 6100 and a UDMP and an 8 gigabit WAN, so as you can imagine, I often want to use the UDMP just because of it’s superior WAN routing performance. I’ve made the migration between the two (after lots of hours getting firewall rules etc… identical) and each time I’ve done it I’ve encountered a few issues:
3/5 Times my upload speeds tank to nearly useless with no actual information in the logs from Unifi to tell me what’s going on. I’m talking a full 8 gigabit download and upload speeds will be stuck at 20-80Mbps. This will never recover on it’s own and the only solution 2 of the 3 times (the 3rd just happened and I gave up) was to do a backup of the config, and then a full factory reset and restore. IMHO this proves it’s a bug and not a configuration issue since the config restored is 100% identical
I also experience packet loss each time I do this, 5/5 times I’ve made the swap. Sometimes it’s very severe, other times it’s fairly minor, and other times it’s only when the UDMP is under a heavy sustained load. Today I was losing about 1 ICMP response (so 4 packets) every 30 seconds or so to a public IP address and about 1 ICMP response every 1-2 minutes pinging the UDMP itself (meaning this isn’t just a WAN issue)
It’s things like this that make me regret it every time, I want to like Unifi, it’s a nice platform, it looks good, etc… But the stability just still isn’t there.
Worth noting, I reached out to support about 1 of the 3 times my upload speeds were bad and they could not figure out a resolution after quite a bit of back and forth.
Diagnosing these issues is exceedingly hard since Unifi gear lacks real deep logging and their packet capture system is basically a joke and I’d hardly even say ticks the box.
Has anyone else felt this way after doing said migration? I’m also completely confident it’s not some switch issue or something like that since I always restore the UDMP from a UCKG2 backup so device adoption goes smoothly.
I know there has been another complaint from 2guysTek talking about similar performance issues, but he was testing the UDMP and EFG. I think Rich hit the nail on the head that the kernel is the bottleneck and you’ll never hit the numbers you are looking for. So you are CPU bound to your performance and its possible the 6100 has a better chip AND/OR has hardware offloading on the NIC’s.
I moved away from PFsense about 3 months to vyos and I’m not looking back.
Some of the issues I’m seeing are likely related to everything you mentioned here.
But the upload speed issue is absolutely a bug of some kind, it’s not just performance related. I want to be very clear here, on my 8 gigabit fiber link, I was seeing a maximum of 80 megabits per second, not 800 and not megabytes per seconds. It was usually more like 40 megabits.
This same exact issue has occured 3 times, and 2 of those times I did a factory reset and restore and the issue went away completely. It’s not a CPU bound thing though, the performance is too abysmal and the issue clears itself upon the factory reset and never comes back until I do another restore. (I’ve flopped back and forth many times).
The packet loss issues very well could be performance related though, I wouldn’t be surprised.
As for VyOS, how are you liking it? I’ve got it spun up in my lab but haven’t done that much with it yet, seems a lot of people really like it though. Also going to reach out to Netgate about a TNSR license for my 6100, if they’ll do it cheap enough I might go for that just to get the better speeds while still being on something more stable.
I’m guessing that since you said you have to restore the config that a simple reboot is not clearing any errors. Just wondering if it is something with the ISP changing IP address, though I get the feeling you might have a static IP.
Have you looked at OPNsense? I don’t have a high enough speed connection to say if it can do ~10g, so maybe it’s not a good fit. I also know that if you are using Zenarmor, it is still stuck at a single core for processing and may not hit full speed due to this limitation.
I have not looked at VyOS yet, just haven’t had the time.
It was a little learning curve, but not too bad if you understand how networking works. I also use VyManager because I like the gui. But CLI is sufficient. VyManager is still in beta and we are still working on it.
You are correct, a simple reboot doesn’t help with it at all, it requires a full factory reset and then a restoral of the config.
I haven’t been able to find anything triggering this behavior either, I thought maybe it was related to me restoring from a UCK G2 with a 3rd party gateway to the UDMP, but this time I did the restore from the UCK G2 backup and things worked perfectly, then a few reboots and a lot of rule adjustments later and it just crapped out.
None of my rules are weird though and I’m not using any odd settings, and this isn’t PPPoE.
As for OPNSense, I’ve considered it, but it’s important to know it’s basically the same thing underneath so performance is about the same.
I’m considering TNSR but it’s $1k per year which is a lot, really wish they still had a homelab license, even if you had to like reach out to them about it or something.
It’s a fiber provider with an ONT and gateway so not PPPoE, I thought at first that could be the issue. Even then though, 40 megabits instead of 8000 megabits is an insane drop off.
I may try this again, though if I’m honest, in all probability, I would’ve moved back to pfSense anyway. The additional capabilities are very useful to me so it’s likely I’ll stick with them.
And yeah normally this maxes out my 8 gigabit when it’s not having issues, so it’s definitely plenty fast.
I’m measuring with a few services, primarily speedtest.net but some others as well.
For me the big thing is the packet loss also points to another issue, there should be absolutely zero Layer 2 packet loss when pinging the gateway on it’s local IP, so there’s definitely something up with the firewall itself (again switch ports had no STP issues, and moving back to pfSense with an identical configuration on the UCK G2 and things instantly stopped having issues).
I would try different cabling just to rule things out. Also, you might ask if you can get RMA if you think the hardware is bad. It sounds like it may be.
Edit: I ran the thread through Gemini to see what other ideas. Here is what it spit out:
Based on the Lawrence Systems forum thread, planedrop (Ethan Word) is experiencing a massive performance degradation—dropping from 8 Gbps to 40 Mbps—along with Layer 2 packet loss when pinging the gateway’s local IP. Interestingly, a reboot doesn’t fix it; only a factory reset and configuration restore provides a temporary fix before it “craps out” again.
If I were troubleshooting this specific UniFi Dream Machine Pro (UDMP) issue, I would follow this escalation path:
1. Rule Out Configuration Corruption
Since Ethan mentioned that the issue persists after a restore but is temporarily fixed by a factory reset, the backup file itself might be the culprit.
Manual Rebuild: Instead of restoring from a Cloud Key G2 backup (which might contain legacy settings or incompatible database entries), I would suggest a clean manual configuration. This rules out “ghost” settings from the migration that might be triggering a memory leak or process hang.
Toggle Threat Management: Disable IDS/IPS (Threat Management) and Smart Queues entirely to see if the throughput recovers. The UDMP is generally rated for ~3.5 Gbps with IDS/IPS; hitting 8 Gbps requires these to be tuned or off.
2. Deep Dive into the OS (SSH Access)
Layer 2 packet loss to the local gateway is highly unusual and suggests the internal switch chip or the CPU is being overwhelmed.
Monitor Resources: SSH into the UDMP during a slowdown and run top or htop. Look for processes like suricata (IDS/IPS) or ubnt-device-mgmt pinned at 100% CPU.
Analyze Logs: Check /var/log/messages and /var/log/uterm.log for “kernel panic,” “interface flaps,” or “out of memory” (OOM) errors.
Check Temperature: Ensure the unit isn’t thermal throttling, as 8 Gbps of throughput generates significant heat on the SoC.
3. Physical & Interface Layer
SFP+ Compatibility: Since he is on an 8 Gbps fiber connection, he is likely using the SFP+ WAN port. I would swap the SFP+ module or DAC cable. Incompatible modules can cause intermittent “RX/TX errors” that manifest as packet loss and extreme throttling.
Flow Control: Experiment with enabling/disabling Flow Control on the UDMP and the connected switch. In high-speed fiber environments, buffer exhaustion can cause the exact “drop-off” Ethan is seeing.
4. Hardware Verification (RMA)
Ethan mentioned that moving back to pfSense with the same cabling and environment fixed the issue immediately. This is the “smoking gun” that points to either a software bug in UniFi OS or a hardware defect in his specific UDMP unit.
RMA Request: If a clean manual install (no restore) still results in Layer 2 packet loss, the internal backplane or the CPU’s integrated switch is likely faulty. I would recommend an RMA at that stage.
The hardware is very old at this point, I was a very early purchaser of the UDMP.
As for cabling, it’s not that since pfSense has no issues with 2-3 gigabit upload speeds, the issue is specific to the UDMP being in use.
However, at this point, I’m not sure I want to take the time to troubleshoot it more just to get more WAN performance, I’ve got pfSense mastered and configured exactly how I like it so I think I’ll stick with it and just continue using the UDMP in my lab as a firewall to practice their systems on.
TL;DR I did not test or validate but the core technical arguments appears sound. The write up identifies several Linux networking issues:
The single-core ceiling for kernel ip_forward with offloads disabled (~5 Gbps on a fast x86 core, scaling down proportionally for slower ARM cores) is accurate networking fundamentals.
The impact of deep iptables chains on per-packet forwarding cost is real and well documented.
The nf_flow_table flowtable fast-path bypassing conntrack for established flows is a genuine, mainline Linux feature that does deliver the kind of improvement claimed.
GRO/TSO offloads being disabled having a 3-5x throughput impact is consistent with how the Linux network stack works.
Single-flow TCP traffic being bound to one core (due to RSS hash) is correct — this is a genuine architectural limitation of kernel forwarding for single streams.
I did read through a good chunk of this the other day actually, but my issue seems to stem from a bug of some kind.
I’ve factory reset this UDMP like 6 times now and of the 6 times, 3 times the upload speed has been broken and will never go above 100Mbps at most (usually much lower) while download will be fine. Rebooting, troubleshooting, working with UI directly, there seemed to be no fix. 2 of the 3 times I factory reset it and reconfigured everything and then it worked just fine and was full fiber line speed (8 gigabit). I’ve yet to do the 3rd reset since I’ve just gone back to pfSense due to it’s reliability and faster VPNs anyway.
Regardless, the write up on github is extremely interesting and I plan to read all of it in depth as soon as I can.
On the other hand, it’s still being hinted at by Netgate that pfSense is going to get VPP of some sort in the future, Jim himself even said “vpf was designed with a new pfSense in mind” so I’m very curious to see where that goes performance wise.
I’m really curious to see which direction they go. I know there was the porting of VPP to BSD, but obviously that doesn’t mean VPF works on BSD so I wonder if they’ll move pfSense to Linux and use VPP and VPF for it.
I still look back on that April Fools post from Netgate in 2024 and it gives me hope. I mean, TNSR was an April Fools post originally anyway lol
