고속도로에서 차가 막힌다고 생각해 봅시다. 차선이 1개뿐이라면 아무리 좋은 차가 있어도 속도를 낼 수 없습니다. 반면 차선을 2개, 4개로 늘리면 같은 시간에 훨씬 많은 차가 지나갈 수 있습니다. 네트워크에서 이 "차선 늘리기"에 해당하는 기술이 바로 LACP(Link Aggregation Control Protocol)입니다. 여러 개의 물리적 네트워크 케이블을 하나로 묶어서 대역폭을 늘리고, 동시에 케이블 하나가 끊어져도 다른 케이블이 살아있으면 계속 통신할 수 있게 해줍니다. 이 글에서는 트래픽 병목 현상이 무엇인지, LACP가 어떻게 이를 해결하는지 쉽게 풀어서 설명해 드리겠습니다.
1. 트래픽 병목 현상이란? — 네트워크가 막히는 이유
트래픽 병목 현상(Traffic Bottleneck)은 네트워크에서 데이터가 처리할 수 있는 용량보다 많이 몰려서 속도가 급격히 떨어지는 현상입니다. 마치 좁은 하천에 갑자기 많은 물이 밀려오면 넘치듯, 네트워크 링크의 대역폭을 초과하는 트래픽이 들어오면 패킷 손실과 지연이 발생합니다.
병목 현상이 발생하는 주요 원인으로는 업링크 대역폭 부족, 서버와 스위치 사이의 단일 링크 한계, 예상보다 많은 사용자 접속, 특정 시간대의 트래픽 집중 등이 있습니다. 1Gbps 링크 하나에 너무 많은 트래픽이 몰리면 CPU 사용률이 올라가고, 패킷 큐가 넘쳐서 패킷이 버려지기 시작합니다. 이 상태에서 사용자들은 인터넷이 느려지거나 끊기는 것을 경험하게 됩니다.
실제로 회사에서 영상 회의 시스템을 도입하고 나서 오후 2시 전후로 네트워크가 심하게 느려지는 현상을 겪었습니다. 처음에는 서버 문제인 줄 알고 서버만 점검했는데 아무 이상이 없었습니다. 와이어샤크로 캡처해 보니 특정 스위치 포트의 트래픽이 최대 대역폭의 95%를 넘어서고 있었습니다. 영상 회의는 데이터 양이 상당히 많기 때문에, 기존 1Gbps 링크 하나로는 도저히 감당이 안 되는 상황이었습니다. 처음에는 고가의 10Gbps 스위치로 업그레이드해야 하나 고민했는데, 선임이 LACP를 제안해줘서 기존 1Gbps 케이블 두 개를 묶어서 2Gbps 효과를 내는 방법으로 해결했습니다. 단순히 케이블 하나 더 연결하고 설정 몇 줄 추가하는 것만으로 속도가 눈에 띄게 개선됐습니다. 장비를 교체하지 않고 기존 인프라를 최대한 활용하는 방법을 찾는 것이 엔지니어의 역량이라는 것을 그때 배웠습니다. 병목 현상은 원인을 정확히 파악하지 않으면 엉뚱한 해결책에 시간과 비용을 낭비하기 쉽습니다. 반드시 모니터링 도구로 어디서 막히는지 먼저 확인해야 합니다.
[트래픽 병목 현상 구조]
[서버]
|
(1Gbps 링크) ← 여기가 병목!
|
[스위치]
/ | \
[PC1] [PC2] [PC3] ... [PC50]
각 PC → 100Mbps, 50대 연결 시 이론상 최대 5Gbps 요구
[병목 현상 증상 확인]
Linux 명령어:
sar -n DEV 1 ← 실시간 네트워크 사용량
ifstat ← 인터페이스별 트래픽
ip -s link show eth0 ← 패킷 드롭 카운터 확인
Windows 명령어:
netstat -e ← 이더넷 통계
Get-NetAdapterStatistics -Name "Ethernet" ← PowerShell
[패킷 드롭 확인 출력 예시]
$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
RX: bytes packets errors dropped
9.8GB 7234512 0 4821 ← dropped 증가 = 병목!
TX: bytes packets errors dropped
2.1GB 3412088 0 0
2. LACP란 무엇인가? — 링크 집선의 원리
LACP(Link Aggregation Control Protocol)는 IEEE 802.3ad 표준으로 정의된 프로토콜로, 여러 개의 물리적 네트워크 포트를 하나의 논리적 포트로 묶는 기술입니다. 이렇게 묶인 논리적 포트를 LAG(Link Aggregation Group) 또는 포트 채널(Port-Channel), 본딩(Bonding)이라고 부릅니다. 제조사마다 용어가 다른데, 시스코는 EtherChannel, 리눅스는 Bonding, 일반적으로는 Trunking이나 Teaming이라는 표현도 씁니다.
LACP가 제공하는 두 가지 핵심 기능이 있습니다. 첫째는 대역폭 확장(Load Balancing)입니다. 예를 들어 1Gbps 케이블 4개를 묶으면 최대 4Gbps의 대역폭을 사용할 수 있습니다. 단 이론적 최대치이고, 실제로는 로드 밸런싱 알고리즘에 따라 특정 플로우(flow)가 하나의 링크에만 할당될 수 있어 완벽한 4배가 되지는 않습니다. 둘째는 이중화(Redundancy/Failover)입니다. 묶인 링크 중 하나가 단선되거나 포트가 다운돼도 나머지 링크로 트래픽이 자동으로 전환되어 서비스가 중단되지 않습니다.
LACP 동작 방식을 좀 더 자세히 보면, 양쪽 장비(스위치와 서버, 또는 스위치와 스위치)가 LACPDU(LACP Data Unit)라는 제어 메시지를 주고받으면서 링크 집선을 협상합니다. LACP에는 Active 모드와 Passive 모드가 있습니다. Active 모드는 자신이 먼저 LACPDU를 전송하고, Passive 모드는 상대방이 먼저 시작하면 응답합니다. 양쪽이 모두 Passive이면 협상이 시작되지 않으므로, 적어도 한쪽은 Active여야 합니다. 데이터센터에서 서버 2대를 이중화하면서 LACP를 구성했는데, 처음에는 양쪽 모두 Passive로 설정해 놓아서 링크가 묶이지 않는 문제가 있었습니다. 설정 로그를 보니 LACPDU 교환이 전혀 일어나지 않고 있었고, 한쪽을 Active로 바꾸자마자 바로 협상이 완료되고 Port-Channel이 올라왔습니다. 이처럼 세팅 하나 때문에 전혀 동작하지 않는 경우가 생기기 때문에, LACP 구성 후에는 반드시 상태 확인 명령어로 검증해야 합니다. Static LAG(LACP 없이 그냥 묶는 방법)는 설정이 간단하지만, 링크 장애를 자동으로 감지하지 못하는 단점이 있어 운영 환경에서는 반드시 LACP를 사용하는 것이 바람직합니다.
[LACP 동작 구조]
[서버] [스위치]
eth0 ──────────────────────────── Port 1
eth1 ──────────────────────────── Port 2 → LAG (Po1)
eth2 ──────────────────────────── Port 3
↑ ↑
bond0 (논리적 인터페이스) Port-Channel 1
[LACPDU 교환 과정]
서버(Active) ──LACPDU──▶ 스위치(Passive)
서버(Active) ◀──LACPDU── 스위치(Passive)
→ 협상 완료 → LAG 형성
[LACP 모드 조합]
Active - Active : 정상 동작 ✓
Active - Passive : 정상 동작 ✓
Passive - Active : 정상 동작 ✓
Passive - Passive: 협상 안됨 ✗
[로드 밸런싱 알고리즘]
src-mac : 출발지 MAC 주소 기반
dst-mac : 목적지 MAC 주소 기반
src-dst-mac : 출발지+목적지 MAC 기반 (권장)
src-ip : 출발지 IP 기반
src-dst-ip : 출발지+목적지 IP 기반 (권장)
src-dst-port : 출발지+목적지 포트 기반
3. 시스코 스위치에서 LACP(EtherChannel) 설정하기
시스코 스위치에서 LACP를 설정하는 방법을 알아보겠습니다. 시스코는 LACP 기반 링크 집선을 EtherChannel이라고 부릅니다. EtherChannel을 구성하면 여러 물리 포트가 하나의 Port-Channel 인터페이스로 묶입니다. 설정 전에 반드시 확인해야 할 사항은 묶으려는 포트들의 속도, 듀플렉스, VLAN 설정이 모두 동일해야 한다는 것입니다. 조건이 맞지 않으면 EtherChannel이 형성되지 않거나 폴링(flapping) 현상이 발생합니다.
설정 순서는 이렇습니다. 먼저 묶을 인터페이스로 진입해서 channel-group 명령어로 그룹 번호와 LACP 모드를 지정합니다. 그다음 생성된 Port-Channel 인터페이스에서 VLAN, 속도 등 나머지 설정을 합니다. 주의할 점은 물리 인터페이스에 직접 IP나 VLAN을 설정하면 안 되고, 반드시 Port-Channel 인터페이스에 설정해야 한다는 것입니다.
처음 EtherChannel을 구성할 때 가장 많이 하는 실수가 양쪽 스위치에 설정을 동시에 하지 않는 것입니다. 한쪽만 설정하고 Port-Channel이 올라오지 않는다고 당황했던 기억이 납니다. 양쪽 스위치에 거의 동시에 설정을 적용해야 하며, 특히 스위치 간 업링크 EtherChannel은 설정 순서를 잘못 하면 일시적인 루프가 생겨 네트워크 전체가 마비되는 경우도 있습니다. 실제로 운영 중인 스위치에서 EtherChannel을 재설정하다가 STP(Spanning Tree Protocol)가 루프를 감지하고 포트를 차단해버리는 상황을 겪었습니다. 30초 정도 네트워크가 끊겼는데, 그 짧은 시간에 서버 알람이 수십 개 울렸습니다. 이후로는 반드시 변경 작업을 야간 점검 시간에 하고, 롤백 절차를 미리 준비하는 습관을 갖게 됐습니다. EtherChannel 설정은 간단해 보여도 운영 환경에서는 매우 신중하게 접근해야 합니다. 특히 PAGP(시스코 독자 프로토콜)와 LACP(표준 프로토콜)를 혼용해서 설정하는 실수도 자주 보이는데, 이종 장비 간에는 반드시 표준인 LACP를 사용해야 합니다.
[시스코 스위치 LACP(EtherChannel) 설정]
# 스위치 A 설정 (GigabitEthernet 0/1, 0/2 묶기)
Switch_A(config)# interface range GigabitEthernet 0/1 - 2
Switch_A(config-if-range)# switchport mode trunk
Switch_A(config-if-range)# channel-group 1 mode active
Switch_A(config-if-range)# exit
Switch_A(config)# interface Port-channel 1
Switch_A(config-if)# switchport mode trunk
Switch_A(config-if)# switchport trunk allowed vlan all
# 스위치 B 설정
Switch_B(config)# interface range GigabitEthernet 0/1 - 2
Switch_B(config-if-range)# switchport mode trunk
Switch_B(config-if-range)# channel-group 1 mode passive
Switch_B(config-if-range)# exit
Switch_B(config)# interface Port-channel 1
Switch_B(config-if)# switchport mode trunk
# EtherChannel 상태 확인
Switch_A# show etherchannel summary
Switch_A# show etherchannel 1 detail
Switch_A# show interfaces port-channel 1
[show etherchannel summary 출력 예시]
Flags: D - down, P - bundled in port-channel
I - stand-alone, s - suspended
H - Hot-standby (LACP only)
U - in use
Group Port-channel Protocol Ports
------+-------------+----------+-----
1 Po1(SU) LACP Gi0/1(P) Gi0/2(P)
↑
P = 정상 묶임 상태
4. 리눅스 서버에서 본딩(Bonding)으로 LACP 구성하기
리눅스 서버에서는 커널 bonding 모듈을 사용해서 LACP를 구현합니다. 리눅스 bonding은 여러 가지 모드를 지원하는데, LACP와 동일한 동적 링크 집선은 mode 4(802.3ad)입니다. 그 외에도 mode 1(active-backup), mode 0(balance-rr) 등 다양한 모드가 있지만, 스위치와 표준 LACP를 맞추려면 반드시 mode 4를 사용해야 합니다.
리눅스 본딩 설정 방법은 배포판에 따라 다릅니다. 현재는 nmcli(NetworkManager CLI) 또는 systemd-networkd, 또는 직접 설정 파일을 수정하는 방법을 사용합니다. Ubuntu 20.04 이상에서는 netplan을 통해 설정하는 것이 표준적인 방법입니다.
처음 리눅스 본딩을 설정할 때 가장 헷갈렸던 부분은 스위치 설정과 맞추는 것이었습니다. 스위치 쪽에서 LACP Active로 설정했는데, 서버에서 mode 4가 아닌 mode 0으로 설정하는 바람에 스위치가 LACP 협상을 거부하고 포트를 차단해버렸습니다. 서버에서 bond0가 UP으로 보이는데 실제로 통신이 안 되는 상황이라 원인을 찾는 데 시간이 걸렸습니다. 스위치 로그를 확인하니 "LACP PDU mismatch"라는 메시지가 있었고, 서버의 본딩 모드를 4로 바꾸자마자 해결됐습니다. 이처럼 양단(서버와 스위치)의 설정이 일치해야 한다는 점이 LACP 설정에서 가장 중요합니다. 또한 리눅스에서 bonding 상태를 확인할 때 /proc/net/bonding/bond0 파일의 내용을 꼼꼼히 읽으면 각 슬레이브 인터페이스의 상태와 LACP 협상 상태를 자세히 알 수 있습니다. 현업에서는 대부분 ansible이나 puppet 같은 자동화 도구로 bonding 설정을 배포하는데, 설정 파일 한 줄이 다르면 수십 대의 서버에 동시에 문제가 생기므로 철저한 검증이 필요합니다.
[Ubuntu 리눅스 LACP 본딩 설정 - netplan 방식]
# /etc/netplan/01-netcfg.yaml
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: no
eth1:
dhcp4: no
bonds:
bond0:
interfaces: [eth0, eth1]
addresses: [192.168.1.10/24]
gateway4: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
parameters:
mode: 802.3ad ← LACP (mode 4)
lacp-rate: fast ← LACPDU 1초마다 전송
mii-monitor-interval: 100
transmit-hash-policy: layer3+4 ← IP+포트 기반 로드밸런싱
# 설정 적용
$ sudo netplan apply
# 본딩 상태 확인
$ cat /proc/net/bonding/bond0
[/proc/net/bonding/bond0 출력 예시]
Ethernet Channel Bonding Driver: v3.7.1
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
LACP Rate: fast
Aggregator selection policy (ad_select): stable
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
[CentOS/RHEL 본딩 설정 파일 방식]
# /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
TYPE=Bond
BONDING_MASTER=yes
IPADDR=192.168.1.10
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
ONBOOT=yes
BOOTPROTO=none
BONDING_OPTS="mode=4 miimon=100 lacp_rate=1 xmit_hash_policy=layer3+4"
# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
MASTER=bond0
SLAVE=yes
ONBOOT=yes
# /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
MASTER=bond0
SLAVE=yes
ONBOOT=yes
5. LACP 로드밸런싱 검증 및 장애 테스트
LACP를 구성했다고 해서 끝이 아닙니다. 실제로 트래픽이 여러 링크에 분산되고 있는지, 링크 하나가 장애 났을 때 자동으로 전환되는지 반드시 검증해야 합니다. 많은 현장에서 LACP를 설정해 놓고 실제로 로드밸런싱이 동작하는지 한 번도 확인하지 않는 경우를 봤습니다. 설정은 됐지만 로드밸런싱 알고리즘이 맞지 않아서 트래픽이 한쪽 링크에만 몰리는 상황이 의외로 자주 발생합니다.
로드밸런싱 검증 방법은 각 링크의 트래픽 사용량을 모니터링하는 것입니다. 여러 IP 간의 트래픽을 동시에 발생시킨 후, 각 물리 인터페이스의 트래픽이 고르게 분산되는지 확인합니다. 장애 테스트는 운영 환경에서 하기 전에 반드시 테스트 환경에서 먼저 진행해야 합니다. 링크 하나를 강제로 down시킨 후 트래픽이 끊기지 않고 남은 링크로 계속 흐르는지 확인합니다.
실제로 LACP 페일오버 테스트를 처음 했을 때 연결이 0.5초 정도 끊기는 것을 발견했습니다. LACP 타이머 설정이 slow(30초)로 되어 있어서 링크 장애를 감지하는 데 시간이 걸렸던 것입니다. lacp-rate를 fast(1초)로 변경하고 mii-monitor-interval도 줄이니 페일오버 시간이 거의 없어졌습니다. 이런 세부 파라미터의 중요성을 현장에서 직접 경험하면서 배웠습니다. 또한 로드밸런싱 알고리즘을 잘못 선택하면 특정 서버 간 트래픽이 항상 같은 링크로만 흐르는 문제가 생깁니다. 예를 들어 src-mac 방식은 동일 서버에서 나오는 모든 트래픽이 하나의 링크로만 가기 때문에, 서버가 몇 대 안 되는 환경에서는 로드밸런싱 효과가 거의 없습니다. src-dst-ip나 src-dst-port 방식이 실제 로드밸런싱 효과가 더 좋습니다. LACP를 구성하고 이 검증 과정을 생략하면 장애 발생 시 엄청난 혼란이 생길 수 있습니다. 반드시 테스트와 검증을 습관화해야 합니다.
[LACP 검증 명령어]
# 리눅스 - 각 슬레이브 인터페이스 트래픽 모니터링
$ watch -n 1 'cat /proc/net/dev | grep -E "eth0|eth1"'
# ifstat으로 실시간 트래픽 확인
$ ifstat -i eth0,eth1 1
# iperf3로 부하 테스트 (서버-클라이언트 간)
# 서버 측:
$ iperf3 -s
# 클라이언트 측 (여러 병렬 스트림):
$ iperf3 -c 192.168.1.10 -P 4 -t 30
# 장애 테스트 (링크 하나 강제 down)
$ sudo ip link set eth0 down
# → bond0가 eth1로만 트래픽 전환되는지 확인
$ cat /proc/net/bonding/bond0 | grep "MII Status"
# 시스코 - EtherChannel 트래픽 분산 확인
Switch# show interfaces port-channel 1
Switch# show etherchannel load-balance
Switch# test etherchannel load-balance interface port-channel 1 ip 10.0.0.1 10.0.0.2
[페일오버 시간 최적화 파라미터]
lacp-rate: fast ← LACPDU 1초마다 (slow는 30초)
mii-monitor-interval: 100 ← 100ms마다 링크 상태 확인
updelay: 200 ← 링크 UP 후 200ms 후 활성화
downdelay: 200 ← 링크 DOWN 후 200ms 후 비활성화
[이론적 대역폭 확장]
1Gbps × 2링크 = 최대 2Gbps
1Gbps × 4링크 = 최대 4Gbps
(실제는 로드밸런싱 분산도에 따라 다름)
출처 및 참고 경로
- IEEE 802.3ad LACP 표준: https://standards.ieee.org/ieee/802.3ad/1090/
- 시스코 EtherChannel 구성 가이드: Cisco EtherChannel Configuration Guide
- 리눅스 커널 본딩 문서: https://www.kernel.org/doc/Documentation/networking/bonding.txt
- Ubuntu netplan 공식 문서: https://netplan.io/reference/
- Red Hat 네트워크 팀 설정 가이드: Red Hat Docs - Network Teaming
- RFC 7424 - LACP: https://datatracker.ietf.org/doc/html/rfc7424
'IT적응기' 카테고리의 다른 글
| VPC(Virtual Private Cloud)클라우드 안에 네트워크 만드는 법! (0) | 2026.04.16 |
|---|---|
| 기초 보안의 ACL(Access Control List)로 특정 IP 차단 설정법 (0) | 2026.04.16 |
| 패킷 캡처 - 와이어샤크(Wireshark)로 L2-L3 헤더가이드 (0) | 2026.04.15 |
| ARP 테이블 분석 IP와 MAC 매칭 주소 오류를 해결 (0) | 2026.04.14 |
| 네트워크 장애 1순위 케이블 불량 포트 설정 오류 확인법 (0) | 2026.04.14 |
