Hi everyone,

I’m looking for help diagnosing a persistent and worsening network instability issue that began immediately after updating Unraid. This system was stable for months prior and no hardware changes were made.

---

System Overview

• Unraid versions tested:

  • 7.2.3 (initially noticed issue)

  • 7.2.2 (downgraded for testing)

  • Currently back on 7.2.3 for further diagnostics

• Hardware:

  • CPU: AMD EPYC 7452

  • Motherboard: ASRock ROMED8-2T

  • NIC: Onboard Intel ixgbe 10GbE RJ45

  • Memory: 128 GB ECC

  • Boot device: Samsung FIT Plus 64GB (reseated and booted successfully after 1 failed boot)

• Network:

  • 10GbE RJ45 to Unifi switch (Pro HD 24 port)

  • No bonding (single interface)

  • VLANs configured via bridge (br0 / br0.70)

  • DHCP with static reservation on UniFi (IP unchanged)

• Diagnostics attached:

  • 7.2.2 diagnostics zip from multi-day run (*1248.zip)

  • 7.2.3 diagnostics zip from after I returned to 7.2.3 today (*1443.zip)

---

Problem Summary

After updating to Unraid 7.2.3, the server began experiencing frequent NIC link flaps:

• ixgbe eth0: NIC Link is Down

• Followed seconds later by:

  • NIC Link is Up 10 Gbps

  • Bridge ports cycling (br0 / br0.70 disabled → forwarding)

  • DHCP lease teardown and rebind

  • Temporary loss of connectivity (SSH, WebUI, services, Cloudflared tunnel drops)

Each event lasts ~5–30 seconds but occurs repeatedly, sometimes every few minutes.

---

Observations

• System was rock solid for months before this.

• No hardware changes, firmware updates, or BIOS changes were made prior to the issue.

• Only action taken before the issue started was updating Unraid OS.

  • No other changes whatsoever from when the system was stable.

• The instability is much worse overnight, but has now begun occurring during the day as well.

• Unifi switch does not seem to reliably log corresponding port down/up events, even while Unraid clearly reports link loss.

---

Testing & Troubleshooting Performed

Unraid 7.2.3 (initial run)

• Observed frequent NIC flapping.

• Live monitoring via:

tail -n 0 -F /var/log/syslog | egrep -i 'ixgbe|eth0|link is|reset|watchdog|NETDEV|pcie|aer|IOMMU|DMA|br0|dhcpcd'

• Repeated logs of:

  • Link down/up

  • Bridge disable/enable

  • DHCP route removal and re-addition

Downgrade to 7.2.2

• Downgraded via Tools → Downgrade OS.

• Perceived improvement: system appeared stable during daytime hours.

• Overnight instability continued; returned shortly after shutting down PC, continued until I turned my PC back on in the morning and accessed files/SSH

• Continued monitoring showed same link flap behavior, just less frequent initially.

• Over time, instability began occurring during the day again.

MTU Change

• Originally running MTU 9000 (jumbo frames).

• Observed increasing rx_long_length_errors.

• Dropped MTU to 1500.

• Result:

  • rx_long_length_errors stopped increasing

  • Link flaps continued

Other Checks

• Flow control status checked (ethtool -a eth0 → RX/TX off)

• Offload features inspected

• No bonding configured

• Tried different switch ports previously

• No spare NIC available to swap

---

Current State

• System is now back on Unraid 7.2.3

• Array starts successfully

• Network instability persists

• Monitoring still shows repeated:

  • ixgbe eth0: NIC Link is Down

  • Bridge cycling

  • DHCP reset/rebind

---

What I’m Hoping For Help With

I’m trying to understand what changed and how to restore stability without permanently disabling core functionality/abilities of the system.

Specifically:

• Is this a known issue with ixgbe in recent Unraid releases?

• Are there known regressions involving:

  • 10GbE RJ45

  • MTU handling

  • Bridge + VLAN setups

• Are there kernel parameters, driver options, or Unraid settings I should test?

