Combinare due porte Ethernet può significare cose molto diverse. L’utente della fonte desiderava LACP/aggregazione dei collegamenti su due interfacce 2.5GbE, in modo che il NAS ottenesse maggiore larghezza di banda aggregata e ridondanza. Un’altra discussione della community riguardava un bridge Linux che inoltra il traffico tra le interfacce. Non sono configurazioni equivalenti.
La discussione della fonte del 2025-2026 non ha prodotto una configurazione LACP persistente e verificata per ZimaOS. Gli utenti hanno segnalato l’assenza di controlli per il bonding nella WebUI e l’autore del post originale ha provato ad adattare una configurazione in stile NetworkManager, affermando però che né il riavvio di NetworkManager né quello dell’intero sistema hanno fatto funzionare il bond.
Un bridge non è la stessa cosa di LACP
Un bridge Linux collega segmenti di rete al Livello 2 e può far comportare l’host in modo simile a uno switch. Non combina automaticamente due uplink in un’unica connessione logica da 5 Gbps.
LACP/802.3ad crea un’interfaccia logica aggregata e normalmente richiede una configurazione compatibile sia sul NAS sia sullo switch gestito.
La fonte voleva usare due porte 2.5GbE come un unico bond
Il sistema disponeva di una NIC integrata da 1GbE e di due interfacce 2.5GbE su una scheda di espansione. L’utente voleva aggregare la coppia, invece di usarle semplicemente come indirizzi separati.
Aveva inoltre riconosciuto l’alternativa: installare una singola NIC 10GbE e utilizzare uno switch compatibile.
La fonte non ha trovato alcun controllo LACP di ZimaOS nell’interfaccia
La prima risposta affermava che l’aggregazione dei collegamenti non era disponibile nella WebUI. In seguito, altri utenti hanno continuato a richiedere il supporto nativo al bonding fino a luglio 2026.
La documentazione pubblica attuale di ZimaOS sul networking mostra le porte fisiche singolarmente, con stato del collegamento, velocità, IP DHCP/manuale, gateway e impostazioni DNS. Non documenta una procedura per creare un LACP/bond.
Usa l’attuale modello delle interfacce di rete di ZimaOS come riferimento supportato.
Il bonding manuale in stile NetworkManager non è stato confermato come funzionante
L’autore del post originale ha scoperto che ZimaOS non utilizzava la struttura Debian tradizionale /etc/network e ha invece trovato una configurazione relativa a NetworkManager. Ha copiato e modificato i file delle connessioni per creare un bond, ma ha riferito che né il riavvio di NetworkManager né un riavvio completo hanno prodotto il risultato desiderato.
Questa è un’evidenza negativa tratta dalla fonte. Non deve essere trasformata in un tutorial CLI funzionante.
Il solo LACP sullo switch non è sufficiente
Uno switch gestito può aggregare le porte solo quando anche il server partecipa alla stessa configurazione LACP/bond. Collegare due interfacce ZimaOS ordinarie a un unico gruppo LACP senza bonding sul lato host può causare un apprendimento instabile degli indirizzi MAC o la perdita della connettività.
Due collegamenti 2.5GbE non trasformano una singola copia di file in una connessione da 5 Gbps
Anche sui sistemi con LACP funzionante, il traffico viene generalmente distribuito tramite hashing dei flussi. Un singolo flusso SMB/TCP normalmente rimane su un solo collegamento membro, mentre più client o sessioni possono essere distribuiti su collegamenti diversi.
L’aggregazione dei collegamenti è quindi più utile per la larghezza di banda aggregata di più client e per il failover, non come metodo garantito per raddoppiare la velocità di trasferimento di un singolo flusso da una workstation.
Una singola NIC più veloce è spesso più semplice
Se l’obiettivo effettivo è trasferire dati da un client a una velocità superiore a 2,5 Gbps, un singolo percorso 10GbE può essere più facile da gestire rispetto a LACP, perché non dipende dall’hashing dei flussi né dalla configurazione di un LAG su uno switch gestito.
Il pool di archiviazione e il client devono comunque essere abbastanza veloci da alimentare quel collegamento.
La discussione è rimasta una richiesta di funzionalità
Nella discussione della fonte nessuna risposta dello staff di IceWhale ha annunciato il supporto nativo a LACP e, a luglio 2026, un partecipante chiedeva ancora controlli per il bonding nelle interfacce di gestione ufficiali.
Finché ZimaOS non pubblicherà una procedura di bonding supportata, evita di apportare modifiche persistenti alla rete dell’host su un NAS remoto o headless, a meno che tu non disponga dell’accesso a una console locale e di una procedura di ripristino.
Domande frequenti sull’aggregazione dei collegamenti
Un bridge di rete è la stessa cosa di LACP?
No. Un bridge inoltra il traffico al Livello 2; LACP aggrega i collegamenti in un’unica interfaccia logica con la collaborazione dello switch.
La discussione della fonte ha confermato un bond ZimaOS persistente e funzionante?
No. Il tentativo manuale dell’autore del post originale con NetworkManager non ha funzionato.
Due collegamenti LACP da 2.5GbE faranno funzionare una singola copia SMB a 5 Gbps?
Di solito no. LACP è più utile per più flussi simultanei e per la ridondanza.
