LACP(802.1ax) 이야기

우리가 알고있는 Network에서 사용되는 LACP(Link Aggregation Control Protocol)는 여러 물리링크를 하나의 논리적인 링크로 생성함으로써 대역폭을 증가시키고 장애 발생시 정상적인 성능 저하(fault-tolerant)를 제공하며 가용성을 증가시킨다.

자주 사용하는 LACP와 관련하여 나름대로 자세하게 분석하여보았다.

 

제목에 표준네임을 잘못 표기한 것처럼 보일 수 있는데, 잘못 표기한게 아니다.

LACP를 왜 802.3ad가 아닌 802.1ax로 표기한 이유도 본문에 적어 보았다.

 

OSI 7 Layer - Datalink

OSI 7Layer에서는 Layer 2계층에 속하며, 아래 사진처럼 Data Link sublayer인 MAC부계층 위에 위치해 있다.

 

LACP의 sublayer 포지션

LACP의 특징

 1. 대역폭 증가

 2. 2개 이상으로 구성할 경우 fault-tolerant 및 link에 대한 가용성 증가

 3. 데이터를 로드밸런싱 가능하며 hash-algorithm을 사용

 

LACP를 정상적으로 구성하기 위해서는 아래 요소들은 필수로 만족해야 한다.

 1. Point-to-Point(system-id=mac 기준)

 2. Full-Duplex

 3. 피어간 동일한 Speed

 4. 피어간 동일한 Encapsulation Type. (ex : VLAN untag / tag)

 5. UDP의 경우는 피어간 MTU 사이즈 동일. (TCP의 경우 MSS 재협상으로 가능.)

 

Etherchannel과 LACP의 가장 큰 차이점

C - A = B 라는 구성.

A와 B의 aggregation에서... C 장비의 인터페이스가 문제가 생길 경우, EtherChanel과 같은 Trunk는 잘못된 인터페이스 연결을 감지하지 못하나, LACP는 감지가 가능하다. 이 때문에, BFD를 함께 사용을 할 수 있게 된다.

 

 

LACP에 대해 좀 더 깊게 테스트하고 조사해봤다.

LACP의 LACPDU(slow)와 Multicast주소

위 이미지처럼 LACP는 LACPDU라는 데이터를 1초마다 멀티캐스트로 전송만하며, 링크 유지에 대한 메커니즘인 fast(1s)/slow(30s) 2가지를 정의한다. fast/slow 중에 어떤걸 사용하라는 표준은 없다.

1. LACPDU

   - LACP system priority
   - MAC address
   - LACP interface priority
   - interface number, and operational key.
2. LACPDU는 Multicast로 전송하며, mac주소는 01:80:c2:00:00:02 (01-80-c2-00-00-02)

3. LACPDU를 전송하는 link(interface)인 Actor와 수신만하는 Partner로 구성.

4. Active모드와 Passive모드를 선택할 수 있음.

   - Acitve mode : 포트가 나타나면 장치는 즉시 LACP 메시지 (LACP PDU)를 보냄.

   - Passive mode : 포트는 수신 한 LACP PDU에만 응답하지만 LACP 협상을 시작하지는 않음.

5. system-id는 peer간의 MAC 정보를 나타낸다.

6. BFD(Bidirectional Forwarding Detection)를 사용하면 더 빠르게 링크 오류를 감지할 수 있음. 

7. A와 B가 동일한 LACP 시스템 우선 순위를 갖는 경우, 더 작은 MAC 주소를 가진 장치가 Actor Device가 된다.

8. Actor Device를 선택한 후, 두 장치는 Actor의 Interface Priority에 따라 활성 Interface를 선택한다. Actor Device에 대한 인터페이스의 우선순위가 같을 경우, 인터페이스 번호가 작은 인터페이스가 활성 Interface로 선택된다.

 

 

 

LACP 분석

아래 이미지는 2대의 스위치를 Stack/VirtualChassis/MC-LAG 등의 기술로 서버에서 1대의 스위치로 보이게 하는 기술을 적용하여 LACP와 함께 사용할때의 예제이다. (여기선 VirtualChassis를 사용)

그림1 - 스위치와 서버 LACP 구성

그림2 - 스위치에서 LACP 상태

 

LACP 조건에 맞게 system우선순위가 높은 스위치(xe-0/0/20)가 Actor가 되었고, Partner는 서버(eno1,eno2)가 되었다.

그림3 - 서버 Bonding Mode 4(802.3ad)

만약, LACP관련하여 장애인지 확인하고 싶다면 어떻게 확인해야 될까?

1. 먼저, LACP 필수조건이 만족하는지 체크한다.

2. 일반적인 1:1 LACP에서는 그림2에서처럼 Actor와 Partner의 systemID를 정상적으로 가져오는지 확인한다. 위에 언급대로 mac주소가 systetmID가 되므로 장비의 mac주소와 일치하는지 확인해보자.

3. 만약, systemID가 00:00:00:00:00:00으로 표시된다면, 해당 표기가 된 장비의 설정(오타 등)을 체크해보고, 정상이라면 peer간 negotiation을 확인해 본다. (00은 LACPDU에 대한 협상이 되지 않았으므로)

 -> 여기서 또.. 중요한부분이 하나 있다. 이더넷 표준에서는 negotiation이 다른 경우, speed와 duplex가 변경 될 수 있다. 만약 10g인데 duplex 및 speed nego가 mismatch인 경우에는 이더넷의 하위호환성 특징이 작용하여 가장 낮은 Value를 사용하게 된다.