• Is there a recommended way to validate whether this is OS/driver behavior vs hardware without spare NICs?

• Am I missing something obvious?

I’m happy to run targeted tests or provide additional logs if pointed in a specific direction.

Thank you for taking the time to read this.

---

Attachments

• Diagnostics zip (from 7.2.2 run, *1248.zip)

• Diagnostics zip (from current 7.2.3 run, *1443.zip)

---

A couple other observations:

• When I reinstalled 7.2.3, the boot USB was not seen and boot failed, this was solved by simply re-seating the USB and trying again.

• I have another Unraid server on 7.2.3 that is not experiencing the same problems. That server is running completely different hardware though (Intel i5-13500, MSI Z-790 motherboard)

cs-15-diagnostics-20251226-1248.zip cs-15-diagnostics-20251226-1443.zip

Edited December 27, 2025Dec 27 by CandleSir
Completed unfinished title, clarification on which zip file corresponds to which version run

Kernel is the same between both releases, and AFAIK nothing else changed that would interfere with that, suggesting the upgrade is not the issue. I recommend running for longer on the last known good release to confirm.

NIC link going down is almost always an external issue, like cable, switch, or the NIC itself.

in 99% this can be seen with bad cable (or too long one). But I agree, it is very hard to track because they wont tell you the truth if you buy one.

Look at the cable, if there is something written on it like "rawcable", through it away. 10G only works almost stable with real cable and plugs at the ends.

If you cant make it out (I gave up after 6months of depressing tries), switch to fiber and you are done.

I would consider everything >5m lenght as a potentional source of evil. They say 30m would be fine, they lie...

6 hours ago, JorgeB said:

Kernel is the same between both releases, and AFAIK nothing else changed that would interfere with that, suggesting the upgrade is not the issue. I recommend running for longer on the last known good release to confirm.

NIC link going down is almost always an external issue, like cable, switch, or the NIC itself.

Thanks for the clarification. That makes sense and I guess the fact it aligned perfectly with the upgrade is purely coincidence here. At least a version discrepancy is one possibility I can stop chasing. I did run 7.2.3 for about 36 hours when I first upgraded and noticed the problem but as I did not capture diagnostics as thoroughly as I am now, I will continue to try 7.2.3 for a longer observation window.

That said, I have already ruled out the specific switch port and the cable. The cable is a short, ~3ft, known good and tested Cat6a that sustained this 10 Gbps configuration for ~8 months. I also tested the switch port with other devices, only one of which was a 10 Gbps link though, and it showed no errors or instability. After everything I have ruled out I have trouble committing to a "it must be hardware" approach, admittedly some of this is emotional difficulty as I dropped a pretty penny on this build, but I will continue to run and test on 7.2.3 for a longer observation window and will test a completely different switch if find the ability to do so.

6 hours ago, MAM59 said:

in 99% this can be seen with bad cable (or too long one). But I agree, it is very hard to track because they wont tell you the truth if you buy one.

Look at the cable, if there is something written on it like "rawcable", through it away. 10G only works almost stable with real cable and plugs at the ends.

If you cant make it out (I gave up after 6months of depressing tries), switch to fiber and you are done.

I would consider everything >5m lenght as a potentional source of evil. They say 30m would be fine, they lie...

I understand that. In this case though, this is a confirmed good and tested ~3ft Cat6a cable. The link was fully stable at 10 Gbps for about 8 months with this exact configuration. No CRC errors or negotiation instability were ever present since the build and configuration were first powered on. Because of this stability, I do not believe the cable itself is the root cause here, although I do agree that 10 GbE copper can be an unforgiving beast in general. I am planning on a move to an SFP+ NIC with fiber for the long term. I just have not rushed this change as the system had been perfectly stable up until this current instability was first observed.

For now I will keep trying to isolate the issue while staying on 7.2.3.

Overnight severity update:
I pulled ixgbe … eth0: NIC Link is Down events from /var/log/syslog.1 and /var/log/syslog covering Dec 26 13:51 → Dec 27 08:36 (198 total link drops).

