1. Symptoms
The problem initially looked like a hardware failure.
- The NAS lights would stop blinking or showing any activity
- Netgear unmanaged switch and a D-Link unmanaged switch would hang until shutting them down
- The issue occurred with either of the two onboard Ethernet interfaces.
- An additional PCIe Ethernet card exhibited the same behavior.
- Only one Ethernet cable was connected at a time.
This made a failure of one specific switch or Ethernet port less likely.
2. Testing Unraid Safe Mode
My first suspicion was a software issue involving plugins or Docker networking.
I booted Unraid in Safe Mode, which disables third-party plugins.
The issue persisted.
I also confirmed that:
- Docker was not running.
- Virtual machines were not running.
- The issue occurred with different physical Ethernet interfaces.
This ruled out active Docker containers, virtual machines, and normal plugin startup as necessary conditions for reproducing the problem.
3. Investigating BIOS and firmware
The NAS was running an AMI BIOS with the following information:
| Property | Value |
|---|---|
| BIOS vendor | AMI |
| AMI version | 2.22.1289 |
| BIOS date | 2024-05-11 |
| BIOS identifier | RP0R0170 |
I investigated whether a BIOS or NIC firmware update might resolve the issue.
However, UGREEN's download page primarily provided a complete UGOS update package of approximately 900 MB rather than an easily accessible standalone BIOS update.
Since I had replaced UGOS with Unraid, firmware updating was less straightforward. I abandonned this idea.
I also investigated upgraded Unraid to version 7.3.0. I don't think it has anything to do with the resolution.
4. Discovering bonding and bridging in Unraid
During troubleshooting, I inspected the Unraid network settings and noticed that bonding and bridging were both enabled.
The configuration was:
| Setting | Original value |
|---|---|
| Bonding | Enabled |
| Bonding mode | Active-backup |
| Bond members | eth0 |
| Bridging | Enabled |
| IPv4 | DHCP |
| IPv6 | Disabled (IPv4 only) |
| VLANs | Disabled |
| MTU | 1500 |
Despite having only one Ethernet cable connected, Unraid was using a logical bond and bridge.
The effective configuration resembled:
eth0 → bond0 → br0 → LAN
Active-backup bonding can work with unmanaged switches, even with a single member. However, it was unnecessary in my setup and introduced additional networking complexity.
Simplifying the network configuration
I tested disabling:
- Bonding
- Bridging
- VLANs
I kept only one physical Ethernet interface connected, with DHCP enabled.
Important: The issue did not immediately disappear when I first reported testing with bonding and bridging disabled. Therefore, this change cannot be identified conclusively as the fix.
5. Investigating OPNsense
Because the problem appeared shortly after DHCP assignment, I also investigated the OPNsense side of the network.
The suggested diagnostic checks included:
- DHCP leases and static mappings
- Duplicate IP addresses
- ARP table entries
- MAC address changes
- Firewall state counts
- Interface packet statistics
- Packet captures
Packet capture
I captured traffic on an OPNsense network interface and examined it for unusual activity.
The capture included frames sent to:
01:80:c2:00:00:00
This is a reserved Ethernet multicast address used for bridge-control protocols, including Spanning Tree Protocol (STP).
That observation raised questions about Layer 2 traffic, especially given the original Unraid bonding and bridging configuration.
However, the presence of these frames did not prove a network loop or establish the cause of the switch failures.
No conclusive broadcast storm or ARP flood was established from the initial capture analysis.
Were any OPNsense settings changed?
I can't recall changing any OPNSense conf. The OPNsense work consisted of diagnostic suggestions and traffic analysis. I may have made additional changes independently, but I no longer remember doing so.
6. Current working configuration
Several months later, the NAS is operating normally.
The current Unraid network configuration is:
| Setting | Working value |
|---|---|
| Bonding | Disabled |
| Bridging | Disabled |
| Network protocol | IPv4 only |
| IPv4 assignment | Automatic (DHCP) |
| IPv4 DNS | Automatic |
| VLANs | Disabled |
| MTU | 1500 |
| Jumbo frames | Disabled |
| Physical Ethernet cables | One |
The resulting network configuration is straightforward:
eth0 → LAN
There is no logical bonding interface or network bridge required for the basic NAS connection.
7. What actually fixed it?
Unfortunately, the precise resolution remains unknown.
The most significant documented difference between the original configuration and the current stable configuration is that both bonding and bridging are disabled.
My leading hypothesis is that simplifying the Unraid networking configuration contributed to the eventual resolution.
However, because the issue initially persisted after disabling these features, I cannot rule out another change, such as a reboot, a network service reset, a DHCP-related change, or a modification in OPNsense.
I also cannot confirm whether the Unraid upgrade contributed to the fix.
The important distinction is:
- Confirmed: The NAS is now stable with bonding and bridging disabled.
- Confirmed: The issue previously affected multiple NICs and two different switches.
- Confirmed: The issue occurred with Docker, VMs, and plugins inactive.
- Not confirmed: Bonding or bridging was the root cause.
- Not confirmed: OPNsense configuration was responsible.
- Not confirmed: A BIOS or driver update fixed the issue.
8. Troubleshooting checklist for similar issues
If an Unraid server appears to crash or destabilize an unmanaged Ethernet switch, I would investigate in this order:
- Connect only one Ethernet interface.
- Test a different cable and switch.
- Disable Unraid bonding if it is unnecessary.
- Temporarily disable bridging when Docker and VM networking do not require it.
- Test Unraid Safe Mode.
- Disable Docker and VM services during diagnosis.
- Inspect DHCP leases and ARP entries on the router.
- Capture traffic with OPNsense or Wireshark.
- Check NIC driver logs and link-state changes.
- Reboot after network configuration changes and verify the active interfaces.
Useful commands on Unraid:
# Show physical and logical network interfaces
ip -br link
# Show interface IP addresses
ip -br addr
# Inspect network configuration
cat /boot/config/network.cfg
# Identify Ethernet controllers
lspci -nn | grep -i ethernet
# Check Ethernet link status
ethtool eth0
# Watch kernel messages
dmesg -w
# Monitor interface packet statistics
ip -s link
These commands help identify active bridges or bonds, link negotiation problems, and driver errors.
Conclusion
This was one of the more unusual networking problems I've encountered with Unraid.
A single NAS connection appeared to destabilize two different unmanaged switches, regardless of which physical NIC was used.
The issue persisted in Unraid Safe Mode, with Docker and virtual machines disabled.
After troubleshooting, the system eventually became stable and has remained so for months.
The current working configuration uses a single Ethernet interface, DHCP, and no bonding or bridging.
Although I cannot identify the exact final fix, documenting the working configuration and the troubleshooting process should make any future recurrence much easier to investigate.
Status: Resolved — exact root cause unconfirmed.