커뮤니티 솔루션

ZimaOS의 이더넷 링크 집성: LACP, 본딩, 브리지 혼동 및 현재 제한 사항

An October 2025-July 2026 feature discussion from a TrueNAS migrant who wanted to bond two 2.5GbE ports. Community members distinguished bridging from LACP, tried NetworkManager-style manual bonding without success, and continued requesting native GUI support. Current public ZimaOS networking docs still document ports individually rather than exposing a bonding workflow.

두 개의 이더넷 포트를 결합한다는 것은 서로 매우 다른 의미일 수 있습니다. 원문의 사용자는 NAS가 총 대역폭과 이중화 기능을 확보할 수 있도록 두 개의 2.5GbE 인터페이스에서 LACP/링크 집계를 사용하려고 했습니다. 반면 다른 커뮤니티 게시물에서는 인터페이스 간에 트래픽을 전달하는 Linux 브리지를 다뤘습니다. 이 둘은 동일한 설계가 아닙니다.

2025~2026년 원문 논의에서는 검증된 영구 ZimaOS LACP 구성이 제시되지 않았습니다. 사용자들은 WebUI에 본딩 설정이 없다고 보고했으며, 원 게시자는 NetworkManager 방식의 구성을 적용해 보았지만 NetworkManager와 전체 시스템을 다시 시작해도 본딩이 작동하지 않았다고 밝혔습니다.

브리지는 LACP와 다릅니다

Linux 브리지는 계층 2에서 네트워크 세그먼트를 연결하며, 호스트가 어느 정도 스위치처럼 동작하도록 만들 수 있습니다. 하지만 두 업링크를 자동으로 하나의 논리적인 5Gbps 연결로 결합하지는 않습니다.

LACP/802.3ad는 본딩된 논리 인터페이스를 만들며, 일반적으로 NAS와 관리형 스위치 양쪽에서 호환되는 구성이 필요합니다.

원문 사용자는 두 개의 2.5GbE 포트를 하나의 본드로 사용하려 했습니다

해당 시스템에는 온보드 1GbE NIC 하나와 확장 카드에 장착된 2.5GbE 인터페이스 두 개가 있었습니다. 사용자는 두 인터페이스를 단순히 별도의 주소로 사용하는 대신 집계하기를 원했습니다.

또한 단일 10GbE NIC를 설치하고 이에 맞는 스위치를 사용하는 대안도 알고 있었습니다.

원문에서는 ZimaOS UI에 LACP 설정이 없었습니다

첫 번째 답변에서는 WebUI에서 링크 집계를 사용할 수 없다고 했습니다. 이후에도 사용자들은 2026년 7월까지 네이티브 본딩 지원을 계속 요청했습니다.

현재 공개된 ZimaOS 네트워킹 문서에는 물리 포트가 개별적으로 표시되며, 링크 상태, 속도, DHCP/수동 IP, 게이트웨이, DNS 설정이 설명되어 있습니다. LACP 또는 본드 생성 절차는 문서화되어 있지 않습니다.

지원되는 기준으로는 현재 ZimaOS 네트워크 인터페이스 모델을 사용하세요.

수동 NetworkManager 방식의 본딩은 작동이 확인되지 않았습니다

원 게시자는 ZimaOS가 기존 Debian의 /etc/network 구조를 사용하지 않는다는 사실을 확인하고 대신 NetworkManager 관련 구성을 발견했습니다. 연결 파일을 복사하고 수정해 본드를 생성했지만, NetworkManager를 다시 시작하거나 시스템을 완전히 재부팅해도 원하는 결과가 나오지 않았다고 보고했습니다.

이는 원문에서 확인된 부정적인 증거입니다. 이를 작동하는 CLI 튜토리얼로 바꾸어 제시해서는 안 됩니다.

스위치 측 LACP만으로는 충분하지 않습니다

관리형 스위치는 서버도 동일한 LACP/본딩 구성에 참여할 때만 포트를 집계할 수 있습니다. 호스트 측 본딩 없이 일반적인 ZimaOS 인터페이스 두 개를 하나의 LACP 그룹에 연결하면 MAC 학습이 불안정해지거나 연결이 끊길 수 있습니다.

2.5GbE 링크 두 개가 하나의 파일 복사를 5Gbps로 만들지는 않습니다

정상적으로 작동하는 LACP 환경에서도 트래픽은 일반적으로 흐름 해싱에 따라 분산됩니다. 하나의 SMB/TCP 흐름은 보통 하나의 구성원 링크를 계속 사용하며, 여러 클라이언트나 세션이 서로 다른 링크로 분산될 수 있습니다.

따라서 링크 집계는 단일 워크스테이션의 단일 스트림 전송 속도를 확실히 두 배로 만드는 방법이라기보다, 여러 클라이언트의 총 대역폭과 장애 조치에 더 유용합니다.

단일 고속 NIC가 더 간단한 경우가 많습니다

실제 목표가 한 클라이언트에서 2.5Gbps보다 빠르게 전송하는 것이라면, 단일 10GbE 경로가 LACP보다 이해하고 구성하기 쉬울 수 있습니다. 흐름 해싱이나 관리형 스위치의 LAG 구성에 의존하지 않기 때문입니다.

다만 스토리지 풀과 클라이언트도 해당 링크를 충분히 처리할 수 있어야 합니다.

해당 스레드는 기능 요청으로 남았습니다

이 원문 스레드에서 IceWhale 직원이 네이티브 LACP 지원을 발표한 답변은 없었으며, 2026년 7월의 한 참여자도 여전히 공식 관리 인터페이스에 본딩 설정을 추가해 달라고 요청하고 있었습니다.

ZimaOS가 지원되는 본딩 절차를 공개하기 전까지는 로컬 콘솔 접근과 롤백 방법이 없는 상태에서 원격 또는 헤드리스 NAS의 호스트 네트워크를 영구적으로 변경하지 마세요.

링크 집계 FAQ

네트워크 브리지는 LACP와 같은가요?

아니요. 브리지는 계층 2 트래픽을 전달하고, LACP는 스위치의 협력을 바탕으로 링크를 하나의 논리 인터페이스로 본딩합니다.

원문 스레드에서 작동하는 영구 ZimaOS 본딩이 확인되었나요?

아니요. 원 게시자의 수동 NetworkManager 시도는 작동하지 않았습니다.

2.5GbE LACP 링크 두 개를 사용하면 하나의 SMB 복사가 5Gbps로 실행되나요?

대체로 그렇지 않습니다. LACP는 여러 동시 흐름과 이중화에 가장 유용합니다.