• Daytime / evening (Dec 26, 13:00–21:59): ~24 drops over ~9 hours (~2–3/hour)
• Overnight (Dec 27, 00:00–08:36): ~174 drops over ~8.6 hours (~20/hour)

This shows the clear order-of-magnitude increase in link instability overnight compared to daytime and I am still not sure what causes this increase each night.

Thank you for the feedback and input.

1 hour ago, CandleSir said:

This shows the clear order-of-magnitude increase in link instability overnight compared to daytime and I am still not sure what causes this increase each night.

Another reason for these drops could be "too much power saving".

If the nic (or the port on the switch) is powered down for some reason, these things can happen.

On UNRAID the tool "powertop" is known for producing such problems. If you use it, delete it and reboot.

1 hour ago, MAM59 said:

On UNRAID the tool "powertop" is known for producing such problems. If you use it, delete it and reboot.

I do not but that is good thinking. Thanks for the suggestion.

In an attempt to further rule out (or confirm) hardware faults, I have someone bringing over a new SFP+ NIC and will be testing with that today.

Coming from 7.1.4 and I have the same issue with network stability.

I end up with a bunch of these in my syslogs:
Dec 24 08:45:48 My-Hostename kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:

Can't access/ping the IP but have CLI access through a KVM. If I bounce the port manually, it comes back up but I have to disable docker and VM service to disable/re-enable bridging to get those back online.

5 hours ago, Panja said:

e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:

This is another issue specific to those NICs, they have bugs that the kernel tries to work around, but it's not always successful. Some options you can try to help, most are mentioned here:

https://bugzilla.kernel.org/show_bug.cgi?id=118721#c11

Failing that, best bet is to replace the NIC with one that doesn't use that driver, e.g., Intel igb driver is good.

8 hours ago, JorgeB said:

This is another issue specific to those NICs, they have bugs that the kernel tries to work around, but it's not always successful. Some options you can try to help, most are mentioned here:

https://bugzilla.kernel.org/show_bug.cgi?id=118721#c11

Failing that, best bet is to replace the NIC with one that doesn't use that driver, e.g., Intel igb driver is good.

Would it have been introduced with the upgrade to 7.2.3? I haven't had any issues whatsoever on 7.1.4. I'll do some digging and see if there's something I can do to resolve, or failing that update my NIC.

On 12/27/2025 at 1:16 AM, MAM59 said:

switch to fiber and you are done.

I ran a 24 hour observation using an Intel X520-DA1 SFP+ NIC with a fiber connection and maintained stability with no network drops and no syslog activity (monitored syslog using tail -n 0 -F /var/log/syslog | egrep -i 'ixgbe|eth2|link is|reset|watchdog|NETDEV|pcie|aer|IOMMU|DMA|br0|dhcpcd|IOMMU|SFP|optical'). Even though I will be using the X520-DA1 as the permanent network interface, I am going to further explore the viability of both onboard NICs but as Unraid has been ruled out I will take that exploration elsewhere and mark this as solved.

Thank you for the input and taking the time to read my post and offer suggestions.

Edited December 28, 2025Dec 28 by CandleSir
spelling

14 hours ago, Panja said:

Would it have been introduced with the upgrade to 7.2.3?

It's a very old bug, it's been happening for years, but it can show up with those NICs when there are any kernel changes.

I just upgraded to 7.2.3 and my network dropped too. On initial boot its fine, but it just disappears.. upgraded from a totally stable 7.2.0 directly to 7.2.3. I had pushed my rack back slightly after the update, so I just reseated the 10gb fiber connection to see how that works.

Ethernet controller: Mellanox Technologies MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s] (rev b0)

1 hour ago, theDrell said:

I just upgraded to 7.2.3 and my network dropped too. On initial boot its fine, but it just disappears

What helped me most was watching syslog for NIC-related messages when the drop happened, and checking interface counters over time with ethtool -S. You’d just want to adjust the interface name and filters for your Mellanox card.