Bonding

리눅스에서 여러 개의 물리 NIC를 하나의 논리 인터페이스(bond0 등)로 묶는 기술이다. 스위치에서 포트를 묶는 LACP/LAG와 같은 개념을 서버(호스트) 쪽에서 구현한 것으로, 목적도 동일하게 이중화와 대역폭 확장이다.

서버의 애플리케이션과 OS는 bond 인터페이스 하나만 보게 되며, 실제 어느 물리 NIC로 트래픽이 나가는지는 bonding 드라이버가 모드에 따라 결정한다.

Bonding 모드

모드	이름	동작	스위치 설정 필요
0	balance-rr	패킷을 라운드로빈으로 순환 전송	필요 (Static LAG)
1	active-backup	한 NIC만 사용, 장애 시 예비 NIC로 전환	불필요
2	balance-xor	해시 기반으로 NIC 선택	필요 (Static LAG)
3	broadcast	모든 NIC로 동일 패킷 전송	특수 용도
4	802.3ad	LACP 표준 동적 협상	필요 (LACP)
5	balance-tlb	송신만 부하 분산	불필요
6	balance-alb	송수신 모두 부하 분산 (ARP 조작)	불필요

실무에서 주로 쓰이는 모드는 두 가지다.

Mode 1 (active-backup) — 가장 단순하고 안전한 이중화. 평소엔 Active NIC 하나만 트래픽을 처리하고, 링크 다운 시 Backup으로 즉시 전환된다. 스위치 설정이 필요 없어 서로 다른 두 스위치에 나눠 꽂는 이중화가 자유롭다. 다만 Backup NIC는 대기만 할 뿐 트래픽을 흘리지 않으므로, NIC를 몇 장 묶든 대역폭은 Active NIC 한 장 속도가 상한이다.
Mode 4 (802.3ad) — LACP로 스위치와 협상해 모든 멤버 링크를 동시에 사용한다. 대역폭 확장 + 이중화를 모두 얻지만 스위치 쪽에도 LACP 설정이 필요하고, 서로 다른 스위치 두 대에 나눠 꽂으려면 상위 스위치가 vPC를 지원해야 한다.

스위치 관점에서 bonding 서버는 LAG로 연결된 상대 장비와 동일하다. 따라서 양쪽 설정(모드, LACP 여부)이 일치해야 하며, 서버만 Mode 4로 설정하고 스위치에 LACP가 없는 식의 불일치는 협상 실패나 트래픽 블랙홀로 이어진다.

장애 감지

bonding 드라이버는 멤버 NIC의 상태를 두 방식으로 감시한다.

MII 모니터링 — 링크의 물리적 up/down을 주기적으로 확인(보통 100ms). 가장 일반적.
ARP 모니터링 — 지정한 대상 IP로 ARP 요청을 보내 응답 여부로 경로 전체의 생존을 확인. 링크는 살아 있지만 상위 경로가 죽은 경우까지 감지할 수 있다.

Mode 4에서는 여기에 더해 LACPDU 협상 상태로도 장애를 감지한다.

설정 예시

# nmcli 기준 (RHEL 계열)
nmcli con add type bond ifname bond0 mode 802.3ad
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0

# 상태 확인
cat /proc/net/bonding/bond0

/proc/net/bonding/bond0에서 모드, 멤버 NIC 상태, LACP 파트너 정보(Mode 4)를 확인할 수 있다.

Teaming

RHEL 7에서 bonding의 대안으로 teaming(teamd 데몬 기반)이 도입되었으나, RHEL 9부터는 deprecated 되어 다시 bonding으로 회귀했다. 현재 리눅스 서버의 표준은 bonding이다.