데이터센터 네트워크 이중화 기술 완전 정리: Bonding부터 MC-LAG, ToR, ARP까지

🤖 AI Assisted Content
이 글은 AI(Claude, Anthropic)의 도움을 받아 작성되었습니다.
작성자가 내용을 검토하고 편집했으나, AI가 초안 작성 및 구성에 참여했음을 밝힙니다.

들어가며

네트워크 인프라를 설계하다 보면 자연스럽게 이런 질문들을 마주치게 된다.

"서버에 NIC가 두 개인데, 하나가 죽어도 서비스는 살아있어야 하지 않나?"
"스위치 자체가 다운되면 본딩이 무슨 소용이지?"
"그래서 ToR 스위치가 왜 필요한 건데?"

이 글은 그 질문들을 따라가며 Linux Bonding/Teaming, LACP, MC-LAG, ToR 스위치, 그리고 서브넷 간 ARP 동작 원리까지 데이터센터 네트워크 이중화의 핵심 개념을 한 흐름으로 정리한다.

---

1. Bonding과 Teaming — 여러 NIC를 하나의 논리 인터페이스로

왜 필요한가

서버에 물리 NIC가 한 개라면 해당 NIC나 케이블이 끊어지는 순간 서비스가 중단된다. Bonding과 Teaming은 여러 물리 NIC를 하나의 논리 인터페이스로 묶어 링크 수준의 이중화와 대역폭 향상을 동시에 제공한다.

Bonding vs Teaming

두 기술은 같은 목적이지만 구현 방식이 다르다.

항목	Bonding	Teaming
구현 위치	커널 모듈 (bonding)	커널 드라이버 + 유저스페이스 (teamd 데몬)
페일오버 속도	상대적으로 느림	빠름
유연성	낮음	높음
설정 방식	/etc/modprobe.d/, nmcli	teamd, nmcli

Bonding은 Linux 커널 2.0 시절부터 존재했고, Teaming은 이를 개선한 대안으로 등장했다. 현재도 둘 다 지원되며 RHEL 계열에서는 Teaming이 권장 방식이다.

"단일 MAC 주소"는 모드에 따라 다르다

흔히 "본딩은 단일 MAC 주소"라고 알려져 있지만, 정확히는 모드에 따라 다르다.

모드	이름	MAC 동작
mode 0	balance-rr	bond 전체 단일 MAC
mode 1	active-backup	외부엔 단일 MAC만 노출, 각 slave는 고유 MAC 유지
mode 4	802.3ad (LACP)	bond 전체 단일 MAC
mode 5/6	balance-tlb/alb	slave별 MAC 활용

💡 포인트: active-backup 모드에서 페일오버가 발생하면 새로운 active slave가 bond의 MAC 주소를 이어받고, gratuitous ARP를 전송해 상대방의 ARP 캐시를 갱신한다.

---

2. LACP와 LACPDU — 스위치와 서버가 서로를 인식하는 방법

본딩만으로는 부족한 이유

서버에서 본딩(mode 4)을 설정해도 스위치는 이 사실을 모른다. 스위치 입장에서는 그냥 여러 개의 독립된 포트로 보일 뿐이다. 스위치와 서버가 "우리 하나로 묶자"고 협상하는 프로토콜이 바로 LACP(Link Aggregation Control Protocol) 다.

LACP는 IEEE 802.3ad 표준으로 정의되어 있다.

LACPDU — 협상 메시지의 실체

LACP-enabled 인터페이스들은 LACPDU(Link Aggregation Control Protocol Data Unit) 를 주고받아 LAG(Link Aggregation Group)를 협상한다.

LACPDU에 담기는 핵심 정보:

필드	역할
System Priority	어느 쪽이 주도권을 가질지 결정
System MAC	장치 식별
Interface Priority	어떤 포트를 active로 선택할지
Interface Number	포트 번호
Key	같은 그룹으로 묶일 수 있는지 확인

LACP는 Slow Protocol 멀티캐스트 주소(01-80-C2-00-00-02)를 통해 LACPDU를 전송한다.

LACP 동작 흐름

[서버 bond0 (mode 4, 802.3ad)]         [스위치 Port Channel]
        NIC eth0 ──────────────────────── port 1
        NIC eth1 ──────────────────────── port 2

① 양쪽에서 LACPDU 전송 (priority, MAC, key 교환)
② LACPDU 비교 → 같은 그룹으로 묶을 수 있는지 협상
③ Active 인터페이스 선택 → LAG 수립
④ 이후 트래픽은 논리 링크로 분산

Active vs Passive

각 포트는 Active 또는 Passive 모드로 설정할 수 있다.

• Active: 먼저 LACPDU를 전송
• Passive: 상대방이 Active일 때만 응답

⚠️ 주의: 양쪽이 모두 Passive이면 협상이 이루어지지 않는다.

