Combining two Ethernet ports can mean very different things. The source user wanted LACP/link aggregation across two 2.5GbE interfaces so the NAS could gain aggregate bandwidth and redundancy. Another community thread discussed a Linux bridge that forwards traffic between interfaces. Those are not equivalent designs.
The 2025-2026 source discussion did not produce a verified persistent ZimaOS LACP configuration. Users reported no bonding controls in the WebUI, and the original poster tried adapting NetworkManager-style configuration but said restarting NetworkManager and the whole system did not make the bond work.
A Bridge Is Not the Same Thing as LACP
A Linux bridge connects network segments at Layer 2 and can make a host behave somewhat like a switch. It does not automatically combine two uplinks into one logical 5Gbps connection.
LACP/802.3ad creates a bonded logical interface and normally requires compatible configuration on both the NAS and the managed switch.
The Source Wanted Two 2.5GbE Ports as One Bond
The system had a 1GbE onboard NIC plus two 2.5GbE interfaces on an expansion card. The user wanted the pair aggregated rather than merely using both as separate addresses.
They also recognized the alternative: install a single 10GbE NIC and use a matching switch.
The Source Found No ZimaOS LACP Control in the UI
The first reply said link aggregation was not available from the WebUI. Later users continued requesting native bonding support through July 2026.
Current public ZimaOS Networking documentation shows physical ports individually, with link state, speed, DHCP/manual IP, gateway, and DNS settings. It does not document an LACP/bond creation workflow.
Use the current ZimaOS network-interface model as the supported baseline.
Manual NetworkManager-Style Bonding Was Not Confirmed Working
The original poster discovered ZimaOS was not using the traditional Debian /etc/network layout and found NetworkManager-related configuration instead. They copied and edited connection files to create a bond, but reported that neither a NetworkManager restart nor a full reboot produced the desired result.
That is negative source evidence. It should not be transformed into a working CLI tutorial.
Switch-Side LACP Alone Is Not Enough
A managed switch can aggregate ports only when the server also participates in the same LACP/bond configuration. Plugging two ordinary ZimaOS interfaces into one LACP group without host-side bonding can create unstable MAC learning or loss of connectivity.
Two 2.5GbE Links Do Not Make One File Copy 5Gbps
Even on systems with working LACP, traffic is typically distributed by flow hashing. One SMB/TCP flow normally stays on one member link, while multiple clients or sessions can be spread across different links.
Link aggregation is therefore most useful for aggregate multi-client bandwidth and failover, not as a guaranteed way to double one workstation's single-stream transfer rate.
A Single Faster NIC Is Often Simpler
If the actual goal is one client transferring faster than 2.5Gbps, a single 10GbE path can be easier to reason about than LACP because it does not depend on flow hashing or a managed switch LAG configuration.
The storage pool and client must still be fast enough to feed that link.
The Thread Remained a Feature Request
No IceWhale staff reply in this source thread announced native LACP support, and a July 2026 participant was still asking for bonding controls in official management interfaces.
Until ZimaOS publishes a supported bonding workflow, avoid making persistent host-network changes on a remote/headless NAS unless you have local console access and a rollback path.
Link Aggregation FAQ
Is a network bridge the same as LACP?
No. A bridge forwards Layer-2 traffic; LACP bonds links into one logical interface with switch cooperation.
Did the source thread confirm a working persistent ZimaOS bond?
No. The original poster's manual NetworkManager attempt did not work.
Will two 2.5GbE LACP links make one SMB copy run at 5Gbps?
Usually not. LACP is most useful for multiple simultaneous flows and redundancy.
