네트워크 인프라 이해하기 · 제2부 · 가까운 장비까지 데이터는 어떻게 전달될까
링크 네 개를 하나로 묶으면 개별 통신도 네 배 빨라질까
LACP가 Member를 하나의 논리 링크로 묶고 해시 결과가 통신 흐름을 배치하는 방식
여러 물리 링크를 Port-Channel 하나로 묶으면 여러 통신의 전체 트래픽을 나눠 보낼 수 있지만, 한 통신이 링크 수만큼 빨라지는 것은 아닙니다. LACP는 양쪽 포트의 조건을 확인하고 스위치는 해시 결과에 따라 각 통신 흐름을 Member Link 하나에 배치합니다. 이 글에서는 협상, 부하 분산, Member Link 장애와 카운터를 차례로 확인하며 링크가 남아 있어도 병목이 생기는 이유를 설명합니다.
여러 물리 링크를 묶으면 스위치에는 왜 하나의 논리 링크처럼 보일까↑
Link Aggregation Group은 평행한 Point-to-Point 링크를 하나의 논리 링크로 취급하게 합니다. 스위치의 STP와 MAC 학습은 보통 논리 Port-Channel을 기준으로 보고, Data Plane은 선택한 Member Link로 프레임을 내보냅니다.
이렇게 하면 링크 하나가 실패해도 남은 Member Link로 통신을 이어 갈 수 있고, 여러 통신 흐름의 전체 대역폭을 분산할 수 있습니다. 양쪽 장비와 중간 경로가 같은 논리 묶음을 이해해야 합니다.
두 스위치 사이의 1Gbps 링크 네 개를 개별 Trunk로 두면 STP는 Loop를 막기 위해 일부를 대기시킬 수 있습니다. LAG로 묶으면 상위 프로토콜은 하나의 Port-Channel을 보고, Data Plane은 네 Member 가운데 하나를 선택해 프레임을 보냅니다. 합산된 여러 통신 흐름이 최대 4Gbps에 가까운 용량을 사용할 수 있지만, 각 방향의 실제 처리량은 트래픽 분포와 장비 한계에 달려 있습니다.
물리 포트가 같은 논리 묶음에 참여하려면 속도와 이중 통신 방식, L2/L3 모드, Access·Trunk 설정과 허용 VLAN 등 주요 조건이 맞아야 합니다. 한쪽만 Port-Channel로 묶고 반대쪽은 독립 포트로 두면 루프, 프레임 중복이나 패킷 손실이 생길 수 있습니다. Stack·MLAG처럼 여러 섀시에 걸쳐 묶는 구성은 제어부와 장비 간 연결에도 의존하므로, 단일 장비의 링크 집성과 장애 조건을 구분해야 합니다.
Member는 속도, Duplex, L2/L3 Mode, VLAN 설정 등 논리 묶음 조건이 일치해야 합니다. 조건이 다른 포트를 억지로 묶으면 한 방향만 전달되거나 특정 VLAN만 누락될 수 있어 장비가 Suspended 또는 Individual 상태로 제외하기도 합니다. 설계 용량은 Member 수의 합뿐 아니라 최소 동작 링크 수와 각 링크의 실제 경로 독립성을 포함합니다.
이 절의 근거 IEEE 802.1AX-2020
LACP는 양쪽 포트가 정말 같은 논리 묶음에 속하는지 어떤 정보로 확인할까↑
LACP를 사용하는 인터페이스는 LACPDU를 교환해 System ID, Key, 포트 상태와 우선순위를 알립니다. 양쪽 정보가 맞는 링크만 Aggregation에 참여하고 실제 전달 상태로 들어갑니다.
벤더의 Active·Passive 같은 Mode 이름은 LACPDU를 먼저 보내는지에 관한 구현 설정입니다. 최소 한쪽은 협상을 시작할 수 있어야 하며, 정적 묶음은 이런 협상 없이 양쪽 구성이 맞다고 가정합니다.
각 LACPDU에는 Actor와 Partner의 System ID, 포트 ID, Key와 상태 비트가 들어갑니다. 양쪽 장비는 자신이 보낸 정보가 상대의 Partner 정보로 되돌아오는지 확인해 동일한 연결을 보고 있는지 판단합니다. 동기화된 Member가 Collecting 상태면 프레임을 수신 집합에, Distributing 상태면 송신 집합에 참여할 수 있습니다. 물리 링크 Up 상태만으로 실제 Data 전달 Member라고 판단할 수 없는 이유입니다.
한쪽 포트의 Key나 Trunk 설정이 다르면 해당 링크가 Individual 또는 Suspended 상태로 남을 수 있습니다. 이때 Port-Channel 인터페이스는 Up 상태이고 나머지 Member로 트래픽도 흐르므로 용량 감소가 눈에 잘 띄지 않을 수 있습니다. 논리 묶음 요약뿐 아니라 각 Member의 Actor·Partner 정보와 Collecting/Distributing 상태를 확인해야 합니다. Static LAG는 이런 불일치를 프로토콜로 검출하지 못하므로 변경 관리와 양쪽 설정 검증이 더 중요합니다.
논리 인터페이스가 Up 상태여도 일부 Member가 Collecting/Distributing에 참여하지 않을 수 있습니다. Actor와 Partner의 System ID·Key, Synchronization, Collecting, Distributing 상태를 Member별로 확인해야 실제 양방향 논리 묶음을 알 수 있습니다. MLAG처럼 두 물리 장비가 하나의 논리 System으로 보이는 구현은 Peer 링크와 분할 상태까지 별도 확인합니다.
이 절의 근거 IEEE 802.1AX-2020 · Cisco Layer 2 EtherChannel and Trunking
한 통신 흐름을 여러 링크에 나누지 않고 해시 결과로 Member 하나에 배치하는 이유↑
장비는 출발지·목적지 MAC, IP, TCP/UDP 포트 등 지원하는 필드를 조합해 해시를 계산하고 Member Link를 고릅니다. 같은 통신 흐름을 한 링크에 유지하면 패킷 순서가 뒤집힐 가능성을 줄일 수 있습니다.
따라서 하나의 TCP 통신 흐름은 보통 한 Member의 속도 한계를 넘지 못합니다. 여러 클라이언트·서버와 통신 흐름이 충분히 다양해야 전체 묶음의 합산 용량을 활용합니다. 실제 해시 Field와 알고리즘은 ASIC·Software·설정에 따라 다릅니다.
네 Member가 있어도 해시 결과가 단순히 통신 흐름 번호 1부터 차례로 배치되는 것은 아닙니다. 장비가 선택한 Source·Destination IP와 포트 Bit를 계산해 Bucket을 만들고 Bucket을 Member에 연결합니다. 같은 5-Tuple의 패킷은 같은 Bucket을 사용하므로 순서가 유지됩니다. 반대 방향은 반대편 장비가 독립적으로 해시하므로 요청과 응답이 반드시 같은 물리 Member를 지날 필요는 없습니다.
단일 TCP Copy가 1Gbps Member 하나를 사용 중이라면 나머지 세 링크가 비어 있어도 그 통신 흐름을 패킷 단위로 쪼개지 않는 것이 일반적입니다. 여러 TCP Connection을 만드는 File Transfer나 여러 클라이언트의 트래픽은 서로 다른 Tuple로 해시 결과에 따라 합산 용량을 활용할 수 있습니다. ASIC이 지원하는 Field와 Inner 헤더 해석 여부는 플랫폼마다 다르므로 Overlay 트래픽에서는 겉쪽 Tunnel 주소만 해시 계산에 사용해 쏠림이 생기는지도 확인합니다.
결과적으로 단일 대용량 TCP 통신 흐름의 최대 속도는 보통 Member 하나의 속도를 넘지 못합니다. 여러 사용자·세션이 서로 다른 해시 버킷에 분산될 때 논리 묶음 총 용량을 활용합니다. 장비에 따라 Resilient 해싱이나 Per-패킷 방식이 있을 수 있으므로 “EtherChannel은 항상 5-Tuple 해시”라고 단정하지 말고 실제 알고리즘과 지원 필드를 확인합니다.
이 절의 근거 IEEE 802.1AX-2020
네 링크가 모두 살아 있는데도 한 Member만 붐비는 이유는 무엇일까↑
모든 통신이 같은 서버 IP와 포트로 향하고, 해시가 이 목적지 정보만 사용하면 입력값이 같아 한 Member에 몰릴 수 있습니다. 이는 LACP 협상 실패가 아니라 트래픽 특성과 해시 결과일 수 있습니다.
인터페이스별 Byte·패킷 카운터와 통신 흐름 분포를 함께 봅니다. 해시 기준을 바꾸면 다른 트래픽에는 불리할 수 있으므로 한 번의 속도 시험만 보고 전체 정책을 바꾸지 않습니다.
백업 서버 하나로 수백 클라이언트가 접속해도 해시가 Destination MAC·IP만 사용하면 모든 통신 흐름이 같은 값으로 계산되어 한 Member에 몰릴 수 있습니다. L4 포트까지 포함하면 분포가 나아질 수 있지만 Fragment, 암호화 Tunnel과 Hardware 지원 조건에 따라 사용할 수 있는 Field가 제한됩니다. 가장 많은 트래픽을 만드는 실제 통신 흐름의 헤더 다양성을 먼저 조사해야 올바른 해시 기준을 고를 수 있습니다.
인터페이스의 평균 사용률만 보면 짧은 트래픽 집중과 특정 멤버의 큐 폐기를 놓칠 수 있습니다. 멤버별 바이트·패킷 수, 폐기·큐·오류 카운터를 같은 간격으로 수집해 Port-Channel 합계와 비교합니다. 해시를 바꾸면 기존 흐름의 전송 링크가 바뀌어 패킷 순서가 일시적으로 뒤바뀔 수 있으므로 변경 시간과 되돌릴 방법도 정해야 합니다. 트래픽을 매 순간 똑같이 나누는 것보다, 어느 흐름에 병목이 생기고 손실이 얼마나 발생하는지 확인하는 것이 중요합니다.
먼저 Member별 Byte·패킷·폐기 카운터를 같은 간격으로 측정하고, Heavy 통신 흐름의 Source/Destination과 현재 해시 입력을 확인합니다. L4 포트를 포함하도록 알고리즘을 바꾸면 분포가 개선될 수 있지만 Fragment, 암호화 Tunnel, 적은 Endpoint처럼 입력 다양성이 낮으면 효과가 제한됩니다. 변경은 기존 통신 흐름 재배치와 순서 변화 가능성을 고려해 시험합니다.
이 절의 근거 IEEE 802.1AX-2020 · Cisco Layer 2 EtherChannel and Trunking
도해에서 확인할 내용 왼쪽은 단일 통신 흐름이 한 Member Link에 배정되는 경우, 오른쪽은 여러 5-Tuple의 흐름이 Member Link에 나뉘어 배정될 수 있는 경우를 보여 줍니다. 도해의 해시 입력 설명과 버킷 배정을 비교하되, 같은 수의 버킷을 배정해도 링크별 실제 전송량은 다를 수 있다는 점을 구분합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
Member Link 하나가 끊기면 기존 통신 흐름은 남은 링크로 어떻게 옮겨 갈까↑
물리 링크가 Down 상태가 되거나 LACP가 Partner 상태를 잃으면 해당 Member를 전달 집합에서 제외합니다. 기존에 그 Member를 사용하던 통신 흐름은 남은 링크 중 하나로 다시 배치됩니다.
전환 중 일부 패킷 손실과 TCP 재전송이 생길 수 있습니다. Minimum Links를 설정한 환경에서는 남은 Member 수가 기준보다 적으면 논리 LAG 전체를 Down 상태로 전환해 상위 라우팅이나 이중화가 다른 경로를 선택하게 할 수 있습니다.
광 신호가 사라지면 물리 Layer가 빠르게 Down 상태를 알릴 수 있지만, 한 방향만 끊기거나 상대가 LACPDU를 멈춘 경우에는 LACP Timeout 뒤에 Member가 제외될 수 있습니다. 그 사이 일부 프레임이 손실될 수 있습니다. Member가 빠지면 해시 버킷이 남은 링크로 재배치되는데, 구현에 따라 많은 통신 흐름이 이동하거나 영향 Bucket만 바뀔 수 있습니다. 기존 TCP는 재전송으로 회복해도 실시간 UDP는 손실이 그대로 보입니다.
Minimum Links는 남은 용량이 서비스 요구보다 낮아졌다는 사실을 상위 프로토콜에 알리기 위한 정책입니다. 링크 네 개 중 하나만 남아도 Port-Channel을 Up 상태로 유지하면 라우팅은 계속 이 경로를 사용하고 남은 1Gbps가 과부하될 수 있습니다. 최소 두 개를 요구하면 그보다 적게 남았을 때 논리 인터페이스를 Down 상태로 전환해 다른 Route를 선택하게 할 수 있습니다. 임계값은 가용성뿐 아니라 필요한 최소 용량과 우회 경로가 감당할 수 있는 부하를 기준으로 정합니다.
min-links는 사용 가능한 멤버 수가 설정한 최솟값 아래로 내려가면 Port-Channel 전체를 Down 상태로 만들 수 있는 기능입니다. 필요한 최소 용량에 맞춰 값을 정하면 상위 경로를 다른 연결로 전환하는 데 사용할 수 있습니다. 다만 우회 경로에 충분한 용량이 있고 라우팅도 수렴해야 합니다. 멤버가 복구될 때 기존 흐름의 링크 배정이 바뀌는지는 장비와 해시 방식에 따라 다르므로, 장애 전환과 복귀를 각각 시험합니다.
이 절의 근거 IEEE 802.1AX-2020
도해에서 확인할 내용 왼쪽은 네 개의 Member Link가 동작하는 정상 상태이고, 오른쪽은 Port 4를 제외한 뒤의 버킷 배정 예시입니다. 사용 가능한 링크가 바뀌었을 때 남은 세 링크에 버킷이 어떻게 배정되는지 비교합니다. 버킷 수의 비율과 실제 전송량의 비율은 다르며, 전환 시간과 손실은 따로 시험해야 합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
Port-Channel이 Up 상태라는 표시만 보지 말고 Member별 상태와 카운터를 확인한다↑
상황: 4×1Gbps Port-Channel인데 대용량 전송 하나가 약 1Gbps를 넘지 못합니다.
- 네 Member가 모두 LACP Collecting·Distributing 상태인지 확인합니다.
- 단일 TCP 통신 흐름인지 여러 독립 통신 흐름인지 시험 조건을 구분합니다.
- 장비의 현재 해시 Field와 Member별 Byte 카운터를 확인합니다.
- 여러 Source·Destination 통신 흐름으로 전체 합산 용량을 다시 측정합니다.
- Member Link 하나를 차단해 통신 흐름 재배치와 상위 프로토콜 영향을 검증한 뒤 원복합니다.
단일 흐름과 여러 흐름은 나누어 시험합니다. TCP 연결 하나로 멤버 링크의 속도 한계와 패킷 손실을 보고, 출발지·목적지·포트가 다른 여러 흐름으로 Port-Channel 전체의 분산 상태를 측정합니다. 양쪽 장비에서 같은 시각의 멤버별 카운터와 LACP 상태도 수집합니다. 한쪽의 송신이 특정 링크에 몰렸다고 반대쪽 응답도 같은 링크를 사용할 것이라 단정할 수는 없습니다.
장애 시험에서는 멤버 링크를 하나씩 끊어 Port-Channel 상태, 흐름의 재배정, 패킷 손실과 상위 STP·라우팅 변화를 기록합니다. 설정한 최소 멤버 수보다 적게 남았을 때 백업 경로가 선택되는지, 링크를 복구하면 반복적인 연결 해제 없이 묶음에 다시 참여하는지 확인합니다. 설정을 고친 뒤에는 허용 VLAN과 MTU 등 논리 인터페이스의 설정이 모든 멤버에 일관되게 적용되었는지도 대조합니다.
포트 네 개가 모두 녹색이어도 네 링크를 전부 사용할 수 있다는 뜻은 아닙니다. 각 링크가 묶음에 정상 참여하는지, 흐름이 어떻게 나뉘는지, 장애 뒤에는 어느 링크로 전달되는지까지 확인해야 실제 사용 가능한 용량을 알 수 있습니다.
이 절의 근거 IEEE 802.1AX-2020 · Cisco Layer 2 EtherChannel and Trunking
FAQ↑
LACP와 EtherChannel은 같은 말인가요?
용어사전↑
출처와 검증
- IEEE 802.1AX-2020 — Link Aggregation 현행 표준
- Cisco Layer 2 EtherChannel and Trunking — LACP를 사용하지 않는 EtherChannel·Trunk 구성 예시
- IEEE 802.1AX-2014 Project — Link Aggregation 표준 프로젝트 정보
해시에 사용하는 필드와 멤버 수, Minimum Links 설정, 장애 전환 동작은 장비와 소프트웨어에 따라 다릅니다. 여러 링크의 대역폭을 더한 값이 한 통신의 속도가 되는 것은 아닙니다.