Introduction to MC-LAG

1. MC-LAG names by Vendor

• MC-LAG 기술은 표준화가 되어있지 않아 Vendor마다 부르는 명칭과 동작 방식이 상이
• 본 글은 Juniper Vendor를 기준으로 작성

Vendor	Implementation name
Juniper	MC-LAG
Nokia	MC-LAG
Alcatel-Lucent	MC-LAG
Arista	MLAG
Extreme	MLAG
Cisco Nexus	vPC(Virtual Port Channel)
Dell	vPC(Virtual Port Channel)
Brocade	Multi-Chassis Trunking
Huawei	E-Trunk

 

 

2. MC-LAG 필요성

1) LACP without MC-LAG

• Partner System-ID 값이 동일하면 LACP Member Link 들은 동일한 장비와 연결되어 있다고 판단
• Partner Admin-Key 값이 동일하면 LACP Member Link 들은 동일한 LACP Group에 속해 있다고 판단
• LACP는 Node 수준의 SPoF(Single Point of Failure)의 단점을 보유

 

2) LACP with MC-LAG

• LACP의 단점인 Node 수준의 SPoF(Single Point of Failure)를 보완하기 위해 SW1을 SW1-1 및 SW1-2 두 개로 구성하여 Node 이중화로 구성
• SW1-1 및 SW1-2에서 System-ID를 동일한 값으로 구성하여 SW2에서 LACP Memeber Link가 동일한 장비와 연결되어 있다고 판단
• SW1-1 및 SW1-2에서 Admin-Key를 동일한 값으로 구성하여 SW2에서 LACP Memeber Link가 동일한 LACP Group과 연결되어 있다고 판단

 

• SW1-1 및 SW1-2는 SW2에서 인식하는 것처럼 하나의 장비처럼 동작해야 하므로 서로 Data Traffic이 지날 수 있는 링크(ICL)를 연결

 

• SW1-1 및 SW1-2는 SW2에서 인식하는 것처럼 하나의 장비처럼 동작해야 하므로 서로 ARP 및 MAC Table을 동기화시키기 위해 링크(ICCP)를 연결
• 위 구성은 "ㄷ" 모양의 트라이앵글인 Loop 구조가 생성되는데 이는 Block Mask로 Loop을 방지

 

 

3. Introduction to MC-LAG

1) Introduction to MC-LAG

• MC-LAG Peer 란, Neighbor 장비가 아닌 MC-LAG를 구성하는 Local 장비를 의미하는 것
• 두 MC-LAG Peer에서 여러 물리적 인터페이스를 하나의 Bundle로 구성
• 두 MC-LAG Peer에 LACP에 대한 가상 System-ID와 Admin-Key를 구성하여 MC-LAG Client는 MC-LAG의 존재를 모르며 MC-LAG 장비들을 하나의 논리적 스위치로 인식
• STP를 사용하지 않고 Loop이 없는 Bridge Domain에서 이중화 및 Load Balancing을 제공
• MC-LAG Peer 장비들은 독립적인 장비이므로 별도로 관리
• 두 MC-LAG Peer가 모두 동일한 소프트웨어 버전일 때만 Protocol State, Data Forwarding, Redundancy를 보장
• MC-AE 인터페이스 Up/Down 시, Convergence Time을 개선하려면 "Enhanced Convergence"기능을 사용
• MC-LAG가 없는 일반적인 LACP(802.3ad)에서는 Master 장비가 Port Priority와 Port-ID 값을 이용하여 Active 인터페이스와 Standby 인터페이스를 결정했는데, 개인적인 생각으로 두 MC-LAG Peer 간에 Port Priority가 동일하면 Chassis-ID 및 Port-ID 값을 기준으로 Active 인터페이스와 Standby 인터페이스를 결정한다고 판단하며 이러한 개념을 Juniper Vendor에게 구두로 질문하였지만 답을 듣지 못하는 상황

 

2) MC-LAG Load Balancing

• MC-LAG Peer의 Load Balancing은 Local에서 결정되며 Link Aggregation Hashing Algorithm으로 결정

 

3) MC-LAG 장점

(1) Link Aggregation 및 LACP의 장점

• Bandwidth 증가(MC-LAG Active/Active Mode로 사용 시)
• Link 이중화
• Link 효율성 제공
• Link 장애 발생 시, 보다 빠른 Convergence Time 제공
• System-ID의 Key 값으로 LACP Remote 장비에서 물리적 구성이 잘못되었는지 확인 가능

 

(2) MC-LAG의 장점

• Link Aggregation 및 LACP의 장점을 보유
• Link Aggregation 및 LACP의 단점인 Node 수준의 SPoF(Single Point of Failure)를 보완
• Link 및 Node 장애 발생 시, 보다 빠른 Convergence Time 제공

 

 

4. MC-LAG Packet Forwarding(Block Mask)