Static 본딩 대비 LACP의 장점

비교 항목	Static 본딩	LACP 본딩 (mode 4)
스위치 설정	없음 (스위치는 개별 포트로 인식)	필요 (스위치도 LACP 활성화)
링크 장애 감지	MII/ARP 모니터링	LACPDU 중단 즉시 감지
설정 오류 탐지	어려움	LACPDU 불일치 시 링크 down
표준	-	IEEE 802.3ad

---

3. MC-LAG — 스위치 장애까지 커버하는 노드 수준 이중화

LAG의 한계

LACP까지 설정해도 스위치 자체가 다운되면 연결이 끊긴다. 서버 입장에서 두 NIC를 묶어봤자 둘 다 같은 스위치에 연결되어 있다면 의미가 없다.

[기존 LAG의 한계]

서버
├── eth0 ──┐
└── eth1 ──┴── Switch A  ← Switch A 장애 → 전체 단절 💀

MC-LAG란?

MC-LAG(Multi-Chassis Link Aggregation Group) 는 LAG를 구성하는 포트들을 서로 다른 스위치(섀시)에 분산시켜 노드 수준의 이중화를 제공하는 기술이다.

          [서버]
           bond0 (mode 4, 802.3ad)
          /        \
       eth0        eth1
        |            |
   [Switch A] ── ICL ── [Switch B]
   (MC-LAG Peer)         (MC-LAG Peer)

서버 입장에서는 두 스위치가 하나의 LACP 피어로 보인다.

"하나의 스위치처럼 속이기" — 핵심 원리

서버와 LACP 협상 시 Switch A와 Switch B는 동일한 System ID를 사용한다. 서버는 자신이 두 개의 독립된 스위치와 연결되어 있다는 사실을 알지 못한다.

# 두 스위치에서 동일하게 설정해야 하는 값
lacp-key: 10
system-id: 00:00:00:12:12:12
system-priority: 32768

스위치 간 조율 — ICL과 ICCP

두 MC-LAG Peer 스위치는 ICL(Inter-Chassis Link) 로 연결되어 ICCP(Inter-Chassis Control Protocol) 를 통해 상태를 동기화한다.

ICL/ICCP 역할	내용
Keepalive	Peer 스위치 생존 확인
상태 동기화	MAC 테이블, ARP, LACP 파라미터
페일오버 조율	장애 감지 시 자동 절체

장애 시나리오

정상:
서버 → Switch A (active path), Switch B (active path, 부하 분산)

Switch A 장애 발생:
① Switch B가 LACPDU 수신 중단 감지
② ICL 통해 페일오버 트리거
③ 서버의 bond0는 Switch B로만 통신
④ 서비스 중단 없음 ✅

벤더별 구현 (모두 Proprietary)

MC-LAG는 IEEE 표준이 아니라 벤더별로 독자 구현된다.

벤더	명칭	제어 프로토콜
Cisco Nexus	vPC (virtual PortChannel)	mLACP
Juniper	MC-LAG	ICCP
Arista	MLAG	TCP 기반

---

4. ToR 스위치 — 데이터센터 랙 단위 네트워크 설계

ToR(Top of Rack)이란?

ToR 스위치는 각 서버 랙 상단에 배치되는 전용 네트워크 스위치로, 랙 내 서버들에게 직접 연결을 제공한다.

[Spine Switch 1]  [Spine Switch 2]
      ↕    ↕          ↕    ↕
[ToR/Leaf 1]      [ToR/Leaf 2]      [ToR/Leaf 3]
  (Rack 1)          (Rack 2)          (Rack 3)
  ├─ Server1         ├─ Server1        ├─ Server1
  ├─ Server2         ├─ Server2        ├─ Server2
  └─ Server3         └─ Server3        └─ Server3

현대 데이터센터의 Leaf-Spine 토폴로지에서 ToR 스위치 = Leaf 스위치 역할을 한다.

ToR 스위치의 역할

• Aggregation: 랙 내 서버 트래픽 집약
• Forwarding: 랙 내 서버 간 통신 + 상위 Spine 스위치로 업링크
• L2/L3 기능: 프레임/패킷 포워딩, VLAN, 라우팅 지원

전형적인 포트 구성:

• 다운링크 (서버 방향): 10GbE / 25GbE (48포트)
• 업링크 (Spine 방향): 40GbE / 100GbE (4~8포트)

ToR vs EoR(End of Row)

ToR의 대안으로 EoR 방식이 있다. 행(Row) 끝단의 공용 스위치에 서버들이 직접 연결되는 구조다.

항목	ToR	EoR
스위치 위치	각 랙 내부	열(Row) 끝단
케이블 길이	짧음 (1~3m)	길음
장애 영향 범위	해당 랙만	열(Row) 전체
확장성	우수	복잡