즉, Speed의 경우에는 100Mb/10Mb/10Mb(10g ethernet/fast ethernet/ethernet)로, Duplex의 경우에는 Half-Duplex로 잡힐 수 있다.

참고할만한 사항은 이렇게 변경되는 장비는 auto-nego가 disable상태인 장비가 아닌 enable인 peer 쪽에서 이렇게 변경된다. (en.wikipedia.org/wiki/Duplex_mismatch)

 

 

LACP Loadbalancing

LACP를 사용시에 loadbalancing이 된다고 하였는데, 리눅스 본딩을 기준으로 이야기해보자면.. 처음 본딩을 802.3ad로 셋팅할 경우 loadbalancing 기본 값은 layer2로 설정이 된다. 또한, 로드밸런싱은 다른 메커니즘들과 동일하게 전송 시에, 수행된다.

리눅스 본딩에서는 xmit_hash_policy라고 표현하며, layer2(0) / layer3+4(1) / layer2+3(2)로 설정이 가능하다.

각 의미는...

 - layer2(0) = 목적지 MAC 주소를 보고 LB를 수행한다.

 - layer3+4(1) = ip + port 2가지의 tuple 값을 보고 LB를 수행한다.

 - layer2+3(2) = mac + ip 주솔를 이용하여 LB를 수행한다.

이렇게 정의되어 있다.

 

LACP Loadbalancing CASE

만약 LACP를 layer3+4로 사용한다면.. 당연히 default인 layer2보다 Loadbalancing이 잘된다. (엄밀히 말하면 "네트워크 구성과 트래픽에 사용되는 프로토콜에 따라 다르다"가 좀 더 맞는 표현일 것 같습니다)

하지만, 여기서 주의할 사항이 있다. layer3+4는 port도 함께 보기 때문에 src-port가 동일한 TCP 세션을 이용하는 트래픽은 분산이 잘 되지 않는다.

예제를 들면.. FTP처럼 1개의 동일한 src-port로만 통신을 할 경우에는 인터페이스 별로 5:5와 가깝게 밸런싱이 되지는 않는다는 점이다.

또 재밌는게 icmp의 경우에도 마찬가지로 밸런싱이 되지 않는다.

이유는... icmp는 최초 통신에 사용된 id값을 그대로 사용하기때문에 마찬가지로 세션이 1개이므로 밸런싱이 되지 않는다.

(아래 패킷을 보면 최초 할당된 id 27583을 그대로 사용하기 때문)

 

<icmp packet>

03:18:00.559572 IP 192.168.0.18 > 1.1.1.1: ICMP echo request, id 27583, seq 0, length 64
03:18:00.576068 IP 1.1.1.1 > 192.168.0.18: ICMP echo reply, id 27583, seq 0, length 64
03:18:01.564887 IP 192.168.0.18 > 1.1.1.1: ICMP echo request, id 27583, seq 1, length 64
03:18:01.569018 IP 1.1.1.1 > 192.168.0.18: ICMP echo reply, id 27583, seq 1, length 64
03:18:02.570114 IP 192.168.0.18 > 1.1.1.1: ICMP echo request, id 27583, seq 2, length 64
03:18:02.606047 IP 1.1.1.1 > 192.168.0.18: ICMP echo reply, id 27583, seq 2, length 64

 

 

 

의문점

LACP는 2000년에 802.3ad 표준으로 최초 정의됐고, 2008년에  802.1ax로 변경되었다. 

LACP 802.3ad -> 802.1ax 개정안

 

<LACP 표준 변경 인용글>

2006년 11월 제9차 개정 프로젝트에서 특정 802.1 계층(802.1x와 같은)이 802.3 하위 계층으로 정의된 link aggregation 아래의 프로토콜 스택에 위치했다는 점.

이 불일치를 해결하기 위해 802.3ad를 802.1ax로 공식 전송이 이루어졌다고 한다. (2008년 11월 3일 AX-2008)

 

대충 802.1 계층의 일부 프로토콜들이 802.3 하위 계층에 있어서 문제가 되어서 802.1로 바꾼 것 같다.

이건 읽어도 읽어도 왜 문제가 되는지는 모르겠다... 더 deep한 영역이 있는 것 같다. 

그런데 변경되었다고는 하지만, 기술적으로는 변경된 사항이 없다. 일단 이 부분이 특이한 부분이었고, 내가 의문점을 가지는 것은 벤더사들의 LACP관련 매뉴얼이나 설정의 help부분을 봐도 802.1ax가 아닌 802.3ad로 소개를 한다는 점이다.(리눅스 본딩에서도 802.3ad로 표현되고 있다.)

2008년이면 12년이나 지났으며, 기술적으로 변동도 없는 상태인데도 글로벌 벤더사와 리눅스가 아직까지 LACP를 802.3ad로 보여주는게 왜 그런지.. 무언가가 이유가 있을 것 같은데 도무지 알 길이 없다.

(혹시, 이 글을 읽고 이 부분에 대해서 아시는 분께서는 댓글을 달아주시면 감사하겠습니다) 

 

 

참고 자료

 - www.ieee802.org/3/hssg/

 - en.wikipedia.org/wiki/Link_aggregation#802.1AX

 - en.wikipedia.org/wiki/Duplex_mismatch