• ICCP를 통하여 MC-LAG Peer 간에 Block Mask 정보를 교환하며 Block Mask 설정이 MC-LAG Peer 간에 동기화되어 일관된 트래픽 처리를 보장
• ICL 인터페이스에서 수신된 트래픽이 MC-AE 인터페이스로 전달되는 것을 방지하면 MC-AE 인터페이스에서 수신된 트래픽이 다른 Peer의 동일한 링크로 다시 전달되는 것을 방지
• MC-LAG Client가 두 MC-LAG Peer로부터 동일한 데이터를 여러 개 수신하는 것을 방지하기 위해 Block Mask를 사용
• Block Mask를 사용하여 ICL에서 수신한 트래픽이 MC-AE 인터페이스로 전달되는 것을 방지
• MC-LAG Peer에서 MC-AE 인터페이스의 모든 Local Member가 다운되면 해당 MC-AE 인터페이스의 Block Mask가 제거
• 빠른 Convergence Time을 달성하기 위해 MC-AE 인터페이스의 모든 Local Member가 다운된 경우, MC-LAG의 Outbound 트래픽은 Data Plane의 ICL 인터페이스로 Redirected 되어 전송

 

 

5. MC-LAG ARP and MAC Address Synchronization

1) ARP & MAC Address Learning

• ARP Learning은 ARP Request 또는 ARP Reply를 수신하고 D-MAC이 본인이고 Target IP가 본인일 때, Sender MAC과 Sender IP 정보를 ARP Table에 Learning
• MC-LAG 피어가 ARP Request를 수신하면 ICL 및 MC-AE 인터페이스로 ARP Reply를 전송하며 이와 같이 ARP Reply를 모든 인터페이스로 전송하는 이유는 ARP이기 때문이라고 Juniper Vendor로부터 구두로 답변 받은 상황
• ICL 인터페이스를 통한 Dynamic ARP Resolution(Learning) 및 MAC Address Learning 불가능
  • ICCP를 통한 ARP 및 MAC Address를 Learning한 정보가 ICL로 변경되지 않도록 하기 위한 것
  • ICL 인터페이스로 수신되는 ARP Reply는 Discard
  • 단, Remote MC-LAG 장비의 MAC Address는 ICL 인터페이스로 설치 가능
  • Ex) Remote MC-LAG Peer의 single-homed client의 MAC Address는 ICL 인터페이스에 설치 가능
• Remote MC-LAG Peer로부터 ICCP를 통해 ARP 및 MAC Address 정보가 ICL 인터페이스로 복제 가능

 

2) ARP Table Synchronization

• MC-LAG Peer가 ARP Reply를 수신하면 다른 MC-LAG Peer에게 복제하여 ARP Resolution을 동기화하여 MC-LAG Peer 간에 ARP Table 일관성을 유지
• MC-LAG Peer가 ARP Request가 아닌 ARP Reply를 수신했을 때만 ICCP를 통해 다른 MC-LAG Peer에게 복제하여 ARP Synchronization 상태를 유지
• MC-LAG Peer가 ARP Request를 수신할 경우, ICCP를 통한 ARP Synchronization이 불가
• ARP Synchronization 기능이 없는 경우, MC-LAG Peer가 ARP Request를 전송하고 다른 MC-LAG Peer가 Reply를 수신하면 ARP Resolution Failure 발생
• MC-LAG Peer 중 하나가 재시작되어 ICCP Session이 다시 연결되면 해당 MC-LAG Peer의 ARP가 동기화

 

3) MAC Address Synchronization

• MC-LAG Peer에서 MAC Address가 학습될 때마다 다른 MC-LAG Peer로 복제되어 불필요한 Flooding을 방지
• MC-LAG Peer에서 학습된 MAC Address는 다른 MC-LAG Peer의 동일한 MC-LAG에서 학습된 것과 동일하게 복제
• MC-LAG Peer의 "single-homed customer edge client"에서 학습된 MAC Address는 다른 MC-LAG Peer의 ICL 인터페이스에서 학습된 대로 복제
• IRB/RVI 인터페이스의 MAC Address가 변경되어도 GARP Request 미전송
• ICL로 수신되는 트래픽의 Source MAC Address Learning이 자동으로 비활성화
• "single-homed" 링크에서 학습된 MAC Address는 MC-LAG 링크를 멤버로 가진 모든 VLAN에 전파

 

4) ARP & MAC Address Synchronization

• MC-LAG 구성에서 일반적으로 ARP 및 MAC 테이블이 동기화된 상태를 유지하지만 특정 네트워크 조건(Link Flapping 등)에서 동기화되지 못하는 경우가 발생
• 위와 같은 특정 네트워크 조건들이 해결되는 동안 테이블이 동기화된 상태를 유지하도록 하려면, MC-LAG의 IRB 인터페이스에 "arp-l2-validate"을 설정
• ARP 및 MAC 테이블의 동기화 손실을 유발하는 문제가 발생할 때 "arp-l2-validate"을 사용
• "arp-l2-validate" 명령은 ARP 및 MAC 테이블 항목의 유효성을 확인하고 동기화되지 않을 경우, 자동으로 업데이트
• "arp-l2-validate" 명령은 규모가 큰 구성에서 성능에 영향을 미칠 수 있으므로 정상 운영 시에는 비활성화할 것을 권고