MC-LAG + ToR로 완성되는 이중화

앞서 배운 개념들이 실제로 이렇게 조합된다:

[서버]
  bond0 (LACP mode 4)
  ├── eth0 ──── ToR Switch A ──(MC-LAG Peer)──┐
  └── eth1 ──── ToR Switch B ──(MC-LAG Peer)──┘
                      ↕ ICL

• 본딩: 링크 이중화 (NIC/케이블 장애 대응)
• LACP: 스위치-서버 간 동적 협상
• MC-LAG: 스위치 장애 대응 (노드 이중화)
• ToR: 랙 단위 격리 및 독립적 확장

---

5. L2/L3 통신과 ARP — 서브넷 경계에서 무슨 일이 벌어지는가

같은 서브넷: L2 스위치만으로 통신 가능

같은 서브넷 내의 두 서버는 L3 장치 없이 L2 스위치만으로 통신할 수 있다.

[Server A: 10.0.0.1/24] ──── L2 Switch ──── [Server B: 10.0.0.2/24]

동작 순서:

1. Server A가 목적지 IP와 자신의 서브넷 마스크를 AND 연산 → 같은 네트워크 확인
2. ARP 브로드캐스트로 Server B의 MAC 주소 요청
3. Server B가 자신의 MAC으로 응답
4. L2 스위치가 MAC 테이블 기반으로 유니캐스트 전달

다른 서브넷: L3(라우터)가 반드시 필요

다른 서브넷의 서버와 통신하려면 L3 장치가 필요하다. L2 스위치가 문제가 아니라, 서버 자신이 처음부터 다른 서브넷 목적지에 ARP를 보내지 않는다.

Server A의 판단 로직:
목적지 IP(10.0.2.20) AND 서브넷마스크(/24) = 10.0.2.0
자신의 IP(10.0.1.10) AND 서브넷마스크(/24) = 10.0.1.0

→ 네트워크가 다름 → "Default GW로 보내야 해"
→ Default GW의 MAC 주소를 ARP로 요청

ARP는 외부 통신 시에도 사용된다 — 대상이 바뀔 뿐

여기서 중요한 포인트. ARP가 "내부 네트워크 전용"이라고 생각하기 쉽지만, 실제로는 외부 통신 시에도 ARP를 사용한다. 단, 대상이 다르다.

상황	ARP 대상
같은 서브넷 통신	목적지 서버의 IP
다른 서브넷 통신	Default Gateway(라우터)의 IP

L2 헤더는 홉마다 교체된다

다른 서브넷 통신 시 패킷 구조가 핵심이다.

Server A → Router 구간 프레임:
[ Dst MAC: Router MAC  | Src MAC: Server A MAC ]  ← L2 (로컬 구간)
[ Dst IP: 10.0.2.20    | Src IP: 10.0.1.10    ]  ← L3 (종단간 유지)

Router → Server B 구간 프레임:
[ Dst MAC: Server B MAC | Src MAC: Router MAC  ]  ← L2 교체됨!
[ Dst IP: 10.0.2.20     | Src IP: 10.0.1.10   ]  ← L3 유지됨

💡 핵심 원칙:

• L2 MAC 주소: 홉(Hop)마다 교체
• L3 IP 주소: 출발지~목적지까지 유지
• ARP: 각 홉에서 "다음 장치의 MAC"을 알아내는 도구로 계속 사용

Router의 역할 정리

라우터(L3 스위치)는 패킷을 받으면:

1. L2 헤더 제거
2. IP 목적지로 라우팅 테이블 조회
3. 출력 인터페이스 결정
4. 출력 인터페이스 서브넷에서 다시 ARP로 다음 장치 MAC 조회
5. 새로운 L2 헤더 부착 후 전달
6. TTL 1 감소

---

마무리

데이터센터 네트워크 이중화는 계층적으로 쌓인다.

링크 이중화    → Bonding/Teaming (NIC 여러 개를 하나로)
협상 프로토콜  → LACP/LACPDU (스위치-서버 간 동적 협상)
노드 이중화    → MC-LAG (스위치 장애까지 커버)
물리 설계      → ToR 스위치 (랙 단위 독립 구조)
통신 원리      → ARP (L2 MAC 조회, 홉마다 대상이 달라짐)

각 기술이 독립적으로 보이지만, 실제 데이터센터에서는 이 모든 것이 맞물려 하나의 고가용성 네트워크를 구성한다. 특히 LACP → MC-LAG → ToR로 이어지는 흐름을 이해하면 엔터프라이즈 네트워크 설계의 기본 뼈대가 보이기 시작한다.

---

참고 문서

• Linux Kernel Bonding Driver HOWTO
• RFC 826 — ARP
• RFC 1027 — Proxy ARP
• Juniper MC-LAG 공식 문서
• Red Hat RHEL 8 - Network Bonding